Hivra explores a Person-First Runtime: a locally controlled foundation for identity, authenticated history, and pairwise relationships. The architecture asks which party has authority over each part of an interaction, whether execution happens locally or through a shared service.
Keys can identify a signer, and storage can hold records. A lasting interaction also needs authenticated history and rules for recognizing the other participant. Capsule brings these together without requiring a Hivra-operated account server, directory, or a personal VPS. Message delivery and external services still need their own available infrastructure.
A Capsule establishes its own signing identity. Transport credentials and provider accounts have separate roles.
The runtime process can stop while stored history remains. Recovery of identity and recovery of that history have different requirements.
Installed software uses host APIs and explicit permissions. Replacing a compatible package does not create a new Capsule identity.
Core interprets authenticated domain history. Operational records, application data, and secrets have their own owners and storage boundaries.
The canonical Capsule identity comes from its local root key. A Nostr key or a service login does not replace it.
The Ledger records signed Capsule domain facts in an append-only history. Core derives the current state from those facts.
Root signing authority and application permissions serve different purposes. A transport's ability to deliver gives it neither.
The host checks an application's grants and execution context before permitting a capability call.
Plugin state, external-effect journals, delivery records, and credentials stay in their dedicated stores rather than becoming Ledger facts.
Core accepts domain truth through defined transitions; external receipts and journals remain owned by their capability or effect boundary.
Not an account A Capsule can use accounts, but it is not itself a provider account.
Private relationships There is no global people search or discovery directory. Public visibility would require a separate higher-level mechanism and a sharing decision.
Domain-specific data Medical histories and financial accounts belong to specialized applications and their participants, outside Capsule Core.
Not a transport identity Network protocols and endpoints are pluggable, not canonical.
Limited scope A Capsule is not a personal cloud, universal database, or replacement operating system. Applications use its defined runtime interfaces.
Foundational relationships are pairwise. Each Capsule keeps its own authenticated side; an application or intermediary cannot produce the other party's valid signature without that party's signing authority. Either party may end its participation, but cannot rewrite the other's signed past. Retained relationships need no continuous activity; updates still depend on delivery, so a local view is not a guarantee of the peer's latest state.
Applications may use an established relationship when they need a trusted peer. Each side retains its own history independently of the application's availability.
Mutual recognition does not grant access to private records or authorize an operation. Each capability has its own bounded access requirements.
Starters, slots, invitation lifecycles, and Pair Consensus are defined in the 1.x specification. The State Explorer illustrates local Starter history.
Drones are installed WASM plugins. The host mediates their access to storage, delivery, and external effects. Host-level transport and provider adapters handle external I/O.
Chat and Moltbook are maintained application capabilities. Capsule AI Runtime is a shared host capability used by authorized surfaces, not a downloadable drone or Core.
Package replacement depends on compatible host APIs, contracts, grants, and catalog trust. New provider operations may require host changes.
Effects and receipts stay tied to the provider or capability boundary and are not merged back as person continuity by default.
Nostr is the currently mounted transport. Its relays carry authenticated messages; they do not define Capsule identity or own the relationship. Delivery still depends on connectivity and available relays. Separation of transport makes replacement possible in the architecture, not automatic for every protocol.
Transport keys and sessions stay behind host interfaces. Plugins request delivery without receiving those credentials.
A delivery acknowledgement is operational evidence. It does not by itself create an accepted Capsule domain fact.
A transport outage does not erase retained local history. It can prevent delivery and leave a participant with an older view of the pair.
Status checked on 11 October 2026. v1.0.4-test1 is the latest published test build for macOS and Android. The development status tracks source and plugin work separately; Hivra 2.0 remains design-only.
Implemented in the 1.x test runtime
Experimental release limits
Research direction
Hivra combines existing primitives with its own ownership boundaries. Tests within one implementation, external artifact checks, and independent implementations answer different questions.
External tooling can check published signatures, digests, and package structure. This establishes facts about distributed bytes, not the validity of a Capsule's history.
A separate verifier would check authenticated history and its semantics. This remains research beyond package verification.
Another implementation would need to continue the same Capsule history under compatible rules. Verifying past records alone would not demonstrate this.
Replacing a plugin or adapter within Hivra does not prove interoperability between independent runtimes. Hivra is not presented as a finished universal standard.
The plugin owns its decisions and reconciliation rules. The host validates grants and mediates external requests; adapters execute them and return evidence to the same owner.
The effect lifecycle contract requires one owner across retry, restart, and reconnect. External receipts remain with that owner; only defined, accepted domain transitions enter Core/Ledger history.