(I wrote this in a dupe of this story so I'm posting an extended version of the message here. Maybe it is useful.)
Maybe that's a good reason to open for federation and now I wonder if it would be possible to have an user migration between servers without cooperation from the origin server. This would allow users to move to a new one without losing track of existing conversations.
Seems crazy, but the reason we can't do this with email is the lack of a generally agreed identity for an user account that does not depend on the server itself. Signal accounts have a "master" key that can provide this and it's only stored in the device and backups (it's the most trusted of all keys, after all).
A sketch:
- User creates an initial account on server X (account: user@serverX.org), the procedure includes signing a message saying "I use server X since $TIMESTAMP and this is the 1st server that I use";
- Everything works as now.
- User wants to change server, so they signs a new message "I use server Y since $TIMESTAMP and this is the 2nd server that I use" (account: user@serverY.org); this message is sent to all chats/groups/contacts and to the old server (as an information only, it may be already down or be non-cooperative). Contacts update the server part of the account and start sending messages through the new one. Maybe the user can still try to contact the old server for a while, for the event it delivers a message from a account that didn't get the first, but at some moment all users will get the new address.
Notice: I have no idea of how this can work with sealed senders of other metadata-prevention measures that Signal uses and we all love.
Bonus: no more dependency on phone numbers.
Or if it goes to an more email-like architecture were users only speaks with their servers, it can adopt concepts from djb's Internet Mail 2000 [https://cr.yp.to/im2000.html]. This will *not* work for current email due to the need of keeping compatibility with the enormous existing user base, but this problem does not exist for a new protocol.
Maybe that's a good reason to open for federation and now I wonder if it would be possible to have an user migration between servers without cooperation from the origin server. This would allow users to move to a new one without losing track of existing conversations.
Seems crazy, but the reason we can't do this with email is the lack of a generally agreed identity for an user account that does not depend on the server itself. Signal accounts have a "master" key that can provide this and it's only stored in the device and backups (it's the most trusted of all keys, after all).
A sketch:
- User creates an initial account on server X (account: user@serverX.org), the procedure includes signing a message saying "I use server X since $TIMESTAMP and this is the 1st server that I use";
- Everything works as now.
- User wants to change server, so they signs a new message "I use server Y since $TIMESTAMP and this is the 2nd server that I use" (account: user@serverY.org); this message is sent to all chats/groups/contacts and to the old server (as an information only, it may be already down or be non-cooperative). Contacts update the server part of the account and start sending messages through the new one. Maybe the user can still try to contact the old server for a while, for the event it delivers a message from a account that didn't get the first, but at some moment all users will get the new address.
Notice: I have no idea of how this can work with sealed senders of other metadata-prevention measures that Signal uses and we all love.
Bonus: no more dependency on phone numbers.
Or if it goes to an more email-like architecture were users only speaks with their servers, it can adopt concepts from djb's Internet Mail 2000 [https://cr.yp.to/im2000.html]. This will *not* work for current email due to the need of keeping compatibility with the enormous existing user base, but this problem does not exist for a new protocol.