ActivityPub really needs some decoupling of identity from server. If a server I'm using starts acting up, the answer is to move servers, right?
But, wait, my 50K followers from Server A won't be following me on Server B. Essentially, you only get to pick your original server once, without having to rebuild your network. So choose wisely!
This obviously isn't an easy problem to solve. You'd need to separate identity from hosting, and have some way to look up "identity A is on server D" so peope following identity A know where to get the content.
I truly believe it's essential to the success of the protocol, though.
I'll take it a step farther. One of the consequences of building a distributed network is that individual nodes are much more likely to fail than a centralized node. The overall network health is going to be better, but for a given random article or person you find online somewhere, the odds that the server does something screwy are a lot higher because the server is smaller and has less backing.
It's not just about separating identity from hosting so that content creators can move around - content itself needs to be separated from its hosting. I want to be confident that if I share a link to some content, that content is still going to be available at that link 4 or 5 years from now. Minus that solution, in some ways ActivityPub actually makes my life worse because it means content moves around more often.
Mastadon and PeerTube are great examples of this - instances are not an implementation detail of these platforms that we could swap out later for something more robust - they're a core concept that's talked about at a user-facing level. That's insane to me. Why on earth do we even have the concept of an instance or a server? Why is it baked so hard into our protocols as to guarantee that we can't possible get rid of it in the future?
Sure, someday maybe IPFS will completely solve the problem and we'll switch off of URLs. But probably not soon. So we should be trying to find mid-term solutions that allow us to separate identity and content from a location regardless of whether or not we're using IPFS. We should be designing everything around that constraint.
I think there are a lot of blockchain projects working on exactly that issue now - I like to think about an internet that is totally distributed yet (because of blockchain) totally secure. I'd like to think it would make the internet at large even more secure, avaliable, and faster, but I don't know enough of the technicals to know if that is actually feasible or just a pipe dream.
This is what the whole IndieWeb movement is about -- being distributed rather than merely federated. I'm mildly concerned that the two camps seem to be building their own protocols rather than working together (excepting the existence of Bridgy Fed, perhaps).
Good point -- it would actually be simple to combine IndieWeb + Mastadon and solve this problem.
IndieWeb's solution is to own your own domain: https://indieweb.org/personal-domain. If you control your DNS, you can move your data to a different back-end provider and just update your DNS entries.
To combine this with Mastadon, just make your own domain, like https://chipotle.coyote, and point it at Mastadon-Server-A. Then if you want to move everything to Mastadon-Server-B, just copy the data and update DNS.
I agree with you but for the general social medial user updating the DNS records sounds scary and complicated. And for such user even if the idea of owning their own domain might sound compelling, how many will simply forged to renew the domain, be done with it and move to the next facebook.
I'm not sure it does solve the problem. Extreme example, but when you die, won't your domain registration lapse?
And you can argue that doesn't matter at that point, but it kind of does if I want to be able to use a social network for something like collective scrapbooking or time capsules. Or even just if I want to make sure that essays, projects, and Open Source work are permanently accessible to people who care about them.
Competition is good, but cooperation is also good, and protocols benefit enormously from network effects. (No pun on network protocols intended.) I suppose this isn't zero sum, though, strictly speaking.
It is social media, why does this need to be handled at the protocol level? Post a final message on the "You@ServerA" account saying "This is my last post here, keep talking to me with my new account: You@ServerB"
Anyone who visits your old account will see the last message. Anyone who sees that message and can't muster the effort to make 2 mouse clicks probably isn't a follower except from a numbers perspective.
If you're content losing 90% of your followers because the server you host on decides to implement draconian censorship or start charging $50/mo, then yeah, be my guest and use the protocol as it is.
I personally think tying identity to a particular server instance is the wrong approach, whether you can beg your followers to come find your new location or not.
Also, your method only works if the server is still up. If your host server is taken down indefinitely, then you truly do get to rebuild your network again. Fun.
As a human, social, user of Mastodon, yes that's totally fine with me. 50k followers is absurd, I have maybe in the 100's of social connections, and realistically only maintain in the dozens of meaningful conversations with people. I just want a means to have those connections that's not feeding some omnipotent beast.
I'm assuming your values are something else. Do you monetize your social media followers/follower count in some way? For some professions it's smart and necessary, but for my career it's not relevant in any way at this point.
I'm thinking of business use-cases, yes. For instance, I agree with you, if my personal twitter was lost, I wouldn't lost any sleep over it. But if my business twitter was lost, which has almost 1500 followers and took years to build up, I'd be pretty upset. And I don't have a deep connection with all of those followers, but if 10% of them see each post I make, that's a lot of marketing value to me.
But, wait, my 50K followers from Server A won't be following me on Server B. Essentially, you only get to pick your original server once, without having to rebuild your network. So choose wisely!
This obviously isn't an easy problem to solve. You'd need to separate identity from hosting, and have some way to look up "identity A is on server D" so peope following identity A know where to get the content.
I truly believe it's essential to the success of the protocol, though.