HearthMesh Run locally

Experimental open-source project

Continuity, built
node by node.

HearthMesh preserves selected public documents as signed packages. Nodes keep complete local copies and can repair a damaged pack from a reachable valid replica. Today, it is a pre-alpha prototype with manually configured peers.

Run the three-node demo See how it works
No AI at runtimeSigned publicationsNo mandatory central cloud
ILLUSTRATIVE TOPOLOGY3 EXAMPLE NODES
Three HearthMesh nodes replicating a signed pack Example nodes A, B and C retain a signed pack. A reader accesses a local copy. This diagram does not depict live nodes or measured geographic resilience. PUBLISHERNODE A REPLICANODE B REPLICANODE C READER SIGNED PACK 04
✓
Signature validSigning key and file integrity checked

01 / PURPOSE

Useful knowledge should not disappear with one service.

A HearthPack contains files and a signed manifest. A complete local copy can remain downloadable when the publisher disappears, as long as the local node and access network still work. Repair needs another reachable valid copy; hashes cannot recreate missing data.

What verified means.

The signature binds a pack to a key. It does not establish a real-world identity, factual accuracy, safe content or the latest revision. Publisher approval is planned; it is not enforced by this release.

02 / FLOW

From publication to recovery.

  1. 01Package

    A publisher puts selected public files and a manifest into a HearthPack ZIP.

  2. 02Sign

    The publisher signs the manifest with its persistent Ed25519 identity.

  3. 03Replicate

    A node polls its configured sources, downloads complete packs and verifies them.

  4. 04Recover

    A damaged pack can be restored when a reachable peer retains a valid copy.

03 / NETWORK

A public prototype. Private cells are a future step.

CURRENT PUBLIC PROTOTYPE

Signed public collections

Complete packs move between explicitly configured sources. The next goal is one non-critical collection on three separate machines, after adding authorization and resource limits.

  • Public test contents
  • Persistent signing keys
  • Complete local replicas
  • Local integrity checks
FUTURE PRIVATE CELLS

Restricted collections

A future private group would need membership controls, encryption and recovery keys. A list of known peers alone does not make data private. This mode is not implemented.

  • Authorized membership
  • Encrypted data and connections
  • Separate recovery keys
  • Tested isolation and retention

04 / GUARDRAILS

Clear boundaries for the pre-alpha.

01

Attribution

Every public pack identifies the cryptographic key that created it.

02

Direct peers

The official design does not include onion routing or publisher concealment.

03

Local evaluation

Publishing is unauthenticated and transport is plain HTTP. Use public test data locally; do not expose this release to the Internet.

04

Trust policy next

Approved publishers and storage quotas come before the pilot. Current nodes try to acquire every pack advertised by their configured sources.

05 / MVP

Explore the recovery sequence.

APublisherOnline
BReplicaVerified
CReplicaVerified
Ready. Three nodes hold the same signed HearthPack.
0 / 4

This is a scripted illustration, not a live network or test result. The executable demo uses three nodes on one host. It does not establish resilience across independent sites, and repair needs a reachable valid copy.

06 / RUN LOCALLY

Inspect the behavior yourself.

Use the repository instructions to run three temporary nodes on one machine, publish a signed pack and exercise repair. The four unit tests include a separate two-node replication test. The next pilot adds separate machines and a usable offline reading path.

Repository and downloads · Recorded validation

terminal
cd hearthmesh/mvp
go test ./...
sh demo.sh