The Ant64 isn't just a computer. It's a node in a mesh. Every Ant64 in the world is capable of finding, trusting, and communicating with every other — without a server, without a cloud account, without asking anyone's permission. That capability is built into the OS at a level as fundamental as the filesystem. It's called Gossip.
The Problem With Connected Computers
Every personal computer made in the last thirty years has been connected to the internet, yet genuine peer-to-peer communication between them remains surprisingly hard. You need an account. You need a server somewhere that stores your messages. You need to trust a company to keep your data private, to stay in business, to not change its terms of service. The machine on your desk is powerful enough to talk directly to the machine on your friend's desk, but in practice it almost never does.
Gossip is a direct response to this. It is a fully decentralised peer-to-peer messaging layer, built into AntOS, that requires no accounts, no servers, and no infrastructure beyond the network the computers already share. Every Ant64 is its own node. Your address is your public key. Your friends list lives on your machine.
Identity
When AntOS initialises Gossip for the first time, it generates an Ed25519 keypair and stores it securely on the B: drive. Your public key is your node ID — a 64-character hex string that uniquely identifies you across the entire network, forever, without any registration. Every packet you send is signed with your private key. Every packet you receive is verified against the sender's public key before it is acted upon. There is no concept of spoofing a Gossip identity.
You can give yourself a name — a short known as and a longer formal name — and these travel with your heartbeat packets so your friends always see a human-readable label alongside your node ID.
Discovery
On a local network, Ant64s find each other automatically. Every few minutes, AntOS broadcasts a signed DISCOVER packet on every active subnet. When another Ant64 hears it, they reply directly. Within seconds both nodes know each other's IP address and port, and the node table is updated. No configuration required. Plug two Ant64s into the same network and they will find each other.
When you run `gossip discover` from the command line, you trigger an immediate broadcast rather than waiting for the next scheduled one — useful when you've just joined a network and want to see who's around.
Trust
Discovery doesn't mean trust. Knowing someone is on your network is very different from trusting them with your messages. Gossip models this explicitly.
When you want to communicate with another node, you send them a friend request — a signed packet that says "I want to trust you." They see it listed as a pending request and choose to accept or decline. Only when both sides have accepted is the relationship established as a mutual friendship. Either party can unfriend or block at any time.
Blocked nodes are silently ignored at the packet level. Their messages are not stored, their handshakes are not answered, and they receive no indication that anything is wrong. They simply disappear from your network.
Introductions
What about nodes you can't reach directly — friends of friends on different networks? Gossip supports a friend-of-friend introduction system. If you know Alice, and Alice knows Bob, Alice can introduce you to Bob. She sends a signed introduction packet to both of you containing each other's public keys and connection details. You can then send Bob a friend request directly. Neither Alice nor any other intermediary is involved after that point — the friendship, once established, is entirely between you and Bob.
Communication
Messages between friends are sent as signed UDP packets directly to the recipient's IP and port. The system tries direct delivery first. If the recipient's address isn't known — perhaps they've just rebooted, or are behind NAT — Gossip automatically attempts to route the message via a mutual friend as a relay. The relay forwards the packet without being able to read it (all content is signed by the sender) and the recipient knows the message came via a relay rather than directly.
Message types include plain text, JSON, binary blobs, and game-specific event and state packets — the same infrastructure that carries a chat message can carry a real-time game state update. The full payload capacity is 400 bytes per packet.
Delivery acknowledgements travel back to the sender so the system knows when a message has been received. Undelivered messages are kept in the local database for retry.
Persistence
All Gossip state — the node table, the friend list, message history, your keypair — lives in the DBFS SQLite database on B:. This means it survives reboots, benefits from the shadow backup system, and can be exported. The 'gossip backup' command produces a JSON file containing your identity and friend list that can be restored to a fresh machine or used to migrate to new hardware without losing your social graph.
A few deliberate choices are worth explaining.
No central authority
There is no Gossip server, no Gossip account, and no Gossip company. The protocol is fully specified in the AntOS source and the wire format is stable. If Ant64.com ceased to exist tomorrow, every Ant64 that had ever made friends would continue to communicate with those friends indefinitely.
Cryptographic identity, not usernames
Your node ID is your public key. There is no registration, no namespace collision, no "that username is taken." Two people can both be called "Tony" without any conflict — their node IDs are different, and their friends lists refer to them by node ID, not by name.
Minimal attack surface
The gossip task verifies every incoming packet's signature before doing anything else. Malformed packets, replayed packets, and packets from unknown or blocked nodes are all dropped silently. The trust model is explicit: only confirmed friends can deliver messages to your database.
Designed for constrained hardware
Gossip runs on a RISC-V processor with modest RAM, inside a OS task, alongside the rest of the OS. It is written in C, allocates conservatively, and is designed to consume minimal CPU between events.
The current implementation covers LAN and WAN communication between mutually trusting nodes. Several extensions are planned:
LoRa mesh
The Ant64 hardware includes support for LoRa radio communication. The intention is to extend Gossip over LoRa, allowing Ant64s to communicate over distances of several kilometres without any network infrastructure — useful for field use, events, and situations where WiFi is unavailable.
Game integration
The 'GAME_EVENT' and 'GAME_STATE' message types already exist at the protocol level. The intention is to build a high-level API that allows games to send inputs and state updates between Ant64s using Gossip as the transport layer, making local multiplayer as simple as calling 'gossip.send_game_event()'.
File transfer
Binary blob messages are implemented at the protocol level. A file transfer UI built on top of them is a natural next step.
Gossip is one of the things that makes the Ant64 a genuinely different kind of computer — not just a machine you use alone, but one that is social by default, and on terms that you control.