by Wolf McNally and Christopher Allen
Hubert provides a distributed infrastructure for secure multiparty transactions, such as FROST threshold signature ceremonies, enabling participants to communicate bidirectionally with complete opacity to outsiders. By leveraging write-once distributed storage with cryptographic identifiers, Hubert creates a trustless coordination layer where parties can exchange encrypted messages without relying on centralized servers or exposing sensitive information to network observers.
Hubert's main purpose is to facilitate secure multiparty transactions where:
- Participants write once using ARID (Apparently Random Identifier) keys
- Messages contain ARIDs for expected responses, enabling bidirectional communication
- Complete opacity to outsiders through end-to-end encryption (GSTP)
- No central server required for coordination
- Trustless operation using public distributed networks (BitTorrent DHT, IPFS)
Example Use Case: FROST Signing Ceremony
- Coordinator publishes encrypted signing request with ARID for responses
- Participants retrieve request, generate signature shares
- Each participant publishes encrypted response at coordinator-specified ARID
- Coordinator retrieves all responses and completes signature
- Network observers see only GSTP envelopes (encrypted subject, sealed recipient assertions)
- ARIDs are never exposed - shared privately via secure channels (Signal, QR codes, etc.)
Ted Nelson's Project Xanadu had its own playful jargon. The basic object that behaved like a "file" was called a bert—named after Bertrand Russell. And because geeks can't resist wordplay, there was also an ernie, the metered unit of billing in the publishing system.
Mark S. Miller, one of Xanadu's architects, later designed the Club System (early groundwork for his capability-security thinking), which modeled group permissions but still relied on identity-checked ACLs rather than pure capabilities. That historical thread matters because Hubert sits exactly where Xanadu's ideas were pointing, but finishes the job with cryptography.
So: Hubert is the hub of berts. In Xanadu terms, it's the rendezvous point where these file-like objects (and their successors) can meet, exchange sealed messages, and coordinate—without servers, accounts, or trusted intermediaries. It's a deliberate nod to Nelson's vocabulary and to the "clubs" lineage, reframed for an era where capability comes from math, not administrators.
There's also a second layer to the name. Cryptography uses a stock cast—Alice, Bob, Carol, et al.—to illustrate protocols. Hubert joins that dramatis personae as the sturdy switchboard operator in the background: the dropbox, dead-drop, and message hub that keeps multiparty ceremonies moving while revealing nothing but ciphertext to the outside world.
Install hubert from crates.io:
cargo install hubertOr install from source:
cd hubert
cargo install --path .See the CLI Manual for detailed usage instructions.
Add Hubert to your Cargo.toml:
[dependencies]
hubert = "0.1.0"
bc-components = "^0.25.0"
bc-envelope = "^0.34.0"
tokio = { version = "1", features = ["macros", "rt-multi-thread"] }See the API Manual for detailed usage instructions.
Hubert provides APIs for four storage backends, all using write-once semantics:
- BitTorrent Mainline DHT: Fast, lightweight, serverless (≤1 KB messages)
- IPFS: Large capacity, content-addressed (up to 10 MB messages)
- Hybrid: Automatic optimization by size, combining DHT speed with IPFS capacity
- Server: Centralized storage for testing and controlled deployments (configurable size limits)
The first three backends (DHT, IPFS, Hybrid) provide decentralized, trustless operation suitable for production use. The Server backend is designed for development, testing, and controlled environments where centralized coordination is acceptable.
Write-once semantics eliminate race conditions and ensure message immutability—once published, content cannot be modified or deleted by anyone, providing strong integrity guarantees.
All storage operations use ARIDs (Apparently Random Identifiers):
- Deterministic: Same ARID always maps to same storage location
- Privacy-Preserving: ARID never exposed publicly; only derived storage keys visible
- Collision-Resistant: 256-bit cryptographic strength
- Capability-Based: ARID holder can read; ARID creator can write (once)
- Secure Distribution: ARIDs shared via encrypted channels (GSTP, Signal, QR codes)
Participants generate ARIDs for their messages and embed ARIDs where they expect responses, creating a decentralized communication graph. Storage networks see only derived keys (via HKDF), never the ARIDs themselves.
Hubert is designed to work with GSTP (Gordian Sealed Transaction Protocol) messages:
- Sender Authentication: Cryptographic signatures prove message origin
- Receiver Encryption: Only intended recipients can decrypt content
- Multi-Recipient: Single message encrypted to multiple parties
- Stateless Operation: Encrypted State Continuations eliminate server-side sessions
- Network Opacity: Storage networks see only encrypted envelopes
With GSTP integration, even storage indirection is secured—when Hybrid storage uses references, the references themselves are encrypted to the same recipients as the payload.
Hubert enables request-response flows without direct connections:
Requester Workflow:
- Generate response_arid for where responder should publish
- Create request message containing response_arid (encrypted within GSTP)
- Publish encrypted request at request_arid
- Share request_arid with responder via secure channel (Signal, QR code, etc.)
- Monitor response_arid for responder's reply
Responder Workflow:
- Receive request_arid via secure channel
- Retrieve GSTP envelope from storage (using derived key from request_arid)
- Decrypt and process request (only if recipient)
- Extract response_arid from decrypted request
- Create encrypted response
- Publish response at response_arid
This pattern supports complex multiparty protocols (threshold signatures, distributed key generation, secure voting) without requiring participants to be online simultaneously or maintain persistent connections.
The Hybrid storage backend automatically optimizes for size:
- Small messages (≤1 KB): Stored directly in DHT for fast retrieval
- Large messages (>1 KB): Reference stored in DHT, actual content in IPFS
- Transparent indirection: Applications use same API regardless of size
- Secure references: With GSTP, even references are encrypted to recipients
This enables applications to send compact control messages via DHT while supporting large payloads (key material, proofs, documents) via IPFS without changing code.
Coordinate multi-party threshold signature ceremonies:
- Coordinator publishes signing request with participant ARIDs
- Participants publish signature shares at designated ARIDs
- Coordinator aggregates shares into final signature
- No trusted server required; all communication encrypted
Bootstrap threshold key generation among multiple parties:
- Participants exchange commitments via encrypted messages
- Share verification happens asynchronously
- Final key shares distributed to all participants
- Entire ceremony verifiable but private
Enable privacy-preserving computation across parties:
- Input commitments published by each party
- Computation steps coordinated via message passing
- Results revealed only to designated recipients
- Network observers see only encrypted data flow
Facilitate multi-round negotiations without real-time requirements:
- Parties exchange proposals at their convenience
- Each round builds on previous ARIDs
- State carried in encrypted continuations
- No intermediary servers involved
Provide sovereign messaging infrastructure:
- Sender publishes encrypted message at chosen ARID
- Shares ARID with recipient via secure channel (Signal, GSTP, QR code)
- Recipient retrieves and decrypts message (using derived storage key)
- No metadata exposed to network observers (only GSTP envelope structure visible)
- Initial release.
Hubert is currently in the community review phase and should not be used for production tasks until it has had further testing and auditing.
See Blockchain Commons' Development Phases.
Hubert is a project of Blockchain Commons. We are proudly a "not-for-profit" social benefit corporation committed to open source & open development. Our work is funded entirely by donations and collaborative partnerships with people like you. Every contribution will be spent on building open tools, technologies, and techniques that sustain and advance blockchain and internet security infrastructure and promote an open web.
To financially support further development of Hubert and other projects, please consider becoming a Patron of Blockchain Commons through ongoing monthly patronage as a GitHub Sponsor. You can also support Blockchain Commons with bitcoins at our BTCPay Server.
We encourage public contributions through issues and pull requests! Please review CONTRIBUTING.md for details on our development process. All contributions to this repository require a GPG signed Contributor License Agreement.
The best place to talk about Blockchain Commons and its projects is in our GitHub Discussions areas.
Gordian Developer Community. For standards and open-source developers who want to talk about interoperable wallet specifications, please use the Discussions area of the Gordian Developer Community repo. This is where you talk about Gordian specifications such as Gordian Envelope, bc-shamir, Sharded Secret Key Reconstruction, and bc-ur as well as the larger Gordian Architecture, its Principles of independence, privacy, resilience, and openness, and its macro-architectural ideas such as functional partition (including airgapping, the original name of this community).
Gordian User Community. For users of the Gordian reference apps, including Gordian Coordinator, Gordian Seed Tool, Gordian Server, Gordian Wallet, and SpotBit as well as our whole series of CLI apps. This is a place to talk about bug reports and feature requests as well as to explore how our reference apps embody the Gordian Principles.
Blockchain Commons Discussions. For developers, interns, and patrons of Blockchain Commons, please use the discussions area of the Community repo to talk about general Blockchain Commons issues, the intern program, or topics other than those covered by the Gordian Developer Community or the Gordian User Community.
As an open-source, open-development community, Blockchain Commons does not have the resources to provide direct support of our projects. Please consider the discussions area as a locale where you might get answers to questions. Alternatively, please use this repository's issues feature. Unfortunately, we can not make any promises on response time.
If your company requires support to use our projects, please feel free to contact us directly about options. We may be able to offer you a contract for support from one of our contributors, or we might be able to point you to another entity who can offer the contractual support that you need.
The following people directly contributed to this repository. You can add your name here by getting involved. The first step is learning how to contribute from our CONTRIBUTING.md documentation.
| Name | Role | Github | GPG Fingerprint | |
|---|---|---|---|---|
| Christopher Allen | Principal Architect | @ChristopherA | <[email protected]> | FDFE 14A5 4ECB 30FC 5D22 74EF F8D3 6C91 3574 05ED |
| Wolf McNally | Lead Researcher/Engineer | @WolfMcNally | <[email protected]> | 9436 52EE 3844 1760 C3DC 3536 4B6C 2FCF 8947 80AE |
We want to keep all of our software safe for everyone. If you have discovered a security vulnerability, we appreciate your help in disclosing it to us in a responsible manner. We are unfortunately not able to offer bug bounties at this time.
We do ask that you offer us good faith and use best efforts not to leak information or harm any user, their data, or our developer community. Please give us a reasonable amount of time to fix the issue before you publish it. Do not defraud our users or us in the process of discovery. We promise not to bring legal action against researchers who point out a problem provided they do their best to follow the these guidelines.
Please report suspected security vulnerabilities in private via email to [email protected] (do not use this email for support). Please do NOT create publicly viewable issues for suspected security vulnerabilities.
The following keys may be used to communicate sensitive information to developers:
| Name | Fingerprint |
|---|---|
| Christopher Allen | FDFE 14A5 4ECB 30FC 5D22 74EF F8D3 6C91 3574 05ED |
You can import a key by running the following command with that individual's fingerprint: gpg --recv-keys "<fingerprint>" Ensure that you put quotes around fingerprints that contain spaces.
- Gordian Envelope: Structured data format with encryption and signing
- GSTP: Sealed transaction protocol for secure messaging
- Clubs: Gordian Clubs
- bc-components: Cryptographic components including ARID
Hubert: Enabling trustless coordination for secure multiparty transactions.