Comment history

Versions of a comment on Federation Design Plan, newest first.

Current version | Edited by Rex
Changes
Removed: > [@rennr](https://github.com/rennr) is it possible we could have communication on the official fluxer dev federation channel? also on the [fluxer blog post roadmap](https://blog.fluxer.app/roadmap-2026/) 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 itAdded: > @rennr is it possible we could have communication on the official fluxer dev federation channel? also on the [fluxer blog post roadmap](https://blog.fluxer.app/roadmap-2026/) 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 itThis 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.
Show
@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.
Original by Rex
Show
@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.