-
Stefan
larma: I think I will be there.
-
deuill
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.
-
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
-
deuill
Indeed yeah, though you would need DNS/host entries for this kind of multi-domain approach.
-
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)
-
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?
-
Ge0rG
deuill: you don't need any DNS for only-locally-reachable components, see eg. https://prosody.im/doc/components
- Ge0rG &
-
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
-
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.
-
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...
-
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.
-
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
-
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.
-
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.
-
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
-
Mx2
And send XML commands to someone else, to get information about his client
-
Mx2
Is the server involved or just relays the stream?
-
Zash
Servers relay stanzas.
-
Mx2
Even malformed?
-
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.
-
pep.
(Catching up on logs)
-
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.
-
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
-
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