@kaniini people have an unhealthy fetish for federation-at-all-costs, and think that XMPP is the perfect solution for that.
@kaniini yeah but that doesn't mean xmpp is the right solution, they just see "federated" on the xmpp marketing page and smash like and subscribe
fuchsiaaaaaaaaaaaaaaaaa
@f0x @kaniini that xmpp is a bad design?
XML is pretty heavy and expensive to decode compared to other serialisation protocols. Additionally, the idea of XEPs was a pretty bad idea, as it meant that important features had to be painted in after earlier parts were set in stone, often at the expense of better whole-system design.
XEPs were also variously implemented with overlapping but incomplete sets between major clients and servers, and implemented in frequently incompatible manners, despite appearing being correct.
The long and the short is that the org I worked with, in the end, just had to say "we use OpenFire and Pidgin, nothing else will be supported".
But at least it was designed.
@f0x Matrix is chasing growth over stability or design. Most design decisions happen off the cuff as needed rather than being planned before hand from a whole-system point of view.
Because of this, Matrix developers have painted themselves into corners over how they need to implement important features because of previous mistakes, Synapse groans under it's own weight and is famously difficult to set up and administrate.
Third party HS don't really exist because keeping parity with such a casually thrown together "reference" implementation is a massive pita, and the written docs aren't worth the paper.
Operationally, this shows: the appservice api has massive holes, and doesn't integrate well with most other services. The primary form of maintenance is just "restart a bridge with 20k users" (which in early days would lead to storms of restarts because it turns out naively reconnecting 20k users is a pain). Matrix.org can barely stay operational and has turned off flagship features to remain performant. The federated network is unhealthy because operating your own HS is hard, and Matrix.org, chasing growth, do not encourage people to register elsewhere.
It's all a bit of a cluster tbh.
i think XMPP and Matrix both have design strengths and weaknesses, personally.
it really comes down to which technology is best adapted to fit our requirements.
XMPP is likely seen as preferable because NV unilaterally controls the matrix specs (the matrix.org foundation is, well, frankly, a meaningless distinction)
XMPP also has a slight edge because there's a third-party XMPP server already that fits into the erlang ecosystem (Mongoose) and can integrate with Pleroma authentication.
with Matrix, I mean, frankly, Synapse isn't acceptable for inclusion as a third-party component in the platform, so we would have to either work on Ruma or write a homeserver from scratch. NV, having commercial interests, are probably not likely to cooperate with us.
@kaniini I guess there is a certain amount of trust needed in NewVector, but imo they haven't done anything to lose it. From what I've seen from the devs they'd much rather help the ecosystem with a new HS than keep the Synapse monopoly (because they know it sucks as well)
i do think if an organization like Pleroma made a play in the Matrix community, it would balance out a lot of those concerns.
@f0x @kaniini matrix is even shitter than xmpp.
xmpp is a bad design, but at least it's designed.