jdev - 2022-05-12

larma: I think I will be there.

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.

deuill: is there a real need for running different protocols on the same component domain?

There is https://xmpp.org/extensions/xep-0106.html but it has mixed client support

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.

my gut feeling is that having one domain per legacy protocol would be the cleaner design, probably at least with dedicated config files

Well, that's not 100% true -- I can have the same deployment bind/be exposed on separate DNS domains, which might do the trick.

deuill: does it have to be reachable via s2s?

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

For my uses, it would be a component running somewhere locally (resolvable only by the XMPP server)

in that case you don't need anything but local TCP ports

Indeed yeah, though you would need DNS/host entries for this kind of multi-domain approach.

(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)

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`.

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?

deuill: you don't need any DNS for only-locally-reachable components, see eg. https://prosody.im/doc/components

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.

deuill, also I didn't see this pointed out yet, but one binary can still serve multiple domains

One process, even

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.

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...

Bit late but it would have been nice if addressing used URIs

Like, a hierarchical scheme?

Like `<message to="mailto:whoever@example.com"/>`

Ah where the legacy protocol is part of the URI scheme

Yeah that'd be cool as well.

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.

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?

Correct

Then the subdomain scheme is viable, though I still don't like needing to potentially escape legacy usernames in the local part...

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.

You can't subscribe to the presence of full JIDs, which limits the usefulness of using the resource to identify users

If someone added that JID to their roster, the subscribe would go to the bare JID

and if multiple resources responded as online, they would be shown as a single contact in clients

So it's definitely going against the way things would be expected to work

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.

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

(you can probably ignore most of the rest of XEP-0100 though)

Hmmm *that's* what Ge0rG meant -- apologies for misreading that.

Its possible that a client in an open muc get stanzas to send the complete contact list?

To anyone who make the request?

(If the server just relay data or does some processing, or its client related)

I don't understand the question

What exactly

I am in an open muc

And send XML commands to someone else, to get information about his client

Is the server involved or just relays the stream?

Servers relay stanzas.

Even malformed?

depends on the kind fo malformedness

and on the server

`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.

(Catching up on logs)

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.

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?

Not sure if the behaviour here is server-specific, but I'm on Prosody 0.12 if that counts.

Server-specific

Nothing stops the server from adding whatever items it wishes to the listing it returns to the client.

Indeed yeah, I'm trying to think which JID schema helps with operationalizing this without too much faff

As the component needs to parse the domain part somehow to derive the legacy protocol name

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

I'll pick this thread up in the Prosody room and read ejabberd docs