auerbachApr 4, 2017

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?

Show threadauerbachApr 4, 2017
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?
Show threadauerbachApr 4, 2017

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

Show threadauerbachApr 4, 2017

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.

Show threadᏒ๐ϲoᴄo Ⅿoԁｅm ᏴaｓіliｓkApr 4, 2017
@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.
Show threadauerbachApr 4, 2017

@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?

Show threadᏒ๐ϲoᴄo Ⅿoԁｅm ᏴaｓіliｓkApr 4, 2017

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

Show threadauerbach
@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.
Apr 4, 2017 at 5:17pmWeb
Show threadᏒ๐ϲoᴄo Ⅿoԁｅm ᏴaｓіliｓkApr 4, 2017

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

Show threadᏒ๐ϲoᴄo Ⅿoԁｅm ᏴaｓіliｓkApr 4, 2017
@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.)