ChatNode is a program you run yourself, not a service you sign up to. That makes a few things work differently from the apps you are used to — mostly in your favour, but it is worth ten minutes to understand.
This page walks through getting started, then explains each part of the app and when you would use it.
Ordinary messaging apps put a company in the middle. You send a message to their servers, and their servers deliver it. That company can read it, keep it, lose it, or be compelled to hand it over.
ChatNode removes the middle. Your device connects directly to the other person's device and the message goes straight across, encrypted so that only the two of you can read it. Nobody holds your conversations, because there is no server keeping them.
Three consequences follow, and they explain almost everything else on this page:
Pick the build for your platform. On Windows and Android it runs as a normal app. On macOS, Linux and Raspberry Pi the node runs in the background and you open the interface in your browser.
No installer wizard, no account, no email address.
On first launch your node generates a cryptographic keypair. That keypair is your identity — there is nothing to sign up for and no password to choose.
Your Peer ID is the public half. Share it freely.
Your node finds others through community-run bootnodes and starts holding connections open. Once it is connected you can be reached by anyone who knows your Peer ID.
Leave it running — an offline node cannot receive messages.
Paste someone's Peer ID into Messages and send. Nothing routes through a company's servers: the message goes to their node, encrypted end to end.
No name needed to get this far — register one when you want the network to find you.
On macOS, Linux and Raspberry Pi, open 127.0.0.1:8080 in your browser after starting the node. That is the same interface the Windows and Android apps show — it is served by the node on your own machine, not fetched from the internet.
Your Peer ID is a long string beginning 12D3KooW…. It is generated on your device, it is yours cryptographically, and it is how other people reach you. Anyone can have it; it reveals nothing you would not want shared.
You can use ChatNode straight away without registering anything. As a guest you have a full identity, and the core of the app already works: send and receive encrypted messages, make audio and video calls, send files, reach your own machines through My Nodes, watch your cameras, and hold a wallet. That is not a trial or a limited tier — it is the product, and it costs nothing.
Nothing about a guest identity is second-class: your keys, your encryption and your ability to be contacted are exactly the same as everyone else's.
What a guest lacks is a name. People can reach you, but only by pasting 52 characters, and the network cannot look you up.
A .chat domain is a short name recorded on a blockchain that points at your Peer ID — yourname.chat instead of 12D3KooW…. It is yours, it renews yearly, and no company can take it back or reassign it.
Being findable is what the rest of the app is built on, so registering a name switches several things on at once:
The split is not arbitrary. Everything a guest can do is between you and someone you already know; everything a name adds involves the network knowing who you are. One is private by nature, the other needs an identity to point at — so the name is what you register when you want to be part of the wider network rather than just talk to the people you brought with you.
Nothing is lost by waiting. Register whenever you like and your existing conversations, contacts and history carry straight over — the name attaches to the identity you already have.
Your key file is the one thing you cannot replace. It lives in the node's data folder as id.json.
Lose it and that identity is gone permanently — contacts, domain and history with it. Let someone else copy it and they can read your messages and send messages as you. Export a backup from Settings today, and keep it somewhere safe.
Open Messages, paste a Peer ID or a .chat name, and start typing. Messages are end-to-end encrypted using keys derived from the two identities involved, so only the two devices can read them. Unencrypted messages are refused rather than displayed.
You can edit or delete a message after sending, and the change propagates to the other person's node. Files can be sent the same way, straight between devices.
Audio and video calls connect peer to peer using WebRTC. Where a direct connection is impossible — some mobile and office networks block it — the media is relayed so the call still connects.
The first message to someone new goes through a bootnode, because your two devices have not met yet and there is no connection between them. It is encrypted before it leaves your device, so the bootnode passes along ciphertext it cannot read.
After that first exchange the other person becomes a contact, and your nodes connect to each other directly. Everything from then on — messages, files, calls — travels straight between the two devices with nobody in between. Your node re-establishes those connections automatically whenever you and a contact are both online.
The exception is a network that makes a direct connection impossible, which some mobile carriers do. There the traffic keeps flowing through a bootnode relay, still encrypted end to end.
Normally a message to an offline contact simply fails: their node is not running, so there is nowhere to deliver it. Rather than leave that as a dead end, ChatNode can hold the message for them — but only if you ask it to, message by message.
When you type to a contact who is offline, the app offers two choices:
A queued message waits on a bootnode and is pushed to the recipient the moment they next come online. Messages that travelled this way are marked relayed in the conversation, so you can always tell which path a message took.
A bootnode cannot read what it holds. The message is encrypted on your device before it is handed over, and the queue refuses to accept anything that is not already ciphertext. The operator stores an opaque blob addressed to someone else.
Queued messages are deleted on delivery, and after 24 hours either way. If your contact does not come back within a day, the message is gone rather than sitting on someone else's disk indefinitely.
Relaying is off unless you choose it. Nothing is stored anywhere by default — that is the point of the prompt. If you send nothing and your contact is offline, there is no copy of anything, anywhere.
One caveat worth knowing: the message queues on the single bootnode your node relayed through. Nodes normally reach all of them, so this is rarely an issue, but a recipient who only ever connects to a different bootnode may not collect the message before it expires.
Peers lists other nodes on the network, with their domain and connection status, so you can find people without knowing their Peer ID in advance.
Rooms are group chats that exist across the network rather than on a server. Anyone in a room sees what is posted there — treat rooms as public, not private.
Browser reaches sites served by other nodes. Each node can publish a small site from its own data folder, so pages are hosted by the people running them rather than by a hosting company.
These require a registered .chat domain, along with Games — see Guests, Peer IDs and .chat Names for why.
If you run ChatNode on a machine at home, My Nodes lets you reach devices on that machine's local network from anywhere — your router's admin page, a NAS, a camera — without setting up port forwarding.
It works because your home node already holds an outbound connection to the network, and traffic rides inside that existing encrypted link.
To use it, start the node on the remote machine with your own Peer ID as the authorised peer. It then appears under My Nodes, and you can open a connection to an address on its network.
This is deliberately restricted: it is off unless you enable it, and it reaches only private addresses on a short list of administrative ports.
Two peers can connect: the one you name, and the network administrator. The second exists so a misconfigured node on a machine with no other remote access can still be recovered — but it means enabling this grants the network admin reachability into that machine's local network. Do not enable it on a network you are not willing to expose on that basis.
Use it only on networks you own or administer. Reaching someone else's network without permission is a criminal offence in most countries.
If a machine running ChatNode sits on a network with IP cameras, My Cameras lets you watch them from anywhere. Add a camera by its RTSP address on the node beside it, and it appears in the app on every device you own.
This is the part worth understanding, because it is normally the hard bit. Watching a home camera from outside usually means forwarding a port on your router, or trusting a manufacturer's cloud — the first puts your camera on the public internet where anyone can find it, and the second hands your footage to a company.
ChatNode needs neither. Your home node already holds an outbound connection to the network — the same one it uses for messages — and the video travels back inside it. Nothing listens for incoming connections, so there is no router configuration at all, and no open port for anyone to scan, find or attack. Your camera stays invisible from the outside while you watch it from the other side of the world.
It also works where port forwarding cannot: behind carrier-grade NAT, on mobile broadband, or on a network you are not allowed to reconfigure.
Where a camera supports it, you also get two-way audio (listen, and speak back through its speaker), pan, tilt and zoom, on-device recording, and controls like reboot and lights. The app shows only the controls a given camera actually has.
Cameras on several different nodes — a home, an office, a cabin — appear together in one place.
The camera's password never leaves the node beside it. That node is the only one that ever talks to the camera; it converts the feed and relays the video inside your encrypted connection. Neither the credential nor the raw stream passes through a bootnode or any other third party.
Recordings are saved on the device you are watching from, not on the camera's node.
ChatNode includes a wallet for the CHAT token. You can send and receive tokens, view your transaction history, and scan QR codes for payments. The private key stays on your device with the rest of your identity.
The wallet is also what pays for a .chat domain registration, since that is recorded on a blockchain.
Blockchain transactions cannot be reversed. Check the destination address before sending — there is no support desk that can undo it.
By default your node is open: anyone on the network can connect to it. Private peers mode narrows that to a list you control.
With it enabled and at least one peer listed, your node refuses every incoming connection from anyone not on your list, stops taking in network-wide peer lists, and connects only where you direct it. It also stops relaying through bootnodes — the group reaches each other directly, so no third party carries your traffic or sees who is talking to whom.
One thing still happens: the node performs a DNS lookup at startup to find bootnodes, before deciding it does not need them. That reveals nothing about your conversations, but it is not literally zero contact with project infrastructure.
That makes it the strongest privacy setting ChatNode offers, and the right choice for a company or a closed group.
The trade-off is setup. Without discovery servers, every member needs to be reachable at a stable address — in practice a static IP or a hostname that tracks one, plus a forwarded port on their router. Members on ordinary home connections that change address, or behind carrier-grade NAT, will not be reachable this way.
Bootnodes are the nodes that help everyone else find each other. They cannot read the traffic they relay, and the only thing they ever store is a message a sender explicitly asked them to hold for an offline contact — encrypted, and deleted within 24 hours. The network needs some of them to exist.
Anyone can run one. A bootnode is the same software you already have, started in a different mode, and it is the most direct way to support the network if you have a machine that stays online.
A bootnode is only useful if other nodes can reach it from the outside, and that is a networking requirement rather than a software one. Before you start, you need:
This is why a bootnode is usually run on a VPS or a server rather than a home connection. A hosted machine comes with a static address by default and needs no router configuration at all — the two hardest requirements disappear.
If you are behind carrier-grade NAT — common on mobile and some fibre providers — port forwarding will not help, because you do not control the address others would connect to. A rented server is the practical route.
Everything lives on your device, so backing up is worth doing properly. Settings has a backup section that exports your identity key together with your contact list. Store that export somewhere safe and offline — anyone holding it can become you.
Updates are checked from within the app. Every release is cryptographically signed, and your node verifies that signature before installing anything, so an altered build is refused even if the download server were compromised.
Questions the guide does not answer? Ask in the Telegram group, or read the full feature list.
Get the decentralized communication platform on your device. Windows and Android run as full apps; macOS, Linux, and Raspberry Pi run the node and serve the portal at 127.0.0.1:8080 in your browser.
Windows installer • macOS & Linux binaries • Android APK • Raspberry Pi (ARM64)