Hivra

Your own foundation for life online.

Usually, going online starts with an app, an account, and the rules of its operator. Hivra explores another starting point: a digital foundation you establish and control, then use with applications and shared services.

We call it a Capsule. It holds your identity, signed history, and your side of relationships with other independent participants. Hivra is a working experiment in this approach, called a Person-First Runtime.

Durable participants and relationships. Replaceable software and infrastructure. Your own identity History you keep Pairwise relationships Applications you choose

A different starting point

Start with the participant.

Applications made participation convenient by providing accounts, storage, and services together. Personal computing and local-first software now make more arrangements practical. Hivra explores what a participant can maintain independently, while still making use of shared infrastructure.

Your foundation Establish a Capsule

Create a local identity and signing authority without registering with a mandatory Hivra account server or directory.

Your relationships Connect as independent parties

Two participants establish a verifiable relationship. Each keeps their own side, rather than relying on an application's contact list.

Your applications Add useful software

Applications provide interfaces and specialized work. Their access is bounded; they do not become the source of your Capsule identity.

Pairwise relationships

A relationship has two independent sides.

A channel delivers messages. The relationship belongs with its participants. Hivra records each side in its Capsule's signed history, so the relationship can remain even when a particular application is closed or unavailable.

Mutual recognition

Relationships are established between two Capsules through an explicit invitation and acceptance.

Each side speaks for itself

Signed evidence lets each side verify the other. Carrying a message gives an intermediary no authority to sign for either participant.

Access is a separate decision

A relationship alone grants no general access to private data or permission to act on someone's behalf.

Private by default

There is no global discovery directory. Public visibility would need a separate application and an explicit sharing choice.

Useful between interactions

A quiet relationship remains in retained history. Reaching the other participant still requires an available delivery channel.

Recovery needs preparation

A recovery phrase restores identity. Restoring history needs a compatible backup or available authenticated history as well.

A possible application

Independent on both sides.

Imagine your relationships with a bank, a hospital, a fitness center, and other people. Each party could keep its own history and authority, and verify shared facts. These are conceptual possibilities, not current Hivra institutional integrations.

You and a bank

A future application could exchange authenticated records between independent parties. The bank would still operate its accounts and services.

You and a hospital

A future health application could keep a longitudinal history locally, receive authenticated clinical records, and share selected information. Institutions would retain their own records and legal responsibilities.

You and a fitness center

An application could verify a membership fact without receiving your wider history. Such access would need its own rules and implementation.

You and other people

Applications could use an established relationship for different activities. Medical, financial, and other application records would stay outside Capsule Core.

Available to test

A working experimental runtime.

As of 11 October 2026, v1.0.4-test1 is the latest test release for macOS and Android. It is not a stable release.

Implemented in 1.x

Local Capsule identity, signed history, invitation-based relationships, and a host for installed plugins.

Experimental release

Packaged launch and restart checks passed. Full recovery and migration qualification is deferred; the macOS build is unsigned and not notarized.

Development continues

Source changes and plugin work can be ahead of released builds. See current development status for their evidence and limits.

Research direction

What this could make possible.

Hivra combines known technical capabilities. Its wider applications remain questions to explore, not promised outcomes.

More work at the edge

Local computing and AI tools may let participants do more themselves, while shared services remain useful.

More ways to communicate

Peer-to-peer networking may widen delivery options. Reachability and infrastructure dependencies still need testing.

Independent continuation

Continuing the same Capsule through a separate implementation is a research goal, not a demonstrated interoperability guarantee.

Applications in practice

Software works within granted access.

Applications provide useful interfaces and workflows. The runtime mediates their access; external services execute permitted requests and return evidence of the outcome. Running locally or remotely does not by itself grant authority.

  • Goal enters capability
  • Capability decides
  • Adapter executes
  • Receipt reconciled
  • Result returns
Person / Capsule Continuity root
Capability Owner One decision path
Capability Adapter Execution
Receipt / Reconciliation Verified outcome

This diagram illustrates one application request. Its result stays with the responsible application; it does not automatically become part of the Capsule's foundational history.

Explore Hivra

Read the architecture. Inspect the experiment.

Follow the reasoning, inspect the technical evidence, or try a published test build.