Comment by unicornporn | Hacker News Reader

Comment by unicornporn | Hacker News Reader

Parent Full thread

> isn't it possible to just revive XMPP?

Please no. XMPP has adapted over time to support various chat and instant messaging features that we today take for granted. These adaptions come in the form of Extensions[1]. A year ago I spent about two hours with a geek friend to configure something that resembles what we get from any other instant messenger today. That's not acceptable to the outside world.

Meanwhile, Matrix just worked. Granted, UX involved with the key management associated with E2EE was not what it should have been. But, that has largely been fixed in v1.0.

Funny thing, Matrix is still struggling (like every other federated network) to explain the concept of federation. People may have grasped email, but for some reason it seems hard to translate that knowledge to other federated technologies.

To suggest that we should just go back to XMPP seems like insanity to me. Matrix stands a chance. It's freaking wonderful!

[1] https://xmpp.org/extensions/

> Funny thing, Matrix is still struggling (like every other federated network) to explain the concept of federation.

Are there any data on how federated is Matrix? I mean number of users on different servers.

From my experience most of people are on matrix.org server and even if they run their own homeservers the identity server is still vector.im.

From memory, about 50% of the users visible in Matrix are on the matrix.org server, which is one of about 30K deployments total that we're aware of, directly or indirectly. This will likely change in the near future as the French deployment expands, which should dwarf the matrix.org server. In the medium/long term, we'd like to at least disable registration on the matrix.org server if not turn it off entirely (once decentralised accounts land).

The identity server is used ONLY for mapping email addresses and phone numbers to matrix IDs, and is strictly optional, so I'm not sure it counts as centralisation. We are also hoping to remove it entirely from the mix in future (switching to storing 3pid->mxid mappings per room instead).

Thanks for your post. I've been wondering about federation distribution in various protocols since seeing similar stats for Mastodon [0]. Having federated protocol where vast majority of users still use one server is sub-optimal IMHO (this is not only for Matrix).

[0]: https://rosenzweig.io/blog/the-federation-fallacy.html

As for identity server, it was just surprising for me (from user's perspective) that when my friends ran a homeserver I still needed a lot of config on Riot for Android to connect to (homeserver URL, identity server URL). I've seen some well-known URIs [1] but sadly Riot for Android did not query them for my e-mail.

[1]: https://f-droid.org/.well-known/matrix/client

Thanks for your work on Matrix, glad that you guys are pushing the boundaries of UX of open-source software!

the mobile clients lagged a bit on .well-known support, but it landed over the last few weeks: https://github.com/matrix-org/matrix-ios-sdk/pull/644 and https://github.com/matrix-org/matrix-android-sdk/pull/436. Hopefully this should improve things a bunch.

For 'the federation fallacy' thing: our approach is to first decentralise accounts (so you can transparently move them between servers), at which we can turn off matrix.org (or at least disable signup) assuming there are enough other quality public servers available to incorporate the resulting diaspora. In the longer term, we want to enable P2P in Matrix so you don't even need a server at all if you don't want it, at which point the federation fallacy argument entirely falls apart :)

and thanks for the thanks! :)

Doing the same for XMPP: http://upload.zinid.ru/xep-eax-cir.html

Let's compete.

Reply on news.ycombinator.com