Sortify Cloud and Enterprise SyncNative

Published by: MokingBird Oy Last updated: 6 June 2026

Overview

Sortify is local-first. The app keeps the working copy of each workspace on the user's device, then syncs only when the user chooses a sync model.

Sortify supports a hybrid product direction:

This article explains the implemented Sortify Cloud and Enterprise SyncNative architecture at a high level. Both workspace types are entitlement-gated, and production availability depends on the active app release, Firebase deployment, security rules, indexes, account entitlement, and commercial configuration.

The Core Design

Sortify Cloud and Enterprise SyncNative are not designed as plaintext hosting. They are designed as encrypted message transport.

Device A
  encrypts change locally
  uploads encrypted event
Firebase/Firestore
  stores encrypted event + safe routing metadata
Device B
  downloads encrypted event
  decrypts locally with workspace key

The server does not need plaintext item names, room names, locations, notes, quantities, photos, or workspace keys. Those fields remain inside encrypted payloads.

Optional managed photo sync is a separate media layer. The device normalizes an inventory image to JPEG, constrains it to a 1280 x 1280 bounding box, compresses it at quality 55, encrypts the bytes with the workspace key, and uploads ciphertext to a workspace-scoped Firebase Storage object. Firestore stores only safe ciphertext metadata. Users enable this layer per workspace from Workspace Settings, and a media failure does not stop core event sync.

What Firebase/Firestore Can Store

Sortify Cloud and Enterprise SyncNative store safe coordination data such as:

• workspace ID;
• organization or account ID;
• member IDs and roles;
• device IDs;
• encrypted event sequence numbers;
• encrypted checkpoint generation;
• sync cursors;
• timestamps;
• invitation and approval state;
• entitlement and billing flags;
• encrypted event payloads;
• encrypted checkpoint payloads;
• encrypted key envelopes for recovery.

This metadata is needed so devices can find the right encrypted updates, apply them in order, and recover after reinstall.

What Firebase/Firestore Must Not Store

Sortify Cloud and Enterprise SyncNative must not store plaintext workspace content, including:

• item names;
• room names;
• exact item locations;
• notes;
• tags;
• quantities;
• barcodes;
• photo bytes;
• decrypted workspace database snapshots;
• plaintext WorkspaceKeys;
• plaintext AccountMasterKeys;
• recovery passwords.

The privacy rule is simple: if the data describes the user's inventory content, it must be encrypted before it reaches managed infrastructure.

How Sync Works

The device remains the primary workspace engine.

1. A user changes an item locally.
2. Sortify writes the change to the local SQLite database and local change journal.
3. For managed sync workspaces, Sortify converts the change into a small event.
4. The device encrypts the event with the workspace key.
5. The encrypted event is uploaded to Firebase/Firestore.
6. Other authorized devices listen for new events.
7. Each device downloads, decrypts, validates, and applies the event locally.
8. Periodically, the app may upload an encrypted checkpoint so new devices do not need to replay an unlimited history.

This is different from cloud-drive snapshot sync. Instead of repeatedly uploading a whole encrypted database file, managed sync moves small encrypted deltas.

Why This Improves Collaboration

Cloud-drive sync is useful for personal backup and small collaboration, but files are not realtime databases. Multi-user inventory work benefits from faster propagation.

Managed encrypted deltas help with:

• faster item moves;
• lower upload bandwidth;
• fewer provider-specific sharing problems;
• clearer member management;
• better recovery from stale devices;
• smoother enterprise admin workflows;
• fewer whole-file conflict windows.

Sortify still remains local-first: users can continue working locally, and sync catches up when the network is available.

Recovery Model

Recovery uses encrypted key envelopes and encrypted checkpoints.

A typical recovery flow:

1. User signs in to Sortify.
2. Firebase Authentication proves account identity.
3. Firestore returns workspace memberships, encrypted key envelopes, and encrypted checkpoint references.
4. The user unlocks recovery using the current Sortify password, recovery password, or an already trusted device flow depending on account setup.
5. The device decrypts the workspace key locally.
6. The device downloads encrypted checkpoints and events.
7. The device rebuilds the local SQLite workspace.

MokingBird cannot decrypt the workspace without the user's unlock secret and workspace key.

Member Management

Sortify Cloud and Enterprise SyncNative keep the same product logic users already understand:

• workspace owner/admin creates a workspace;
• owner/admin invites members with a link or code;
• joining users request access;
• owner/admin approves or denies;
• approved members receive encrypted access material;
• removed members lose future access;
• role permissions control invite, settings, delete, item edit, and read-only behavior.

For Enterprise workspaces, the owner role is presented as an admin role. Admins can manage members, review activity, and apply enterprise policies. Secondary users can work in assigned workspaces without needing to connect a personal Google Drive, OneDrive, or Dropbox account.

Sortify Cloud vs Enterprise SyncNative

Sortify Cloud Platinum and Enterprise SyncNative can share the same technical foundation but serve different users.

Cost-Control Design

The managed sync design should be cost-aware from the beginning.

Implemented and architectural controls:

• local-first writes so the app does not read/write cloud on every screen render;
• compact encrypted event payloads backed by the local change journal;
• checkpoints to avoid replaying long event histories;
• per-workspace listeners only while needed;
• backoff when devices are offline or provider action is pending;
• compact event payloads;
• entitlement limits for non-enterprise plans;
• retention windows for old events once checkpoints are confirmed;
• Firestore security rules intended to limit reads/writes to workspace members.

Firebase costs should stay controlled if Sortify avoids chatty reads and treats Firestore as encrypted transport, not as the primary UI database.

UI Direction

The app presents workspace modes without splitting the product into separate apps.

Workspace mode tabs:

Personal | Enterprise

Personal covers:

• local-only workspaces;
• solo cloud sync;
• provider-based collaboration through Google Drive, OneDrive, and Dropbox;
• Sortify Cloud Platinum when enabled.

Enterprise covers:

• organization/admin workspaces;
• SyncNative managed realtime encrypted sync;
• enterprise member management;
• organization recovery and support flows.

All workspaces can still appear on Home and Search. Workspace cards should clearly indicate whether they are personal, provider-based collaborative, Sortify Cloud, or enterprise.

Security Summary

Sortify Cloud and Enterprise SyncNative preserve Sortify's privacy promise if these rules are enforced:

• encrypt before upload;
• never store plaintext workspace content in Firebase;
• never store plaintext workspace keys;
• keep local SQLite as the working database;
• use Firestore as encrypted transport and coordination;
• use role-based access control for workspace membership;
• keep recovery based on encrypted envelopes and user-held unlock secrets.

The user-facing message is:

Sortify uses managed cloud infrastructure only to pass encrypted updates between your devices. Our servers are blind to your inventory contents.

Current Rollout Status

The application includes the managed provider types, entitlement gates, separate Firestore namespaces, encrypted event envelopes, local event queues, realtime listeners, checkpoints, compaction, invite/approval/removal flows, recovery foundations, enterprise organization records, and organization-level member controls.

This implementation is not a claim that every account can use managed sync immediately. Firebase rules and indexes, runtime multi-device validation, billing products, organization entitlements, and commercial support terms must be enabled for the target release. Full CRDT behavior is also not claimed: the current implementation provides a pragmatic encrypted event stream with field-level conflict foundations for common item updates and moves.

Google Drive, OneDrive, and Dropbox remain supported user-owned cloud choices. Managed sync is an additional isolated architecture, not a replacement for those providers.