Freehold 1.1.0 · Peer-to-peer · Post-quantum · Credential vault · MIT licensed
Secure comms you hold outright
Freehold is peer-to-peer encrypted chat, calls, file transfer and a credential vault for small teams that handle sensitive work. No server, no accounts, no per-seat rent, no third party holding your metadata - and it keeps working where the internet does not reach. New in 1.1: your API keys, tokens and PATs live in the same vault as your history, and you hand one to a teammate down the same encrypted link instead of pasting it into a chat window. It downloads as a single self-contained file with nothing to install. Built for the defense industrial base: the five-person machine shop on three primes programs, with CUI obligations and an assessment coming.
Proof, not promises
Every claim on this page is enforced by the protocol and proven by an automated gate - 26 suites, 23 of which spawn real nodes over the real network and try to break the claim. A carrier that alters a relayed message is refused. A tampered evidence bundle fails verification. A 1 GB transfer killed at 30% resumes byte-identical. Two machines with no internet find each other in under a minute. A team whose lead has lost their machine still accepts the successor the old key named. A credential handed to a teammate is read back out of both machines’ history, and the test fails if it is there. The verifiers run on plain Node.js on a machine that has never seen Freehold - so the capture and the verdict can come from different people.
- $0MIT licensed - no tiers, no seats
- ML-KEM-768Post-quantum on every link, today
- 26Automated suites gating every claim
- ZeroCredentials pasted into a chat window
01 - See it work
A session, as it actually behaves
freehold · session open · 4 peers · Noise X25519 + ML-KEM-768 $ /roster import fireteam.roster signed by D. Whitlock - 6 members onboarded, 0 pasted keys policy: mandatory vault · 30d retention · CUI banner enforced $ /fuse 5s "grid ref for tomorrow - do not forward" grid ref for tomorrow - do not forward (burns in 5 seconds) burned on every device · no copy anywhere · entry written to audit chain $ /peers dana - direct - ML-KEM-768 - verified jonah - LAN - no internet - ML-KEM-768 - verified rivera - relayed - ML-KEM-768 - verified $ /secret send prod-deploy-token dana offered on the encrypted link · dana accepted - it is in her vault written into neither history · nothing to find in a transcript later $ /evidence export --since 30d bundle written · 412 events · hash chain intact mapped to NIST SP 800-171 · verify offline: node verify-evidence.mjs $ /burn --identity vault, history and identity destroyed. clean exit.
/fuse - ephemerality with a receipt
The message is destroyed on every recipient device when the fuse runs out, and the deletion itself is written to the tamper-evident chain. You get the operational benefit of a message that does not linger, without losing the ability to show an assessor that the policy was applied.
/secret send - the key that never enters the chat
The credential leaves your vault, crosses the same encrypted link as your messages, and lands sealed in hers - as an offer she accepted, not a message either of you now has to remember to delete. Search the transcript afterwards and there is nothing to find, because it was never written there.
…and where it is refused
In a records channel, roster policy makes the channel append-only - and a fuse is refused on every member machine, not merely discouraged by a console. That is the federal-records tension resolved rather than dodged: ephemeral where you want it, provably permanent where the rules require it.
02 - Sovereign by architecture
The dependency is the vulnerability
Your identity is your key
A Freehold UID is an Ed25519 public key generated on your machine. No account, no registration, nobody to register with - and no server exists to breach, subpoena, take offline, or bill you. Peers connect directly, NAT holepunching included.
Post-quantum today, not on a roadmap
Every link runs Noise (X25519) plus an independent hybrid ML-KEM-768 (FIPS 203) layer - a fresh key per message, periodic re-keying, downgrade refusal. Traffic recorded today stays unreadable to tomorrow computers, ahead of CNSA 2.0 timelines.
Policy enforced, not suggested
A team lead signs the member list and security policy with the same key that authenticates them. Retention, expiry caps, banners and mandatory vault are enforced by every member machine. Follow several rosters at once - strictest policy wins. And the roster names a successor in advance, so losing the lead machine does not freeze the team.
Provenance, not trust
Every channel message carries its author own signature, bound to the channel. A tampered message is refused and logged at the receiving end. That is what makes store-and-forward safe: relayed does not mean trusted, it means verified.
03 - Capability
Slack-grade workspace, zero servers
A real daily driver
- Channels, threads, reactions, editing, unread badges and @mentions
- Desktop notifications, search and image previews
- Voice and video calls, plus screen sharing, in the browser
- A full terminal client for people who live there
- Multi-device - one identity across up to eight machines
- A stolen laptop is revoked account-wide and stops receiving ciphertext
Built for where clouds cannot go
- Air-gapped LAN: two laptops find each other in under a minute, zero config
- Private bootstrap node never announced on any public network
- Store-and-forward relay through teammates you never overlap with
- Mission-size files - 2 GB chunked transfers that survive a dropped link
- Transfers resume where they stopped and are hash-verified on both ends
- DDIL is the design point, not the failure mode
Compliance without a cloud
- One-command signed evidence bundle mapped to NIST SP 800-171
- Verifiable offline by a third party with nothing but Node.js
- Records channels: append-only, deletion and self-destruct refused peer-side
- Signed, timestamped transcripts export on demand
- Tamper-evident hash-chained security event log
- CUI marking banners per conversation, enforced both ends
At rest and under duress
- AES-256-GCM at rest with a scrypt-hardened key; auto-relock on idle
- Credentials sealed individually inside that - the program holds ciphertext
- Duress passphrase that opens an innocent-looking empty account
- The duress wipe clears the whole data directory - not a list of filenames
- Dead-man switch that wipes an abandoned machine; /burn for a clean exit
- Priority alerts everyone must acknowledge, with a live who-has-not board
- Optional traffic-shape padding; cover traffic hides idle links
Continuity, not a single point of failure
- A roster names its successor inside its own signature, before it is needed
- Losing the lead machine no longer freezes the team permanently
- Members offline during a succession pick it up when they reconnect
- Encrypted identity backup - seed, rosters, attestations and contacts
- Sealed with the same scrypt and AES-256-GCM as the vault
- Stated plainly: a successor is a delegation, and a backup file is you
Nothing to install
- Version 1.1 ships as a bundle carrying its own Node runtime
- Six builds: macOS Apple Silicon and Intel, Windows x64 and ARM, Linux x64 and ARM
- 32 to 44 MB compressed - unzip, double-click, running
- No Node, no Python, no npm install, no admin rights, no IT ticket
- Your data lives outside the app folder, so upgrading never loses an identity
- A published SHA-256 per archive so you can check what you downloaded
04 - New in 1.1
Your keys belong in the vault, not in the thread
In the vault you already have
Credentials require the vault passphrase - every command is refused without one, and the vault cannot be turned off while credentials are in it. Values are sealed individually inside the already-encrypted store, so the running program holds ciphertext: listing, searching and every export have never touched a plaintext key. One is opened only to answer a single request.
Handed over, never posted
Send a credential to a teammate and it travels the live end-to-end encrypted link as an offer they accept or refuse - straight into their vault, sealed under their passphrase the moment it lands. It is written into neither side’s history, so it cannot come back in a transcript, an export, or a backfill to somebody who was offline. A machine with no vault refuses to receive one and says why.
It inherits every protection you set
Auto-lock drops credentials from memory with everything else. The duress passphrase and dead-man switch destroy them with the rest of the data directory. The encrypted identity backup carries them out, because a dead disk is the one thing your peers cannot help you recover from. And the evidence bundle gains NIST SP 800-171 3.5.10 - authenticators stored and transmitted cryptographically protected.
And what it does not do
This is not your browser autofill: no extension, no form filling, no phone. And once a teammate holds a credential, that copy is theirs - rotating yours does not reach it. So the app shows you who else holds each one, because that list is the blast radius and the people you have to re-send to, and telling you that is more useful than implying a control we do not have.
05 - The comparison
Freehold versus renting a cloud messenger
| Freehold | Cloud secure messengers | |
|---|---|---|
| Cost | $0 - MIT licensed, no tiers, no seats | ~$5–15 per user / month; retention and e-discovery in the premium tier (~$1,800/yr for 10 seats) plus procurement friction |
| Infrastructure | None. Peer-to-peer - nothing to stand up, patch, or trust | Vendor cloud holds accounts, routing and metadata |
| Cross-org collaboration | Import a signed roster file per team - a sub on three primes follows three rosters at once | Admin-gated federation: security groups and network IDs exchanged between administrators per org pair |
| No internet / air-gapped | Native: zero-config LAN discovery, private bootstrap, relay through teammates | No reach to the cloud means no service |
| Quantum resistance | Hybrid ML-KEM-768 on every link, today | No public evidence the E2EE protocol itself is post-quantum |
| Retention vs ephemerality | Records channels: append-only and signed, enforced peer-side, beside fully ephemeral channels | Compliance bolt-on in the paid tier of a burn-by-default tool |
| Assessment evidence | Signed, 800-171-mapped bundle your assessor verifies offline | The vendor own accreditations keep the vendor compliant - they do little for your SSP |
| Message provenance | Per-message author signatures; tampered relays refused and audited | Server-mediated trust |
| Passing a credential to a teammate | Handed down the encrypted link into their vault, written into neither history - included, not a second subscription | Pasted into a chat thread, or bought separately as a team password manager at another ~$4–8 per user / month |
| Deployment | Download, unzip, double-click - the runtime is in the bundle. No admin rights, no MDM packaging, no per-seat provisioning | Installer plus account provisioning per seat, and a directory integration when it is more than a handful of people |
| If someone leaves | The roster names a successor in advance, signed by the key that was already the anchor. You hold an encrypted identity backup | The vendor console restores the account - convenient, and the same fact as the vendor holding your identity |
| Distribution trust | Published SHA-256 per archive; builds are not code-signed yet, and we say so on the download | Signed, notarized installers - a real advantage today |
06 - Deployment
Five minutes, no IT department
Download and unzip
Pick the build for your machine - macOS, Windows or Linux, Intel or ARM. Between 32 and 44 MB. Check the published SHA-256 if you want to; it takes ten seconds and is worth doing.
Double-click Freehold
There is nothing to install. The bundle carries its own runtime, so no Node, no Python, no admin rights. The first open needs a right-click → Open on macOS, or More info → Run anyway on Windows, because the build is not signed yet.
Swap UIDs once, and you are operational
Send your UID over any channel you already trust and add theirs - the mutual add is the whole trust ceremony, verified with matching emoji fingerprints on a call. Direct encrypted links then come up on their own through NATs, with no port forwarding and no server.
07 - Plain speaking
What we do not claim - read this part
Not an accredited system
No IL4/IL5, no FedRAMP, and the cryptography is not FIPS-validated - the algorithms are the NIST standards, but the implementation has not been through a validation programme. Where a contract mandates an accredited tool, Freehold is the disconnected-operations, cross-org, records-honest complement to it - not a compliance substitute. Confirm CUI usage with your FSO.
Not code-signed yet
The 1.1 builds are unsigned, so macOS and Windows both warn on first open - and those warnings are correct: your OS cannot verify who produced the file. We publish a SHA-256 for every archive instead, which proves the download was not altered but not who made it. Signing is a certificate we have not bought yet, and we would rather say that than teach you to click through security prompts.
Not a full password-manager replacement
The credential vault covers what a team passes between people - keys, tokens, PATs, service passwords. It is not your browser autofill: no extension, no form filling, no phone, no shared folders with per-item permissions. And once a credential is used or handed over it is outside our reach - a teammate’s copy is theirs, and rotating yours does not reach it, which is why the app shows you who else holds each one instead of implying control we do not have.
Not for thousands of seats
Built for program teams - tens of people. If you are rolling out to an enterprise directory of five thousand users, this is the wrong shape of tool and we will say so.
Not on phones yet
Desktop today: six builds across macOS, Windows and Linux, in the browser or a full terminal client. No mobile client. If you need phones now, we will tell you in the first conversation rather than the third.
Not self-updating
A portable folder has no update path, so nothing tells you a new version exists - you download the new bundle and replace the old folder. That is safe, because your identity and history live outside the app folder and survive the swap. It is still a manual step, and on our list.
Not magic
A compromised laptop beats any messenger, a peer can leak anything you send, and a forgotten vault passphrase has no recovery - that is the price of nobody else holding your keys. Every feature states its limits at the moment of use. That discipline is the product.
08 - Specification
The summary for whoever will actually evaluate it
| Version | 1.1.0 - built and published 2 August 2026 |
|---|---|
| Identity | Ed25519 keypair generated on your machine - no account, no registration |
| Transport | Peer-to-peer with NAT holepunching; no server in the data path |
| Transport encryption | Noise protocol over X25519, peer identity pinned |
| Post-quantum layer | Independent hybrid ML-KEM-768 (NIST FIPS 203), downgrade refusal |
| Message keys | Fresh key per message, periodic re-keying |
| At rest | AES-256-GCM with a scrypt-hardened key; idle auto-relock |
| Credential vault | Each value AES-256-GCM sealed on its own inside the encrypted store; vault passphrase required, and it cannot be turned off while credentials are held |
| Credential handover | Offered peer-to-peer on the live encrypted link and accepted explicitly; never written into message history, a transcript or an export |
| Rosters and policy | Ed25519-signed; enforced on every member machine, strictest wins |
| Continuity | Successor named inside the roster signature; encrypted identity backup |
| Message provenance | Per-message author signature bound to the channel |
| Audit | Hash-chained security event log; silent tampering breaks the chain visibly |
| Evidence | Signed bundle mapped to NIST SP 800-171 - including 3.5.10, authenticators stored and transmitted cryptographically protected - verifiable offline with Node.js |
| File transfer | 2 GB chunked, resumable, hash-verified both ends |
| Platforms | macOS, Windows, Linux - Intel and ARM; browser or terminal; up to 8 devices per identity |
| Distribution | Self-contained bundle carrying its own Node runtime - 32 to 44 MB compressed, around 120 MB unpacked. Not code-signed |
| Integrity | SHA-256 published for every archive; verify before you run it |
| Licence | MIT, open source - built on the chat-tunnel protocol |
| Assurance | 26 automated suites, 23 of them driving real nodes over the real network |
Source, protocol and verifiers: github.com/MacTech-Solutions-LLC/chat-tunnel. Builds for all six platforms, with their checksums, are on the v1.1.0 release.
09 - Questions
Asked and answered
What is Freehold?
Freehold is peer-to-peer encrypted chat, calls and file transfer for small teams that handle sensitive work. There is no server, no accounts, no per-seat rent, and no third party holding your metadata. It is MIT licensed and open source, built on the chat-tunnel protocol. The name is the thesis: a freehold is property you own outright rather than rent - which is exactly the difference between this and a cloud messenger subscription.
Freehold is a password manager as well?
As of 1.1, yes - for the credentials a team actually passes around: API keys, deploy tokens, PATs, service passwords. They live in the same encrypted vault as your history, and the reason it belongs in a messenger is the failure it removes. The way a production key usually reaches a colleague is a chat message, a mail, or a ticket, and it stays there afterwards. In Freehold you hand it over the same end-to-end encrypted link, as an offer they accept - and it is never written into either side’s message history, so it cannot resurface in a transcript, an export, or a backfill to someone who was offline. Values are sealed one by one inside the already-encrypted file, so the running program holds ciphertext until you ask for a specific credential by name.
What stops the credential vault from being the weak link?
Three deliberate constraints. Credentials require the vault passphrase: every command is refused without one, and turning the vault off is refused while credentials are stored - a credential store that wrote production keys to a plaintext disk would not be a degraded feature, it would be a lie. A credential is decrypted only for as long as it takes to answer one request, so listing, searching and every export have never touched a plaintext value. And handing one over needs both people online, because there is no queue for a credential; a machine with no vault refuses to receive one and tells the sender why. What we do not claim: once you use a credential it is subject to everything on that machine, and once a teammate holds it, that copy is theirs - rotating yours does not reach it, which is why the app shows you who else holds each one.
How much does Freehold cost?
Nothing. It is MIT licensed with no tiers and no seats. The comparison that matters is against cloud secure messengers at roughly $5–15 per user per month, where retention and e-discovery typically live in a premium tier - around $1,800 a year for a ten-seat subscription, plus the procurement friction of buying it. Freehold has no per-seat cost because there is no vendor infrastructure to pay for.
How does Freehold work with no internet at all?
Two laptops on one network segment find each other in under a minute with zero configuration, using an identity-free discovery beacon. You can also run your own one-file bootstrap node that is never announced on any public network. Messages relay through teammates to people you never overlap with - carrying the original author signature, so a relayed message is still verified rather than merely trusted. Denied, disrupted, intermittent and limited connectivity is the design point, not the failure mode.
What does post-quantum actually mean here?
Every link runs Noise over X25519 plus an independent hybrid ML-KEM-768 layer - the NIST FIPS 203 standard - with a fresh key per message, periodic re-keying, and downgrade refusal. Traffic recorded today stays unreadable to tomorrow computers, which is the "harvest now, decrypt later" exposure post-quantum cryptography exists to close. This is ahead of CNSA 2.0 timelines rather than a future roadmap item.
Can Freehold produce evidence for an assessment?
One command exports a signed bundle - verified audit chain, roster policy, retention settings, crypto inventory - mapped to NIST SP 800-171 control families. A third party can verify it offline with nothing but Node.js. Drop it in an SSP or hand it to a C3PAO. Freehold also supports records channels where roster policy makes a channel append-only: deletion and self-destruct are refused on every member machine, and signed timestamped transcripts export on demand. That resolves the federal-records retention versus ephemerality tension the DoD IG has documented, instead of dodging it.
What protects a device that is lost or seized?
Identity, history, files and stored credentials are encrypted at rest with AES-256-GCM and a scrypt-hardened key, and the vault auto-relocks on idle - the browser is outside the trust boundary. A duress passphrase destroys everything and opens an innocent-looking empty account. A dead-man switch wipes an abandoned machine. There is a /burn command for a clean exit. The tradeoff is stated plainly: a forgotten vault passphrase has no recovery, because nobody else holds your keys.
Is Freehold accredited - can it replace an authorized system?
No, and we will not claim otherwise. There is no IL4/IL5 or FedRAMP accreditation. Where a contract mandates an accredited tool, Freehold is the disconnected-operations, cross-org, records-honest complement to it - not a compliance substitute. It is built for program teams of tens of people, not thousands of seats. Anyone handling CUI should confirm usage with their FSO.
How is a team set up without exchanging keys by hand?
A team lead signs the member list and security policy with the same key that authenticates them. Policy - retention, expiry caps, banners, mandatory vault - is enforced by every member machine rather than suggested by a console. You can follow several rosters at once and the strictest policy wins, which is how a subcontractor on three primes programs works in practice. Cross-org collaboration is importing a signed roster file per team, not an admin-gated federation negotiated between two organizations.
How long does deployment take?
About five minutes and no IT department. Version 1.1 ships as a self-contained bundle - 32 to 44 MB compressed, depending on platform - that carries its own Node.js runtime. There is nothing to install: unzip it, double-click Freehold, and the app opens. No Node, no Python, no npm install, no admin rights. Then swap UIDs with your teammates once over any channel you already trust - the mutual add is the whole trust ceremony, and you verify with matching emoji fingerprints on a call. After that, direct encrypted links come up on their own through NATs, with no port forwarding, no firewall tickets, and no server.
What platforms does Freehold run on?
Version 1.1 publishes six bundles: macOS on Apple Silicon and Intel, Windows on x64 and ARM, and Linux on x64 and ARM. Desktop today - the app runs in your browser, or as a full terminal client for people who live there. One identity works across up to eight machines, messages reach every device, and a stolen laptop is revoked account-wide and stops receiving ciphertext at all. There is no mobile client yet. If your use case requires phones today, we will tell you that in the first conversation rather than the third.
Why does my computer warn me when I open the download?
Because the builds are not code-signed yet, and the warning is accurate - your operating system genuinely cannot verify who produced the file. macOS Gatekeeper will refuse the first open; right-click and choose Open, once. Windows SmartScreen will warn; choose More info, then Run anyway. Instead of training you to click through security prompts, we publish a SHA-256 for every archive so you can confirm the file arrived unaltered. That proves integrity, not origin - signing is the fix, and it is a purchase we have not made yet rather than a build step we forgot.
What happens if the team lead loses their laptop?
A roster can name a successor inside its own signature. If the issuer can no longer sign, the named key issues the next version and every member accepts it - not because they trust the new key, but because the old key, while it still worked, signed that name into the roster they already hold. Team, policy and channel scope carry over, and members who were offline pick it up when they reconnect. Separately, any member can seal an encrypted backup of their identity, followed rosters and contacts with the same scrypt and AES-256-GCM as the vault. We state the sharp edges too: a successor is a delegation, not a backup - that key can take the team at any time - and whoever opens a backup file becomes you.
Bring us the network you think will break it
The demonstration is two laptops, one switch, and no uplink - or your own contested environment, if you would rather we earned it the hard way. Thirty minutes, no procurement, and you keep the evidence bundle either way. Or skip the meeting entirely: it is MIT licensed, the download is free, and nobody is counting your seats.