explaingit

encrypted-spaces/prototype

Analysis updated 2026-05-18

95RustAudience · developerComplexity · 5/5Setup · hard

TLDR

A Rust research prototype for a collaboration workspace where the server only ever sees encrypted data, verified with cryptographic proofs on each client.

Mindmap

mindmap
  root((Encrypted Spaces))
    What it does
      Encrypted collaboration
      Client side verification
      Hash chained log
    Tech stack
      Rust
      Zero knowledge proofs
      Client SDK
    Design goals
      Verifiable history
      Selective deletion
      Insider protection
      Deniable authorship
    Status
      Research prototype
      Not audited
    Audience
      Developers

Code map

Detail Auto

An interactive map of this repo's files and how they connect — its source is parsed live in your browser. Click Visualize to build it.

filefunction / class

What do people build with it?

USE CASE 1

Study a working example of an encrypted, tamper-evident collaborative workspace design.

USE CASE 2

Experiment with the client SDK to build tables, lists, or collaborative text on top of an encrypted log.

USE CASE 3

Explore the zero-knowledge proof system used to verify server responses without trusting the server.

USE CASE 4

Prototype selective deletion or insider-protection features for a secure collaboration tool.

What is it built with?

Rust

How does it compare?

encrypted-spaces/prototypeqewer33/ratscadquininer/cbor4ii
Stars959889
LanguageRustRustRust
Last pushed2025-11-30
MaintenanceQuiet
Setup difficultyhardmoderateeasy
Complexity5/53/52/5
Audiencedeveloperdeveloperdeveloper

Figures from each repo's GitHub metadata at analysis time.

How do you get it running?

Difficulty · hard Time to first run · 1day+

This is an unaudited research prototype with placeholder authentication, not safe for real data or production use.

No license information is provided in the README.

In plain English

Most collaboration tools store everyone's shared data on a central server in readable form, meaning the company running that server can see the contents. This project explores a different approach: the server holds only encrypted data, and the software on each participant's device verifies every server response with cryptographic proofs before accepting it. A compromised server cannot silently alter what users see. The core concept is an Encrypted Collaboration Space, a shared workspace where multiple people can read and write structured data (tables, ordered lists, and collaborative text), but the server only handles ciphertexts and proof material. Every change is recorded in an append-only, hash-chained log. Clients check the current database state against the latest log entry on every server response, so any tampering is detected locally. The design targets four specific properties. First, verifiable history: every change is recorded in a tamper-evident log that members can audit. Second, selective deletion: members can remove data so neither the server nor future members can read it, without re-encrypting everything else. Third, insider protection: someone who leaves cannot read communications that happen after their removal, and a malicious insider cannot cause a silent denial of service for others. Fourth, deniable authorship: members know who wrote something, but there is no publicly verifiable cryptographic receipt linking a specific person to a specific message. The project is written in Rust. It includes a client SDK with a relational database API, core cryptographic primitives, a zero-knowledge proof system, a reference server, and example demo applications. The README carries a prominent warning: this is a research prototype that has not been audited or hardened for production. Authentication is a placeholder (the server accepts whatever identity a client claims), and some input handling paths are not yet protected against resource exhaustion. It must not be used in any production system or to protect sensitive data.

Copy-paste prompts

Prompt 1
Explain how an append-only, hash-chained log lets a client detect server tampering without trusting the server.
Prompt 2
What is deniable authorship in a collaboration system, and how does encrypted-spaces implement it?
Prompt 3
Walk through how selective deletion works when the server cannot see the underlying data.
Prompt 4
Summarize the security warnings in this project's README before I consider using it for anything real.

Frequently asked questions

What is prototype?

A Rust research prototype for a collaboration workspace where the server only ever sees encrypted data, verified with cryptographic proofs on each client.

What language is prototype written in?

Mainly Rust. The stack also includes Rust.

What license does prototype use?

No license information is provided in the README.

How hard is prototype to set up?

Setup difficulty is rated hard, with roughly 1day+ to a first successful run.

Who is prototype for?

Mainly developer.

Open on GitHub → Explain another repo

This repo across BitVibe Labs

Verify against the repo before relying on details.