You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Apr 26, 2024. It is now read-only.
These problems include having to reapply all notification settings for all re-joined servers. Re-validation of all clients using the new server, reopening and re-exchanging of keys for encrypted conversations. The list goes on.
The biggest problem however is when the old account had administrative or moderative privileges on servers.
There is absolutely no reason why it should not be possible to move a users identity between servers as it can easily be represented as an encrypted database entry to whose decryption only the end-user may hold the key. information exchange of this nature is already a thing by the very nature of federation and actively used to synchronise message histories.
What's more a users identity can already be verified across servers. so why is it not possible to move it's point of origin as well?
From the perspective of a chat-room it matters not where an identity comes from. It is a unique fingerprint whose usage validity by a client can optionally be verified already.
Giving users the option to transfer this client verification (maybe in encrypted form) during a server-move would effectively enable a user to decrypt/verify the moved ID on the new server and therefore, from then on, use it from there to identify against chatroom, verify client and keep encrypted conversations and privileges associated to the ID on chatrooms.
The text was updated successfully, but these errors were encountered:
There should be an option to transparently move account between servers
Core problems of moving to a different server is the work associated with it, even when using https://modular.im/tools/matrix-migration.
These problems include having to reapply all notification settings for all re-joined servers. Re-validation of all clients using the new server, reopening and re-exchanging of keys for encrypted conversations. The list goes on.
The biggest problem however is when the old account had administrative or moderative privileges on servers.
There is absolutely no reason why it should not be possible to move a users identity between servers as it can easily be represented as an encrypted database entry to whose decryption only the end-user may hold the key. information exchange of this nature is already a thing by the very nature of federation and actively used to synchronise message histories.
What's more a users identity can already be verified across servers. so why is it not possible to move it's point of origin as well?
From the perspective of a chat-room it matters not where an identity comes from. It is a unique fingerprint whose usage validity by a client can optionally be verified already.
Giving users the option to transfer this client verification (maybe in encrypted form) during a server-move would effectively enable a user to decrypt/verify the moved ID on the new server and therefore, from then on, use it from there to identify against chatroom, verify client and keep encrypted conversations and privileges associated to the ID on chatrooms.
The text was updated successfully, but these errors were encountered: