Wildbloom
Encrypt, upload, publish, retrieve and verify in the browser. Nothing contacts the network until you press the relevant button.
ForgeSworn · open source · MIT
Wildbloom
Files that outlive their host.
Publish encrypted files without handing one company the keys, the address book and the only copy. Wildbloom joins Nostr discovery, Blossom storage and a home node reached through direct HTTPS or optional Tor.
- No account
- No private keys
- Tor is optional
- No STUN or TURN for the node path
What it is
A publishing tool and a storage node. Not another promise-shaped cloud.
The browser prepares and encrypts a file, asks your Nostr signer to approve exact actions, and publishes a signed pointer. Wildbloom Node stores the bytes on a machine you control and exposes a standard Blossom service through your HTTPS setup or a stable Tor onion address.
Wildbloom Node
A desktop tray app for Windows, Linux and macOS. Choose direct mode or optional bundled Tor; either way, writes remain limited to your chosen Nostr public key and invited friends.
Why it exists
A URL is not custody.
Servers disappear
A Blossom URL proves where bytes were once available. It does not promise that somebody else will keep paying for the disk.
Home hosting is awkward
Router rules, changing IP addresses and carrier NAT make a simple home server needlessly hostile. Optional Tor removes that inbound networking chore; people with HTTPS infrastructure can use it directly.
Redundancy must be visible
Wildbloom uses content hashes and standard Blossom mirroring. A second node is a real second copy, not a green tick backed by the same provider.
Use cases
Useful anywhere the file matters more than the host.
- CreatorsKeep media referenced by Nostr posts available without betting everything on a free upload host.
- CommunitiesShare the storage burden across independently run nodes and verify every replica by hash.
- Families and small teamsUse optional Tor when the home address should stay hidden, or connect the same node to infrastructure you already operate.
- DevelopersDogfood standard Blossom storage in an existing Nostr application rather than adopting a proprietary API.
Install
Start with source while signed installers finish their trust checks.
The node targets the three desktop families, but public downloads stay unpublished until macOS notarisation, Windows code signing and clean-machine installation have all been proved. We won't disguise an unsigned preview as a release.
Windows · Linux · macOS
Wildbloom Node
Follow the locked source build while installer signing is being completed.
Build the desktop app from sourceAny modern browser
Wildbloom
The publishing tool runs here. For onion endpoints, use Tor Browser and read the privacy boundary before connecting.
Open the publishing toolProtocol
Boring standards at the joins. Explicit limits at the edges.
- 1Prepare
The browser encrypts content, filename and MIME type locally, then calculates the payload's SHA-256.
- 2Authorise
Your signer approves a short-lived BUD-11 action for one hash and one Blossom host. Wildbloom never asks for an nsec.
- 3Store and replicate
BUD-02 uploads the exact bytes. BUD-04 lets another authorised node mirror them, and each node verifies the content hash.
- 4Discover
A signed NIP-94 event tells readers where to fetch the payload and what hash and size to expect.
- 5Verify
Retrieval is not complete until the byte count and SHA-256 match the signed event. Decryption happens locally.
The blunt bit. Wildbloom is interoperable storage and
client-driven replication, not a new autonomous storage network.
Nodes do not discover strangers, promise permanent custody or create
replicas without somebody explicitly asking them to. Two nodes mean
two copies only after mirroring succeeds and both hashes verify.
What it does not do
No magic words.
Encryption protects file content, not timing, byte counts or a reused public identity. Nostr relays provide discovery, not the file bytes. Tor is optional and hides the node's home address, not every behavioural clue. Direct mode exposes ordinary network metadata. The experimental direct browser swarm remains an optional compatibility path and can expose IP addresses; the Wildbloom Node path does not use WebRTC, STUN or TURN.
Browser tool
Publish or retrieve a file
Wildbloom encrypts file content locally by default and keeps signing keys in your chosen signer. Use NIP-07 or hand exact event JSON to an external signer; never give Wildbloom a private key. Publishing metadata and joining a torrent swarm still reveal information. Nothing starts automatically.
01
Choose your infrastructure
No endorsed defaults. You decide which services learn about the file.
Use Tor Browser rather than SOCKS-proxying a normal browser. Wildbloom cannot prove that this browser is using Tor; an ordinary browser lacks Tor Browser's fingerprint protections and may not provide Web Crypto on HTTP onion origins. Tor-only mode refuses clearnet endpoints and disables WebRTC, but a NIP-07 add-on or reused Nostr key can still fingerprint or identify you.
Peer mode has no hidden public STUN or TURN default. That avoids an undeclared third party, but peer connections may fail across networks until an operator-controlled ICE policy is reviewed and configured.
02
Publish a file
Inspect locally first. Every network step remains separate.
External signing handoff
The handoff exposes the intended service and metadata, and the returned event adds the public signing identity. Transfer it deliberately. Never paste a private key or recovery key here.
Signing creates a NIP-94 hybrid file event and a NIP-35 torrent index locally.
03
Retrieve and verify
Resolve a signed NIP-94 event, then choose HTTP or peer delivery.