In only one day, I've noticed increasing latency on mastodon.social. That's to be expected, but what's the end-game here? Drive centralization by backing this instance with more hardware? Encourage federation by capping the number of users on this instance?
Follow-up: any strategy to encourage increased federation is dead-in-the-water without a good story for identity portability.
At minimum that means: an automated way to move follows and followers to another address.
Ideally, there would be a way the migrate content too, but microblogging is pretty forgetful so I don't think this is a requirement.
@ttuegel Eugen's going with just scaling this one up, it seems like. If there's going to be a push for federating out to more servers, it's probably going to have to come from the users.
@ttuegel there are a lot of programmers here, surely someone could work on this.
not me, i'm not a real programmer, i just like talking about monoids
@argumatronic There's implementation, but first there's design.
At the moment, the network supports toots, boosts, and favorites, and notifications about the same. I can export the list of users I follow and import at a new address. I cannot, however, broadcast a new name for myself on the network, such that followers of the old me will follow the new me instead.
This is not a trivial design problem. It must be seamless for you, but keep my identity secure.
@ttuegel what do you mean by "secure"?
@argumatronic A bad actor must not be able to redirect my followers to someone who isn't me. That sounds trivial, but consider that while I trust the admin of my instance, I may not trust yours.
This should apply across time also, so that a deactivated address does not become available again.
@ttuegel mmm yes, i see. these do seem like nontrivial issues. are there any models around for doing this well?
@argumatronic The other major federated services where personal identity is important are e-mail and IRC.
E-mail identity management consists of sending your new address to all your contacts and hoping they change it in their address book. I'm in the process of moving my e-mail out of the U.S. and I can tell you it takes several reminders to get it done.
IRC solves this problem by centralizing identity verification with NickServ. This only works because IRC has a single namespace for nicks.
@argumatronic One way to publish a canonical, authoritative identity database without centralization would be:
[Pause for breath]
A blockchain-distributed, Webfinger-accessible public key database.
Like Keybase, but more buzzwordy.
@ttuegel Why do I need to?
@chris_martin If copy integrity can't be verified, then I'll just put up a copy of the list with my public key in place of yours, allowing me to spoof your identity.
@ttuegel Oh right, if you need to register names. But you don't - you just need a list of signed "this pub key is the same identity as this other pub key" assertions, then I can just issue a signed toot that says "this pub key is me"
@chris_martin What if I generate a new public key for a new account and issue an assertion that it is the same as one of yours?
Well, that problem is easy to sweep under the rug by requiring one-to-one mapping of identities and keys. This is what Keybase does, for example, but you'd want to take Keybase out of it.
I thought I had an even simpler way to do this, but it is really hard to do if I don't necessarily trust your instance.
@ttuegel If wouldn't matter, because trust follows assertions in one direction only. If somebody knows that I'm key A, then an assertion by key A that is it the same as key B links the two, and an assertion by key B that it is the same as key A is meaningless.
@chris_martin That's fine, but if all this requires you to retain access to key A, why bother having multiple keys at all? Why not tie each identity to one key only so there is no list to distribute?
@ttuegel Perhaps because it prevents you from ever needing to export a private key from the server it was generated on?
@ttuegel None of this is the system I would design, but I'm starting from the premise that you have an identity on each Mastodon instance because that's apparently something people are really into.
@chris_martin The use case I was thinking of wasn't "How do I run multiple IDs concurrently?" as much as "How do a migrate an ID once, because this instance is getting to crowded or shutting down?"
@chris_martin Generating keys remotely is :nauseated_face: ! That gets back to trusting other instances. If you generated a private key on another instance, I can never trust that key. For that matter, neither can you!
Of course, I can never be certain you kept your private key safe if you generated it locally, but at least that doesn't invite abuse.
@ttuegel If I have an account on some instance, and I want it to be able to toot *as me*, that doesn't that necessarily mean I trust the operator?
We're not talking about a system where you sign every toot with keys you hold yourself, right?
@clacke I don't want that at all, I just want to automate the age-old process of telling all your friends "hey, I moved and my new phone number is ..."
@chris_martin @clacke if both accounts are up you could establish a two way rel="me" relationship between the accounts and people and computers could determine that you're the same you across the two accounts. it doesn't have more or less trust than you give a single server right now in the fediverse.
@argumatronic What I'm saying is, there's no need for programmers yet, real or otherwise. ☺
And I don't know who told you you're not a real programmer, but the programming book you co-authored is pretty thick. Maybe hit them with that.
@Meaningness I think part of the key here is to separate sync and broadcast into independent operations. This…thingy…conflates them.
@bitemyapp Not sure I follow—what is sync'd and what is broadcast?
@ttuegel Totally agree. StatusNet used to have some support for migration, but the UX story for this needs to be solid.
@ultimape I agree that the ability to migrate content is important. Maybe this is a problem where blockchain methods can live up to the hype. 😀
@ttuegel Content is important too - I routinely remember some tweet or reply from my Twitter history and then go and search for it on Pinboard (since Twitter's search sucks and for now I have Pinboard indexing my tweets for me).
I think people don't do that, having indeed the perception that microblogging is "forgetful", simply because searching your history on Twitter or Facebook is awful.
@ttuegel that was my initial reaction, then I thought about what happens when the trolls turn up (and they will turn up).
Let's posit a swarm of trolls who move from server to server. A couple of them get warning from an admin, then the plague just moves onto another server at a single klick.
Maybe there needs to be a cost involved in moving.
@chris_martin Personally, a strong push towards federation. Like what Evan tried to do as he transitioned from Identi.ca to pump.io. At pump signup you had to pick an instance.
@ttuegel I think one of the best things we can do to increase federation is to help folks understand the benefits of other instances.
I'm on Mastodon in part because I'm scared to enter into a bunch of other networks, but maybe we can make this experience better/easier.
I agree re:portability, but I'm also sensitive to the demands already put on Gargron and others running instances for us
Server run by the main developers of the project It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!