Notices by Tim Makarios (tmakarios@theres.life)

@rose_myrtle
Looks approximately correct, according to this: https://ourworldindata.org/extreme-poverty-in-brief

@rose_myrtle
Piles of stuff on my desk...

My email inbox can end up a bit like that, too, though less physical.

@fuat2mb
Yes, Conversations can definitely do video calls (at least one-to-one), and @monocles is a fork of Conversations, so I guess that should work, too. If you're looking for a server that supports video calls, https://compliance.conversations.im/ might help you find one. I think XEP-0215 (discovery, particularly of STUN and TURN services) is the one you want for video calls. I'm not sure whether the clients can do video calls even without STUN or TURN if they have IPv6 addresses (for example, Yggdrasil addresses); that's something I haven't tested yet.

I think some clients, such as @dino, have some support for multi-party video calls, but that's another thing I haven't tried out yet.

@fuat2mb
Well, I don't know about "market" relevance, but for me, #XMPP is how I chat with friends and family. @prosodyim's suite of "invites" modules has been hugely helpful in getting people signed up with accounts, even those with old phones and no special technical skills.

But an all-in-one #XMP2P app might make it even easier to get people using it, and wouldn't require anyone to be a server administrator.

I guess, in cases like mine, the network effect hasn't been particularly relevant, except within my circles of family and friends. But I do occasionally participate in public channels, or chat with people I've never met.

Apparently those hashtags in the content warning didn't work. See above if you're interested in #P2P #XMPP over #yggdrasil.

I might write more about this next week.

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.

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.

I like XMPP, and I also like #peerToPeer things. So why not both at once?

Yggdrasil gives you a stable IP address, and it turns out that the domain part of an XMPP address can be just a [bracketed] IPv6 address, meaning you can have a stable XMPP address, without buying DNS entries, regardless of whether or how often you change how you're connected to the internet.

As an experiment, I tried setting up #Prosody to run on such an address, on my desktop and on my phone. And it worked!

All I needed to change in the default configuration file was the VirtualHost line and the s2s_secure_auth line (setting it to false, so that they would accept each others' self-signed certificates, which is ok, because yggdrasil takes care of the end-to-end authentication and encryption). I also had to persuade each operating system that its own self-signed certificate was legit, so that #Dino on the same machine would be willing to accept it, to sign me in.

And with that, I could send myself peer-to-peer XMPP messages, and it carried on working seamlessly even when I switched my phone's WiFi off, leaving it to connect via its mobile data connection, which is a #CGNAT IPv4 address.

Having seen #libp2p try and not yet succeed in CGNAT holepunching, I'm really impressed by how easy it was to get yggdrasil to make the CGNAT barrier effectively disappear.

Cc: @neilalexander, @prosodyim @dino