Design & Implementation

How Pixelmine is built.

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 content and the keys to read it.

The system at a glance

Four parts, clear
responsibilities.

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

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 — nothing readable is ever handed to a server.

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.

Holds your keysEncrypts on your deviceReads your content

The storage network

A set of independently operated nodes acts as the network’s memory. Each keeps its own copy of the encrypted posts, messages, and files, and passes changes along to the others so everyone stays current.

Anyone can run a node. 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.

Stores encrypted dataReplicates to peersReads nothing

The coordination service

A single lightweight service ties the network together. It registers accounts, helps messages find their destination, hands off the sealed keys that let new contacts reach one another, and delivers notifications.

It is deliberately minimal — holding only the routing details it needs and never any readable content. A sealed key is passed along and then discarded once delivered, so there is little of value gathered in one place.

Routes & registersDelivers sealed keysStores no content

The live media path

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.

It carries video directly between participants where it can, and switches to a broadcast-friendly method when an audience grows large, so a stream stays smooth whether it is a one-to-one call or a room of viewers.

Real-time videoLow latencySeparate path
Identity & accounts

You are your key,
not a row in a database.

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.

  • When you register you receive a key file that is yours alone, paired with a short code only you know. Neither half is any use without the other.
  • Your public identity is derived from your key, so nobody can claim to be you without holding it.
  • Because no central store of passwords exists, there is nothing of that kind for an attacker to breach in one place.
  • Nodes are identified the same way. A node’s name is derived from its own key, so it cannot pose as another one.
  • The trade-off is real: whoever holds your key file and code is you. Losing both means losing the account, because no one else can restore it for you.
The encryption model

A key you set up once,
then keys per message.

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.

Established once

A shared key per contact

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.

Per post & message

A fresh key each time

Every post or message is locked with its own brand-new key. That key is then sealed individually for each intended recipient using the shared key, and travels alongside the content — so only the right people can open it.

Group conversations refresh their shared key whenever someone joins or leaves, so the record stays with the people who were actually there. And the labels that route a message — who belongs to a conversation, who sent it, who has read it — are locked as well. Only a plain routing tag is left in the open, just enough for a node to carry something without learning what it is or whom it concerns.

Set up once per contact New key for every message Sealed for each recipient Built to outlast future computers
Posts & audiences

Public by choice,
sealed by default.

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.

Public posts

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.

Follower-only posts

Sealed. Each one is locked with its own key, and that key is wrapped separately for every follower allowed to see it.

Messages & groups

Always sealed, for the people in the conversation and no one else — never open, whatever the setting.

  • The audience is decided the moment you publish. Removing a follower stops them from receiving anything new, but a post they could already open stays readable to them — unsharing after the fact is not something any system can truly promise.
Opening a sealed feed

Sealed, and still
instant to scroll.

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.

  • The shared key with an author is worked out the first time you open one of their posts — not up front for everyone you follow.
  • That happens once per author. After that the key is kept for you, and comes back on any device you sign in to.
  • When a page of the feed loads, the app asks for that whole page’s keys in a single request instead of one request per post.
  • Unlocking is then fast local work on your own device, so scrolling stays smooth even though nothing on the wire was ever readable.
Messaging & channels

Conversations that give
away as little as possible.

Direct messages and group chats share one design. A conversation is stored as a plain routing label plus sealed content — enough for the network to carry messages to the right place, never enough to understand them.

  • Who belongs to a conversation, who sent each message, and who has read it are all locked away. Only a plain label identifies the conversation so that it can be routed.
  • Group chats refresh their shared key whenever someone joins or leaves — so newcomers cannot read what was said before them, and people who leave cannot read what comes after.
  • One-to-one chats keep a single steady key, since only two people are ever involved and the membership never changes.
  • Even read receipts and unread counts are worked out from locked markers, so who has seen what stays private as well.
Files & media

Photos and video,
handled the same way.

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.

  • Large files are locked in pieces rather than all at once, so even a long video can be sealed without overwhelming a phone.
  • Nodes store and replicate those sealed files exactly like any other record — holding the bytes without being able to view them.
  • Files are opened on demand, as you reach them, instead of everything being unlocked up front.
  • Each operator can cap how much storage their node contributes, so running one never means an open-ended commitment.
Deleting in a shared network

How you delete from
a network of copies.

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 deletion is itself a record: a signed note saying an account is gone, which travels the network exactly like any other record.
  • Because it carries your signature, no one else can forge the deletion of your account — and nodes can check that for themselves.
  • Nodes receive it and act on it as it spreads, with no central authority needing to order them to.
  • The trade-off is honest and inherent: a network of independent copies can propagate a deletion, but it cannot promise the absolute erasure that a single controlled database can.
Live video & calls

Real time, on its
own path.

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.

As direct as possible

Video travels straight between participants wherever it can, so a call feels immediate instead of being routed through storage first.

Scales to a room

Once an audience grows past a handful, a broadcast follows one path out to many viewers at once, so a stream stays smooth as the room fills.

Rings even when closed

An incoming call reaches your phone through its own notification system, so it rings whether or not the app is running.

  • Live video is carried in the moment rather than filed away: it follows the real-time path instead of being sealed, stored, and replicated the way a post is. Different job, different trade-offs.
Gossip & exchange

How nodes find each other
and trade what’s new.

No central directory tells nodes what exists or who is online. They work it out by talking among themselves — continuously, and on their own timers — so the network heals itself instead of depending on any single message getting through at the right moment.

STEP 01

Announce yourself

A node simply tells the others it is here. Presence travels by word of mouth, so the network learns who is online without anyone keeping a registry.

STEP 02

Reconcile on a timer

Every node wakes on its own schedule and reconciles with peers. A message missed now is caught on the next pass, so nothing hinges on perfect timing.

STEP 03

Nudge on change

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.

STEP 04

Pull, never push

A sync runs one direction at a time: a node pulls into itself. Nothing is forced on it, so it always decides what it accepts.

Keeping the network in sync

How nodes agree on
the same data.

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 rely on agreement among several peers rather than trusting any one of them.

STEP 01

Fingerprint the data

Every record has a short fingerprint, and a whole collection has one too — combined so the order things arrived in never matters.

STEP 02

Compare and split

When two fingerprints differ, the data is split into smaller groups and compared again, quickly zeroing in on where the two nodes disagree.

STEP 03

Find the exact records

Within a group that differs, individual fingerprints are matched to pinpoint exactly which records are missing or changed.

STEP 04

Exchange only the diff

Just those records are sent. Syncing an enormous store moves only what actually changed — and matching totals confirm nothing was altered in transit.

Verifying what arrives

Nothing is believed just
because it arrived.

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.

  • Every replicated record carries its author’s signature, made over that record’s own fingerprint. Alter so much as a character and the signature no longer fits.
  • The author’s key is not taken on faith either. It comes from that author’s own record, which travelled the network like everything else.
  • And that record proves itself: an identity is precisely the fingerprint of its own key, so it cannot claim a key that isn’t its own. The chain ends at something self-evident rather than at an authority anyone has to trust.
  • A record failing any of this is rejected outright by default — not stored first and sorted out later.
  • And if a record arrives from an author a node has not heard of yet, it is not guessed at. It is set aside and offered again on a later pass, once that author’s own record has caught up.
Proving nothing drifted

One number for
an entire node.

Comparing record by record is fine for a handful of changes, but nodes need a cheap way to ask a blunter question first: are we identical at all? So every collection’s fingerprint rolls up into a single number standing for everything a node holds.

  • Each collection carries its own fingerprint, recomputed the moment anything inside it changes.
  • Those fingerprints combine into one number covering the node’s entire record — stored data and files alike.
  • Nodes trade just that single number as they gossip. If it matches, they are identical and there is nothing else to do.
  • If it does not match, they step down a layer — to collections, then buckets, then records — until the exact difference surfaces, without ever exchanging everything.
Joining the network

How a new node comes
online — and earns trust.

Adding capacity does not require anyone’s permission. A new node finds the others, introduces itself, and begins catching up on the shared record until it holds a complete copy — then it starts helping carry the load.

STEP 01

Find and announce

A new node discovers existing ones and announces itself, as the network continually gossips about who is currently online.

STEP 02

Catch up

It fills in the shared record using the same fingerprint comparison, pulling only what it is missing until it is completely current.

STEP 03

Cross-check, don’t trust

Rather than believing any single peer, a node checks with several and follows the majority — so one bad actor cannot quietly rewrite history.

The logic, step by step

Two nodes reconciling,
end to end.

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.

Two nodes compare a collection Fingerprints match? YES Already identical — done NO Compare 256 bucket fingerprints Isolate the buckets that differ Compare record fingerprints Request only what’s missing Signature valid? NO Reject the record YES Store it, update the fingerprint Both nodes now match
One pass of the reconciliation loop
How the parts cooperate

Following a post
through the system.

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.

STEP 01

The app seals it

Your app locks the content and seals a copy of its key for every person meant to receive it — all before anything leaves your device.

STEP 02

The network stores it

The sealed content is handed to the storage network, where nodes keep it and replicate it to one another so it stays available everywhere.

STEP 03

Keys are delivered

For a contact you are reaching for the first time, the coordination service passes along the sealed key they need — then discards it once it arrives.

STEP 04

Recipients open it

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.