Skip to main content

Foundations

Sync-in is built on design choices that prioritize storage control, access consistency, and operational scalability.

  • Readable and reversible storage, with files kept in their original filesystem.
  • On-demand metadata, created only when a feature requires it.
  • Operational scalability, without a mandatory full database mirror of the file tree.
  • Access consistency, regardless of the entry point: web interface, WebDAV, synchronization, editors, or API.
  • Collaborative governance, with spaces, granular permissions, virtual anchoring, and nested sharing.
  • Native interoperability, through WebDAV, synchronization clients, and document integrations.
  • TypeScript foundation, to strengthen interface consistency and rely on the JavaScript ecosystem.
  • Integrated security, based on consistent permission, locking, and traceability rules.

These choices translate into several key mechanisms that structure Sync-in's architecture.

Design Comparison

To place these choices against other open source EFSS architectures, see Design Comparison.


Targeted Metadata and Filesystem Reconciliation

For collaborative metadata, Sync-in only indexes files that carry useful application state: comments, shares, anchors, synchronizations, permissions, activity, and related state. The database does not act as a mandatory full mirror of the filesystem tree: it stores the functional state required by the platform. This approach keeps database growth closer to real collaborative usage, reduces indexing overhead on very large trees, and improves both fluidity and overall platform performance.

This model also strengthens scalability: adding millions of files does not mechanically create millions of application entries. Database load grows primarily with the features actually used, such as shares, synchronizations, permissions, or activity.

When a file already associated with metadata changes on the filesystem, Sync-in can reconcile the real storage state with the existing metadata. This keeps shares, anchors, synchronizations, permissions, and activity coherent without imposing a global cache for every file.

Full-text indexing is a separate mechanism: it concerns document content, can be enabled or disabled, and does not need to be locked into the database. It can rely on search engines better suited to full-text workloads, such as Elasticsearch. Results remain filtered by the user's access rights, including when they come from the content index.


Storage Reversibility

Files are not absorbed or stored in a database: they remain directly accessible on the filesystem.
This ensures users retain the freedom to read, back up, migrate, or process their data with other tools, without any constraint or dependency on Sync-in. When filesystem changes occur, Sync-in can reconcile the observed state with existing metadata to preserve application consistency.

Application state is not embedded into files through backend-specific filesystem metadata, which makes copy, restore, and migration workflows less dependent on hidden storage attributes.

👉 See also: Design Comparison


Virtual anchoring without duplication

The anchoring mechanism makes it possible to link a file or folder to a space without moving or duplicating it.
The item is accessible as if it were physically present (interface, WebDAV, API), while still following the permission rules of the target space.
This avoids redundancy and provides better control over data distribution.

Anchored files remain subject to dual control: the rights of the original location and the rights of the collaborative space must both allow the action. This prevents a space from indirectly expanding permissions defined by the file owner.

This logic also applies to external locations: an administrator can attach an existing server directory to a share or space without importing it into a specific application storage layout.

👉 See: Anchored files concept and External location


Granular permissions and nested sharing

Sync-in introduces advanced rights management: a share can be redelegated while still giving the owner full visibility and control over the entire chain of shares.
This approach allows the owner to manage, adjust, or revoke child shares with full transparency.

Nested shares therefore remain governable: owners and managers can track distribution, limit delegated rights, and remove child access when context changes.

👉 See: Managing shares in collaborative spaces and Managing child shares.


Space governance and operational visibility

Collaborative spaces define a manager role, responsible for supervising the files, members, shares, and permissions associated with the space.
Governance also covers the management of anchored files, with strict rules ensuring that the original rights attached to the file remain unchanged, even when the anchor is administered at the space level.

This approach provides clear, ready-to-use governance for collaborative spaces, with an explicit responsibility model.

Even when a file is shared or anchored elsewhere, its storage usage remains attached to its original location. Quotas therefore keep a clear responsibility model, independent of the different contexts from which the file is accessed.

👉 See: Collaborative space management


Unified Locking

The unified locking system ensures transactional consistency and file integrity across the entire platform, regardless of the access method used: web interface, WebDAV, synchronization clients, collaborative editors, or APIs.

The implementation of this system provides deterministic management of concurrent access by serializing operations, thereby preventing any state corruption and eliminating conflicts caused by simultaneous writes.

👉 See: File Lock Management


Optimized and integrated synchronization

Sync-in provides a native file synchronization system, optimized and consistent with the Web interface.
It relies on existing APIs to ensure uniform behavior in terms of control, security, and traceability.
Thanks to optimized handling of copy and move actions, network usage is reduced.
This feature also includes advanced mechanisms such as automatic transfer resume, synchronization simulation, data loss protection, regular expression filtering...

Synchronization therefore prioritizes operational safety as much as speed: dry-run simulation, transfer resume, data loss protection, and move optimization limit both errors and unnecessary transfers.

👉 See: Synchronization


Native WebDAV protocol implementation

While other solutions rely on external libraries (such as sabre-dav in PHP), Sync-in provides its own WebDAV implementation, fully compliant with RFC 4918 and developed in TypeScript.
This technical choice ensures native support, optimized performance, and seamless integration into the platform's global security model.

👉 See: WebDAV


TypeScript Foundation

Sync-in uses TypeScript as a shared language across backend and frontend. This provides explicit, typed, and consistent interfaces across business services, APIs, WebDAV, synchronization, clients, and the web interface.

This continuity between both stacks limits contract drift, imposes shared interfaces between server implementation and client usage, and makes platform evolution safer.

TypeScript also retains the advantages of the JavaScript/Node.js ecosystem: a widely known language, mature tooling, a broader contributor base, and natural integration with modern web technologies.


Access Separation and Revocability

Sync-in separates access types according to their use: internal users, guests, guest links, groups, WebDAV clients, the desktop application, and command-line tools. This separation makes it possible to apply the right level of access to each context without unnecessarily exposing the main account.

WebDAV and command-line access rely on dedicated application passwords that can be revoked, expired, and traced. The desktop application's synchronization client uses its own registration mechanism: it requires an initial authentication, renewed every six months, and remains subject to the same revocation, expiration, and traceability principles.

For sensitive environments, user and group visibility can be restricted. This reduces unnecessary account discovery and makes it possible to build more compartmentalized collaboration spaces.

Sync-in can also integrate with standard authentication mechanisms such as OIDC or LDAP, and strengthen accounts with MFA when needed. These options complement the access model without replacing the internal permission, sharing, and traceability rules.


Application Consistency

Sync-in's core mechanisms (permissions, locking, WebDAV, synchronization, shares, anchors, and activity) rely on the same business services. This organization avoids divergent behavior depending on the access method used: web interface, WebDAV, synchronization client, collaborative editor, or API.

This consistency allows the platform to evolve without duplicating security rules or multiplying protocol-specific execution paths.