Sovereignty
With Sync-in, users retain authority over their files throughout their lifecycle: where they are stored, how they enter a collaborative context, how access rights propagate, and which rules continue to apply as they are used.
This approach rests on five connected principles:
- Data remains controlled and reversible, independently of the application.
- Collaboration is layered onto files without absorbing or unnecessarily duplicating them.
- A new context cannot indirectly expand the rights defined at the source.
- Provenance and responsibility remain attached to the original location.
- The same governance follows the data through every access method.
The governed sharing chain is the clearest expression of these principles, but it is part of a broader architecture designed to preserve control before, during, and after collaboration.
Data remains primary and reversible
Sync-in's storage model keeps file content directly readable on the filesystem, so using, backing up, migrating, or processing data does not depend on an application-specific repository. Collaboration adds functional state around the files without making the database their mandatory source of truth.
Targeted metadata, filesystem reconciliation, and support for external locations implement this principle while preserving the controlled location of the data. Their storage mechanics are described in Foundations.
Collaboration without dispossession
Virtual anchoring makes a personal file or folder available in a collaborative space without moving or duplicating it. Its effective rights are the intersection of the permissions at the original location and those of the collaborative space: a new context can preserve or reduce access, but cannot expand it indirectly. The underlying mechanism is detailed in Foundations.
A space manager can rename an anchored file within the space or remove its anchor, but cannot modify the permissions defined by the file owner. The manager remains subject to those restrictions even while administering the space.
Delegated sharing follows the same non-escalation principle: every recipient can transmit only rights they already hold.
From access permission to governed delegation
| Conventional access model | Sync-in sharing model |
|---|---|
| B can access a file because A granted access. | B receives a delegation from A, limited to the rights A granted. |
| A manages the access granted directly to B. | If B is allowed to share, B may redelegate to C without exceeding the received rights. |
| Further sharing is considered as another permission. | A retains visibility and control over the resulting descendant shares. |
The model treats sharing as a governed chain of trust. A recipient may become a delegator, but the new delegation remains attached to the chain from which it originated. Rights can be preserved or reduced along the way; they cannot be expanded beyond those held by the delegator.
Although a simple example forms the chain A → B → C, a recipient may create several shares. The resulting structure can therefore branch into a
tree while retaining the same governance principle.
Governance throughout the share lifecycle
The owner of an initial share can inspect all shares that descend from it, including shares created several levels further down. The owner can edit or delete these descendant shares when the collaboration context changes.
Collaborative spaces extend this oversight to the organizational level. A space manager can view and manage every share created from the space, including child shares created by members. This prevents delegated sharing from becoming invisible to the people responsible for the space.
The lifecycle follows explicit rules:
- When a member is removed from a share or collaborative space, the shares they created from it, together with their descendants, are deleted.
- When a parent share is deleted, its entire descendant branch is deleted with it.
- When a member only loses the permission to share, existing shares remain active; the member can no longer create new ones.
- When an anchored file is removed from a collaborative space, the shares created from that file and their descendants are deleted.
These rules tie access to the context in which it was delegated. Removing that context also removes the delegations that depended on it.
Provenance and responsibility remain attached to the origin
Sharing or anchoring a file changes where it can be used, but does not erase where it comes from. The original location continues to determine the storage responsibility associated with the file.
The quota consumed by a shared file remains attached to its source, whether that source is a personal space or a collaborative space. Likewise, when a member deletes a file through a share, it is moved to the trash of its original location. Access may circulate through several contexts while storage accounting and recovery remain tied to a clear origin.
This separation between usage context and data responsibility lets teams collaborate without making data provenance or storage responsibility ambiguous.
A persistent architectural model
The sharing chain is part of Sync-in's data model, rather than a hierarchy reconstructed only by the interface. Every share created from another share stores a reference to its immediate parent. Sync-in uses this relationship to traverse descendants recursively, calculate their number, expose them to owners and managers, and apply lifecycle operations.
The same relationship enforces cleanup: deleting a parent share cascades to its children. During creation and permission changes, delegated rights are intersected with the rights available on the parent share or collaborative space. Persistence, permission inheritance, supervision, and revocation therefore rely on the same parent-child structure.
Because every descendant has one immediate parent, this is more precisely a persistent parent-child tree than an unrestricted rights graph. The term sharing chain describes how trust and authority propagate through that tree.
Governance follows every access method
Governance remains attached to the data and its collaborative context when it is reached through the web interface, WebDAV, synchronization clients, collaborative editors, APIs, or full-text search. These entry points rely on the same permission model, so switching tools or protocols does not create a separate route around the rules established by owners and managers. The shared services that provide this consistency are described in Foundations.
Sovereignty after sharing
Self-hosting answers an essential sovereignty question: where is my data and who operates its infrastructure? Sync-in's architecture extends the answer to the full collaborative lifecycle: the data remains readable and reversible, collaboration does not transfer control away from its source, rights cannot be expanded by changing context, provenance remains identifiable, and governance follows every access method.
Governed delegation brings these properties together once information starts circulating. This explicit treatment of rights propagation is a distinctive emphasis in open-source document collaboration. It does not depend on a claim of uniqueness; its value lies in making the circulation of information governable without surrendering control of the underlying data.