Embed Notice

An #XMP2P network could be hard to get off the ground without any significant network effect at the start. But what if XMP2P users could easily join multi-user chats in the existing #XMPP network, and talk to users of existing XMPP servers?

How much work would it take to get a federated XMPP server to accept server-to-server connections from XMP2P apps?

Not much, it turns out:

1. In order to talk to an #Yggdrasil address, a federated XMPP server would need to be running Yggdrasil, in order to have its own Yggdrasil address. (It could use a 300::/8 address delegated from a router running Yggdrasil, instead of running Yggdrasil itself, but this would lose the end-to-endness of Yggdrasil's encryption.)

2. In order to accept identity assertions from XMP2P apps, a federated XMPP server would need to accept self-signed certificates, at least from Yggdrasil addresses (or accept non-TLS connections from them, since Yggdrasil has built-in end-to-end encryption).

And that's all!

In particular, the federated XMPP server does *not* need to put its Yggdrasil address in any of its DNS entries. As long as an XMP2P app can access the internet outside Yggdrasil, it can make outbound connections to the XMPP server's normal address that it advertises to the rest of the world. And the XMP2P app can, at the same time, accept inbound connections on its stable Yggdrasil address, regardless of whether it's behind CGNAT or whatever. The dialback protocol (often used to verify an XMPP server's identity when TLS identity verification isn't being used) already assumes that outbound and inbound connections might use different IP addresses, or even be on different machines.

I tested the above and confirmed it works in @prosodyim 0.12.3; I also tried it with the federated server end being on #Prosody 0.11.9, and it failed, though I'm not certain why.