For God so loved the world, that He gave His only begotten Son, that whoever believes in Him
should not perish but have eternal life. — John 3:16
FileLuYa
A secure, encrypted system of living files.
FileLuYa is intended to be a secure, encrypted system of living files.
Only authorized people can read or contribute to protected content.
Every change is auditable, and, like a spreadsheet, related content can
automatically respond when any linked cell or file changes. FileLuYa aims
to make this work in a robust, distributed way for
reliable collaboration. Everyone begins with the same amount of
Timé (“Honor”), and Timé can be bestowed within
a system that measures the genuine reuse of content and processes
across the network.
What Makes It Different
| Keybase | Dropbox | Blockchain | FileLuYa |
|---|
| Encryption | E2E | Server-side | Varies | Hybrid post-quantum E2E |
| Files | Static blobs | Static blobs | N/A | Reactive cells that trigger each other |
| Conflicts | Last-writer-wins | Conflict copies | N/A | Knows WHY, resolves intelligently |
| Trust | Social proofs | None | Stake = power | Conserved honor you bestow |
| Sharing | Folder-level | Folder-level | N/A | Per-file, per-key, group keys |
| Rewards | None | None | Mining/staking | Reuse-based, vested, no inflation |
The Four Layers
Layer 1: Secure Knowledge Substrate
Mount as a native drive. Everything encrypted client-side. Server stores only opaque blobs. Private, Shared, or Public visibility per file.
- XChaCha20-Poly1305 (192-bit nonce, quantum-safe)
- Hybrid key exchange: X25519 + ML-KEM-768
- Hybrid signatures: Ed25519 + ML-DSA-65
- Argon2id key derivation (client-side only)
Layer 2: Living Files and Reactive Workflows
Files are cells. Gears block invalid writes. Waterwheels derive outputs from inputs. .forge files define the network — and are themselves cells.
Layer 3: Provenance, Trust, and Reputation
Every edit signed. Path-based trust via evidence sets. Reputation earned through reuse — citations, forks, dependent computations. Not views. Not likes.
Layer 4: Bounded Economic Rewards
Timé tokens. Vested 90 days. One-time per content/version. Token sinks: storage, compute, governance. Capital cannot buy truth.
Honor System (Timé)
Everyone starts with 1. You bestow your honor on people whose work you value.
You give it — you have less, they have more. They can pass it onward.
Total honor = total users. Always. Anti-sybil by construction.
Honor is separate from trust. Trust verifies identity (key signings, evidence paths). Honor endorses value (bestowable, conserved). Neither is the other.
Three Graphs, No Circular Capture
Identity Trust
Honor (τιμ´η)
Conserved, bestowable
→
Content Reputation
Attestations weighted by honor + reuse signals
→
Economic Rewards
Timé tokens
Vested, one-time, tradable
✗ NO feedback from Rewards to Trust or Reputation
Normative Invariants
- Provenance proves authorship, not quality.
- Trust is path-based and evidence-backed, not a single scalar.
- Personalized trust and canonical economic trust are separate.
- Stake = collateral and rate limits, never epistemic weight.
- Rewards are per content/version with vesting, never reputation delta.
- Trust is non-transferable. Honor is bestowable but distinct.
- Personhood requires independent attestation.
- Reuse is the primary quality signal, not consumption.
- Three graphs, damped one-way influence.
Roadmap
| # | Milestone | What |
|---|
| M1 | Encrypted mount | Single-user: mount, write, unmount, remount, read |
| M2 | Locking | Multi-client with propagator-lattice locks |
| M2.5 | Forge integration | Files as cells, gears, waterwheels |
| M3 | Sharing | Group keys, per-file per-key access |
| M4 | Conflicts | TMS-based detection + resolution |
| M5 | Formal verification | LEAN4 proofs of core properties |
| M6 | Windows | WinFsp support |
| M7 | CLI + GUI | User-facing tools |
| M8 | Timé | Honor system, reputation, token rewards |
118 tests passing. 72+ tasks tracked. 7 Rust crates. Backend-agnostic.
github.com/loveJesus/fileluya
|
Whitepaper (PDF)