Federation Design Plan

Yes I agree with the user transfers bit. It was something that was discussed in the Fluxer Developers server but I didn't have a chance to put in my draft above. But I do think there should be a mechanism to transfer a user's account to another instance. I agree it should be on an approval basis or there can be Instances that are whitelisted for auto-approval. Good thinking about reserving a username for a period of time - I hadn't thought of that. It may make sense to make it permanent or extremely lengthy (like 12 months) since the discriminator is involved. It's not like you're taking away a slot from someone to a unique name.

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.

I've been self hosting a Nextcloud instance since it was Owncloud, and I've recently redeployed a few web apps so I have really started thinking about long term maintenance. Federation is a pretty good vector to fix issues that can build up over time, especially if you need to change domains, or shut down. It can ensure that a community can live on with minimal fuss and is a direct counter to vendor lock in, which is probably why large SaaS providers don't implement it. I know @DamitusThyYeetus123 was also mentioning Federation so maybe we can really start building a discussion around Federation since it's clearly on our minds. ref #1080

with the cryptographic layer and each instance keeping track of any other instances that they have communicated with it should be easy to contact those servers and inform them of the change. As a fall back or just an additional mechanism it would be nice to also do a redirect of some kind with the old domain, but I don't think that should be the only way to update since some people may loose access to a domain. I'm mainly thinking of someone just starting out with self hosting using one of those free subdomain services.

@rennr is it possible we could have communication on the official fluxer dev federation channel? also on the fluxer blog post roadmap it is mentioned that and no instance will store data from outside its own., i want to talk about this with the devs and you to see how literality this should be taken as your DMs are replicated on both the Guest Instance and the Home Instance, from my view, goes against it

Yeah, those seem at odds. Some information would need to be replicated across servers, at least a reference of a chat or channel even if messages are not replicated. DM's have to be stored somewhere and I don't know how you would decide where they are stored if not replicated. Maybe whoever initiates the chat has the messages on their home server?

That would lead to cases where you are unable to access chat history when their homeserver is offline, or has important information deleted (or worse, tampered with), either accidentally or maliciously. DMs being replicated across both parties seems like the logical choice to me for this reason. If this is the decision then the wording should indeed be updated to specify the difference between private chats (DMs) and public chats

@rennr is it possible we could have communication on the official fluxer dev federation channel? also on the fluxer blog post roadmap it is mentioned that and no instance will store data from outside its own., i want to talk about this with the devs and you to see how literality this should be taken as your DMs are replicated on both the Guest Instance and the Home Instance, from my view, goes against it

This was a necessary compromise. The general view I outlined in my post is that there should not be hard, distributed replication like you get with Fediverse or with the Matrix protocol, where effectively the user(s) or instance host(s) in question lose control over the data as it gets copied potentially dozens of times depending on how many instances are participating in a "room" (Matrix) or listening to pub/sub in the Fediverse. Instead, instance hosts should maintain relative sovereignty over the data submitted to their instance. If an individual user is concerned about their personal data to the degree that they do not trust an instance host, they can host their own personal instance, thus bypassing any of the concerns they may have about others. DMs are a bit of an exception because DMs involving individuals across multiple instances necessarily cross these "data sovereignty boundaries". So the compromise would be to replicate all of the communications across all the instances involved in the DM channel. This would prevent any one instance from dropping offline for example and wiping out everyone's DMs (regardless of which instance they belong to). It would also prevent a single instance from being responsible for the data of many instances, creating a potential undue burden. There would of course need to be some sort of synchronization mechanism whereby edits or deletes from one instance's members are replicated to the other instances. But this in my view would be relatively trivial. While there may be concern that an instance could ignore deletion requests or edit requests, the likelihood in my view is low. And simply warning a user that their chats are replicated outside of their home instance would be sufficient - if this truly worries them, they could decide not to engage in DMs across instances.