Modern XMPP project discussion - 2026-02-08

Good day, what's the state of discourse around jid aliasing? With email, it's trivial to hand out dozens of unique addresses that all route to a single inbox and in turn can be messaged from (inbound and outbound).

With email, nothing breaks if you reply from a different address, in XMPP, everything breaks :)

While I like having 2-3 jids for some segregation, I have a handful of domains for the same purpose.

We just create unlimited accounts 🙂

> With email, nothing breaks if you reply from a different address, in XMPP, everything breaks :) Yes, it's a problem if protocol, right? Is that very different from email though actually? ↺

Various layers of email stack handle aliasing rather than the protocol

As menel says, you can do it by having multiple accounts just fine.

Then it becomes an UX issue rather than a protocol issue.

Haven't heard any discussion about this recently, anyway.

I wonder if some server side rewrite module could work. Possibly controlled by adhoc commands. Where one specified what should rewrite to what jid.

Since things generally expect replies/responses to have mirrored to/from, what you end up needing is essentially NAT, and nobody wants to build that.

Or, a jabber-to-jabber bridge/gateway :)

Not sure how to reconcile that with E2EE, much easier to just focus on better multi-account UX. (because I'm a server dev so nothing for me to do then)

Mod firewall, if from jid1 to jid_ext then replace it with "from jid2" And if from jid_ext to jid2 then replace "to" to jid1

😬

> Not sure how to reconcile that with E2EE, much easier to just focus on better multi-account UX. (because I'm a server dev so nothing for me to do then) Yeah. But in the end this is just putting virtual clients into the server, we could also just use multible clients in an end-device. ↺

There did exist a J2J bridge once, I think you could do it with Spectrum as well?

Then it's not directly in the server, but still a server-side virtual client for each account.

I see the complexity and appreciate the ideation. What triggered the question is portability. As a selfhoster, is my current domain the one I want to hand out a year from now or do I have a better domain and when I inevitably switch, how will I continue to be reachable from all of my contacts?

And I'm thinking in a world where a significant portion of my address book overlaps with my roster rather than xmpp just being a niche comms rail

(so hundreds of contacts)

With email it's a matter of DNS records and mail server configuration to change my canonical address

i think j2j bridge is the right approach for protocols with static identifiers

There's been some work on account portability, e.g. import/export and tools that tell your contacts "here's my new address" for semi-automatic migrations

https://docs.modernxmpp.org/projects/portability/

> With email it's a matter of DNS records and mail server configuration to change my canonical address with xmpp you'd need to create certs for the old domain so theres that overhead taken place ↺

>> With email it's a matter of DNS records and mail server configuration to change my canonical address > > with xmpp you'd need to create certs for the old domain so theres that overhead taken place Trivial for a reverse proxy self hoster, same concern for email ↺

curiouser, that’s exactly why you ideally should have your JID at a domain you own, so that if you decide to switch providers you can just CNAME to the new one and get them to import your data.

If you rely on other people’s domains, the day they decide to stop operating their service you will have to tell your contacts you moved to a new address, be it XMPP or email.

> CNAME SRV 😭

Zash, SRV doesn’t allow the provider to get a certificate for your domain, nor to host file uploads over HTTP. ✏

:(

Uploads don't need to be on the same domain tho. Dialback still works for s2s. Conversations does that thing where you host a JSON file that overrides certificate stuff...

I would like to see more DNSSEC & DANE, if the current trend continues towards certificates unavailable for XMPP usages