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.
Somebody archived a thread that discusses some of the motivation for AT:
https://fedimeister.onyxbits.de/topics/thread-archive-about-...
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.
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.
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.
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.
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.
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.
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 agree that the fact anyone can make their own server is great and I’m glad the AT protocol supports that.
See, e.g. steampowered.com
If we want to avoid that, we need a solution to the old as dirt problem.
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.
See, e.g. steampowered.com
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. 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.
Someone who wants to avoid all that can register with a hosted service like masto.host that does it all for them.
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.
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.
If a celebrity with millions of followers uses Bluesky, all users across all servers should be able to follow them and like their tweets.
> 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.