@prosodyim
As a demonstration, there is now an #XMPP channel that you can join from a traditional federated XMPP account, or from an #Yggdradsil #XMP2P setup, as described above: xmpp:[email protected]?join

If you're joining from an XMP2P setup, you'll still need to be able to make outbound connections to public IPv4 addresses; one day I may give the server a globally reachable non-Yggdrasil IPv6 address, but it will not be this day.

(The delay in making this announcement wasn't because setting up the server was particularly difficult; it was about as easy as anticipated above, but I've had other things to do.)

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.

@arcanicanis
I hadn't noticed XEP-0174; thanks for pointing it out!

Yes, I think QR (or Aztec) codes would be good for a purpose-built #XMP2P client, as well as the ability to easily share the address via another text messaging service.

On the other hand, I might write more about it today. (The weekend wasn't as close as I thought when I wrote that.)

The best #peerToPeer systems allow ordinary people to use them without having to rely on a system administrator, or be one themself. What I described above clearly isn't that kind of #P2P system.

But it is a proof-of-concept demonstration, and I'm sure it would be possible to bundle an #XMPP server with its own internal #yggdrasil component, like @neilalexander's #yggmail does for email.

There's something to be said for the way yggmail lets you use your favourite email client, and that could be one way to go for peer-to-peer XMPP, but another alternative would be to bundle the relevant parts of an XMPP client in there, too (so it doesn't need to worry about client-to-server communication), resulting in an an all-in-one #XMP2P app that anyone could use.

Next time, I might talk about interoperability with the existing federated XMPP network.