3 ms·

I would also like to hear more about this. AFAIK there's no way to keep your ActivityPub identity if you (or the instance owner) loses access to the domain it's

I would also like to hear more about this. AFAIK there's no way to keep your ActivityPub identity if you (or the instance owner) loses access to the domain it's hosted on.

vidarh 3y ago
It's more complex and depends on what you consider your identity. 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.
- apitman 3y ago
  The complexity of your answer illustrates my frustration. Identities should be URIs (a la IndieWeb). 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.
  - vidarh 3y ago
    > Identities should be URIs (a la IndieWeb). IMO WebFinger was a bad idea for ActivityPub in the first place (and it's not in the spec). 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.

I would also like to hear more about this. AFAIK there's no way to keep your ActivityPub identity if you (or the instance owner) loses access to the domain it's hosted on.

vidarh 3y ago

It's more complex and depends on what you consider your identity. 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.

apitman 3y ago
The complexity of your answer illustrates my frustration. Identities should be URIs (a la IndieWeb). 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.
- vidarh 3y ago
  > Identities should be URIs (a la IndieWeb). IMO WebFinger was a bad idea for ActivityPub in the first place (and it's not in the spec). 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.