RexSystem1 voteoriginally by @Haplo164 on GitHub1 reply
Pretty good write up, I think it's important to clearly know where chat data is stored and having it on the Guild Instance is probably best. I also think there should be a method to signal a domain change. Matrix doesn't have a way to change a servers domain so you basically have to start a new server, and that really sucks. With encryption keys you should be able to signal that a name change has taken place and update all records to reflect that.
edit: it would also be nice to allow user transfers, it might be best to limit transfers to 2 online instances where the users current Home Instance initiates the transfer and the destination Instance confirms, this would move all private chats to the new Home Instance and updates the messages associated with the transferred user to point the the new Home Instance. The old Home Instance should maintain the old username as unusable for a time and respond to any requests involving the old user with a "Transferred" status and redirect to the user on their new Home Instance.
I also agree with the domain name change event. With the cryptographic key, as you say, the domain name change can be evidenced.
As extra protection, should there be some extra verification step in place? For example:
Instance is transferred to a new domain but would still accept requests on the old domain. Clients are unaffected and continue to connect to the old domain during a transition period.
Instance sends a message to its federated Guest Instances signalling a domain update. The signed message also includes a validation code that Guest Instances can look up by pulling the old and new domain's TXT record.
Guest Instances pull the SRV and TXT records of the old and new domains.
If all is correct, the Guest Instances update all user records, messages, attachments, etc. to reference the new domain.
Thread
Comment by @Haplo164
Comment by @rennr