The federation/migration problem in mastodon seems very important. My broader thought: SMTP/NNTP/etc. thrived because of a set of trusted entities (govt/uni) that could reliably run federated servers. My choice of server is going to be based on which one is most likely to be up and running years in the future.

Who should those entities be today?

I bet someone has already proposed using blockchain to enforce global username uniqueness, so that accountnames aren't tied to an instance. Am I right?

I worked on instant messaging federation for a time back in the day. Check out the history of xmpp (and Google/Pidgin) if you want to see things NOT working out for attempted federation.

Unfortunately, all the easy solutions I can think of begin, "Assuming the triumph of global anarcho-syndicalism..."

The blithe "Pick a server that you trust" on the mastodon sign-up page sums it up. I'd feel foolish saying that I trust any server right now, and I don't even know what criteria to assess servers by.

The most obvious criterion is number of users, which will dissuade federation, as @bcrypt points out.

The second most obvious criterion is, I guess, "Run by some big/huge entity likely to stick around for a while," which has its own problems too.

@auerbach @bcrypt How about trust as in "run by you or someone you know" -- maximizes federation, but limits accessibility to people who can figure out how to set up a server.

@enkiv2 @bcrypt I don't trust that any server I or my friends run will be up in a year, much less 5.

And I'm not sure I understand why you want to limit accessibility?

@auerbach @bcrypt Limited accessibility is an unfortunate downside. Ideally something like this would be easy enough that non-technical users could run their own instances on their own machines with minimal setup.

If you know and trust the people running a server, migration is easier because you can negotiate for someone else to physically take the box, if somebody moves or something.

@enkiv2 @bcrypt But this only seems workable if the network can tolerate instances being transient. That may in fact be the best approach, but it's not what mastodon is currently built for. Ideally I would like non-homed accounts and reserve mastodon servers for authentication *only*, but I recognize that's a real pain. I still incline to thinking certificates & DNS (well, a better DNS) are a more solid starting point than SMTP/NNTP (and certainly xmpp). But I dunno.

@auerbach @bcrypt That's one way to do it. An alternate mechanism would be to have close to a 1:1 ratio between users and servers in the federation (say, by building it into the web browser) & making restoration very easy.

Details depend on how replication & caching work in this federation model.

I'd be surprised if bringing up the exact same image on another IP after transferring the domain & certs would fail.

@auerbach @bcrypt Honestly I'd like something less like DNS & more like IPFS, where running your own node is very straightforward & a public proxy is mostly a service for new users. (And where nodes that display content cache it and will replicate it to peers, making short outages less of a problem.)
@enkiv2 @bcrypt @auerbach I've come to believe that making it easy for non-technical people to run their own servers is one of the most critical problems needing solved if we ever want to get away from what Bruce Sterling calls "The Stacks"... (and for a bunch of other reasons as well)... unfortunately, it's hard to compete with "someone else does all the work for you for free".

@zwol Well, it has its own problems.

Basically every non-technical user on mobile has a linux box in their pocket. It's a security nightmare because nobody involved has much interest in patching known vulns, except the non-technical end user.

Maybe we need to meet in the middle? Make stuff that's easy to set up & keep updated, while simultaneously educating users, outside a commercial context.

@enkiv2 I don't see how that's "meeting in the middle"; the two halves of your statement are complementary work to be done, not a compromise position. ;-)

The "everyone has more computer in their pocket than anyone has really grokked" issue is related, but I don't think it'll ever be the Right Thing to run one's personal server off one's mobile. If nothing else, you don't want to run out of battery just because your website got slashdotted (yes, I'm old and I still call it that).

@zwol Federation is definitely a compromise between true p2p and hierarchical client/server. Improvements to routing & replication will eventually make full p2p feasible, along the lines of micro-federation. It's this configuration that's most important to keep secure & usable. And this would be, essentially, the everyone-has-a-node-in-their-pocket case. I think it really is the Right Thing, and that a client/server distinction is not ideal for anything social.
@auerbach @bcrypt Re: trust, I think people drawn to federated social networks have an interest in having them controlled by people they trust not to fudge/sell their data or keep/distribute it outside what they allow, even if it means having many temporary identities or doing a lot of migration. The two kinds of trust are sort of in conflict, because of the economics of scaling even a pretty tiny federated hierarchical system.