The death of a Mastodon node is inconvenient, but not identity-ending (especially if one uses static indirection to link your abstract Mastodon ID to a concrete instance).
Can you tell me more about that? If you just redirect webfinger requests, don't you still lose everything if your current instance disappears or you move to a new instance?
Webfinger redirects control what people look you up by.
The domain of the URL of the actor webfinger resolved to defines how clients access your profile.
They are usually the same domain, but don't need to be. Effectively your webfinger address functions as an alias (and you redirect multiple URLs to the same actor)
Follows follow the actor, so your webfinger may break and follow relationships will continue.
If the actor url becomes unavailable, however, your profile is inaccessible whether or not you redirect the webfinger.
To get Bluesky like portability we'd need either for that actor url to be possible to point to a DID or other means of decentralized lookup mechanism, and/or for servers to store the webfinger handle and recheck that regularly, and a way for clients to control a key that can be used to sign claims to say "this new instance key is also mine".
It's very much doable, but not done, nor is there consensus about exactly how.
Best current option if you don't want to host your own instance is to control your webfinger domain; if your instance goes without warning so you can't use the normal migration, you'd still need to manually get people to follow you again, but at least you can point them to the same id.
IMO WebFinger was a bad idea for ActivityPub in the first place (and it's not in the spec). It makes it a lot more hacky to statically host your profile, and the indirection is confusing. As far as I know the presupposition that users would find URIs as IDs confusing is just an assumption that was made early on.
> To get Bluesky like portability we'd need either for that actor url to be possible to point to a DID or other means of decentralized lookup mechanism, and/or for servers to store the webfinger handle and recheck that regularly, and a way for clients to control a key that can be used to sign claims to say "this new instance key is also mine".
Or just eschew this complexity entirely and use URIs as IDs. Make permanent personal domains much easier to buy and use.
ActivityPub only deals with URIs. Including in Mastodon. Mastodon then layers WebFinger on top, but you can still give Mastodon the actor URI and it works just fine, and all underlying interactions use the actor URIs. E.g. follows are between actors by URI, not between webfinger IDs. If you want to pretend Webfinger isn't involved, you can choose to do so.
> It makes it a lot more hacky to statically host your profile, and the indirection is confusing. As far as I know the presupposition that users would find URIs as IDs confusing is just an assumption that was made early on.
I wish WebFinger specified a URI format that made it possible to do fully statically without breaking the spec -, but the minimal "implementation" using an otherwise static file takes a URL rewrite with a single small regexp. It's not an issue for anyone who understands what's going on well enough to need/want to decouple their webfinger response from their ActivityPub actor. If you just want to point at an instance you can just do a static redirect.
However, that is mostly orthogonal to the portability issue.
> Or just eschew this complexity entirely and use URIs as IDs. Make permanent personal domains much easier to buy and use.
Then you've traded one kind of complexity that provides decentralization as an option, for a massively larger complexity problem that involves navigating a lot of government bodies, a highly self-interested bureaucracy, and a number of major multinational companies. I co-founded the company that launched ".name" - the bureaucracy may have tapered off a bit, but it's still a nightmare. Reforming that space in any kind of meaningful way that wouldn't leave your identity beholden to an intersection of centralized government and corporate interests in not likely to happen anytime over the next decade or three.
The portability matters to some of us. It just doesn't require ditching ActivityPub. And it doesn't require all that much complexity - all it requires is to allow DIDs to be used as an alternative means to identify or update the actor URL in a relationship. You can keep backwards compatibility by allowing resolved actor URLs to keep working, and just add a signed reference to the DID in the profile and the webfinger response. Then clients and servers that supports it can use the DIDs to allow discovering a moved profile, while clients and servers that don't support it will behave just as before (work as long as the actor URL works; fail if it stops working without a preceding move).
Because of federation, it's even fairly trivial to sort out a simple DID method that needs no central authority: Spread the DID document to all the instances you have followers on, and allow rediscovery by pinging those servers from a new instance with a request to use the keys to validate an updated DID document at a provided new instance. Let every instance act as a first resort to bootstrap recovery, and every instance you interact with act as fallbacks to help you recover control, as long as your clients keep backups of the relevant private keys.
And if you include those DID references in the profile as well, then just as now you can choose to ignore webfinger if you prefer.
Yes, this will take time to get right, but some variant of proper portability is just a question of time.
It's a good point, though not one I'd really considered because I never consider microblogging to be anything but ephemeral data (note the lack of a robust search solution also; this is not a place to chisel the words for which countless generations will remember you).
I'd love to see the ability to import a timeline. Sadly, that's not a feature of Mastodon right now AFAIK (though an admin handed a SQL dump and relevant image blobs could probably merge it into their node, but it'd be a hassle).
Truly portable identity via DIDs, ie you can keep your underlying identity even if you migrate servers, is one of the key reasons the Bluesky team made their own protocol. https://atproto.com/guides/faq#why-not-use-activitypub
And there was no need to make a new protocol for a portable identity - a change to ActivityPub to support did's as actor urns would be sufficient, and would also open the door to unilateral account migration fairly easily.
This is my big problem with Bluesky - all of their gripes about ActivityPub would be easily solved in ways that'd make interop a temporary problem of getting people to buy into protocol tweaks, instead of inventing something from scratch.
Their claim that it's not easily possible to retrofit e.g. did's and signed repositories onto ActivityPub makes me question whether they understand ActivityPub at all, because there's nothing about it that would be problematic. E.g. objects are already signed - their mechanism for migration would require some changes to the signing mechanism to allow users to make a unilateral assertion that the key on their new instance belongs to them, but not much more. DID's is down to how ActivityPub clients and servers resolve URLs, nothing more.
You wouldn't even need everyone to buy into these changes - the worst case would be lack of federation w/instances that fail to support it - in other words no worse than starting your own network.
Even then it'd be possible to maintain fairly broad interop by announcing the did's in ways that'd allow also specifying resolvable urls to a proxy.
I set my Mastodon posts to auto-delete after 6 months so I don't care if I lose them, and I made sure to have some "me" links in the appropriate places pointing at my profile. Even if I were to lose that paper trail from doing proper account migrations, it's pretty easy to say which profile is mine. And if I lose followers, so be it. I'll follow people when I remember who they are. I'll make new posts. If I don't, that's fine. Life happens.
It's not ideal because there isn't a reverse link; if someone-else-owns-this-server dies, people who were following you on it will see you evaporate. But you can edit @you@site-you-own to point to @you@your-new-site so that at least people holding your ur-name can find you.
But unfortunately, there are few better solutions when someone else owns the data. One nice thing about the Fediverse is you can ameliorate most of this by setting up your own server (though I won't pretend that's going to be the solution that replaces everyone using Twitter; I maintain my own server and it is the same pain in the ass that self-hosting has always been).
Why do I need to run a webserver for this redirection? I don't have one; my TLD is essentially for email only.
AT proto lets me achieve the same goal using just a TXT DNS record.