Mastodon’s weaknesses and how to fix them
https://2ality.com/2024/11/mastodon-weaknesses.html
Do I understand Bluesky’s protocol (*) correctly? It seems less decentralized than ActivityPub:
* A lot is nice, pluggable and decentralized: feeds, PDSes, etc.
* However, core functionality (e.g. for finding replies to a post) depends on the Relay as a “firehose”. A Relay is expensive to run (especially if combined with AppView & Labeler). It has to be comprehensive, otherwise accounts can’t follow each other. Isn’t that an obstacle to more federation(?)
@rauschma nothing groundbreaking there to anyone working on the projectc, it's mostly just a matter of time & money to fix things.
For replies still being present after blocking, that's actually missed the mark: in mastodon we don't currently manage the replies collection on each post, and instead just fetch everything that says it's "in reply to" that post. Fixing that would be a big lift, but would solve many problems around replies.
More important is fixing project governance & leadership
@thisismissem Thanks for your work on Mastodon!
Would you be OK with being quoted like this (no problem if not)? “in mastodon we don't currently manage the replies collection on each post, and instead just fetch everything that says it's "in reply to" that post. Fixing that would be a big lift, but would solve many problems around replies.”
Naively, I’d think you could exclude people blocked by the post’s author during fetching, but it’s probably more complicated than that.
@thisismissem
> More important is fixing project governance & leadership
Do you mean #3 in the following list? https://github.com/mastodon/mastodon/issues/17107
I kind of understand G. wanting to remain in control of his company. But with so much volunteer work, more democracy would only be fair. The ActivityPub standard is more democratic, though.
Let me know if there is any material I should add to the blog post.
@rauschma sure! The main thing with “exclude people blocked on fetch" is that it'd only be server-local, since who you block is not shared with other servers (well, sometimes it is, but it's also not, the AP spec was terrible about defining this)
Managing the replies collection would result in an experience like that on twitter, where you'd have the replies, and then beneath those a button to “show hidden replies”, I think
@rauschma great list. I'd argue that remote users following/followers sync is a major issue as well.
@shlee Good point! I added it to the blog post.
@rauschma this is an amazing breakdown!
I have advocated for building a plugin api so the core mastodon team does not need to rubber stamp and support every idea. Do you have any thoughts on if that makes sense and any benefits or drawbacks?
@stefan Many improvements belong to the core, I think. But Bluesky has great ideas w.r.t. pluggability—e.g. its custom algorithms.
I wonder how many of these can be fixed on the client side.
@rauschma this thread made it make more sense to me: https://bsky.app/profile/mmasnick.bsky.social/post/3l7y5rlcleb2y
Trying to think of it as “decentralized” but not “federated”. Maybe it’s decentralized more in the sense that DNS is decentralized? In the respect that eventually you will need use a relay that you don’t/can’t control, otherwise you cut yourself off from the network (or you need to spend a ton of money to become a root DNS/relay basically)
@austinwillis Interesting, thanks!
I’m not sure what that sentence means: “[…] ATproto thinks of decentralized more like the web is decentralized, not that you have to pick your own feudal lord.”
The Relay is your feudal lord on Bluesky.
I think in terms of: What are the centralized elements of a system? And a Relay is such an element (in practice). They went with a firehose where Mastodon retrieves on demand.
Also: Someone has to moderate the Relay. That’s labor/cost-intensive, too.
@austinwillis My current and preliminary conclusion is that ActivityPub going with server = community is a compromise but a good one that helps with making the Fediverse diverse.
@rauschma Right, I think that compromise is necessary to make moderation possible at a volunteer capacity. It would be a complete disaster if the volume of people joining Bsky were jumping on mastodon.social right now, and honestly I think it’s best that they don’t. We’ll see how Bsky pans out, but I do think their design is the best way to handle that level of scale that we have seen so far. If the day comes where they turn the dials too far, then maybe then the technical crowd can provide a non-extractive relay to free everyone
@rauschma thank you for the good article that highlights the problems! I actively work on the problem (data and identity ownership) with my team. We decided to build from scratch and solve the fundamental flaws in social digital interaction. There are several fundamental rules on which our work is based:
1. Content-addressable.
2. DiD
3. Relative friendly names (everyone is a root).
And the properties:
1. Protocol agnostic
2. Freedom of posting any content.
3. Free from spam and unwanted content.
Yes, the network allows #2 and #3 to coexist.
It's completely decentralized and distributed. It's less like blockchain and more like global Git.
@functionalscript You may enjoy this blog post (see section “What should the fediverse do?”): https://dustycloud.org/blog/how-decentralized-is-bluesky/
@rauschma very insightful! Thank you, Axel! It's a good overview of different strategies and protocols. However, I still have that feeling that social network developers and advocates focus on the wrong things: protocols and servers. IMHO, we need to focus on how we store data in the way that it belongs to users no matter where we store it. That's the reason I work on a content-addressable storage. Protocols are just ways to synchronize the decentralized storages. We can have all sorts of protocols to synchronize our storage work simultaneously, including sneakernet and pigeon mail. As soon as I, as a user, can prove that the message is from my friend (or from a friend of my friend), I don't care how I got it. And a hash as an address helps me to ignore duplicates.
@functionalscript Quoting the post: “Some of these tasks are quite feasible for the fediverse to pick up today: the content-addressed storage and the portable identity stuff I think would be a major thing to introduce into the system but would be quite doable and would give the fediverse properties of surviving nodes going down better.”
@rauschma yes, I've seen it. It should be the core and foundation. And the message formats, signatures, private key should be available to users. I have no idea what is my private key in Bluesky account. It doesn't belong to me. I can't communicate using the account using different servers, applications etc. It's still a vendor lock-in.
@rauschma and when we have such infrastructure (where CAS is the main storage and we use cryptographic proofs) then the main question would be: why do we need fediverse at that stage?
@functionalscript Interesting. I’d have thought you’d need a protocol on top of CAS for moderation and managing/distributing data.
@rauschma we can still have some nodes, servers, aggregators, search engines, communities on top of content-addressable internet. They can delete, filter messages, ban users. However, they can't delete the content from the internet completely. So, it's freedom for everyone. Users can keep their content forever and publish it wherever they like, servers/communities have freedom to ban any content and any user.
@rauschma I'm not saying that we don't need a fediverse, protocols etc. My point is that we should change our focus from "add content addressable infrastructure to fediverse" to "build content-addressable infrastructure and then we can add fediverse to it, if we need it".
I'm sorry that it takes multiple posts for me to polish and clarify my thoughts. Spamming was not my intention.
@functionalscript From what I’ve read: Bluesky manages your keys for you for usability reasons but you can also manage them yourself.
@rauschma enjoyed your article. Went back and found toot from https://fosstodon.org/@rauschma/113816734342101723
Ultra minor quibble 4.3-4.5 seem less than "certain or likely" especially anytime soon (which your text mentions).
But the reason I'm writing is to especially thank you for calling out 5.2. Probably just a personal hangup, but the multitude of URLs for a given post annoys me, seems...uncool. Wish Mastodon at least made "original" slightly easier than "open original page" to get to (though thankful for that)!