Hey all, I've got a bit of an open-ended question -- I'm working on building a gateway for legacy protocols (the rocks on which many a ships have found their final resting place) specific to XMPP, and am wondering what the best JID schema might be. This will allow for running multiple gateways on the same component, so there needs to be some way of differentiating between "legacy" protocols.
Ge0rG
deuill: is there a real need for running different protocols on the same component domain?
Ge0rG
There is https://xmpp.org/extensions/xep-0106.html but it has mixed client support
deuill
Mainly ease-of-deployment and other such operational concerns -- I don't want to have to deploy multiple versions of essentially the same binary just to get separate components.
lovetoxhas left
Ge0rG
my gut feeling is that having one domain per legacy protocol would be the cleaner design, probably at least with dedicated config files
deuill
Well, that's not 100% true -- I can have the same deployment bind/be exposed on separate DNS domains, which might do the trick.
Ge0rG
deuill: does it have to be reachable via s2s?
Ge0rG
a component will be running behind an xmpp server anyway, and you can use SRV records to reach all the domains on one IP/actual hostname
deuill
For my uses, it would be a component running somewhere locally (resolvable only by the XMPP server)
Ge0rG
in that case you don't need anything but local TCP ports
jubalhhas left
deuill
Indeed yeah, though you would need DNS/host entries for this kind of multi-domain approach.
Laurahas left
deuill
(I'm running stuff under Podman, which does DNS resolution for containers joined in the same network, but which makes adding arbitrary network aliases somewhat harder)
debaclehas left
lovetoxhas joined
deuill
There's basically three reasonable choices, in my mind:
- Use a separate domain part for each protocol, and use the local part for the "legacy" protocol user name, e.g. `someuser@skype.gateway.example.com`.
- Use the same domain part, but splice "legacy" network and user names in the local part, e.g. `someuser%skype@gateway.example.com`
- Use the same domain part, set the local part to the "legacy" network name, and use the resource part for the user name, e.g. `skype@gateway.example.com/someuser`.
deuill
For me, the latter of the three is cleaner since you mostly don't need JID escaping, and it makes operationalization somewhat simpler -- however I'm wondering if this is abuse of the resource part that might end up causing issues?
amee2khas left
Ge0rG
deuill: you don't need any DNS for only-locally-reachable components, see eg. https://prosody.im/doc/components
Ge0rG&
amee2khas joined
suohuahas joined
deuill
Hmmm the main issue with using SRV records, in my case, is that components are registered against Prosody automatically as they come up (and using the hostnames Podman gives you works automatically). This is sort of a tangent, however, and likely specific to how I've got Prosody set up.
MattJ
deuill, also I didn't see this pointed out yet, but one binary can still serve multiple domains
MattJ
One process, even
Dele Olajidehas left
PapaTutuWawahas joined
Dele Olajidehas joined
deuill
This would depend on the domain part of the JID resolving to the same host, right? Which means you either need SRV records to that effect, or (local) DNS should resolve correctly.
deuill
Apart from JID escaping concerns with using the local part for the legacy username, I think the separate domain part setup looks cleaner, though having to wrangle with DNS is definitely not the favourite part of my day...
Zash
Bit late but it would have been nice if addressing used URIs
deuill
Like, a hierarchical scheme?
Zash
Like `<message to="mailto:whoever@example.com"/>`
deuill
Ah where the legacy protocol is part of the URI scheme
deuill
Yeah that'd be cool as well.
MattJ
deuill, also note that the DNS part is only needed if you want to serve the gateways to users on other servers. Which is sometimes the case, but often not.
Anton L. Šijanechas left
Anton L. Šijanechas joined
deuill
Oh, wait, I think I've misunderstood how this works -- the XMPP server knows to route traffic to a specific component by domain part because of how components register against the XMPP server -- the domain part doesn't have to be a valid, resolvable DNS name from the perspective of the XMPP server, right?
MattJ
Correct
deuill
Then the subdomain scheme is viable, though I still don't like needing to potentially escape legacy usernames in the local part...
marchas joined
deuill
Using the resource part feels... risky, though, as my impression is that it's typically expected that you can message a bare JID across resources and get a reasonable result.
Matrix Traveler (bot)has left
homebeachhas left
homebeachhas joined
Matrix Traveler (bot)has joined
MattJ
You can't subscribe to the presence of full JIDs, which limits the usefulness of using the resource to identify users
MattJ
If someone added that JID to their roster, the subscribe would go to the bare JID
MattJ
and if multiple resources responded as online, they would be shown as a single contact in clients
MattJ
So it's definitely going against the way things would be expected to work
nikhas left
nikhas joined
deuill
That's great context, thanks Matt! Reading the JID RFC made it look like a viable option (as far as not bending semantics goes), but it's great to have confirmation of the gut feeling here.
Wojtekhas joined
MattJ
JID escaping should be performed, ideally, automatically by clients. The gateway can also offer a helper protocol to perform JID translation: https://xmpp.org/extensions/xep-0100.html#addressing-iqgateway
MattJ
(you can probably ignore most of the rest of XEP-0100 though)
deuill
Hmmm *that's* what Ge0rG meant -- apologies for misreading that.
suohuahas left
goffihas left
antranigvhas left
antranigvhas joined
goffihas joined
Stefanhas left
southerntofuhas left
southerntofuhas joined
antranigvhas left
Laurahas joined
Mx2has joined
Mx2
Its possible that a client in an open muc get stanzas to send the complete contact list?
Mx2
To anyone who make the request?
Mx2
(If the server just relay data or does some processing, or its client related)
jonas’
I don't understand the question
Mx2
What exactly
Mx2
I am in an open muc
goffihas left
goffihas joined
Mx2
And send XML commands to someone else, to get information about his client
Mx2
Is the server involved or just relays the stream?
amee2khas left
amee2khas joined
Zash
Servers relay stanzas.
Stefanhas joined
Alexhas left
Dele Olajidehas left
Dele Olajidehas joined
goffihas left
Alexhas joined
amee2khas left
Alexhas left
Alexhas joined
PapaTutuWawahas left
Mx2
Even malformed?
pasdesushihas left
flow
depends on the kind fo malformedness
flow
and on the server
pep.
`skype@gateway/user` will only appear as one participant in MUC (single barejid) and you'll have a hard time talking to fulljids in 1:1 with popular clients, most address only the barejid nowadays.
antranigvhas joined
pep.
(Catching up on logs)
jeronathhas left
jeronathhas joined
debaclehas joined
antranigvhas left
antranigvhas joined
norayrhas joined
nikhas left
nikhas joined
antranigvhas left
antranigvhas joined
antranigvhas left
antranigvhas joined
Matrix Traveler (bot)has left
homebeachhas left
homebeachhas joined
Matrix Traveler (bot)has joined
norayrhas left
norayrhas joined
deuill
Indeed yeah, I think the way I'll go is protocol name is in the domain-part, and legacy username is in the local part, and maybe if there's multiple dimensions to care about (such as IRC server) I'll do as biboumi does and either use an allowed character (such as `%`) or just rely on JID escaping.
jubalhhas joined
xnamedhas joined
deuill
Another semi-relevant question: assuming a VirtualHost of `example.chat`, service discovery only works automatically for components that are direct subdomains, e.g. `irc.example.chat`, but not anything under that, e.g. `irc.gateway.example.chat`, right?
deuill
Not sure if the behaviour here is server-specific, but I'm on Prosody 0.12 if that counts.
Zash
Server-specific
Zash
Nothing stops the server from adding whatever items it wishes to the listing it returns to the client.
deuill
Indeed yeah, I'm trying to think which JID schema helps with operationalizing this without too much faff
deuill
As the component needs to parse the domain part somehow to derive the legacy protocol name
nikhas left
deuill
So whatever is commonly accepted use-case (and it seems that components that are direct subdomains is one of these things) would probably be the best way to go
deuill
I'll pick this thread up in the Prosody room and read ejabberd docs