Seeing how community is concerned about data sovereignty with multiplayer, e.g. export permission, I wonder if it is possible with Anytype’s infrastructure to limit editor/viewer’s access to only when owner/editor is online.
I am not sure if my understanding is accurate, but since users can edit objects when s/he is offline and re-sync the edition history, and there is a CRDT conflict resolution, I imagine with shared spaces/objects, there is always a copy of the data on editor’s device?! Then what about viewers? Do they get a copy as well?
What about encryption? How is encryption managed on multiplayer, when and where? Anytype Docs only explain encryption with Anytype backup nodes…
Would it be possible to refrain viewers to get a copy? Like when server is offline, users don’t have access to the webpages because server is the access point to the data. OR decryption only possible when online?
– Would this cause conflict to the decentralised concept?
– Would such implementation cause excessive traffic on users’ device?
Access control: Currently, viewers and editors have equal views of the objects, however there are many cases where viewers should not view certain objects or editions.
- Sometimes when objects are not ready to be viewed (e.g. not final version), we don’t want viewers to access the objects yet or don’t want viewers to see the work progresses. For example, when objects are being worked on, we only want access within the same team (possibly even only local-only); when the objects are ready to be review or share, we grant access completed objects to department(s) ; then later, we share final version and final version only to clients or outsiders (viewers only).
– In the current structure, we would need to have at least two instances of Anytype (local-only and networked) and two spaces (distinguishing authorisation; one for team and possibly another for department, and one for external or mimicking publish)
– Network setting per space could reduce required instances
– Exporting / sharing objects to different spaces for creating access control points could control how much data editors/viewers could access. But this doesn’t look like a seamless workflow. Although this would create clear boundary between what’s shared and what’s not, so it is safe, but efforts to maintain spaces would be high. This also increases the potential need for number of spaces. - Especially with the future discussion feature, other departments don’t need to know what team discussed; client must not see internal discussions.
P.S. Maybe we need some gallery demonstrations for multiplayer usage.