Why the fediverse is stuck. : fediverse

[–] [email protected] 28 points 2 years ago (1 children)

As someone who is not at all competent, this is an interesting read, and the comments that I see here are also very valuable.

However, there are a few points in the article that seem at least unfair, and sometime are straight gratuitous insults. The ones that stand out most to me are the following

Still we must admit that some aforementioned protocols have created huge ecosystems and hundreds of applications, while ActivityPub seems to be relegated to a very few applications aimed at mimicking GAFAM, and nothing more.

No mention to the most obvious reason why so far there are more successful applications of 42-year-old SMTP and 22-year-old XMPP and SIP than applications of 4-year-old ActivityPub.
Similaarly, no mention to the most obvious reason why AP applications feel less original wrt the corporations who overwelm today's web way more than they ever did.

(mostly south american communists , european anarchists , vegans and other freaks you won't be friend with in real life)

It doesn't get more personal. Also, no shit, the people who are most involved in fighting the corporate statu quo are leftists?

[–] [email protected] 6 points 2 years ago

Couldn't agree more. The whole tone of this piece is rather depreciative, and the author steps over multiple key points. Not a good post, imo.

[–] [email protected] 19 points 2 years ago* (last edited 2 years ago) (4 children)

It may seem contradictory that all these 'decentralised' protocols are based on a very centralised structure such as the DNS, when one could use a DHT, like torrent is doing.

Ah there we go. So it's about how AP is not peer-to-peer and not DHT based, I guess. Well, SecureScuttleButt is right there Also, "decentralized" doesn't exclusively mean "peer-to-peer".

Could SMTP, XMPP, SIP have been used to build the fediverse? The answer is: yes, and they would have worked MUCH better. How do I know? Because they are widely used, and they DO work much better. As easy as that.

If they all work so well and all can replace ActivityPub, can't they replace one another? In that case, why do we even need SIP and XMPP if SMTP was there and already popular?

The answer is: because these are old protocols that are a hell to implement, and were done in completely different times with completely different threat models and for completely different purpose.

This is not a technical assessment, meaning: if all three protocols (plus ActivityPub) can succeed in getting a message to a user (using MIME for SMTP, SDP for SIP, and XML for XMPP), they are all equivalent. If all of three can do it while also describing the type of message , they are equivalent.

Okay, so what exactly is the author saying? "They all could replace ActivityPub, but not really actually"?

Still we must admit that some aforementioned protocols [SMTP, XMPP, SIP] have created huge ecosystems and hundreds of applications, while ActivityPub seems to be relegated to a very few applications aimed at mimicking GAFAM, and nothing more.

Perhaps that's because the oldest of them had ~40 year head-start, and the youngest (XMPP) over 15-year head-start over ActivityPub.

The only actually reasonable criticism of ActivityPub I see there is the documentation and implementation bit. AP's documentation is, indeed, not amazing, and implementing it requires testing stuff out regarding how other AP-implementing software does things.

Which is both true, and interesting in the context of pointing to XMPP as a "better" protocol (ermahgerd the XEPs...).

I don't know why the person is so bitter, but I hope they get better.

[–] [email protected] 9 points 2 years ago* (last edited 2 years ago) (1 children)

The only actually reasonable criticism of ActivityPub I see there is the documentation and implementation bit. AP’s documentation is, indeed, not amazing, and implementing it requires testing stuff out regarding how other AP-implementing software does things.

TBF that's only because mastodon, with it's majority userbase inherited from gnu social, insisted on doing things outside of the AP protocol, to be able to claim those gnu social users in fact. Thus dragging everyone back to the past unnecessarily, and creating confusion for people who expect to be able to simply implement the AP spec as written.

[–] [email protected] 8 points 2 years ago (2 children)

It's more complicated than that. AP is a "compromise" protocol that was created to get some of the 50+ different decentralized federated social networks to maybe consider talking to one another.

For that reason, it only supported some of the simpler use-cases (public posts, DMs), but lacked explicit specification for more advanced use-cases (edits? groups? Markdown content? etc).

Different pieces of server software started implementing these features on top of AP. Today there are instances that support Markdown, and those that don't (notably mastodon.social, for example), that support groups (in several different ways that this can be implemented) and not, etc.

This is an evolving protocol, this is the price for innovation happening (instead of protocol actually stagnating like SMTP). On the other hand, the danger is that it ends up being XMPP, with hundreds of XEPs implemented seemingly randomly across servers and clients, leading to users never being really sure if a given functionality is actually supported by the combination of server software and client software used by them and whoever they are talking to (potentially 4 different pieces of software, draw a matrix of supported XEPs for that!).

So, it's all the more funny that the author uses both SMTP and XMPP as examples of (presumably) "better" protocols.

[–] [email protected] 8 points 2 years ago (2 children)

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

[–] [email protected] 2 points 2 years ago (2 children)

Sure we could use rel=me links but who does that on the fediverse?

The people that utilize rel=me for its use case.

Also what's rel=me?

[–] [email protected] 3 points 2 years ago

Also what’s rel=me?

It's just a semantic tag you add to a link on an IndieWeb profile (h-card) to indicate other addresses which describe the same person. So basically if lemmy implemented basic microformats2 (semantic classes for HTML, part of indieweb ecosystem), you could have an "alternative links" setting in your Lemmy profile that would link to your XMPP, email, mastodon or whatever other addresses. Ideally, we wouldn't even need so many accounts/addresses for a single identity, but as an intermediate measure a multi-protocol client (or a s2s bridge/gateway like bridgy could enable you to subscribe to one person's feed across all protocols.

The indieweb is based on a POSSE principle where your own website is the original source of truth for content but is socially-aware of both: what you republished elsewhere (eg. a twitter post) and replies coming in from elsewhere (eg. a reply on Lemmy). The rel=me link is one of the semantic foundations that enables this. That's just one approach to identity which places the web front and center, but we could also mention other approaches:

domain name as identity (DNS, .onion)
cryptographic keypair as identity (PGP, SSH, ZOT nomadic identities)

The rel=me specification addresses the "discoverability" problem. Both DNS and PGP can store arbitrary data and could be used to advertise different identities however i don't know of standard/specified ways to do it. Something else to consider about digital identities is that you sometimes want different inboxes (collections in ActivityPub parlance) under the same identity, like some people have bank@mydomain and ecommerce@mydomain email addresses. I think that's a rather compelling argument for domain name as identity but that's a complex topic with a lot of nuance (and it's not incompatible with backing your domain name with a cryptographic identifier like the GNU Name System does).

I'm happy to elaborate on certain points, or to provide detailed links (which i did not do in this reply sorry, but any web search engine should be able to help you out) if you ask for it :)

[–] [email protected] 2 points 2 years ago

This might help:
https://www.zylstra.org/blog/2018/10/mastodon-rel-me/

[–] [email protected] 1 points 2 years ago (1 children)

Sure we could use rel=me links but who does that on the fediverse?

Plenty of people, including yours truly (note the green checkmarked link to my blog in my profile). I keep seeing such green-checkmarked links in profiles, so this is not just a couple of people. It's a thing.

[–] [email protected] 3 points 2 years ago (1 children)

Oh that's pretty cool, thanks for sharing! I was not aware this had caught on so please don't take my initial comment as a sarcastic dismissal but rather as a lack of awareness :)

I just followed the link to your blog and i really like the design. Also i liked what i read, especially about contract-based dependency management. I myself had some thoughts (just raw notes with lots of typos/mistakes not a published articles yet) on the topic (about how to specify API/CLI contracts as part documents readable both by humans and by machines) and i'd be thrilled to discuss it further and maybe actually start implementing something (i'm part-time hacking on a SSG, a DIY CI/CD system, and a selfhosting distro and i could really use some specification/testing system that's not overtly complex).

Hope to see you around on IRC/XMPP maybe?

[–] [email protected] 2 points 2 years ago (3 children)

Oh that’s pretty cool, thanks for sharing! I was not aware this had caught on so please don’t take my initial comment as a sarcastic dismissal but rather as a lack of awareness :)

<3

I just followed the link to your blog and i really like the design. Also i liked what i read, especially about contract-based dependency management.

Aww, thank you!

I myself had some thoughts (just raw notes with lots of typos/mistakes not a published articles yet) on the topic (about how to specify API/CLI contracts as part documents readable both by humans and by machines).

Perhaps we need a Lemmy community for that kind of stuff? 🤔

Hope to see you around on IRC/XMPP maybe?

Oh hah, I used to (I even ran several XMPP servers back in the day). Now I am on Matrix, as this is just the easiest for me. And fedi, of course.

load more comments (3 replies)

[–] [email protected] 4 points 2 years ago (1 children)

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.

[–] [email protected] 6 points 2 years ago (1 children)

I didn't say ActivityPub is innovation. I specifically said ActivityPub "only supported some of the simpler use-cases". In that sense we agree.

But I wouldn't call it a regression, either. It's a lowest-common-denominator kind of thing, where yeah it does not support a lot of fancy features, but after 15 years of dozens of different projects each making their own precious incompatible protocol that had ~2k users each, now we have a protocol that brings a bunch of different projects together.

That's a huge step forward. Decentralized social networks always suffered from the Network effect working against them. By agreeing on a protocol, as non-ideal as it is, this got turned around, somewhat.

[–] [email protected] 8 points 2 years ago (2 children)

Overall I get what you're saying and sort of agree but...

By agreeing on a protocol, as non-ideal as it is, this got turned around, somewhat.

I was in those socialcg meetings. What was agreed upon didn't always make it into the protocol because mastodon devs had an outsized influence, and so even when the majority voted on certain things the chair went with what the Mastodon devs wanted.

And then to add insult to injury the Mastodon devs decided not follow the protocol anyway.

And then because MastoPub had the most users, many newbie devs thought that's what they had to implement rather than AP.

And again, most of the things complained about by this person are due to that side of the story.

It's a tragedy of history. And yeah, I guess you could call it a success story too but at what cost? What type of success story would we have had if it didn't go down that way? I argue, much greater success, and much fewer people questioning whether fediverse is a good way forward.

[–] [email protected] 7 points 2 years ago (2 children)

I was in those socialcg meetings. What was agreed upon didn’t always make it into the protocol because mastodon devs had an outsized influence, and so even when the majority voted on certain things the chair went with what the Mastodon devs wanted.

Ah, thank you for that context. I was not on these meetings, but I did follow the e-mail conversations in the fedsocweb working group. And I vividly remember the protocol measuring contest that any suggestion of finding a common ground and choosing/designing a common protocol for the 50+ different, incompatible decentralized social media protocols devolved into very quickly.

At the same time, I was on Diaspora; and on StatusNet, which was all-but killed by Evan developing a yet another incompatible protocol PumpIO and just migrating the biggest StatusNet instance to it, thus tearing the heart out of broader StatusNet. The Network Effect worked against tiny, incompatible, decentralized social networks, and so we were all stuck in walled gardens.

Then comes ActivityPub and suddenly a dozen or so different decentralized social media projects talk the same language. The Network Effect starts working in our favour. That's a big deal!

So that's the lens I see ActivityPub through. Not saying AP is perfect. But it's a large step in a good direction.

Done is better than perfect, I guess.

[–] [email protected] 1 points 2 years ago* (last edited 2 years ago) (1 children)

But do they really talk to each other? They share Note objects at best. That's to say nothing about how most still don't really support urls as actors, and instead fall back on webfinger, which is deliberately not part of AP proper. And even then masto only supports alphanumeric names, so most new software copies that limitation to remain compatible, along with many other masto limitations. You are right about the lowest common denominator though.

[–] [email protected] 5 points 2 years ago* (last edited 2 years ago) (1 children)

But do they really talk to each other?

Compared to, say, 9 years ago? When Diaspora would not federate with StatusNet, and Friendica would try to implement both of their protocols to try to create some form of interoperability between the two? With pump.io, tent.io, and Red doing things differently, and all this fragmenting the decentralized federated social media scene to a point of complete irrelevance?

When to the question I had asked on the public-fedsocweb mailing list about how maybe, you know, there should be some effort to get different projects to speak the same protocol, the answers ranged from "not going to happen" through suggesting Bitcoin integration and claiming all these networks are too different to mentioning Usenet and NNTP.

Today, thanks to ActivityPub (as imperfect as it is), from my Mastodon account I can follow PeerTube channels, WriteAs blogs, Mobilizon events, participate in threads like this one here on Lemmy, follow photostories on Pixelfed, and talk to people who have accounts on Friendica, Pleroma, MissKey, and who knows what other type of instances.

So yes, very clearly they do talk to each other, and very clearly this is already making a difference. Frankly I am flabberghasted this needs to be spelled out explicitly.

Of course, Diaspora still cannot federate with anyone else. But this is their choice. We now finally have a single huge network of different yet compatible (on a basic but important level) instances, so when a user asks "where should I move off of Twitter or Facebook", different decentralized social networks need not fight among themselves to convince them to move to them specifically.

Instead of competing, a large number of federated social networking projects are cooperating, and surfing the Network effect together.

This is makes a lot of difference.

[–] [email protected] 2 points 2 years ago (1 children)

I haven't yet followed your links but there are some things that came to mind from the comment text.

Mostly just that one of the reasons I liked both friendica and Red (who share a common author), was precisely the agnosticism toward protocol. The platforms do what they can within the confines of each protocol, and simultaneously support as many as they can.

There was a dearth of development resources on friendica when the founder left but it didn't take long for the community to pitch in and catch up.

At least, that's the way I remember things.

[–] [email protected] 5 points 2 years ago

Oh, absolutely. I love the "yes, we will implement every single protocol we figure out how to, if we find the resources and time" approach. In fact, I advocated that very approach a lot some years ago.

But that only gets us so far — we end up with a network where a lot of federated social networks federate with Friendica/Red, but not with one another. That's less than ideal.

So I much prefer a situation where we finally get a single protocol a lot of software implements, so that interoperability can be had in any direction. And that's what ActivityPub brought to the table, finally.

[–] [email protected] 1 points 2 years ago (1 children)

ActivityPub is the standardization of the ActivityPump (aka PumpIO) protocol, so all this came from that massive fuck you Even threw at the community. Set us back years, but we're starting to see progress again these days I think, a little.

[–] [email protected] 1 points 2 years ago* (last edited 2 years ago)

Well, progress is often not linear, or even monotonic.

[–] [email protected] 1 points 2 years ago (1 children)

note: I am new to the history of the ActivityPub standard.

Do you think that ActivityPub is capable of reform?

Do you think it would be possible to successfully propose to W3C that Mastodon doesn't care to follow the protocol and those SocialCG decisions in their favor should be revised? What were some of those decisions?

Do you think Mastodon is increasingly in a position where it is 'too big to lose', and that if things escalated it would abandon federation with non-Mastodon platforms over following the majority-decided protocol? Will we see a situation where platforms are again using multiple federation protocols?

[–] [email protected] 2 points 2 years ago* (last edited 2 years ago) (2 children)

Do you think that ActivityPub is capable of reform?

Hard to say. The data model has certain limitations that make it difficult to be used for more advanced things and it is structured in a way that seems to encourage nosql style document databases and has a sort of viral influence on the development of new apps.†

However, it can get the job done with enough brute force -- though if you are doing anything other than microblogging MastoPub apps likely won't work with it even if you are AP compliant.

Do you think it would be possible to successfully propose to W3C that Mastodon doesn’t care to follow the protocol and those SocialCG decisions in their favor should be revised? What were some of those decisions?

No, the W3C process is such that the committee is closed and only addon specs can be ratified by the Community Group. I don't remember any specific decisions but I remember at least a few occasions where everyone voted and there was a clear majority but the masto devs threw a tantrum and threatened to take their ball and go home. The results were mixed. Sometimes it simply went unspecified to "keep the peace" and others the majority was just flat out ignored and the opposite was put in spec. Excuses were always made and had me feeling like the whole voting process was a sham.

Do you think Mastodon is increasingly in a position where it is ‘too big to lose’, and that if things escalated it would abandon federation with non-Mastodon platforms over following the majority-decided protocol?

Not increasingly. It has always been that way. They don't federate with non-mastopub platforms and the platforms that aren't microblogs have had to limit their features to be MastoPub compatible.

Will we see a situation where platforms are again using multiple federation protocols?

The ones that have continue to do so and I still believe it's the best (only) way.

@[email protected] says that such a strategy results in apps that can talk with friendica or hubzilla but not each other, but I say that's the situation we still have, where advanced apps can talk to each other but not Mastodon.

There will always be fragmentation. If that fragmentation falls on the majority (Mastodon) being inconvenienced I think that is a better result than the freedom fighters and innovators being sabotaged and having no options at all.

-- ** --

† Here I am referring to the problem when developing a new app where if you plan to support AP first and foremost, it is easiest to structure your whole app and data model around AP, and then you are kind of stuck in that mindset permanently. Whereas if you develop your app with an open mind, then go back and add AP support you won't cripple yourself.

Edit: I just remembered a couple examples (sort of). One was there was talk of a discovery mechanism that didn't depend on webfinger, but Mastodon rejected it because they wanted to maintain backwards compatibility with gnu social (so they could bootstrap their userbase that gave them their influence).

Another was they almost didn't include sharedInbox in the spec because Mastodon didn't want to use it and thought it was stupid or evil or something. Luckily it still made it in but the compromise was that it was optional, putting extra burden on all other servers to support sending separate copies to every single user's inbox.

[–] [email protected] 2 points 2 years ago (1 children)

Thank you for the very detailed answer!

Another was they almost didn’t include sharedInbox in the spec because Mastodon didn’t want to use it and thought it was stupid or evil or something. Luckily it still made it in but the compromise was that it was optional, putting extra burden on all other servers to support sending separate copies to every single user’s inbox.

I'm not sure if it's the same thing, but I recall a Gab developer justifying their removal of federation in 2019, one of the reasons being that malicious actors were spinning up fake instances with thousands of users to make a server send separate copies of a message to every single user's inbox, slowing the site down. Would shared inboxes help to prevent this type of attack, or is it something else?

[–] [email protected] 2 points 2 years ago

malicious actors were spinning up fake instances with thousands of users to make a server send separate copies of a message to every single user’s inbox, slowing the site down. Would shared inboxes help to prevent this type of attack, or is it something else?

Indeed. Making sharedinbox a requirement would mean that a server could simply refuse to do it the other way and then be immune from that attack. But because it is optional, all servers must then be vulnerable to this attack.

It can be mitigated by batching, and delivering say only 5 copies to one server at a time, but that would have to be very carefully crafted to not cause queue backup for other messages.

The ultimate workaround is queueless delivery, but there will still always be some penalty of having to keep revisiting a particular server.

A malicious actor can also deliberately slowly respond to deliveries, forcing the sending server to keep many sockets open.

[–] [email protected] 2 points 2 years ago (1 children)

Thank you for all the context! Fully agreed on basically everything, esp. that there's always going to be some fragmentation. Still happy that we were able to limit that substantially. 🙂

[–] [email protected] 2 points 2 years ago

Some more context I just remembered (funny how things come in waves):

Notice that I always say Mastodon devs and don't name particular people. Part of that is out of respect and to keep it from seeming personal, but another important thing is that there were several Mastodon devs involved in the committee.

So when I say that there was a clear majority that means several Mastodon devs had a vote and they still lost.

But what happens in committee is people are allowed to argue for or against motions. At times, there would only be one person willing to argue on one side while several Mastodon devs would argue on the other.

So even if there was a majority vote numerically, there was a larger perceived dissent that would prevent motions from passing.

One chair was more affected by this than the other but again out of respect I won't say which.

This is important to understanding why standards committees sometimes have undesirable outcomes. It's also one of the reasons why sometimes groups committee shop and prefer W3C or IEEE or any of the others.

Standards committees is actually one of ~~humanity's~~ society's biggest unsolved problems. 🙃

[–] [email protected] 2 points 2 years ago* (last edited 2 years ago) (1 children)

If they all work so well and all can replace ActivityPub, can’t they replace one another? In that case, why do we even need SIP and XMPP if SMTP was there and already popular?

The answer is: because these are old protocols that are a hell to implement, and were done in completely different times with completely different threat models and for completely different purpose.

First, there is a social network on top of XMPP, which is Movim.

Second, being an "old protocol" doesn't make it difficult or "hell to implement" to get the same. You, as example, simply cannot use SMTP to make an internet call, because it doesn't work in real time by design. And even with that you have Delta Chat for instant messaging.

XMPP, as example, has an XEP implementing other range of protocols for this, RTP family, which is already used as background protocol by SIP for communications.

SIP is also getting extended. Some client, such as Linphone, implemented SIMPLE, which is an extension of SIP for instant messaging which could be used as a base for other kind of social network.

[–] [email protected] 5 points 2 years ago (1 children)

First, there is a social network on top of XMPP, which is Movim.

I am aware. Was around way longer than ActivityPub too, obviously. You can build anything on XMPP, the problem is that the XEPs compatibility matrix will do you in.

Second, being an “old protocol” doesn’t make it difficult or “hell to implement” to get the same.

I didn't say that just being an old protocol makes something hell to implement. What I said is that these specific three protocols are difficult to implement, with all the accrued additions, XEPs (for XMPP), etc.

And even with that you have Delta Chat for instant messaging.

I don't think DeltaChat uses SMTP directly. It uses IMAP to talk to your mail server.

XMPP, as example, has an XEP implementing other range of protocols for this, RTP family, which is already used as background protocol by SIP for communications.

Sure. Again, XEP compatibility matrix makes XMPP difficult to use for users. I've run 4 different XMPP servers over the last 15 years, I stopped for that reason. XMPP needs some kind of certification, "XMMPv2" or something, to make it sane.

SIP is also getting extended

I never SIP is not getting extended. I said SMTP, XMPP, and SIP were designed with different goals in mind and in different times than AP, and their usefulness for building a social network using them is therefore limited.

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.

My point is not that these protocols are somehow "worse". They are okay for what they were designed to do. But they were not designed to be used for a social network (in the sense of microblogging, or facebook-like activities).

And yes, one can claim "e-mail is a social network", but I'd consider that a disingenuous take in this conversation.

[–] [email protected] 2 points 2 years ago* (last edited 2 years ago) (1 children)

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.

[–] [email protected] 4 points 2 years ago (3 children)

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.

I never disputed that and I am not sure what point you are trying to make here. I explicitly mentioned 50+ other protocols devised by people along the way. Pretty clear that people like to experiment, and that's awesome.

The thing is, blogpost's author is making a very strong statement, namely: that ActivityPub is a bad protocol, and that we already had better protocols that could be used for the same purpose:

ActivityPub looks like it was written by an idiot who just won second prize in idiots' contest. It has every possible flaw without having any good.

and

Could SMTP, XMPP, SIP have been used to build the fediverse?
The answer is: yes, and they would have worked MUCH better.

I believe this has nothing to do with reality. Such strong claims (let's ignore the ad hominems there) require strong proof. And there is no proof provided. Yes, these protocols are used to build federated communication networks of one type or another, but they are not social networks (in the sense in which Twitter, Facebook, or the Fediverse are).

The fact is, nobody built anything close to how successful the Fediverse is using any of these three protocols over decades of them being available.

ActivityPub, while far from perfect (whoever and however defines what "perfect" is in this case), seems way better for the purpose of building a modern social network than SMTP, SIP, or XMPP. That's simply because it was designed for this purpose.

The author seems to be just ranting because they don't like ActivityPub for whatever reason; they'd like a more peer-to-peer protocol; they complain about the "mostly south american communists , european anarchists , vegans and other freaks you won’t be friend with in real life"; and they throw around the word "idiot" a lot. 🤷‍♀️

I really don't think such rants need to get the attention this one is getting. They come a dime a dozen, my favorite examples:

https://news.ycombinator.com/item?id=25894414 (the original site where that rant was published, infosec-handbook.eu, is not online anymore; meanwhile, fedi is alive and kicking)
https://mashable.com/article/mastodon-wont-survive (5y ago)

I think the conversation we're having in the threads here in a decentralized, federated (using ActivityPub, no less!) way are way more useful and helpful than whatever the author of that blogpost wrote. Now, if we can only find a way to have them without first having to deal with low quality hot takes like the ones in the blogpost, we'd all be better for it.

load more comments (3 replies)

load more comments (2 replies)

[–] [email protected] 14 points 2 years ago (1 children)

I would like to know what someone working with ActivityPub thinks of this (e.g. the Lemmy devs)

[–] [email protected] 5 points 2 years ago

Same

[–] [email protected] 12 points 2 years ago (1 children)

I don‘t understand why this is upvoted. It‘s pretty clear from the start that the author is not interested in constructive criticism. I don‘t have any stake in ActivityPub, and not really an opinion whether it is a good or a bad protocol. But this article is just an angry rant, and a complete waste of time.

[–] [email protected] 5 points 2 years ago (1 children)

The tone of the article is really unpleasant, and its conclusions appear too bitter and vague to be really trusted, but at least it addresses specific points who fueled interesting discussions in this comment section.

I upvoted the post, not becuse I agree with the content of the article, but because of its potential for interesting discussions, that makes it a good addition to this community.

[–] [email protected] 4 points 2 years ago

Sadly, I had not read the comments from @[email protected] because szmer.info is blocked on feddit.de for whatever reason. The detailed rebuttal from @[email protected] indeed makes this thread worthwhile, and I would love if I could upvote that comment.

[–] [email protected] 10 points 2 years ago

Be aware that the author of this blog is a well known Italian nazi-transhumanist that is famous for making shit up about himself, his expertise and the IT industry since the early '00. Don't trust a single word that comes out of his mouth.

[–] [email protected] 7 points 2 years ago* (last edited 2 years ago) (1 children)

I'm surprised the author did not mention NNTP, the protocol that ran the larges federated discussion system since 1986.

ActivityPub reinvented NNTP with less efficiency and very poor documentation.

load more comments (1 replies)

[–] [email protected] 6 points 2 years ago (1 children)

I remembered XKCD 927 while reading the comments.

[–] [email protected] 3 points 2 years ago

Yeah, this is exactly why I do appreciate that ActivityPub helped the broader fedsocweb scene kind of sort of largely coalesce around a single protocol.

[–] [email protected] 3 points 2 years ago (1 children)

It may seem contradictory that all these 'decentralised' protocols are based on a very centralised structure such as the DNS, when one could use a DHT, like torrent is doing.

DNS is centralized?

[–] [email protected] 8 points 2 years ago (1 children)

Yes, it's controlled by ICANN which licenses out the ability to become a domain registrar. Making a new TLD is very expensive and the whole process is in the hands of like a half dozen corporations.

[–] [email protected] 3 points 2 years ago (1 children)

Oof. What are the actually decentralized alternatives then?

[–] [email protected] 10 points 2 years ago* (last edited 2 years ago) (1 children)

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.

[–] [email protected] 5 points 2 years ago

Of course this is not to say there are no issues with ICANN. Just ask Peter Sunde.

But it's way more nuanced than "[DNS] is controlled by ICANN" and "a new TLD is very expensive".

[–] [email protected] 3 points 2 years ago (3 children)

Good article but the title is a click bait, it should have been "why activitypub sucks". The fediverse is not stuck, the implementation might suck but it's in active development and is even becoming a bit "mainstream"

load more comments (2 replies)