Prerelease: v1.0.0-rc1

Future Directions

Hashiverse is a working protocol, not a finished one. Several important areas are either partially solved or known to need improvement as the network scales. This page describes the most significant planned directions.

Key recovery and management

Self-sovereign identity has a fundamental vulnerability: if you lose your private key, you lose your identity. There is no "forgot password" on a cryptographic key pair. This is the most significant usability barrier to real adoption of Hashiverse.

The planned approach is Shamir's secret sharing: split your private key into N shares such that any M of them (M ≤ N) can reconstruct the key, but M-1 shares reveal nothing. You distribute shares to trusted parties — friends, family members, institutional key holders — and can recover your key if M of them cooperate. The security assumption is that no M-1 of your key holders will collude against you.

Variations on this theme include:

Interoperability

Hashiverse does not need to replace existing social networks to be useful. Bridges that import existing social graphs — Twitter/X history, Mastodon/ActivityPub feeds, Bluesky AT Protocol data — lower the switching cost for users who already have communities elsewhere. This is a deliberate growth strategy: make Hashiverse the place where your identity is sovereign, and let existing networks feed into it rather than requiring users to start over.

Extended signing schemes for post authorship

At present, every post must be signed directly by the key that generates the poster's client_id. Two important real-world patterns require more flexibility.

Ephemeral keys

A client may not want to unlock their master signing key every time they post — for example, on a mobile device where the master key is stored in a hardware enclave or behind a slow biometric check. Ephemeral keys solve this: the client generates a short-lived key pair, signs the ephemeral public key once with the master key, and then uses the ephemeral key for day-to-day posting without touching the master key again.

Servers would accept such posts by performing a three-step check:

  1. Verify that the post body signature is valid under the supplied ephemeral_signature_pub.
  2. Verify that ephemeral_signature_pub itself carries a signature that is valid under the supplied signature_pub (the master public key).
  3. Verify that signature_pub hashes to the poster's client_id, confirming the chain of trust leads back to the declared identity.

Ephemeral keys can carry an expiry timestamp signed alongside the public key, so that a leaked or stolen device key becomes invalid after a bounded window even if revocation is delayed.

Organisational delegation

An organisation may wish to publish under a single shared identity while distributing the ability to post across multiple individual accounts — a news outlet whose journalists each hold a separate client_id but all write under the outlet's identity, for example.

The planned model is for the organisation's root identity to publish a signed delegation list: a set of client_ids that are authorised to post on its behalf. Servers accepting a post from a delegated author would verify that the signing key belongs to a delegated client_id and that the delegation record carries a valid signature from the organisation's root key. Any one of the delegated clients can post; none of them need the organisation's master key.

Client reputation and real-world attestation

Proof-of-work raises the cost of creating large numbers of fake identities, but it is not the only tool available. A complementary direction is client reputation: mechanisms that let a client demonstrate, alongside a post or piece of feedback, that they are a real, long-standing, or externally-verified participant. Several approaches are being explored.

External identity attestation

Third-party identity providers can vouch that a Hashiverse key belongs to a verified human without revealing who that human is. Two broad models are under consideration:

Both approaches are strictly opt-in: clients with no attestation continue to participate normally at the base PoW level. Attestations are signals, not gatekeepers.

Accumulated PoW as reputation

Every time a client performs an RPC it must include a fresh proof-of-work. This is currently spent and discarded, but it represents an observable track record: a client that has been active for months has necessarily performed far more cumulative PoW than one created yesterday.

A planned extension stores a client's best-seen PoW on a day and month decay model — the same half-life scheme used for server reputation today. A client that posts regularly accumulates a strong decayed score; a freshly-minted bot that has only existed for hours has a near-zero score and must compensate with a higher per-request PoW to be accepted. This shifts the economics against sybil farms: the attacker must either invest significant real time warming up each identity, or pay a continuously higher PoW tax per request for every identity that skips the warm-up period.

Because the accumulated score decays over time rather than growing without bound, a dormant account that returns after a long absence would face a modest PoW surcharge until it re-establishes recent activity — a minor inconvenience for legitimate users and a meaningful barrier for bots that are created, used in a burst, then discarded.

Miscellaneous improvements