So i don’t agree with everything the original author said, but i don’t agree with all you said either. The thing is SMTP is stagnating because the mailboxes we use in practice is controlled by a cartel of 4-5 megacorporporations, but at least it’s all specified even though in practice you need to deal with implementation-specific edge-cases.

For XMPP the ecosystem is far from stagnating but lacks resources. There’s tons of specs and it’s hard to figure out the correct way to do things on your own, but fortunately there’s projects like modernxmpp.net to help you out, and if you ask in chatrooms people will point you in the right direction. Also, XMPP from the start is explicitly conceived to be extensible with a tree-like data format (XML) so it’s easy to build pretty much anything on top and people are doing it (realtime code collaboration, video conferencing, social networking etc).

Yes both protocols have downsides but they nailed something that ActivityPub didn’t: they have clearly-defined use-cases. ActivityPub/ActivityStreams is super generic and that’s really cool in the spirit of a generic server and specific clients using the C2S protocol, but now we have the worst of both worlds where each use-case employs different data types in a seemingly-random fashion (so people will focus on interop with a specific implementation rather than defining a sub-specification for a specific usecase), and client apps use custom APIs all over.

This situation is worse for users because the protocol is intended for abstract content but all implementations are very opinionated (yet unspecified), so as a user you need different accounts on Mastodon, Lemmy, Peertube, Mobilizon, Funkwhale, PixelFed, and soon (hopefully) Gitea. How do i follow another user across all those services? Sure we could use rel=me links but who does that on the fediverse? In email/XMPP world at least i have a consistent address no matter what client i use, and there is a clean separation of concerns between clients and servers: the server provides abstract features (storage/federation) following specifications (roster, vCard, MIX, PEP, MAM etc) and the client implements the application logic relevant to the use-case, which is also defined by a specification (eg. MUC, microblogging over XMPP…).

I think the ecosystem/situation could be vastly improved in XMPP land in some regards, but by all means the model is vastly better than what the fediverse is doing in practice so far (not necessarily on paper). To elaborate on areas which could be improved:

• more clearly organizing specifications (and having visualizations of dependencies)
• clearly separating abstract server specifications and client usecase specifications
• having test suites for every single specification: this is already possible for server-side using scansion but there is no corresponding client-test utility
• more UX-focused workshops and quality/usability testing, such as Snikket project has been doing

I personally have strong opinions beyond these points, but i believe any federated protocol would benefit from at least those few points. If you can’t test for client/server correctness, can’t understand how specifications interweave at a glance, and don’t have a community that’s focused on UX, i don’t think it’s gonna be very successful.

To be clear, i’m not dismissive of the fediverse ecosystem (or matrix ecosystem for that matter) there’s a lot of cool innovation happening in there. But i can’t help but notice that they tried to address some implementation issues with newer protocols, and came with new protocol/implementation flaws in the process. And now we have two more protocols to interop with :P

this is the price for innovation happening

Having been in the decentralized social media and prior semantic social web game long before ActivityPub, I can say without a doubt that ActivityPub does not qualify as innovation but rather regression, and that’s even before mastodon fucked it up, which is basically what the author is complaining about without realizing it.

First, Delta Chat uses both because it is a mail client after all.

And second:

If it wasn’t, we’d have a huge, thriving social network with millions of users and thousands of instances years before AP even come into existence. We didn’t. Almost every developer of every decentralized social network decided to develop their own protocol, rather than use SMTP, SIP, or XMPP as the base for their social network. There’s a reason for that.

What you are doing here is called “guessing the reason because it fits”.

The things you tell don’t have to drive to the other per se. There is no process linking them directly.

That doesn’t demostrate it in any sense.

There must be a reason as you say, but that reason doesn’t have to be the one you tell.

I could say in my own POV, that people like to reinvent the wheel to learn, and in the process they find something that fits in their mind for what they want.

That is my little experience in some open projects. Specifically, after I asked reasons to not implement things in a specific way.

Ehh, okay, let’s get into this a bit, shall we?

Yes, ICANN “controls” the DNS root, and then delegates authority over top level domains (TLDs, like say .info, or .is, etc) to registry operators (I’ll call them “registries” for short here) that then operate them. Registries then make decisions how they make second- and third-level domains (say, example.com or example.co.uk) available for registration by people.

Thing is, ICANN delegates that authority usually for decades. So if you want to worry about something related to DNS, you need to worry about your registry (the operator of the TLD you’re using) or your registrar (the company you bought the domain through), rather than ICANN. ICANN has effectively no power to tell specific registries to take down specific domain.

And registries usually really do not like taking down specific domains. Why would they? Not only is this money lost (they usually get paid per a registered domain name), plus people who work in many registries are very often Old Guard Grey Beards, who hate censorship and centralization probably more than you do, with the difference that they do actually understand the underlying technology.

These registries are what is referred in the post higher up in the chain as the “half a dozen” corporations that “the process” is “in the hands of”. And there is considerably more of them than “half a dozen”. They all have their policies, including what is needed to take down a domain name registered with them, and how much a domain name costs.

You can register domains for a couple of dollars per year, which I would posit is not “very expensive”.

Plus, the governance of ICANN has been less and less centralized over the years. There are all sorts of boards and governing bodies that have a say nowadays. Is it perfect? No, not by a long shot, and I have plenty of qualms about ICANN as an organization. But saying “DNS is centralized” glosses over a lot of complexity and makes it seem as if ICANN flat out controls and micro-manages every single domain name, which has nothing to do with reality.

Plus, if you want to go down a rabbit hole, consider IANA, who controls allocation of IP addresses.

Oh noes, IP addresses are “centralized” because of IANA much in a similar way that DNS is “centralized” because of ICANN? Yup, you heard that right! Does it mean that anything that uses an IP address is by definition “centralized”? No, saying that would be somewhat silly.

Disclaimer: I work for ISNIC, the .IS registry. I had also been involved in digital human rights activism for ~15 years, with focus on decentralization and anti-censorship. Take this as you will.