Underneath the app is a small set of parts, each with a single clear responsibility: an app that does all the encryption, a network of nodes that stores it, a thin service that connects everything, and a separate path for real-time video. Kept apart on purpose, they add up to a system where no single part holds both your private content and the keys to read it.
Each part does one job and only that job. The app is the only place your sealed content can be read; everything else exists to store it, move it, or stream it — holding anything private in a form it cannot open.
The app on your device is the trust anchor of the whole system. It creates and holds your keys, and it performs every encryption and decryption right on your device — no private content is handed to a server in readable form.
It is what you actually use: your feed, chats, calls, and live video. And it is the only part of Pixelmine that can turn sealed data back into readable content.
A set of independently operated nodes acts as the network’s memory. Each keeps its own copy of posts and files and passes changes along to the others so everyone stays current; chats and community posts stay on the node that hosts them.
Anyone can run a node, registering it with the coordination service. Anything private it holds is already sealed, so a node stores, serves, and replicates that content without ever being able to read it — even with full access to its own database. Public posts it serves openly, because those are meant to be seen.
A single lightweight service ties the network together. It keeps the directory of nodes, confirms account keys when apps connect, relays chat events and notifications, and passes along the sealed keys for group invitations.
It is deliberately small, and never holds the readable content of your messages or posts. It does hold some account details — such as profile fields and group names — and a sealed group invitation is removed once the invitee collects it.
Live streams and calls have to travel in real time, so they run on their own path tuned for the lowest possible delay — kept separate from where your stored content lives.
One-to-one calls travel directly between the two phones, group calls go through a relay server, and a live stream is sent from the broadcaster’s phone to each viewer.
There is no password waiting on a server to be stolen, because there is no password at all. Your identity is something you hold, and everything you publish carries your signature.
Setting up fresh protection for every single post would be slow and wasteful. Instead, Pixelmine does the heavy step once with each contact, then protects each individual post or message with its own quick key.
The first time you connect with someone — a follow is accepted, or a chat begins — your two devices privately agree on a shared key. That agreement happens a single time for the pair and never has to repeat.
Every post or message is locked with its own brand-new key. For a followers-only post that key is sealed separately for each follower; in a chat it is sealed with the conversation’s shared key. It travels alongside the content, so only the right people can open it.
Group conversations refresh their shared key whenever someone joins or leaves. The content is sealed, but the labels around it are not: who belongs to a conversation, who sent each message and who has read it are stored with plain account IDs, so a node can see whom a message concerns without seeing what it says.
Not everything on Pixelmine is a secret — a public post is meant to be read. What matters is that you choose the audience, and anything meant for a limited one is sealed so only that audience can open it.
Open on purpose. A public post is meant for anyone, so the network carries and shows it freely — that is the whole point of posting publicly.
Sealed. Each one is locked with its own key, and that key is wrapped separately for every follower allowed to see it.
Message content is always sealed, for the people in the conversation and no one else — whatever the setting.
If every post carries its own key, opening a feed could mean a small mountain of work before a single word appears. It doesn’t — because the heavy step happens once per person rather than once per post, and keys arrive a page at a time.
Direct messages and group chats share one design: sealed content, stored on the node that hosts the conversation, alongside plain records of who is taking part.
Media follows exactly the same rule as text. A file attached to a sealed post is locked with that post’s key, and only opened on the viewer’s device at the moment they actually look at it.
In one company’s database, deleting means a row vanishes because a single owner controls the only copy. In a network of independent nodes there is no such lever — nobody can reach into every machine and erase something. So deletion has to be designed rather than assumed.
A stored post can take a moment to settle across the network. A live stream or a call cannot — a half-second of delay is the difference between a conversation and a mess. So real-time video runs on a separate path, built for immediacy rather than permanence.
One-to-one calls travel straight between the two phones, so a call feels immediate; group calls pass through a relay server. Calls are end-to-end encrypted.
A live stream is sent from the broadcaster’s phone to each viewer, with the connections set up through Pixelmine’s media server.
An incoming call reaches your phone through its own notification system, so it rings whether or not the app is running.
Nodes learn about each other two ways: from the coordination service’s directory, and from each other, as every node shares the list of peers it knows. They keep talking on their own timers, so the network heals itself instead of depending on any single message getting through at the right moment.
A node registers with the coordination service and tells the peers it knows that it is here, every few minutes. Peers pass their lists along, so presence also travels by word of mouth.
Every minute, each node reconciles with its peers. A message missed now is caught on the next pass, so nothing hinges on perfect timing.
When a node takes something new in, it can prompt its peers to come and look rather than leaving them to wait for their next turn.
New records are also pushed to peers as they are written. Pushed or pulled, a node checks every record before accepting it, so it still decides what it stores.
Nodes each hold a copy of the same encrypted content, so they need a way to stay identical without shipping whole databases back and forth. They compare compact fingerprints and keep narrowing down until only the true differences remain, then exchange just those. New nodes catch up the same way, and nodes compare with several peers, preferring what the majority holds.
Every record has a short fingerprint, and a whole collection has one too — combined so the order things arrived in never matters.
When two fingerprints differ, the collection’s 256 bucket fingerprints are compared, quickly zeroing in on where the two nodes disagree.
Within a group that differs, individual fingerprints are matched to pinpoint exactly which records are missing.
Just those records are sent. Syncing an enormous store moves only what actually changed — and each record is checked as it arrives.
A node taking data from a stranger cannot simply take its word for it. So every record has to prove itself — and the proof chains downwards until it reaches something that needs no authority to vouch for it at all.
Comparing record by record is fine for a handful of changes, but nodes need a cheap way to ask a blunter question first: is this collection identical? So every collection keeps a single fingerprint, and files have one of their own.
Anyone can add a node. A new node registers with the coordination service, finds the others, introduces itself, and catches up on the shared record — the public and followers-only data every node replicates — then starts helping carry the load.
A new node registers, discovers existing nodes through the coordination service and a starting list of peers, and announces itself.
It fills in the shared record using the same fingerprint comparison, pulling only what it is missing until it is completely current.
Rather than believing a single peer, a node compares with several and prefers what the majority holds — and every record must still carry a valid signature.
Every sync follows the same path. Nodes start from a single fingerprint and keep narrowing until they know exactly which records differ — and nothing is accepted into the record without a valid signature behind it.
The parts each stay in their lane, handing sealed data from one to the next. Here is the same journey described from the components’ side rather than yours.
Your app locks private content and seals its key for the people meant to receive it — all before anything leaves your device.
The sealed content is handed to the storage network, where nodes keep it — and posts are replicated to other nodes so they stay available.
The keys recipients need are stored sealed on the nodes; for a group invitation, the coordination service passes the sealed key along and removes it once it is collected.
Each recipient’s app uses its own key to open the content. Every part in between only ever handled a sealed version it could not read.