> Until an instance goes down either temporarily or permanently and it was your only account.
That's a technical problem, but not a UX or system design one. If a server goes down, my backup account is only going to allow me to keep participating, but it is not going to save the conversations I had on the lost one.
> Accounts aren't portable but there's no inherent reason that accounts need to map 1:1 to identities.
Again, you are talking about identity portability, which is not the same as "creating one different identity for each different server".
> my backup account is only going to allow me to keep participating, but it is not going to save the conversations I had on the lost one.
The same issue exists for other services including email, irc, and matrix. The obvious simple and immediate solution is to retain copies of things you care about locally instead of expecting a particular service to stick around forever. With email this used to be standard practice before the rise of webmail. Even now most desktop clients sync to and retain a copy of everything on the local device.
> > Accounts aren't portable but there's no inherent reason that accounts need to map 1:1 to identities.
> Again, you are talking about identity portability, which is not the same as "creating one different identity for each different server".
It seems like it is though? Servers need a way to handle authorization so they presumably need accounts. With a simple protocol, accounts map 1:1 to identities as far as the software and protocol are concerned. If you make a new account then you also make a new "identity" from the perspective of the software. The obvious way to solve that is to map any number of accounts to one (or possibly multiple) identities, where an account is the thing the server is concerned with and an identity is something else such as a private key.
There's an additional question about the mechanisms for account creation and authentication. Maybe you don't want to maintain an email and password based login for a long list of accounts that are each tied to the same backing identity. There are multiple approaches available there as well, from oauth providers to public key based authentication possibly including things like cross signing.
> The same issue exists for other services including email, irc, and matrix (...) expecting a particular service to stick around forever.
It doesn't have to be like this. This is the point where identity portability comes into play. If the identity belongs to the user and they carry to different servers, the user is independent from the provider.
In the case of email/irc/matrix, as long as you own the domain name, you can change the service provider whenever you want.
You seem to be describing hosting your own service, changing the underlying hosting provider, and tying your identity to ICANN DNS.
There are two separate things here, identity portability and data portability. If your identity is portable (say a key pair) but the service hosting the data goes down and you don't have a backup or there's no way to import the data to a new provider then you've got a problem. Similarly, if the service goes down and you do have a backup of your data and a way to import it to a new provider but your identity isn't portable (perhaps it was user@domain and you don't own the domain) you also have a problem in that case but it's a different problem.
And neither data nor identity is the same as account, at least the way I was using the words.
> You seem to be describing hosting your own service
No, it still gets to be hosted by someone else. And it is not just because I am using a custom domain that it requires a separate server. "Shared hosting" has been a thing for web and email forever, and there is nothing stopping* a matrix or an activitypub server to process requests for different users on different domains.
> tying your identity to ICANN DNS.
Not necessarily. If you see the linked conversation I had with Alex, it was about using Ethereum ENS. It could also be something based on OpenID. The important thing is that the actorid in activitypub can be anything that can be authenticated by the server, it doesn't have to be only the internal username.
* there is a current limitation on matrix synapse (where the homeserver can serve only one domain), I don't see anything on the protocol that forbids the implementation of a multi-tenant server. Perhaps it is not a top priority because such a server would incentivize big hosting companies to offer it as a service and possibly re-centralize it.
That's a technical problem, but not a UX or system design one. If a server goes down, my backup account is only going to allow me to keep participating, but it is not going to save the conversations I had on the lost one.
> Accounts aren't portable but there's no inherent reason that accounts need to map 1:1 to identities.
Again, you are talking about identity portability, which is not the same as "creating one different identity for each different server".
In any case, I totally understand the use case and I tried to get the Pleroma devs to focus on this idea as well: https://mastodon.communick.com/@raphael/106825107786781891