4 ms·

This seems like an even better use of a state-synchronization protocol like Matrix than instant messaging, for which I think XMPP is a better fit.

by zaik 6y ago

177tcca 6y ago
It's not meant to be any one thing. That's its strength. Core to many usecases, many eyes, many industries' backing.
- southerntofu 6y ago
  > It's not meant to be any one thing. Well more so than other federated protocols. matrix has a strong emphasis on resistance to censorship and network splits, at the price of metadata leakage. In contrast, AP/XMPP assume every server is a tiny kingdom (no content is owned by more than one server). matrix usecase is really cool but could have been built on top of existing federated protocols without reinventing a new ecosystem. Can't wait for proper interoperability between the three big federated networks (Matrix, XMPP, ActivityPub). The previous discussion on HN about this topic didn't go very far: https://news.ycombinator.com/item?id=26279906 https://news.ycombinator.com/item?id=26279906
  - 177tcca 6y ago
    There are already frameworks and services for making chatrooms and comments with Matrix protocol for using in centralized and decentralized webpages — why someone would want to hack XMPP into there, besides loyalty and familiarity, is beyond me.
    - southerntofu 6y ago
      My point was not that a commenting system should be implemented using this or that protocol (though it's likely just as easy using established AP or web<->XMPP frameworks). In fact, i believe a public commenting system is a very valid usecase of matrix's censorship-resilient decentralized rooms even though i'm not entirely sure of the consequences of that in terms of moderation/spam. I was reacting to matrix being "not meant to be any one thing". I explicitly recall matrix being marketed by the community (maybe not the devs themselves) as a modern, censorship-resilient IRC replacement that fitted in a short (single?) specification and intentionally avoided the extensibility (and associated implementation/interop failures) of the XMPP protocol. When i say matrix is a more specific use-case than other federated protocols, i mean that decentralized rooms can be implemented as a consensus-reaching algorithm on top of any federated protocol, and that's in fact what matrix servers are doing under the hood. But supporting the usecase of least-metadata-leakage in a protocol designed for sharing state across many actors is arguably trickier. For example, i believe matrix doesn't currently support per-room nicknames which don't reveal your public address to all members of the room (only to chatroom admins for ban purposes). matrix has very interesting developments with or without this specific feature, but i was highlighting that matrix is not more generic/agnostic than other federation protocols (just like XMPP isn't a "universal" protocol either). Like i'm very interested in matrix P2P ecosystem there's some really amazing stuff being developed there (pinecone), but i must say the entire matrix selling pitch is very similar to the selling pitch of XMPP more than a decade ago: "a universal bridgeable messenger". Regarding the P2P example, XMPP had offline-first "zeroconf" federation (XEP-0174) drafted in 2006. Despite being far less advanced than modern matrix P2P, it was already very similar in spirit. So my central point i guess, is not that one protocol is better than the other. They all have very strong pros and cons depending on the actual usecase. Different users, or same users across different contexts/activities may prefer one technology or the other. My point is i believe it is our responsibility as technologists to ease their life and standardize things for more interoperability so users can have a choice between "the federated networks" and "centralized silos" instead of having a choice between "centralized silos" and "tiny federated islands that mostly don't talk to one another", adjusting the balance of power in our favor which is in the direct interest of everyone involved except the corporate silicon valley sociopaths. Cory Doctorow's latest talks have pretty compelling arguments for interoperability if you have some time to spare.
imwillofficial 6y ago
XMPP has been effectively dead for awhile. Time to move on.
- MattJ100 6y ago
  And you're basing this on what? I do concede that XMPP is not the new shiny, but it is very far from dead. It powers more things than you realise, a few are listed at https://xmpp.org/uses/ https://xmpp.org/uses/ There is healthy growth in server count: https://blog.prosody.im/2020-retrospective/ https://blog.prosody.im/2020-retrospective/ Development is very active, across a diverse range of projects: https://xmpp.org/category/newsletter.html https://xmpp.org/category/newsletter.html
  - imwillofficial 6y ago
    Whoa I had no idea! Thanks for sharing!
- southerntofu 6y ago
  Jabber/XMPP ecosystem is far from dead. If anything, my perspective as an end-user for quite a long time is there's been more community-oriented developments in the past few years, than in the entire previous decade. Some clients/servers are unfortunately unmaintained and the XMPP Standards Foundation has a neutral position which prevents it from advertising specific clients which have good UX and modern features. But modern clients like Conversations, Dino, Siskin and Gajim are certainly good messengers with hardware and feature support i haven't seen in other ecosystems (client & server side low resource requirements, good Tor support client, and vast plugin ecosystems) though there's some dearly-missed functionality (eg. groups of chatrooms like matrix spaces). If you're curious about interesting developments, libervia (ex salut-à-toi) is the only federated piece of software i know that is selfhosting its own development (forge). Tickets and merge requests for libervia are done via libervia itself. They've been doing that for almost 3 years now, using mercurial as a backend but implemented in a way that other DVCS backends can be supported. See my blogpost about decentralized forging for more context on that https://staticadventures.netlib.re/blog/decentralized-forge/ https://staticadventures.netlib.re/blog/decentralized-forge/

This seems like an even better use of a state-synchronization protocol like Matrix than instant messaging, for which I think XMPP is a better fit.

by zaik 6y ago

This seems like an even better use of a state-synchronization protocol like Matrix than instant messaging, for which I think XMPP is a better fit.

177tcca 6y ago

It's not meant to be any one thing. That's its strength. Core to many usecases, many eyes, many industries' backing.

southerntofu 6y ago
> It's not meant to be any one thing. Well more so than other federated protocols. matrix has a strong emphasis on resistance to censorship and network splits, at the price of metadata leakage. In contrast, AP/XMPP assume every server is a tiny kingdom (no content is owned by more than one server). matrix usecase is really cool but could have been built on top of existing federated protocols without reinventing a new ecosystem. Can't wait for proper interoperability between the three big federated networks (Matrix, XMPP, ActivityPub). The previous discussion on HN about this topic didn't go very far: https://news.ycombinator.com/item?id=26279906 https://news.ycombinator.com/item?id=26279906
- 177tcca 6y ago
  There are already frameworks and services for making chatrooms and comments with Matrix protocol for using in centralized and decentralized webpages — why someone would want to hack XMPP into there, besides loyalty and familiarity, is beyond me.
  - southerntofu 6y ago
    My point was not that a commenting system should be implemented using this or that protocol (though it's likely just as easy using established AP or web<->XMPP frameworks). In fact, i believe a public commenting system is a very valid usecase of matrix's censorship-resilient decentralized rooms even though i'm not entirely sure of the consequences of that in terms of moderation/spam. I was reacting to matrix being "not meant to be any one thing". I explicitly recall matrix being marketed by the community (maybe not the devs themselves) as a modern, censorship-resilient IRC replacement that fitted in a short (single?) specification and intentionally avoided the extensibility (and associated implementation/interop failures) of the XMPP protocol. When i say matrix is a more specific use-case than other federated protocols, i mean that decentralized rooms can be implemented as a consensus-reaching algorithm on top of any federated protocol, and that's in fact what matrix servers are doing under the hood. But supporting the usecase of least-metadata-leakage in a protocol designed for sharing state across many actors is arguably trickier. For example, i believe matrix doesn't currently support per-room nicknames which don't reveal your public address to all members of the room (only to chatroom admins for ban purposes). matrix has very interesting developments with or without this specific feature, but i was highlighting that matrix is not more generic/agnostic than other federation protocols (just like XMPP isn't a "universal" protocol either). Like i'm very interested in matrix P2P ecosystem there's some really amazing stuff being developed there (pinecone), but i must say the entire matrix selling pitch is very similar to the selling pitch of XMPP more than a decade ago: "a universal bridgeable messenger". Regarding the P2P example, XMPP had offline-first "zeroconf" federation (XEP-0174) drafted in 2006. Despite being far less advanced than modern matrix P2P, it was already very similar in spirit. So my central point i guess, is not that one protocol is better than the other. They all have very strong pros and cons depending on the actual usecase. Different users, or same users across different contexts/activities may prefer one technology or the other. My point is i believe it is our responsibility as technologists to ease their life and standardize things for more interoperability so users can have a choice between "the federated networks" and "centralized silos" instead of having a choice between "centralized silos" and "tiny federated islands that mostly don't talk to one another", adjusting the balance of power in our favor which is in the direct interest of everyone involved except the corporate silicon valley sociopaths. Cory Doctorow's latest talks have pretty compelling arguments for interoperability if you have some time to spare.

imwillofficial 6y ago

XMPP has been effectively dead for awhile. Time to move on.

MattJ100 6y ago
And you're basing this on what? I do concede that XMPP is not the new shiny, but it is very far from dead. It powers more things than you realise, a few are listed at https://xmpp.org/uses/ https://xmpp.org/uses/ There is healthy growth in server count: https://blog.prosody.im/2020-retrospective/ https://blog.prosody.im/2020-retrospective/ Development is very active, across a diverse range of projects: https://xmpp.org/category/newsletter.html https://xmpp.org/category/newsletter.html
- imwillofficial 6y ago
  Whoa I had no idea! Thanks for sharing!
southerntofu 6y ago
Jabber/XMPP ecosystem is far from dead. If anything, my perspective as an end-user for quite a long time is there's been more community-oriented developments in the past few years, than in the entire previous decade. Some clients/servers are unfortunately unmaintained and the XMPP Standards Foundation has a neutral position which prevents it from advertising specific clients which have good UX and modern features. But modern clients like Conversations, Dino, Siskin and Gajim are certainly good messengers with hardware and feature support i haven't seen in other ecosystems (client & server side low resource requirements, good Tor support client, and vast plugin ecosystems) though there's some dearly-missed functionality (eg. groups of chatrooms like matrix spaces). If you're curious about interesting developments, libervia (ex salut-à-toi) is the only federated piece of software i know that is selfhosting its own development (forge). Tickets and merge requests for libervia are done via libervia itself. They've been doing that for almost 3 years now, using mercurial as a backend but implemented in a way that other DVCS backends can be supported. See my blogpost about decentralized forging for more context on that https://staticadventures.netlib.re/blog/decentralized-forge/ https://staticadventures.netlib.re/blog/decentralized-forge/