Wildbloom Node is the native, self-hosted half of the Wildbloom idea. The browser encrypts and signs. The node stores the resulting Blossom blob on the operator's disk and serves it through operator-managed HTTPS or, when selected, a stable Tor v3 onion.
The separation is deliberate:
- no Nostr secret or recovery key enters the node;
- the browser remains a static app with no background or filesystem authority;
- the node can stream large blobs to disk, reserve quota and remain available after the browser closes;
- both halves remain compatible with ordinary Blossom clients and servers.
The node binds to loopback by default. Tor is optional. In Tor mode it supplies the inbound onion route and an internal outbound path for replication, so the operator does not open a firewall port or configure NAT. In direct mode the node does not start Tor; local use works immediately, while remote reachability requires an operator-owned HTTPS reverse proxy. There is no WebRTC, STUN or TURN in either node path.
For the browser's ordinary direct profile, enter the node's HTTPS URL as the
Blossom server. Direct clients and infrastructure see normal network metadata.
For the Tor-only profile, open Wildbloom through Tor Browser and enter the
node's .onion URL. Wildbloom signs a short-lived
BUD-11 event for that exact hostname and hash, uploads only the prepared
ciphertext, and verifies the returned descriptor.
PUT /mirror uses standard BUD-04. A destination node receives a signed upload
authority and a hash-addressed source URL, fetches it through the selected Tor
or public-HTTPS transport, reserves
quota before reading the body, and independently checks its length and SHA-256.
Each mirror stores its complete addressed blob. A pool part is a separate encrypted blob. This is closer to deliberate
Blossom pinning than BitTorrent chunk swarming.
Native macOS acceptance has exercised two independent node processes: node B
mirrored through node A's onion, A stopped, and B still served the exact bytes.
The separate installed-preview matrix has also installed and started the
generated Linux .deb and Windows NSIS package on fresh hosted runners,
reached Tor and Blossom readiness, enforced one app instance, stopped bundled
children and uninstalled. The exact evidence is in the node's
acceptance ledger.
That proves the tested replica survived its source loss and the unsigned Linux and Windows previews ran in those hosted environments. It does not prove future custody, automatic replica discovery, trusted installer signing, updating, reboot behaviour or physical retail-machine support.
The browser can keep whole encrypted copies or encode the ciphertext into threshold-recoverable parts assigned to approved nodes. The signed private receipt records the layout and destinations; the recovery key remains separate. See pool storage for the recovery and trust boundaries.
The 0.3.3 desktop preview imports and validates receipts locally. It offers an explicit read-only check, per-part observations and owner-side automatic repair with a separate external signer, bounded resources and expiring authority. Repair reconstructs ciphertext on the owner machine without the recovery key. Keep that machine separate from storage nodes intended to hold only one part. Reopening the app does not restart repair authority. Local disk errors stop repair; a hard crash preserves temporary files for explicit review before restart. The desktop can show those files and, after confirmation, clear recognised temporary parts while holding the repair lock. Receipts and reports are preserved; cleanup never restarts repair.
On Windows, saved receipts and repair work are private to the current account, SYSTEM and administrators. The desktop and daemon refuse broad file permissions and reparse points; existing permissions are not silently rewritten. See the desktop guide before migrating older state that the new checks refuse.
The desktop guide explains setup and limits. The physical recovery checklist is prepared but has not been performed across independent devices.
The signed Mac preview.2 contains the same 0.3.3 application binaries with Developer ID signatures, Apple notarisation and stapled tickets for Apple Silicon and Intel. Checksums and signing evidence accompany the downloads. Gatekeeper and package checks passed on the development Mac; clean-machine install/upgrade and native Intel execution remain unverified. These are manual installs, not automatic updates. Windows and Linux packages remain in preview.1; Windows signing is outstanding.
Nostr is useful for signed discovery, server lists and private storage offers. It does not carry the file and a relay acknowledgement does not prove custody. Once a Blossom endpoint is known, upload, mirroring and retrieval continue over Blossom HTTP via HTTPS or Tor without a relay.
RelaySwarm may later provide a faster Noise-authenticated native transport. It must remain optional, with standard Blossom over direct HTTPS or Tor as the compatible paths.