The difference between Mastodon, Bluesky, and Threads | Hacker News Reader

The difference between Mastodon, Bluesky, and Threads

eff.org

69 pointssohkamyung40 comments

Genuine question: is there any technological/scaling problem with Mastodon that actually needs solving, and that the AT protocol would fix? What reason is there to split different parts of their backend tech stack between different “operators” with different policies? Does this separation of concerns improve the performance (or other desirable attribute) of the decentralized network versus Mastodon’s approach?

The one I hear about most often is account portability. Your Mastodon account is on a specific server whereas the AT protocol account is owned by the user. You can move it wherever you want. It helps protected you from being banned or from losing your account if your server is shut down.

Somebody archived a thread that discusses some of the motivation for AT:

https://fedimeister.onyxbits.de/topics/thread-archive-about-...

This feels like a decent idea that will never actually work (or matter) for most people, kind of like self-signed PGP emails and such?

They're solving an unreal problem that can be solved by "human trust" in a Mastodon-like system. Like, hey everyone, I'm no longer joebob@bluemastodon, I'm joebob@purplemastodon.

And in fact, Mastodon has a mechanism to migrate your account between servers. It has serious limitations (your posts don't follow you, followers do) but it's the best they can do within the AP spec.

Those limitations are due to the Mastodon software, not the ActivityPub protocol.

ActivityPub provides a mechanism that can technically be used for both post and follower migration – not that I'd suggest using it for that – but Mastodon's account migration feature is something separate. There's no technical reason it couldn't support post migration, except that nobody's put the work (largely social) in to get it past Gargron and implemented.

The problem is, none of that is stopping anyone else from being joebob@greenmastodon unless you get there first.

This is already an old-as-dirt, solved, if imperfectly, problem.

See, e.g. steampowered.com

And if someone else has created accounts for `joebob@<all the colors>mastodon`, what do you do? And what if they all start claiming to be the original joebob@bluemastodon?

What if I register the email address cortesoft@gmail.com or cortesoft@outlook.com and claim to be the original?

More broadly, there are lots of John Smiths in the world. Context is everything: the John Smith in my Bay Area office is different from the John Smith who makes the news in Boston.

The AT protocol is designed to fix this. If email ran on AT, you could take your cortesoft@gmail.com account and move it to Microsoft or even your own server.

Understood, but... was that in dire need of fixing? We're all pretty acclimated to it over the decades we've used email.

That isn't to say we can't or shouldn't improve things. It's more that I'm not convinced the problem here is important enough to justify the complexity of the solution.

For some people, it would be a big deal if Google suddenly locked their account. They might say it’s worth it.

In what universe do you think the Google corporation would allow people to violate their trademark on another's server? Not technically, but legally.

The more I roll over this AT thing in my head, the dumber it really sounds. The skin-in-the-game nature of tying names to servers, and also -- this is the important part -- the fact anyone can make their own server, is an infinitely better solution.

I think you misunderstood. kstrauser and I were using gmail as an analogy. You’re right about Google owning gmail. That was my point - you don’t really own anything. If they lock you out, you’re screwed.

I agree that the fact anyone can make their own server is great and I’m glad the AT protocol supports that.

People have worked around this problem by choosing an account at a well known, long lasting, centralized service.

This is why people have email accounts on gmail instead of a smaller provider; they know the email will last and they can maintain control of it. Same for twitter and facebook accounts.

If the whole point is to get away from centralized services and move to a federated model, that problem needs to be solved.

Right, but my point is that this is a problem that the AT protocol is trying to solve. You pointing out that it is a problem elsewhere is exactly the point; why not try to solve it?

This is especially important for a federated system where individual servers may come and go, and you want to have the ability to move your account if the server goes down or starts doing something shady.

Part of the reason people choose a centralized social media service is because they know their account will last and they can build a reputation. Unless you can move your account and maintain your reputation, a federated system won't have that trait.

What we've been doing, because you're describing an old-as-dirt problem that in no way is unique to mastodon?

See, e.g. steampowered.com

Sure, and what we have been doing to solve this old-as-dirt problem is people pick the big, centralized, social media companies to have their account and identity at, so that they know they will have a persistent identity.

If we want to avoid that, we need a solution to the old as dirt problem.

But again, I think it's already reasonably solved, by the solution we have now, for email.

Again, a universe of difference between e.g. Twitter (where anything can be revoked and they have ultimate power) and the problems with e.g Gmail (you take some care, you just start over, you start your own server.)

As I tell my students -- from a technical POV, mails from gmail.com and mails from jrm4.com (my personal domain) are just about equal on the Email protocol. This is pretty remarkable and a pretty good system already.

Isn't Mastodon supposed to not-scale? Basically, every server should be small enough that it can be reasonably moderated manually. If Mastodon scales to millions of users, we will be back to needing automated methods for moderation which have huge positive and negative errors.

Mastodon would likely make adoption much easier if these install [1] instructions were replaced by `apt-get install mastodon`, and configuration [2] was done in UI, rather than some text file.

Even that is too difficult. Hosting a mastodon instance should be as technically easy as starting a discord server.

[1] https://docs.joinmastodon.org/admin/install/

[2] https://docs.joinmastodon.org/admin/config/

There's 2 ways mastodon can scale (or not):

1. Per-server

2. Network-wide

Moderation load is per-server scaling, mostly. I'd argue that if the load gets to be too much, moderators do less moderating and people decide to migrate to other servers. That's kind of a clean scaling strategy, tbh.

However, adding servers isn't a great story. There's n^2 network connections (worst case) that need to be made to service all subscriptions. That's definitely a scaling problem, although probably addressable via an architecture inspired by gossip protocols.

There's a certain amount of irreducible complexity. There are a lot of things to configure! For instance, what database server do I want to connect to? What mailserver to use for transactional messages, and how do I authenticate to it? Where do I store images? Which Redis do I point at?

Someone who wants to avoid all that can register with a hosted service like masto.host that does it all for them.

The average mastodon server has 1k users, and the median has likely much fewer [1]. All of these choices are immaterial for the median server.

Just set reasonable defaults so that local gym manager's son/daughter can set them up with the gym's server in a couple of hours. And then leave these instructions for the advanced users who want to pay money for large servers.

[1] https://mastodon-analytics.com/

OK, what's your default mail settings at a minimum? You can't really run a server with users other than yourself without that.

That's a fair comment. For small servers, you can probably just get away with inputting the smtp details of any regular account.

But probably not a good idea, and you want to host your own mail server. There are also the domain name settings that you do have to put in. I don't know mastodon, but mailinabox has these settings [1] that took me a while to figure out.

My proposal is to write a software that is layer on top of popular domain name registrars' apis. The user just plugs in the api key into the software, and the software does the configuration on behalf of the user. The mastodon installer can then use this software to set up the mail and domain name settings.

I want to finish with one of my favorite facts: At it's peak LimeWire (a social media of sorts) was installed on 1/3rd of computers worldwide [2]. A dead simple installer that any grandma could follow ensured that it got there.

[1] https://mailinabox.email/guide.html

[2] https://en.wikipedia.org/wiki/LimeWire

I asked this same question to someone on bluesky who worked for it, and I didn't get a remotely coherent answer. If anything, it feels like the "identity portability" actually sets you up for the exact same kind of centralization we're trying to get away from.

While I get that, "lots of servers and easy to create and destroy accounts" may not be the best for adoption/popularity, it definitely feels like the long run smartest way to go about it.

The feature I’ve heard the Bluesky devs talk a lot about is aggregating likes across multiple servers. And search. As far as I can tell, they want Bluesky to be as fast and scalable as Twitter while being decentralised.

If a celebrity with millions of followers uses Bluesky, all users across all servers should be able to follow them and like their tweets.

Brian Newbold has some posts contrasting the design decisions of AP vs Bsky, in reply to this EFF article,

> a design tradeoff between atproto appviews and mastodon instances is that atproto appviews are generally "big world" and index the entire network, so the cost to run the indexing component scales with the size of network. (there is also read-volume scaling, separately)

> in activitypub, the scaling needs of an instance roughly go with the number of users, and the volume of interactions they have with entire network (read and write). so instances can start small (fewer resources)

> the point I was getting at is that actually you can have an atproto appview which doesn't index the entire network, just PDS instance of interest.

> this has some "cheap and totally independent" benefits, but trades off against not being able to see and interact with entire network

> aka, "full" appviews are more resource-intensive to get started, but have huge value.

> (also, the protocol is designed to make it way way cheaper than web crawling or other trad indexing, both in terms of compute resources and in terms of admin/ops labor)

https://bsky.app/profile/bnewbold.net/post/3kva4vxi45s2q

Bsky's as a distributed distribution mechanism has yet to be tested in any major way, but the premise of bulk transmission seems more built-in where-as AP was crafted more as a person-to-person relationship.

I'm less familiar with Mastadon's own protocols. It does seem like trying to keep Mastadon's sidekiq egress queues from flooding is a damned hard job for a lot of growing instances, at least it was ~2 years ago when I was active there.

I'm not optimistic about non tech people adopting mastodon.192.168.555.2.xproxy.remoteinstance2452456a1.mirror.com.

Threads just makes Meta look even more uncool and desperate to catch up. I'm sure they'll do everything in their power to advertise across Instagram and Facebook.

Non tech guy says : "Bluewhat?"

>I'm not optimistic about non tech people easily logging into mastodon.192.168.555.2.xproxy.remoteinstance2452456a1.mirror.com.

Why are you trolling? Mastodon instances have normal URLs like https://mastodon.social, and you can just log in there like any other site. And there's a ton of "non-tech" people on Mastodon.. in fact the people who seem whine the most about how hard it is are the "techies" on HN. It's weird.

Your very own host is https://krapp.masto.host/@krapp

All im saying is it’s not a good look as opposed to a single simple Twitter.com

I’m obviously exaggerating but when I click this link all I see is a scattered mess that the majority of people don’t want to put up with. The non foss people who could care less about the musk takeover enough to actually jump ship.

https://joinmastodon.org/servers

I feel like I’m playing CS 1.6 or something

It's a single user, hosted instance so just https://krapp.masto.host would also work, it's just (unnecessarily) pointing to a user account. It's not that weird - this very forum is a subdomain of ycombinator, people used to host their sites under geocities and tripod and the like.

I agree that instance discovery is a problem - mostly because identity isn't portable on Mastodon so you're kind of making a commitment, but it clearly isn't an insurmountable level of complexity for a lot of people to deal with. Most people will just gravitate to the biggest instances and that's fine.

One of the lessons I think the fragmentation of Twitter is teaching us is that the user experience doesn't have to be as simple and frictionless as possible.. people will put up with some rough edges if they want to.

Maybe on the app it’ll eventually have this nice virtualization where it all appears as one. But hell, I can’t even imagine getting my mom to use Discord with all the channels and servers etc…

I think that's inevitable, but it won't happen without an initial surge of adoption. Things like Mastodon tend to stay platforms by nerds for nerds otherwise. It will have to evolve the way the web in general evolved to serve more people.

"How will I ever remember that I can be emailed at me@alt4.gmail-smtp-in.l.google.com? This email thing will never take off among non-techies."

Email was a real thing, and it took off because corporations like AOL and Microsoft advertised it to the average person.

Mastodon feels like : “Ah yes, my favorite account to follow @CNN@mstdn.social. I hope some day we get the real CNN”

Btw that’s a real account, not me over exaggerating again.

I love EFF but also this article is very biased but also very thorough. Good read.

What bias did you observe?

If I had to guess I would guess they meant against Twitter. IMHO the EFF should be biased against Twitter given their mission, so I wouldn't even consider it to be bias personally.

There should be a social norm where if you're going to call out a bias, you should name the bias (at a minimum) and share the bias you see that bias from so readers can calibrate their interpretation. Without it, we're in a situation like this where someone has to ask and others try to work it out and a lot of time is spent trying to understand the claim rather than have a discussion.

Reply on news.ycombinator.com