[kn0where]

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?

[jrm4]

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.

[criddell]

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-...

[jrm4]

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.

[mperham]

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.

[wizzwizz4]

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.

[cortesoft]

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?

[kstrauser]

What if I register the email address [e-mail] or [e-mail] 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.

[cortesoft]

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.

[criddell]

The AT protocol is designed to fix this. If email ran on AT, you could take your [e-mail] account and move it to Microsoft or even your own server.

[kstrauser]

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.

[jrm4]

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

[cortesoft]

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.

[jrm4]

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.

[krapp]

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

[jrm4]

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

See, e.g. steampowered.com

[abdullahkhalids]

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/

[tkellogg]

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.

[kstrauser]

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.

[abdullahkhalids]

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/

[kstrauser]

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

[abdullahkhalids]

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

[josephg]

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.

[jauntywundrkind]

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.