Explanation

How Mirall works: peer-to-peer, no cloud storage

Mirall connects your devices directly. When you share a file, its contents stay on your device — right where they already are — and other members download it straight from you over an encrypted connection. No server stores your files, and anything that forwards traffic on the way sees only ciphertext.

What does travel ahead of time is lightweight metadata — names, sizes, and which member is offering what — so everyone can see what's available in a space. The actual bytes of a file move only when someone chooses to download it.

The corollary is that availability follows people, not servers. A file is downloadable only while the member who shared it is online. Downloading a file gives you your own copy to keep — but it doesn't turn you into a second source for it, so the person who shared it stays the one who serves it.

Privacy & security model

Every connection between devices is end-to-end encrypted, so nobody in between can see your files, their names, or what's in your spaces, and there's no central server that could be breached. There are no accounts and no tracking. A relay, if you use one, still sees when you are online and who you connect to — Relays covers what that means.

Getting in is not the same as being able to read

A space's contents are protected by a key of their own. That key is handed to you only once an existing member approves your request to join. Reaching a space, or holding a link to it, is therefore not the same as being able to read what's shared in it — a pending member is outside the door, not merely unlisted.

Every space Mirall creates or joins works this way, without exception. A space made before that became true can't be brought up to it: the key would have to be minted by whoever created the space and handed out to every member again, which is a coordinated change across everyone's devices rather than something your own copy can do. Such a space is marked Unsupported rather than left half-working.

Your device at rest

Mirall's local bookkeeping — your list of spaces, mirrored folders, downloads, and similar details — is encrypted on your device with a key tied to your identity. Your identity itself is a signing key, wrapped using your operating system's secure keychain. Copying Mirall's data folder off your machine gives up neither your records nor your identity. The Identity protection row on your Profile page tells you which protection is in force.

The activity log is part of that bookkeeping: it's encrypted the same way, and it is never replicated to anyone. The only way an event leaves your device is if you export the log yourself.

Unfriendly peers

Because peers talk to each other directly, Mirall assumes some of them may misbehave. Connection rate limits, size caps, and a firewall for badly-behaved peers keep a flood of requests or oversized data from exhausting your memory or CPU. Oversized avatars and over-long display names sent by a peer are rejected rather than rendered.

Your profile — display name and avatar — is shared only with the peers you actually connect with.

Membership & approval

Joining a space is a request, not an entitlement. Someone who follows your invite link becomes a pending member: they're visible to the space, but they hold none of its contents and can take no member-only action until an existing member approves them. Approving them is what hands over the key.

The link itself is not the key. An invite carries the address of the space and enough detail to show you what you are joining — never the key to its contents. That key is handed over by a device that is already a member, which is why joining needs one of them to be online and reachable, and why a link that gets forwarded lets someone knock rather than read.

Any member can approve, not just whoever created the space — and a request only needs answering once. As soon as one member approves or denies someone, that decision propagates and the request clears for everyone else.

The two answers are not symmetric. Approval is final: the key, once handed over, can't be taken back, and nothing in Mirall replaces it or removes a member. A later deny changes nothing, and the person keeps access to the space — including to anything shared in it afterwards. Approve only people you mean to keep.

If you'd rather not gate-keep, turn on auto-approve when you create the invite link. Anyone holding that link is then admitted without a member having to decide, as soon as their device reaches one. Either way the link carries an expiry — 2 hours, 2 days, or 2 weeks — after which Mirall refuses it.

Spaces, members & availability

A space is a private group with its own members and its own files. Because files live on members' devices rather than a server, a file is downloadable only while the member who shared it is online.

Whoever shared a file is the one who serves it. Downloading it gives you a copy that's yours to keep and works offline, but it doesn't make you a second source others can pull from — so if the person who shared it goes offline, the file is marked Owner offline until they're back, and any download in flight picks up where it left off. If another member happens to share the same file themselves, Mirall notes that it's also shared by them, and either copy can be downloaded.

When Mirall says your network is the problem

“I have internet” and “other people can reach me” are different questions, and only the second one matters to Mirall. A machine can load web pages perfectly while sitting behind a network that refuses every incoming connection — and on that machine, nothing you do in Mirall will work. Mirall therefore judges reachability rather than internet access, and tells you when the answer is no.

What it actually measures

Two things: whether Mirall can find other people at all, and whether it can connect to any of the ones it finds. Finding nobody and finding plenty but reaching none of them are different failures with different remedies, so Mirall keeps them apart. A single live connection settles the question in your favour, whatever else the network looks like.

That is why the verdicts are worded the way they are. You're offline means this device has no network. Mirall can't reach other people means the network is there and is refusing the traffic. Limited connection means some connections will work and many won't — typically because your network hands out a different port every time, which is what mobile routers and phone tethering do.

Why the connection test can confirm but never accuse

Mirall runs a check against a device that should always answer. When it passes, that is strong evidence your connection is fine. When it fails, it is not evidence of anything about you — a failure looks exactly the same whether your network is blocking the traffic or our own test device is down. So the test can promote a verdict to healthy, and it is never on its own the reason Mirall tells you something is wrong. Blaming your network for our outage would be worse than saying nothing.

Why a verdict takes a moment

Networks flap. A Wi-Fi roam, a VPN reconnecting, a laptop waking up — each of those briefly looks like a failure and is over before you could act on it. Mirall waits these out before changing its mind, in both directions, so the log and the warnings carry real events rather than noise. The exception is losing the network outright: when the cable is pulled or the Wi-Fi is switched off, you can see that for yourself, and Mirall says so immediately rather than waiting.

The VPN it can't be sure about

A VPN that has lost its own connection while keeping the only route off your device is indistinguishable, from the inside, from a network that blocks Mirall. There is no measurement that separates them. Mirall doesn't pretend otherwise — it says it can't reach the network rather than accusing your network of blocking it, and puts turning the VPN off at the top of what to try, because that is the likeliest explanation.

Relays, and what they can see

Mirall connects two devices directly, which works on most networks because both ends cooperate to punch a path through their routers. Some networks refuse to let that happen at all — a corporate firewall that drops the traffic, a carrier that hands out a different port for every connection, a hotel network that isolates its guests from one another. On those there is no direct path to find, and a space simply never syncs.

A relay is a third machine with an address both sides can reach. When the direct path cannot be made, each device connects out to the relay instead and the relay forwards the bytes between them. The connection is slower and it costs somebody bandwidth, but it exists.

Blind, and what that does and doesn't mean

The relays Mirall uses are blind. The two devices run their own end-to-end encryption over the relayed connection, so the relay never holds a session key and has nothing to decrypt with. It cannot see your files, their names, the folders they sit in, which spaces you are in, or who the people on either end are in Mirall's terms.

What it can see is what any machine in the middle sees: the addresses of both ends, the keys they present to each other, when they talk, and how much crosses. Blind to content is not blind to metadata. That is not a flaw waiting to be fixed — it is what forwarding traffic means — so the question worth asking is not whether a relay can be trusted with your files, but whose machine it is.

Which is why Mirall operates no relay of its own and ships no default. There is no relay you fall back to without having chosen it. A relay is something you run, or something someone you know runs and lets you into.

Open and private

An open relay admits anyone holding its key, and that key can be passed on. It is the shape of a relay run for a group whose membership nobody needs to police.

A private relay admits only the people its operator has minted an invite for, and that invite can be revoked. The invite also carries a lasting identity for your device on that relay, which is the difference that matters: an open relay sees a key that changes every time Mirall starts, a private one sees the same member every time.

Why your relay can end up carrying other people

Only one of the two ends needs a relay for a relayed connection to be made. So Mirall offers an open relay you have configured to the people you connect with: if the person on the other end has none, they are carried by yours without configuring anything. It is the quickest way to unblock a group — one person runs a relay and everyone benefits.

The same rule works in the other direction. Turning your relay off doesn't stop another member's open relay from carrying their connection to you, because either end offering one is enough. That is their choice, not yours to overrule, so Mirall names those members in your relay settings rather than pretending the connection is direct.

A private relay is never offered that way. Somebody who adopted its key would be refused at the door, and that refusal is deliberately indistinguishable from the relay being down — so they would see a connection that silently never works, and the operator would see unexplained refusals. Offering a path guaranteed to fail is worse than offering nothing. The consequence is worth planning around: a private relay helps its own members reach each other, so both ends of any pair that needs it have to be enrolled.

It stays out of the way

Configuring a relay changes nothing on a network that already works. Mirall reaches for it when a direct connection cannot be made, or when it can already see that this network hands out a different port every time and a direct attempt is unlikely to land. Everything else goes straight between the two devices, as it did before. The one exception is the setting that prefers the relay for every connection, which exists so you can prove a relay works — not so you can run on it day to day. Even then a direct path can still win.

Sharing without a second copy

When you share a file or a folder, Mirall serves it in place — straight from the original on your disk. It doesn't import a private copy into its own storage.

Two things follow from that. Sharing never doubles a file's disk usage, however large it is. And because there's no copy to fall out of date, an edit you make to a shared file is picked up where it lies, rather than needing to be re-imported.

What Mirall does keep is an index: a compact map of a file's contents that lets it stream the right pieces to whoever asks. That index is small, it never contains the file's contents, and it's freed as soon as you stop sharing the file.

Building that map is the one part of sharing that takes real time, because it means reading the file through. Each space works its own queue and takes the smallest files first, so a file you drop in while a large folder is still being read doesn't wait behind it. A folder you share tells you what it has left to get through, and you can pause that work.

Mirroring & the read-only model

When you mirror a shared folder to disk, you get a live copy that tracks the owner's folder. The owner is the single source of truth, which is why a mirror is read-only.

If you change or delete a file inside a mirror, Mirall notices within seconds, marks it Edited locally, and puts the owner's version back at its own name — that is what keeps every mirror faithful to the original. Your edit isn't destroyed to get there, though: Mirall moves it aside first, into the same folder as name (conflicted copy).ext. To work on a file without leaving a second copy behind, copy it out of the mirror first; to propose changes back, share them with the owner separately.

A mirror only ever manages the files it put there. A file of your own that happens to sit in the same folder is left alone — including when the owner deletes the shared file it collided with. For the same reason, a mirror can't be placed directly on a top-level personal folder like Home, Desktop, Documents, or Downloads.

Who has a folder is not a private fact about the owner's screen. Every folder names its owner and everyone keeping a live copy of it, each with whether they're synced, still catching up, or paused, and anyone in the folder can read it — so the owner can tell whether the people who need the files have them, and a mirrorer can tell whether they're the only one.

How Mirall uses your disk

There are three distinct things on your device, and only one of them is Mirall's:

• Your files — the originals you share. Mirall reads them where they are and never copies them.
• Files you've pulled — downloads, and the contents of folders you mirror. These are ordinary files in ordinary folders that you chose. They're yours; Mirall doesn't reclaim them.
• Mirall's own data — the shared-file index, the app database (your spaces, members, and sync history), and the activity log. This is the App Storage figure in Settings → Storage.

Only the third is Mirall's to manage, and it stays small precisely because there's no second copy of your files inside it. There is nothing to run and nothing to schedule: Mirall compacts its own records on a cadence it keeps across restarts, drops what a member left behind when they leave a space, and sweeps up what it no longer needs each time it starts.

Where downloads land

Downloads go to the folder set in Settings → Storage, unless a space has been given one of its own — so there can be several download folders in play at once. Mirrors are separate again: each one lives at the location you chose when you set it up.

Whichever folder you pick, it can't overlap a folder you share or mirror, in either direction. The reason is worth understanding rather than working around: Mirall publishes what's inside a shared folder, so a download landing there would be offered to your peers without you asking for it.

What the activity log can tell you

The activity log is a record of what your device saw. It notes what you did — spaces created and left, files shared and downloaded — alongside what the members you're connected to did in the spaces you share with them.

It stays on your device. It is stored with Mirall's other records, encrypted the same way, and it is never replicated to peers: nobody can ask your device for it. Exporting it yourself is the only way an event leaves the machine, and an export holds raw identifiers — keys, paths, hashes — rather than the readable sentences the app shows you.

The stretches when nothing could happen

Every other kind of event records something that happened. The questions people actually bring to a log are usually about something that didn't — a file that never arrived, a member who never appeared. Those produce no rows at all, so silence reads as though the other side simply did nothing.

The connection events are the log's answer to that. They mark the windows when this device was offline, or could reach nobody, and close them with how long the gap lasted and the cause Mirall settled on. An unexplained quiet afternoon becomes something you can point at. Members going quiet and coming back are recorded the same way — but only while your own connection is working, because a blocked device makes everyone look as though they left.

What it can't tell you

Because it records what you observed, it is not an audit of the space as a whole. A transfer between two other members never reaches your device, so it is never recorded. Neither is per-file activity inside a folder someone mirrors, nor anything a person does with a file once they have it. Events attributed to a peer carry the time that peer reported, and the name they had at the time — renaming themselves later doesn't rewrite old rows.

What sticks around

Leaving a space doesn't erase its history — those events stay until they age out, which is why a space you've left still appears in the filters. Turning recording off stops new events without deleting old ones. Deleting the log removes the events and hands back the disk space they were using, keeping the retention setting you chose.

What bandwidth limits cover

A transfer limit is a ceiling on the total, not an allowance handed to each transfer. Under a 5 MB/s download cap, one download may use the whole 5 MB/s; start a second and the two share it, roughly half each. The same holds when you're serving several people at once — they divide one upload cap between them rather than getting it each.

Mirall shares the cap out by bytes rather than by whoever asks most often, so a large transfer can't crowd out a small one. The limit is a single app-wide setting: there is no per-space cap.

What isn't limited

The cap governs file transfers only. Keeping your spaces and members in sync — the catalogue of who's in a space and what's on offer — is deliberately left alone. It uses very little data, and throttling it would stop new files and folders from appearing while a transfer ran.

How updates work

Mirall checks for new versions on its own and downloads them in the background while you keep working — no installer downloads, no reinstalls. Updates never restart the app on their own.

A staged update is applied the next time you quit and reopen Mirall, so restarts happen on your schedule. You can see a pending version under App on your Profile page before you restart.