hyperconsciousness

abstract

human knowledge is scattered across files, messages, recordings, cloud drives, and agent conversations. each system stores part of a life or a company, but each also brings its own database, account, and permission model.

hyperconsciousness is a free, local-first protocol for keeping one encrypted history across devices. people and agents receive narrow, revocable access without giving every device, model provider, relay, or storage operator the whole memory.

it is not a notes app, a cloud drive, or a new filesystem. it is a knowledge layer below those interfaces. ordinary files remain ordinary files. agents become the main interface.

1. the premise

people have always compartmentalized memory. what someone tells a friend differs from what they tell a lover, a doctor, a colleague, or a manager. companies do the same thing through teams, roles, projects, and legal boundaries. software usually reduces these relationships to a folder share or an account-wide permission.

agents make that simplification dangerous. an agent can search, combine, and act on far more information than a person can hold in working memory. the useful question is no longer only where the bytes live. it is who may know what, for which purpose, for how long, and with what record of access.

2. the model

the protocol has six durable concepts.

1. a device has its own signing and encryption identity.
2. a record is a small immutable fact, encrypted and signed by its author.
3. an author log is an append-only, hash-chained history written by one device.
4. a blob is large content split into encrypted, content-addressed chunks.
5. a grant limits who may perform an action on a specific part of memory.
6. a fold is a disposable local view rebuilt from valid records and available blobs.

capture, files, and applications
               |
               v
signed encrypted records + encrypted blobs
               |
        sync through any peer
               |
               v
verify, decrypt locally, and build a view
               |
          check the grant
               |
               v
       person, group, or agent

the encrypted history is the durable truth. search indexes, folders, summaries, and user interfaces are projections. they can be deleted and rebuilt.

3. sync without a central authority

each device appends only to its own log. two offline devices can write independently without a shared lock or elected leader. peers exchange signed heads, then request only the records and chunks they are missing. every received object is checked before it is accepted.

transport is separate from the format. devices may sync directly, over ssh, through an opaque relay, through object storage, or with an offline bundle. a relay or bucket can hold and move ciphertext without holding the keys that turn it into memory.

conflicting histories are exposed rather than silently merged. signatures can prove that received history is authentic. they cannot prove that an unavailable peer has sent everything it knows.

4. permission is part of memory

a signed grant can bind all of the following:

• the person, device, role, or agent receiving access;
• the allowed action, such as read, write, or use;
• the permitted record kinds, tags, paths, sensitivity, or compartments;
• an expiry and revocation state;
• an optional parent grant from which only narrower access may be delegated.

a node checks the complete grant chain before returning plaintext. a one-time request can ask the owner for one exact action instead of opening a broad session. permitted reads and writes can leave receipts. unknown scope, missing authority, expiry, and ambiguity fail closed.

revocation stops future access through an enforcing node. it cannot recall plaintext that was already shown to a person or process. sharing is a copy, and the protocol states that limit directly.

5. one person

an individual can separate work, health, finances, journals, and credentials without creating a different memory system for each agent. a coding agent may read one project. a scheduling agent may use a calendar. a hosted model may receive the permitted answer while the rest of the brain remains encrypted and undisclosed.

not every device needs every byte. a laptop may keep current files, a small device may keep only encrypted metadata, and an archive machine may retain everything. a device may remove local ciphertext only after a configured archive proves that it holds the exact bytes.

6. a company

a company should not need one vendor to own its institutional memory. engineering, finance, support, leadership, and individual projects can use separately encrypted compartments. membership in the company does not imply access to every compartment.

root-signed authority defines the organization. roles define narrower authority. people and agents receive scoped grants with explicit actions and deadlines. storage operators can replicate encrypted history without becoming company administrators or readers.

the same format can move between self-hosted devices, company infrastructure, and cloud storage. changing transport does not change the meaning, history, or authority of the data.

7. files and large data

a file record contains a path, stable identity, version ancestry, length, and chunk hashes. whole versions remain retrievable. identical chunks are stored once within an encrypted compartment. a workspace projects those records back into ordinary files.

hyperconsciousness does not mount a filesystem and does not replace application databases. a high-volume recorder such as screenpipe can keep raw capture in its own database while publishing selected records, files, or derived context into the shared memory layer.

8. agents and secrets

agents connect to a trusted node through the command line, mcp, or a scoped http interface. the node applies the grant before returning plaintext. the agent does not need the brain key.

a local agent can keep permitted plaintext local. a hosted agent necessarily receives the permitted plaintext returned to it. end-to-end encryption protects everything else, not text deliberately sent to a model provider.

secret values never enter the log. the log may contain an opaque reference and permission to ask a trusted adapter to perform one named operation. the agent receives the result, not the credential.

9. comparison

filesystem

stores mutable local bytes. history and cross-device authority are external.

git

provides strong history. large private data and runtime permissions are awkward.

cloud drive

provides availability. the provider database and account model remain central.

object storage

stores durable objects. it does not define human meaning or agent authority.

secrets manager

protects credentials. it is not a lifetime or company knowledge system.

hyperconsciousness

combines signed history, encrypted blobs, local operation, selective grants, and transport-independent replication. it can use the systems above without making any one of them the authority for the whole memory.

10. boundaries

hyperconsciousness is not:

• a posix filesystem;
• a general database;
• a real-time collaborative editor;
• a blockchain or token network;
• a replacement for raw application storage;
• a user interface like notion;
• a defense against a device that is compromised while it can decrypt the brain.

there is no operator-held recovery key. losing every enrolled device and either half of the separate recovery material loses access. a permitted recipient can retain plaintext. encrypted traffic still reveals timing and volume.

11. implementation

the current rust implementation includes encrypted author logs, resumable sync, chunked blobs, workspace projections, grants, shared spaces, company roles, recovery, native services, mcp, http, oauth, and a thin ios client.

permission checks use an encrypted local fold bound to the exact signed heads and usable keys. it contains verified signed grant blobs, revoked grant ids, and opaque secret references, not memory content or credentials. mcp resolves its grant chain from this fold instead of decrypting the brain at startup. a cold build folds one immutable signed prefix once, then catches up only its append tail. stale or corrupt cache state is rebuilt and cannot widen access. local agent receipts append from the locked recent head; network imports keep the full fork and history checks.

the human-facing command is hc. the package, protocol, and compatibility name remains brainmesh so existing stores, keys, scripts, and history do not move during the rename.

the implementation is an alpha. the repository is private while the first public release is prepared. the code is licensed under mit.