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 can see your files or metadata in transit, and there's no central server that could be breached. There are no accounts and no tracking.

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.

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.

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.

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.

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 a file inside a mirror, the next sync restores it to the owner's version — your edit is discarded. This keeps every mirror faithful to the original. To work on a file, copy it out of the mirror folder 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.

From the other side, a folder you own shows you who is mirroring it and whether each person is synced, still catching up, or paused — so you can tell whether the people who need your files actually have them.

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. Mirall tidies it as it goes; Free up space prompts it to compact things now and tells you what it recovered.

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.

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; it isn't a way to reclaim disk space, and it isn't meant as one.

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.