Architecture

Raw personal data never leaves your device. This is the load-bearing constraint, not a marketing line.

The open-core split

shenas is open-core. The community version — hosted at shenas.ai/oss — is the open-source version: the plugin SDK, the architecture, the code, the way you extend or replace any piece. A commercial layer with hosted services and team-shaped features funds the work. Anything that touches user data — the local pipeline, on-device models, privacy primitives — stays in the community version, forever.

The distinction matters: a feature that requires sending raw data to a server cannot ship in the community version, regardless of how useful it would be. The on-device constraint is enforced at the architecture level, not by policy.

Key architectural properties

Local-first storage All raw data lands in a local DuckDB database at ~/.shenas/shenas.db. Source plugins write directly to this database. No relay, no cloud storage.
On-device models Federated learning runs entirely on your device (Flower + PyTorch). Only gradient updates — never raw data — leave the device, and only via the Nym anonymous-credential mixnet.
Multi-device sync Device-to-device sync uses an encrypted relay: the server sees only ciphertext. The sync key is derived from your master password and never held server-side.
Plugin signing Every plugin shipped via CI is signed with Ed25519. The CLI verifies the signature before installing. Third-party signing is in progress; see the roadmap.
No telemetry shenas does not phone home. No usage analytics, no crash reporting, no feature flags that depend on server calls. What runs on your device stays on your device.

Go deeper