How Vibn Works

1. The short version

Vibn is a private shared album. You create a group, invite a handful of people, and everyone's photos and videos from the same occasion pool in one place. There is no feed to be ranked into, no public profile, and no way for a stranger to find your group.

• Groups are invite-only. There is no search, no discovery, no browse — the only way in is a link, a code or a QR from someone already inside.
• Photos and videos in encrypted groups are end-to-end encrypted. They are encrypted on your phone before upload and decrypted on the recipients' phones. Our servers hold ciphertext they cannot read.
• The key that decrypts a group never reaches our servers in a form we can use. It travels in the part of the invite link that browsers never transmit, and if you keep a recovery backup, the copy we hold is sealed with a phrase we never receive.
• Face recognition runs on your device. Only anonymous numeric vectors are uploaded — never your enrollment photos, and never back to another user.
• Media is never publicly addressable. Every view is a short-lived, signed URL minted per request.
• You can delete your face data, your media, your groups and your entire account, and the deletions are real.

2. Private by invitation, enforced on the server

Every request for a group's data is checked against your membership row before anything is returned. If you are not a member, the API answers "not found" rather than "not allowed" — so an outsider cannot even confirm that a particular group exists, let alone who is in it.

That check lives in one place, in the API, not scattered across client code. The app cannot grant itself access by asking differently, because the app is not the thing deciding.

There is one deliberate exception: anyone signed in who holds an invite code can read a small preview of that invitation — the group's name, its description, and who invited them — before joining. Without it you would be asked to accept a blind invitation. Invitations expire after seven days.

Since 2026 there is a second check beside membership, and only in one direction — it can withhold, never grant. If you are identified in a photo somebody else posted, you can hide it from the group: from then on the API serves it only to the people already identified in it and to whoever posted it. It does not delete anything, it cannot reach copies already on someone's phone, and the person who posted it is told and can ask you to put it back.

• Roles inside a group are owner, manager and member. Managers can moderate and edit; only the owner can delete the group or appoint managers.
• An owner cannot quietly leave a group they own — they delete it, or hand it on. That prevents an ownerless group whose storage nobody is accountable for.
• Removing a member removes their access going forward. It cannot un-see what they already saw, and we do not pretend otherwise.

3. End-to-end encryption: what our servers cannot do

Groups created after our end-to-end rollout are encrypted. Each has one 256-bit key, generated on the creator's device. Media is encrypted with AES-256-GCM on the phone before it is uploaded, and decrypted on the phone when it is viewed. What we store is an opaque blob.

The important part is not that we promise not to look. It is that a number of features other apps offer are impossible for us, and we accepted losing them:

• We cannot generate thumbnails or previews of your encrypted media server-side, because we cannot decode it.
• We cannot re-encode or compress it to save storage.
• We cannot produce the blurred placeholder used before publish day — so for encrypted groups the app does that work on your device instead.
• We cannot create a public share link for an encrypted group. That feature is switched off for those groups entirely, not merely discouraged.
• We cannot scan encrypted media for content, ours or anyone else's. Sensitive-content detection runs on your device or not at all.
• There is exactly one way the real content of a photo reaches us, and you are the one who sends it: reporting an item as abusive uploads a decrypted copy of that single item from your device, after the app has told you it will. We cannot obtain it any other way, and it is deleted 90 days after the report is settled.

4. How the key travels

A group's key is distributed inside the invite link, after the # character: https://vibn.space/i/CODE#k=… — everything after the # is a URL fragment, and browsers never send fragments to the server. The QR code encodes the same link. Whoever opens it extracts the key in the app and stores it in the device's secure hardware-backed storage: the Keychain on iOS, the Keystore on Android.

This has a consequence we would rather state plainly than bury. Anyone who obtains a full invite link obtains the group's key. Treat an invite link like a house key: it is not a request to join that you approve, it is the thing that opens the door. Share it in a channel you trust.

It has a second consequence, and recovery backup changes its shape rather than removing it. The first time a device holds a group key, Vibn offers you a ten-word recovery phrase. Your phone derives a key from those words and uploads your group keys sealed under it; we store that sealed bundle and the public salt used to derive the key. We never receive the phrase — it is in no request, no email, no share sheet — so the bundle is as unopenable to us as the media is. You may screenshot the words if you prefer that to paper; a screenshot usually syncs to a cloud photo service, so it is only as private as that account. Typing the phrase on a new device brings your keys back, and on iOS the derived key travels in the iCloud Keychain, so most restores need no typing at all. You can still move keys by scanning a code from a device that has them, or restore a group by pasting its invite link. But you can skip the backup or delete it, and if you do, and every device and every link is gone, the media stays encrypted forever. That is the honest cost of the guarantee in section 3.

• The group key is never in a request body, never in the invite code itself, and never in a log in a form anyone can use. The one copy that reaches us is the recovery bundle, sealed under your phrase.
• Current limitation: there is no key rotation when a member leaves, and no per-person revocation. A former member who kept the link keeps the key.
• A group's key is visible read-only in its settings, so you can back it up deliberately if you want to.

5. Where your media actually lives

Files are stored in private object storage that is not readable without a signature. Our database holds only the storage path — not a URL. An early migration deliberately removed the persisted URL columns, so a leaked database row contains nothing anyone can fetch.

Every time you open a photo, the API mints a short-lived signed link for that one object, for that one request, after checking your membership. The link expires. Uploads work the same way in reverse, with the file type fixed at the moment the upload is authorized.

• There is no public bucket, no guessable path, and no permanent URL to leak.
• The one unauthenticated surface in the whole system is a public gallery share, which a member can create for a non-encrypted group. It is a capability token in a link, it can be turned off, and it can never be created for an encrypted group.
• If you switch off resharing in your settings, your uploads are removed from any public gallery share another member creates — your own shares still include them.

6. Publish day

A group can be set to reveal on a chosen date, so nobody sees the photos until everyone does. Before that moment, the server does not simply ask the app to hide things. It hands non-uploaders a different file — a small blurred derivative — and never mints a signed link to the real one. The full-resolution key is not in the response to be found.

You always see your own uploads. Notifications about photos you appear in are held until the reveal, then delivered as a single summary, so a push notification cannot spoil what the screen is hiding.

There is one way to see those photos early, and it is deliberate. The group's owner can start a live wall: a link, valid for at most a day and revocable at any moment, that shows the group's photos in a browser as they arrive — at a party, on a screen in the room. While it runs, whoever holds that link sees the full photos rather than the blurred stand-ins, which is the point of it. Two things bound what that costs. The link ends by itself, and the owner can end it sooner. And the link contains no group key: the key is delivered to the browser in wrapped form and is unwrapped there, only for as long as the session is running, so ending a live wall does not merely turn the page off — it takes the key with it.

7. Facial recognition, and why it is unusual here

Vibn can find the photos you appear in. Almost every implementation of that feature uploads faces to a server. Ours does not, and it could not — the media is encrypted, so a server-side matcher would have nothing to look at.

Instead, detection and the conversion of a face into a numeric vector both happen on your phone. A 512-number vector is all that is uploaded. It is not an image, and it is not reversible into one.

Matching then happens on the server, comparing vectors to vectors. It returns only the identifiers of matched users — never anyone's vector.

• The photos you take during face setup never leave your device.
• No endpoint returns a stored face vector to any client, including yours.
• You can turn off discoverability, and your identifier is stripped from face-match results shown to every other person — you still see your own.
• You can delete all of your face data at any time from settings. It removes the vectors and the enrollment marker, not just a flag.
• The feature is opt-in and is available on both the free and paid tiers. We do not put your privacy behind a paywall.
• You can hide a photo you appear in from the rest of the group, without being able to delete it. It stays visible to the people in it and to whoever posted it, who is told and can ask you to put it back.

8. Identity, payment and the parts we deliberately do not run ourselves

Sign-in is handled by Firebase Authentication — email, Google or Apple. We never see or store a password; there is no password field in our database to breach.

Subscriptions are verified by our own server directly against Apple and Google. There is no third-party billing middleman holding your purchase history. Your entitlement is decided on our side from a store-confirmed receipt, so a modified app cannot grant itself a paid plan.

Plan limits — how many groups, how many members, how much storage, what resolution — are enforced on the server, not in the app. The app's copy of those numbers exists only to show you a friendly message before you hit a wall.

9. What leaves your device, and to whom

This is the section most whitepapers make vague. Ours is specific, including where it is unflattering.

Crash and error reporting goes to Sentry. It receives your account identifier, name and email so a report can be tied to an affected user. It is configured never to receive request bodies, authentication tokens, signed storage URLs, invite codes, share tokens — or the group key. That last one is not a matter of policy: a malformed key would otherwise reach the error report inside an exception message, so the scrubbing that removes it is covered by tests that fail the build if it regresses.

Product analytics goes to PostHog: which screens are opened, which features are used, and app version and platform. Screen names are sanitized so that group, media and invite identifiers never appear in an event.

Push notifications are delivered through OneSignal. Live chat and presence no longer run on a third party's infrastructure: they run on our own real-time server, and messages are stored in our own database — in an encrypted group, as text we cannot read. Your app connects with a short-lived token that identifies you and nothing more, and joins each group's room with a second token issued for exactly that one room, checked against your membership every time. One-to-one messages work the same way, with one difference worth stating: a conversation between two people has no group key, so the two devices derive one between themselves from identity keys we hold only the public halves of. We store the result and cannot open it.

On the free tier, ads are served by Google AdMob. On iOS you are asked before any advertising identifier is used, and if you decline you still get ads, just untargeted ones. Where local law requires a consent form, it is shown before that request. AdMob never receives your name, your email, your photos or anything from inside your groups.

If you installed Vibn from one of our ads, we report back what those ads produced, so we can tell which of them work: that the app was installed, that an account was created, that you opened the plans screen, that you tapped to subscribe, and that a subscription was purchased. Google and Meta receive the first, second and last of these from your device — on iPhone through Apple's SKAdNetwork, which hands an advertiser one aggregated, delayed number and no identifier at all, which is why this app has no tracking prompt; on Android through their own SDKs, and where local law requires a consent form it is shown first. OpenAI Ads receives all five from our servers rather than from your device, and that is the one place an identifier is involved: if you have agreed to advertising measurement, we include a scrambled, one-way form of your email address so a purchase can be matched to an ad you saw. If you declined, or were never asked, no identifier is sent at all. None of them is ever told what you shared, which groups you are in, or anything from inside them.

If you report a photo or video, a decrypted copy of that one item is sent with your report so a person can judge it — the app says so on the screen where you file it. It is stored apart from the group, is only ever shown through a link that expires in minutes, and is deleted 90 days after the report is settled. Nobody is told who filed a report. Reporting a person or a group sends no media at all.

10. Deleting things

Deleting your account removes it, the groups you own, and the media in them, and releases your memberships elsewhere. For 30 days it is recoverable, and that is the only thing we keep it for: the account is walled off, your profile is gone from everyone else's app, the groups you own go read-only with the removal date on them, and signing back in gives you one button to undo all of it. When the 30 days are up, a scheduled job runs the same erase the delete button used to run on the spot, and it is gone — by us as well as by you. It is never a hidden flag on a row we keep afterwards.

You can also start deletion from our website without opening the app, which is useful if you have lost the device. That page is rate-limited and protected against automated abuse, and it deliberately gives the same answer whether or not an account with that address exists — including taking the same amount of time — so it cannot be used to find out who has a Vibn account.

• Deleting media you uploaded deletes the stored object, not just its listing.
• Deleting your face data is immediate and complete.
• Your face data does not wait out the 30 days: it is erased the moment you ask to be deleted, and recovering the account does not bring it back.
• Backups and logs age out on their own schedules; deletion is not instantaneous everywhere at once, and we do not claim it is.

11. What we do not do

Somebody has to pay for the servers your photos and videos sit on. Subscriptions do, and on the free tier ads help. What does not pay for it is you: nothing from inside your groups is offered to anyone, and none of the things below is a business we are holding in reserve.

One item on this list is not a promise at all. Media in an encrypted group is unreadable to us, so it cannot be mined, sold or learned from — not by us, and not by whoever holds these servers later; section 3 explains why. The rest are promises, and we would rather say which is which than let you assume.

• We do not sell your personal data.
• We do not sell, rent or trade access to your account, your groups or your media — not to advertisers, not to data brokers, not to anyone.
• We do not use the content of your photos, videos or messages to target advertising.
• We do not train any model on your content.
• We do not build a social graph across groups, and there is no follower list, public profile or friend suggestion anywhere in the product.
• We do not read your messages. In encrypted groups we could not; in older ones we do not.

12. Known limits

A privacy document that lists only strengths is marketing. These are the things we would want to know if we were you.

• Anyone with a full invite link has the group's key (section 4).
• There is no key rotation and no per-member revocation yet; removing someone stops future access, not past knowledge.
• Lose every device and the invite link, and your recovery phrase is the only way back. Skip the backup or lose the phrase as well, and the media cannot be recovered by anyone, including us.
• Screenshot blocking, where a group has sharing turned off, stops the operating system's screenshot. It does not stop someone photographing the screen with another phone.
• Groups created before the encryption rollout are not end-to-end encrypted. Their media is protected by access control and signed URLs, but the server can read it.
• Metadata is not encrypted: we know which accounts are in which groups, when things were uploaded, when the file said they were taken, and how large they are.
• Metadata about conversations is not encrypted either: we know who exchanges direct messages with whom, and when, even though we cannot read a word of them.
• Storage is charged to a group's owner. If an owner's subscription ends and their groups stay over the free limit for 30 days after a warning, we delete the oldest media in those groups — including media other members uploaded — until they fit.
• Reporting a photo or video sends us a decrypted copy of it. That is the one exception to everything section 3 says; it happens only when a member chooses to report, and only for the item reported. A reported item is also hidden from its group until a person reviews it, and comes back on its own after seven days if nobody does.
• When you send a photo or video, your phone attaches a fingerprint of the file, so we can refuse an exact copy of something the group already has. In an encrypted group that fingerprint is computed with the group's own key, which we never hold: it tells us that two uploads to the same group are the same file, and nothing more. We cannot test a file we already have against it.
• We hold group keys for a handful of accounts we create ourselves: the test accounts used for quality checks and store review. Those groups contain generated placeholder images and belong to nobody. No key to a group of yours is ever stored in a form we could use.

13. Verifying any of this

Claims in this document map to specific behaviour you can observe: an outsider requesting a group receives "not found"; a shared photo URL stops working after its signature expires; a public share cannot be created for an encrypted group; deleting your face data makes the person filter forget you.

If you find something here that does not match how the app behaves, that is a bug in one of the two, and we want to hear about it.

14. Contact

Questions about this document, or about anything in it: [email protected]

For the formal statement of what we collect and why, see our Privacy Policy. Where the two differ, the Privacy Policy is the binding one.