Vaibli Privacy Policy

Effective date: 13 September 2026
Last updated: 14 October 2026

Vaibli (“Vaibli”, “we”, “us”, or “our”) is a mobile application that helps you see and share what is happening near your current location. This Privacy Policy describes how we collect, use, store, and share personal information when you use the Vaibli app (the Service) or our public marketing website (including if you join a launch waitlist there).

Vaibli is developed and maintained by Bircube. If you need to contact us about privacy, use the contact details at the end of this policy.

This policy is written for users, including people in Pakistan where the Service is initially focused.

1. Who this policy applies to

This policy applies to anyone who installs, accesses, or uses the Vaibli mobile app on iOS or Android, and to visitors of our public marketing website where we mirror legal notices or collect a launch waitlist. Some mobile features are only available after you create an account or grant certain permissions. Some are available without an account: where your version of the app offers it, you can read one place in the app as a guest (see §2.12), and anyone can open a public web page for a post or an outage that someone has shared as a link (see §2.13, §2.14).

2. Information we collect

2.1 Account and profile information

Authentication data: If you sign up with email, we process your email address and verification codes. If you use Apple or Google sign-in, we receive identifiers and profile elements that those providers share with us according to their own policies.
Signing in with your phone number: Where your version of the app offers "continue with whatsapp", you enter a mobile number and we send a one-time code to it on WhatsApp through our verification provider. The app does not offer to send it by SMS. The number becomes your account's sign-in phone and, once you enter the code, it counts as phone-verified (below). If the number is already kept with an existing account (see below), you sign in to that account rather than a new one. Numbers verified before 14 September 2026 were not kept, so those accounts are recognised only after verifying again.
Unfinished phone sign-ins: Asking for a code sets up an account holding only that number before you enter the code. If you never enter it, we delete that unfinished account within about a day, or sooner if the same number is verified on another account.
Display handle: A public handle you choose (subject to product rules) shown on posts you publish under your named identity.
Phone number (optional verification): If you complete phone verification to unlock certain features (for example, photo posting), we process your mobile number and the verification message through our verification provider. The code is sent on WhatsApp; SMS is used only if WhatsApp sending is switched off on our side. When verification succeeds, we keep the number with your account as a confirmed way to recognise you, so that if you later sign in with that same number you reach this account rather than a new one. We keep only the number our verification provider confirmed you received a code on. It is never shown to other users, on your profile, or on any public page; people nearby see only that you are verified.
If your number is already on another account: we do not move it. Your verification still counts, and we keep a record of the two accounts involved (not the number) so a person can sort it out. We may contact you through the account to do that.
If someone invites you by your number: where we switch it on, a verified business or an official account can invite you to its team by typing your mobile number instead of your handle. We do not keep the number. We keep a keyed fingerprint of it, which cannot be turned back into the number, and its last two digits, for up to 14 days, so the invitation can reach you if you sign in or verify with that number. The fingerprint is deleted as soon as the invitation reaches an account, is withdrawn, or runs out. Nobody is told whether the number is on Vaibli, or whose it is: the person who invited you sees only "invited · ending 47" until you accept, and sees your handle only if you do. If you decline, they are not told who declined. We never send anything to the number ourselves; the person who invites you sends you the link themselves.

2.2 Location information

Vaibli is built around place. When you grant while-in-use location access:

The app obtains location from your device (for example GPS and network-assisted fixes) so we can show you a feed of content near you and enforce location-based rules on the server.
Precise coordinates are processed on our systems to rank content, enforce radius rules, and perform safety checks (for example, server-side geometry checks so that “nearby” actions reflect where you actually are).
Other users do not receive your precise location. Content you see uses coarse signals only (for example, broad geohash cells and non-exact “proximity” labels such as “right here”, “nearby”, or “around”), not raw latitude/longitude shared with other clients. For anonymous posts, we apply extra limits so that fine-grained proximity is not exposed in ways that could be misused to deanonymize someone.

We do not use background location in version 1 of the product as specified; location is requested when you are using the app according to your operating system settings.

If you deny location access, core feed features may not work; the app may show an empty state until you grant permission.

Places you have been in. From the location your device sends while you use the app, we also keep a coarse, day-level record of which places you were in: the area and the date only, never your coordinates or the time of day, for up to 90 days. We use it to work out which places you belong to — for example, who receives an outage alert (§2.15).

The first day you came to belong to a place. Separately, we keep one date per place: the first day you came to belong to it. We keep it for as long as your account exists, so we can offer you the founding member badge for places you joined within 90 days of the place opening on Vaibli (§2.3). We do not keep the presence days behind that date; those are still deleted after 90 days.

2.3 Content you create

Posts: Text, polls, and (if you are verified for photos) images you publish. Each post is tied to the location at publish time and has a time-to-live; when it expires, it is removed from the product surface according to our data lifecycle.
Comments and reactions: Text comments, reactions on posts and comments, echoes (where allowed), and poll votes. Aggregate poll results may be shown; individual vote choices are not exposed to other users.
Who can see your posts: A live post can be read by signed-in users of the app, by guests reading that place without an account (§2.12), and, if anyone shares a link to it, by anyone with the link on our website (§2.13). What each of them sees is limited as described in those sections. Once a post expires or is removed, guests and web visitors can no longer see it.
Founding member badge: If you are eligible, your own profile lists "founding member of {place}" with a switch that is off by default. Nobody else sees the badge unless you switch it on. When it is on, signed-in users who open your profile from a post or comment you made under your handle see the place name only — never a date, a count or a rank. It is never shown on your posts, or anywhere for anonymous posts. Switching it off removes it everywhere at once.
Verified resident: If you have verified your phone number and you belong to a place (§2.15), that place's composer offers a third way to post: "verified resident · {place}". Such a post is anonymous in every way an anonymous post is — no handle, no avatar, no profile to open, and no pseudonym that links two of your posts to each other — and it adds only the place name, so neighbours can tell it came from someone who lives there. The post must be made inside that place. Moderators can see who wrote it, exactly as they can for any anonymous post. It is available for text and poll posts and for outage updates.
Identity mode: You may post under your handle or under an anonymous presentation. Anonymous labels (for example colour-and-animal style names) are generated on the server so that the mapping between your account and those labels is not exposed through the app APIs to other clients. Moderation and safety workflows may still associate content with your account internally where required.

2.4 Private saves (“Catch It”)

If you save a post privately, we store a private copy of that content for you so you can revisit it after the original expires, subject to product limits (for example maximum number of saves). Those saves are not visible to other users.

2.5 Zone subscriptions

You may subscribe to a limited number of predefined geographic zones to receive notifications about activity there. We process your subscription choices and related settings (for example mute).

2.6 Device, log, and diagnostic data

Device and app data: Device type, operating system version, app version, push notification tokens, and similar technical data needed to run the Service.
Crash and error reporting: If enabled, diagnostic reports (for example via Sentry or similar tools) may include stack traces, device metadata, and contextual information to fix bugs. We aim to minimise personal data in such logs.
Product analytics: We may use analytics tools (for example PostHog or similar) to understand feature usage, funnels, and reliability, using event data that is configured to align with our privacy design (for example not exposing precise coordinates to analytics in ways that would undermine this policy). Events we record include, for example:
- reading as a guest: that guest reading started, and which kind of action (such as reacting or replying) led to a sign-in prompt;
- sign-in: that sign-in started, completed or failed, the method used (email code, email and password, Apple or Google) and, for a failure, the stage and a reason code;
- sharing: that a post link was shared or copied (not who it was sent to, which the app cannot see), and that a post link was opened in the app;
- outages: that the outage prompt was shown, that you reported, confirmed or took back a vote (with the outage and place identifiers and whether it counted), that you viewed or shared an outage card, or posted an update. When an outage alert is sent, a summary event (number of recipients and votes, time since first report) is recorded against a system identifier, not against any person.
- proposing a place: that a proposal was made or joined, reached the number of neighbours it needs, was approved or rejected (with the reason from a short list), or that its place went live, with the proposal, its type and counts. These are recorded against a system identifier, never against a person, and never include a reviewer's note (§2.16).
- place Boards: that a place's Board was on screen and which of its blocks it showed (including when read as a guest), that a contact of a given kind was tapped — never the number or the label — and that a notice was posted, as Vaibli or as an official account (§2.17);
- badges: that a founding-member or founder badge was switched on or off, and which way — never which place (§2.3, §2.16);
- events: that an event time was set in the composer and an event posted, as a business, an official account or a resident; that you set or removed "remind me" on an event, and how many reminders your phone scheduled; that "tell your group" was offered and shared, and to which kind of app (WhatsApp or the share sheet); and that a host opened its results (§2.21);
- following a place: that a follow was made, renewed or stopped, whether it was a shop or an institution and which screen it was done from, and the reason if we refused — never which place, and never any identifier for it (§2.22); that a place's upcoming events or a place page was opened, how many events it showed, and that a poster was printed;
- telling PESCO: that the tell-PESCO step was opened, from the power card or the Board, which channel you used (call, text or the complaint site) and what you said was wrong, and whether you already had a reference number saved; that you saved, changed or removed a reference number or a ticket number — never the numbers themselves; and that you marked or took back "I told PESCO" (§2.20).
Before you sign in, analytics uses a random identifier stored in the app. If you later sign in on the same installation, events from before sign-in (including guest reading) are linked to your account. The public web pages for shared posts (§2.13) run no analytics.

2.7 Payments and payouts (when offered)

Some features described in our roadmap—such as in-app purchases, tips, or wallet balances—are not all part of the initial launch. When we enable them:

App stores and payment partners (for example Apple, Google, RevenueCat, or regional processors such as Tap Payments) will process payment and fraud-prevention data under their terms and privacy policies.
Creator payouts may require know-your-customer information (for example national ID and bank or wallet details) collected only when needed to pay you, not at ordinary signup.

If a feature is not available in your build, we do not collect the associated payment or payout data for that feature.

2.8 Moderation and safety

When you report content or users, we collect the report reason and related context. Moderation staff and automated tools may review content (including media, where applicable) to enforce our rules and the law. Internal records may link reports and enforcement actions to account identifiers where necessary; that linkage is not shown to other users as part of anonymous identities.

2.9 Communications

We may send transactional messages (for example verification, security notices, or responses when you contact support). Marketing communications would only be sent where permitted by law and, where required, with your consent.

2.10 Marketing website waitlist

If you choose to join a waiting list on our marketing site, we process:

Email address, so we can tell you when the app launches or reaches your rollout area.

Submitting your email does not create a Vaibli account. We deduplicate submissions by normalising the email (for example lowercasing); if you later sign up in the mobile app using the same address, flows connect only as ordinary account data under this policy.

We use waitlist contacts only for launch-related messages tied to Vaibli unless you separately agree to broader marketing later. You can contact us using the details at the end of this policy to ask for removal from the waitlist.

2.11 Marketing pricing page (approximate region)

The public pricing page may use coarse location derived from your internet connection solely to infer country so we can show one of five example currencies (Pakistani Rupees, Indian Rupees, US Dollars, Euro, pounds sterling).

This choice is used only to tailor the pricing examples shown in your browser. It does not create or update a Vaibli account, is not merged with mobile app analytics, and is not used to store a separate “pricing profile.”

2.12 Reading without an account (guest mode)

Where your version of the app offers it, you can choose to look around first and read one place in the app without signing in. As a guest you can read that place's live posts and a post's replies. You cannot post, react, reply, vote or report until you sign in.

What we process when you read as a guest:

A device identifier. The app sends the same per-installation identifier it uses for push notifications (on iOS the identifier-for-vendor, on Android the Android ID, or a random identifier the app generates). Our server uses it two ways: a salted hash (HMAC keyed by a secret we hold) limits how many requests one device can make, and a separate, unsalted hash signs a short-lived guest pass to that device without ever being stored anywhere. If the salt is unavailable, the server refuses the request rather than falling back to hashing without one. The identifier and both hashes are not written to our database.
A bot check. Before the first read, the app runs Cloudflare Turnstile, which checks that the request comes from a real person's device. Cloudflare processes technical signals from your device and your IP address to do this, under its own privacy terms. We send Cloudflare the Turnstile result and your IP address to verify it.
Your IP address. We use a salted hash — the same HMAC scheme as the device identifier — and use it only to limit how many requests one network can make. Because many people share mobile-network addresses, this limit is loose. As with the device identifier, the server refuses the request if the salt is unavailable rather than hashing without one.
A guest pass. A passed check gives the app a guest pass that is valid for 30 minutes on that device. It contains an expiry time and a signature, and nothing about you. When it lapses, the check runs again.

What we do not do: A guest has no account. We do not ask for your location, and your location plays no part in what you are shown (you pick the place). Guest reading does not create any record in our database.

What guests see of other people's posts: only fields we have chosen to make public: the post's text, the place name, the author's public name (a person's handle, or a business or institution name) and picture, a photo or video thumbnail, poll questions, link titles, and the number of replies and reactions. Guests never receive coordinates, distances, account identifiers, or the handle of anyone who posted or replied anonymously; anonymous authors appear only under their thread pseudonym. Guests never see a photo or video on an anonymous post.

Retention: The rate-limit records (the salted device and IP hashes) expire automatically within 20 minutes. The guest pass expires after 30 minutes and is not stored on our servers. Analytics events from guest reading are handled as described in §2.6.

2.13 Public share links and web pages

Signed-in users can share a post or copy its link. A link looks like vaibli.app/p/<code>. The code is random, is not derived from the post or its author, and cannot be used to find other posts. Any signed-in user can create a link to a live post they can see, not only its author. Shared links carry a short source tag so we can tell when someone installs the app from a link.

Anyone who opens the link, with or without the app or an account, sees a web page for that post while it is live. The page shows:

the post's text, poll question and options, and the title and domain of any link in it;
the place name (for example "in Gulberg Town") and city;
the author's public name and account mark (a person's handle, or a business or institution name). An anonymous post shows only "anonymous" and its pseudonym;
for a post that is not anonymous, the first photo or video thumbnail;
the number of replies, how long ago it was posted, and when it will fade. The number of reactions is also included in what the page receives.

What the page never shows: your exact location, any distance or radius, account identifiers, the text of replies, or other posts in the place. For an anonymous post it never shows the author's handle or any photo or video. Profile pictures are not shown; the page draws a letter instead.

When a post expires or is removed: the link keeps working, but the page shows only "this vaib has faded" and the place name, with no content and no reason. Pages are cached for up to 60 seconds, so a change can take up to a minute to show.

Search engines: the pages are marked noindex, nofollow, so search engines are asked not to list them. There is no web page that lists a place's posts.

Link previews: each link has its own preview image: the first photo for a photo post, otherwise the quote, author name and place, rendered by us. When a link is pasted into another app, that app (for example WhatsApp) fetches the preview and may keep its own copy, even after the post has faded — including in conversations you are not part of, because it is the recipient's app that makes the copy. We cannot delete copies held by other apps.

Visiting the page: the page is served by Cloudflare. It runs no analytics scripts. As with any website, your browser's request (including your IP address) reaches Cloudflare and our database provider to build the page. Those providers keep standard request logs (such as IP address, browser type, time and the page requested) for a short period set by them, for security and troubleshooting. We do not log your IP address ourselves, with one exception, described next.

Opening someone's invite link. A person on Vaibli can send you a link to the app that carries their handle, vaibli.app/i/<handle>. When you open one, we keep a note that the link was opened: whose link it was, a salted hash of your IP address, and whether the browser was on an iPhone or an Android phone. We do not keep the IP address itself, and the hash cannot be turned back into it. The note is deleted after 7 days. If a new account is created from the same network and the same kind of phone within a day of that, we record that the account was probably invited by that person. We use this only so our own team can see whose invites are bringing people in. That record holds the two accounts and the date, no IP address and no hash, is seen only by Vaibli staff, is never shown to you, to the person whose link it was, or to anyone else in the app, sends no notification, and is deleted with either account. If you tell us who invited you in Settings, what you say replaces our guess. Link-preview robots are not noted.

2.14 Outage reports and confirmations

In places where we have switched it on, you can tell your neighbours about a utility or road outage — the electricity ("light gayi?"), water or gas is out, or a road is blocked — confirm someone else's report ("me too"), say it is back (or the road is open), or say it's fine where you are. Each kind is switched on place by place, and each outage has its own votes. Everything in this section and §2.15 applies to every kind in the same way. You must be signed in. You can do this if you belong to the place (based on the day-level presence record described in §2.15) or are currently inside it.

What we collect and store:

Your vote: which outage, your account, what you said (out, back, or on where I am), whether it counted, and when. Votes that do not count (for example from a new, unverified account) are still kept so moderators can review them. If you take your vote back, we delete it.
A salted hash of your device identifier. The app hashes its installation identifier (SHA-256) before sending it, and our server hashes that again with a secret key before storing it. We use it only so that one phone counts once, even with two accounts. It is never shown to anyone or returned by the app's servers.
Your location, as used. When you open a place's feed, vote or post an update, the app sends your device's current or last-known location, if you have allowed location access, so the server can check whether you are inside the place. We use it for that check only and do not store it with your vote, the outage or your update. Other users never receive it.
The outage itself: the place, its status and times, and who reported it first.
Updates you post on an outage (up to 280 characters) with your account, and reports you make that an outage or update is fake or abusive (the reason, any details you add, and your account).

Who sees what:

Signed-in users viewing the place see the outage's kind, status and how long it has lasted, the number of counted votes (not who cast them), the handle of the first reporter, and the latest update from an official account, if any.
Scheduled power cuts: on an electricity outage, the card and its web page may also show the published load-management schedule for the place ("scheduled off until 4 pm · PESCO"). That line comes from the electricity company's public schedule, which we download daily, and from which feeders we have linked to the place. It uses no information about you, and it never changes the neighbours' count.
Updates from a neighbour follow the same anonymity rules as comments: each update is posted identified (showing your handle) or anonymous (showing a pseudonym scoped to that outage, with no handle or avatar). If you are on the anonymous-comment restriction list, you cannot post an anonymous update. Updates from an official account are always identified and show the institution's name, never anonymous.
Only you can see your own vote. No one else can see who voted or how.
Moderators can see outage reports, counts and the first reporter, and can hide updates or remove an outage.
If you share an outage card, the message includes the place name and a link to the outage web page described below.

The outage web page: Like a shared post (§2.13), a link to an outage — vaibli.app/s/<code> — opens a page for anyone, with or without the app. While the outage is live, or for 24 hours after it clears having gone back, the page shows: the status, the place name and city, the number of counted votes, how long it has lasted, the handle of the first reporter, and the latest official update, if any. It never shows a neighbour update's text or author, or any account, zone, device, or vote identifier. An outage that cleared without going back, was removed, or an unknown code, all show the same "this card has faded" page with just the place, or nothing at all for an unknown code. The page is marked noindex, is cached at the edge for up to 15 seconds so the count stays close to live, and if our database cannot answer, it shows an error page rather than a stale cached result.

Retention: Updates on an outage are still deleted 30 days after the outage ends or is removed. Outages that are cleared or removed, together with their votes (including the device hash) and any outage reports on them, are now deleted automatically 90 days after the outage ended, by a daily job. If you delete your account, your outage votes, your updates, and any reports you filed are deleted immediately as part of that process; the outage itself, and its counted totals, stay for your neighbours, with "first reported by" no longer attributed to anyone.

2.15 Outage alerts

When enough neighbours confirm an outage in a short time, we send one alert for it (for example "bijli out in {place}", "paani out in {place}" or "road blocked in {place}"). It goes to people who belong to the place and to people subscribed to that zone who have not muted it. It does not go to anyone who has already voted on that outage, and no one gets more than one alert of the same kind per place in six hours. The alert follows your quiet hours and our daily notification limits, and it is not sent if the outage is already over by the time it would go out. We do not send a "it's back" alert.

"Belonging to" a place is worked out from a coarse record we keep of which places you have been in: the area and the date only, never your coordinates or the time, kept for up to 90 days. You belong to a place once you have been there on several separate days recently.

How to control outage alerts: set quiet hours in Settings, or turn off notifications for Vaibli in your device settings. If you subscribed to the place, you can also mute or unsubscribe from it in the app, which stops its outage alerts. If you receive alerts because you have simply been in a place, and never subscribed to it, you can still silence that place: in current versions of the app, press and hold the outage card and choose mute outage alerts for {place}, which silences every kind of outage alert for that place. Older versions of the app have no per-place mute, so there quiet hours and your device settings are your controls. There is currently no separate switch for outage alerts only.

2.16 Proposing a place

Where no place on Vaibli covers you yet, and where we have switched it on, you can propose a place — give it a name and say what kind of place it is (for example a street, a mohalla or a village) — or join a proposal a neighbour has made. When enough neighbours have joined, a member of the Vaibli team reviews it and may draw the place and open it. To propose or join, you must be signed in, have verified your phone number, have had your account for at least three days, and be standing where no live place covers you.

What we keep:

A proposal: its name and type, who proposed it, an approximate point for where you were when you proposed it, its status (open, ready for review, approved, rejected or closed), and when each of those happened.
A join: who joined which proposal, the approximate point where you were when you joined, and when. Whoever proposes a place counts as its first join.
Approximate means about 150 metres. When you propose or join, the app sends your device's location so the server can check that no live place already covers you, that you are within 1.5 km of a proposal you join, and whether other proposals are nearby. Before anything is stored, the location is rounded to the centre of a cell about 150 m across. Your exact coordinates are never stored with a proposal or a join.
A record of what happened to each proposal — proposed, joined, left, ready, approved, rejected, closed, went live — with the account that did it and, for a rejection, the reason and any note the reviewer wrote.
Asking for a place where you are: proposing or joining also adds you to the list of people asking for a place in that area, the same list you can join from the app when no place covers you. For it we keep your account, the approximate area (a cell about 1 km across), the city and country, and when you asked.
The founder: if a proposal becomes a live place, we record that the person who proposed it founded that place. That record is never public on its own. It gives them two things, both described below: a founder badge and one pin on that place's Board (§2.17).
The founder badge: your own profile lists "founded {place}" with a switch that is off by default, exactly like the founding-member badge (§2.3). Nobody else sees it unless you switch it on. When it is on, signed-in users who open your profile from a post or comment you made under your handle see the place name only — never a date, a count or a rank. It is never shown on your posts, or anywhere for anonymous posts, and switching it off removes it everywhere at once.

Who sees what:

Signed-in users nearby (within about 1.5 km) see an open proposal's name, type, and how many neighbours have joined out of the number it needs. Only joins from accounts that are still verified and in good standing are counted. They never see who proposed or joined.
You also see which proposals you made or joined, and, if a proposal you made is rejected, the reason. Neighbours who joined it see it as closed.
Vaibli staff reviewing proposals see who proposed each one, its approximate point, the approximate points of its joins (as dots on a map, without names), and the record of what happened.
Guests (§2.12) and public web pages (§2.13) show no proposals.

When the place goes live: everyone who joined its proposal, including the person who proposed it, gets one notification that it is live, which follows your quiet hours and also appears in your notifications in the app. If you have a free zone subscription (§2.5) and no subscription for that place already, we subscribe you to it; you can mute or unsubscribe as with any zone. If your subscriptions are full, the app offers to add it instead.

Retention: an open proposal that has not reached the number it needs after 60 days is closed. If you leave a proposal you joined, your join is deleted, and the record that you joined and left stays. Proposals, joins, the record of what happened, the founder record and your requests for a place are otherwise kept while your account exists. If you delete your account, we immediately delete your joins, your founder records, your requests for a place, and any proposal of yours that did not become a place (with its joins and record). A proposal that became a place is kept, with your account removed from it, and your account is removed from every record of what happened.

2.17 A place's Board

Where we have switched it on, a place's screen shows a Board: notices from Vaibli or from a verified official account (for example a school, a hospital or a utility), key contacts for the area, the verified shops inside the place, and a line for anything that is out right now (§2.14). Everyone who can see the place sees the same Board, including anyone reading that place as a guest, without an account (§2.12).

Almost nothing on a Board is information about you:

Contacts are published numbers of institutions and services — emergency, utility, health or administration — added by Vaibli staff. They are not residents' personal numbers. We keep the label, the kind, the number, which staff account added it, and when it was last checked.
Notices are posted by Vaibli, or by an editor of a verified official account that we have allowed to post on that place's Board. A notice shows the account's name and verified mark — never the name or handle of the person who posted it. We do keep which account and which person posted it, so that we can answer for what was posted; that is not shown to other users.
Shops are the verified businesses whose pin falls inside the place, shown with information already on their business profile.
The founder's pin is the one thing on a Board written by a resident: the person who started the place (§2.16) may keep a single pin there, with a title and a short message they write. It shows their handle only if their founder badge is on; otherwise it says it comes from the person who started the place and names nobody. They can change or remove it at any time.

Tapping a contact opens your phone's dialler with the number filled in. Nothing is dialled until you choose to call, the call goes through your own mobile operator, and we do not see or record that you called anyone. We record only that a contact of that kind was tapped, without the number or the label (§2.6).

If a notice or a founder's pin is wrong: "Something wrong?" reports it to our moderators, with the reason you pick, anything you add, and your account, like any other report (§2.8). Whoever posted it is told the reason it was removed, and is never told who reported it. A founder whose pin is taken down twice keeps their badge but can no longer pin on that place.

Retention: a notice stops showing at its end date (at most 90 days after it was posted) and is deleted 30 days later; a notice we remove is deleted 30 days after removal. Contacts stay while the Board has them. A founder's pin has no end date: it stays until they change or remove it, we take it down, or they delete their account, which deletes it (§2.16).

2.18 Masjid prayer times, nearby lists and masjid reminders

Prayer times. Where we have switched it on, a verified masjid account can show its jamaat times on its page, and in Ramadan its sehri and iftar times. These are published by the masjid, not information about you. The masjid's committee members, or Vaibli staff on the masjid's behalf, enter them. When they change a time, the app may post a short announcement from the masjid's account saying which time changed; it names the masjid, never the person who changed it. We keep which account and which person saved each change, for Vaibli staff only.

Azan, sehri, iftar and countdowns are worked out on your phone. The app calculates azan times from the masjid's approximate position (rounded to about 1 km). When no masjid near you has entered times, it calculates times "for your area" on your phone from your location, which is not sent to us for this.

Nearby masjids and businesses. The pills at the top of the feed and the lists they open show verified masjids, masjids we have listed (below), and verified businesses near you, nearest first. To sort them, the app sends your current location with the request; we use it to count and sort, and do not store it. The lists show places, never people: we do not record or show who goes to a masjid, and there are no check-ins or marks at places of worship. If you are reading as a guest (§2.12), the lists use the place you are looking at, and no location of yours is sent.

Your masjid, and masjid reminders, stay on your phone. You can choose one masjid as your masjid, so its times come first, and turn on reminders before jamaat, or for sehri and iftar in Ramadan. Which masjid you chose, and which reminders you turned on, are saved only on your phone and scheduled by your phone. We never receive them, they are not linked to your account, and deleting the app deletes them. Which masjid a person attends can say something about their beliefs, so we built this so that we never learn it. We record only that a masjid was chosen or that reminders were changed, never which masjid (§2.6).

Masjids we have listed. Where we have switched it on, the nearby list can also show masjids that Vaibli has added to the map before anyone from the masjid has joined. A listed masjid is marked "added by vaibli · not yet run by the masjid". It shows its name, an address or landmark, its area, and azan times worked out on your phone from its approximate position; it never shows jamaat times, posts or announcements, because nobody from the masjid has given us any. It is a place on a map, not an account, and it does not speak for the masjid. When someone from the masjid joins and we have checked who they are, the listing becomes the masjid's own account.

Telling us it's your masjid, or that a listing is wrong. On a listed masjid you can tell us you help run it, and choose to add a phone number and a short note so our team can call you and arrange a visit. This tells us that you are connected with that masjid, so it is seen only by Vaibli staff, is never shown on the masjid's page or to anyone else, is never sent to analytics except as a count, and is deleted 90 days after you send it (sooner if you take it back, which you can do from the same page). You can also tell us a listing is wrong — no masjid there, the wrong place on the map, closed, listed twice, or the wrong name — with an optional note. We keep which account reported it so one person counts once; when three different people report the same listing, it is hidden until our team looks at it. Reports are seen only by Vaibli staff and are deleted after a year.

Retention: a masjid's older timetables are deleted 30 days after a newer one takes over, and records of announcements after 180 days. The announcement posts themselves expire like any other post (§6). Requests to run a listed masjid are deleted after 90 days, reports about a listing after a year, and a listing we remove a year after its removal.

2.19 Masjid announcements and janaza alerts

Where we have switched it on, a verified masjid account can announce a janaza (funeral prayer), Eid prayer times, gatherings such as dars or quran khwani, and masjid needs such as repairs or donations. Only the masjid's committee members, or Vaibli staff on the masjid's behalf, can post them.

What a janaza announcement contains. The name of the person who has died, a relation line (for example "wife of Muhammad Aslam"), or both, as the family chooses; when and where the janaza prayer is; and, if given, the place of burial. A masjid can post one only after confirming that the family has agreed to the announcement. It is shown to people near the masjid, in the feed and on the masjid's page, including to anyone reading as a guest (§2.12).

Taking one down. A family can ask the masjid to remove a janaza announcement, or report it with "Something wrong?" (§2.8); we remove it without asking why. Any announcement can be reported and removed.

What we keep. The details the masjid entered, which account and which person posted it, the family-agreement confirmation, and when. We record the person who posted it for Vaibli staff only; the announcement itself shows the masjid, never the person.

Janaza alerts. "Janaza alerts near me" is off unless you turn it on. If you do, you get one notification for each janaza announced by a masjid in a place you belong to or follow (§2.5), at most three a day, and never during your quiet hours. We keep whether the switch is on with your account; it is never shown to anyone and is deleted with your account. Eid prayer, gatherings and masjid needs never send notifications.

Masjid needs are checked by a moderator before they appear, and may show the masjid's published phone number so you can contact the committee. Vaibli never handles donations.

Retention. Each announcement disappears two hours after its event (a need when the masjid marks it done, or after 30 days). Its record is deleted 30 days after that, and a removed announcement's record 30 days after removal.

2.20 Telling PESCO about a power cut

Where we have switched it on, a live, red power outage card, and the Board's 118 contact row (§2.17), offer a tell PESCO step: your bill's reference number ready to read out, one tap to call 118, text 8118, or open PITC's own complaint site, and a count of how many neighbours here have already told PESCO.

Your reference number, and any PESCO ticket number, stay on your phone. If you save your bill's 14-digit reference number, or a ticket number PESCO gives you afterwards, we keep it only in the app's storage on your device — under your signed-in account, or under guest mode. It is never sent to Vaibli: not to our servers, our analytics, our crash reports, or our logs. It leaves your phone only when you choose to call, text or open the complaint site, and it then goes straight to PESCO or PITC.

Calling 118, texting 8118 and PITC's complaint site are PESCO's and PITC's own channels, not ours. We open your phone's own dialler with 118 ready to call, your SMS app with a message to 8118 already written, or your browser at PITC's complaint site (ccms.pitc.com.pk) — we never submit a complaint on your behalf, never scrape PITC's site, and never see or promise what happens after you tap through. Normal call and SMS charges from your mobile operator apply, and those channels are under PESCO's and PITC's own terms.

"I told PESCO" is a count, never a record of what you said or did. If you tap it after using one of the channels, we store a one-way marker tied to your account and that power outage, so we can count one person per power outage — the marker cannot be read back to your account, and it never carries your reference number or a ticket number. The count is shown to everyone who can see the card, including guests reading without an account (§2.12). You can take your mark back while the power cut is still on. The marker is deleted one day after the power cut is over.

2.21 Events

Where we have switched it on, a verified business or official account (never a masjid or other place of worship) can make a post an event by adding when it starts, when it ends and, if it is not at their own address, a short place line. Events are always posted under the business's or institution's name, never anonymously. Anyone who can see the post sees the event, as with any post (§2.3, §2.12, §2.13).

Events from residents. Where we have switched it on, a person whose phone is verified and who has been part of a place for a few days (§2.3) can also make their own post an event — a cricket match, a clean-up, a Milad. A resident's event is always posted under their handle, never anonymously, and must say where it is: a hall, a ground or a landmark. We never place a resident's event at their home, and we ask them never to write a house number. To decide whether you can host, we check your verified phone and your belonging to the place, and count your own events (at most 2 a week and 3 coming up at once); nothing new is collected for it. If an event points people at somebody's house, anyone can report it as "this is someone's home", and we take it down.

What we keep. The start and end times and the place line, with the post. We ask hosts not to write a home address in the place line.

"Remind me". Tapping "remind me" on an event saves it, like any private save (§2.4). The reminders themselves — the evening before and an hour before — are scheduled on your phone; we do not send them. Removing the save cancels them.

The going count. Where we have switched it on, an event can show how many people tapped "remind me". It appears only once 5 or more people have, and is rounded down (for example "35 going"). It is shown to everyone who can see the event, including guests and anyone with a link, but it never shows who. Events from places of worship never show a count.

Telling your group. After "remind me", the app may offer to share the event, for example to a WhatsApp group. The link it shares carries a short random tag made for you and that event. It is not your handle or account id, and the web page and its preview look exactly the same with or without it; nothing on them names you. We keep which account a tag belongs to, and use it only to count: how many people shared the event, how many opens came through shared links, and how many accounts were created from them. The host, and everyone else, sees totals only — never who shared.

Counting link opens. When someone opens an event's web page (§2.13), we add one to a count for that event and day, and to the count for the tag if the link carried one. The count holds no IP address, device identifier or account, and link-preview robots are not counted.

What the host sees. The people who run the business or institution can see results for their own event: how many signed-in people it reached in the app, how many opened its link, how many tapped "remind me", how many shared it and opened it through shares, how many checked in at the business during the event (only when the event is at the business's own address), and how many new accounts came from its links. Every number below 5 shows as "fewer than 5". There are no lists, no names and no export.

Signing up from an event link. If you create an account after opening an event's link, we record that your account came from that event's link (as for any shared link, §2.13). The host sees only the total.

Private invitations. Where we have switched it on, a person with a verified phone who belongs to a place can invite the people they choose — to a dinner, a gathering, or a wedding's mehndi, barat and walima — by sending a link. An invitation is not a post: it never appears in any feed, search, place page or list, and nobody can find it without the link.

What we keep: the host, the kind, the title, a note, when each part is and where, whether the host approves each guest or lets in anyone with the link, and each person's reply (coming, asked, can't come, or not let in) with how many of them are coming.
Who sees what: anyone with the link sees the title, the host's handle, the kind, the days and times and the name of the area — never the place and never the note, which only people who are in and the host can see. The web page for a link shows the same card and is not indexed by search engines. Only the host sees who replied. Guests never see each other or each other's replies; if the host chooses, guests see how many are coming, as a number only. Guests cannot message each other, and there is no chat.
Notifications: the host is told when people ask to come (at most every 15 minutes); a guest is told when they are let in, when the time, place or note changes, and if it is cancelled. Reminders before each part are scheduled on your phone.
Moderation: anyone who has the link can report an invitation, including as "this is someone's home". Vaibli staff see an invitation only once it has been reported, and can cancel it; the host is told why.
Retention: an invitation, its parts, its replies and its reports are deleted 30 days after its last part ends, or 30 days after it is cancelled. Deleting your account deletes your replies straight away, and cancels and deletes the invitations you host after telling the people coming. A record that staff cancelled or dismissed a report — without the invitation's contents — is kept for our own accountability.

Retention. An event ends its life with its post: the post fades two hours after the event ends, and the event's details, its sharer tags and its link-open counts are deleted with the post. A save you made is kept like any private save until you delete it (§2.4).

2.22 Following a shop or an institution

Where we have switched it on, you can follow a verified business or a verified official account, so you hear when they post a new event.

What can be followed. Only businesses and institutions — never a person. Places of worship can never be followed, because a list of who follows which masjid would say something about you that is not ours to keep. Nor can official accounts of political office-bearers, or any account we have marked sensitive — a clinic, a women's centre, a counselling service — because following one would reveal something about the follower rather than about the place. Health accounts are treated as sensitive unless we have looked and decided otherwise.

What a follow sends. One notification when that place posts a new event. Nothing else: not their ordinary posts, not their offers. At most one from each place a day, at most three a day across every place you follow, and never during your quiet hours. You can follow up to 30 places, turn the whole thing off in Settings → Notifications, or unfollow any one of them there or on its page.

Who knows. A follow is known to you and us, and to nobody else. The place is told how many people follow it — only from 5 upward, and rounded, the same way the going count is — and is never told who. No one else sees any number at all, so there is no public follower count anywhere in Vaibli. Follows are never connected to anonymous posts or pseudonyms.

If you stop using it. If you have not opened anything from a place you follow for 180 days, we stop notifying you and tell you once in your activity inbox; one tap starts it again. We may also stop a place's notifications if it misuses them, and we tell that place why.

What we keep, and for how long. Which places you follow, when you followed them, and when you last opened something from one. Unfollowing deletes the record — there is nothing left afterwards that says you once followed a place. Deleting your account deletes all of them, including any that had gone quiet. If we mark a place sensitive, its follows are deleted rather than paused.

2.23 A place's own page on the web

Where we have switched it on, each verified business and each followable institution has a read-only page at vaibli.app/h/<name>, which anyone can open without the app and which we ask search engines not to index. It shows the place's name, its verified mark, the area it is in, its opening hours if it is a shop, and its upcoming events with their dates and going counts. It shows no phone number, no exact address and nothing about any person. A printable poster of that page carries a QR code to it and nothing else; opening a page through one is counted exactly as §2.21 describes, with no IP address, device or account.

Featuring. An institution may feature another host's event happening in its own area, which adds a line to the event's card and lists it on the institution's page. It changes nothing about who can see the event, sends no notification to anyone, and says nothing about any person. The host whose event it is, is told and can remove it.

2.24 The one question we may ask you

Where we have switched it on, a card may appear once in your feed asking how likely you are to tell a friend or neighbour about Vaibli, answered by tapping a number from 0 to 10.

It is asked at most once. Answering it, or closing it, is recorded so that we never ask you again. Closing it is not a "later" — it is a "no", and we keep it.

There is nothing to type. The card has no text box, so there is no comment to store and nothing you write can end up in it.

What we keep. The number you tapped, or the fact that you closed the card; the version of Vaibli you are on, whether your phone is Android or iPhone, and whether you are reading in English or Urdu. These are tied to your account, for the single purpose of not asking you twice.

Who can see it. Nobody at Vaibli can see who gave which score. The only way we can read any of it is as totals — how many answered, how many closed it, and the overall score — which is what the answer is for. Our analytics are told that a card was shown, answered or closed, and are never told the number.

How long we keep it. While your account exists. Deleting your account deletes your answer with it.

3. How we use information

We use personal information to:

Provide, secure, and improve the Service (feed, posting, notifications, subscriptions, and related features).
Operate our marketing website waitlist, including sending proportionate notices when we open access or widen rollout.
Show marketing pricing anchors inferred from coarse IP location (five currency examples — see §2.11).
Enforce location-based rules and ephemeral content behaviour as designed.
Let people read without an account, while limiting automated abuse (§2.12).
Show public web pages for posts and outages that someone has shared as a link (§2.13, §2.14).
Run outage reports: count one vote per phone, check who may vote, show the outage card, and send outage alerts (§2.14, §2.15).
Show a place's Board: notices, key contacts, the verified shops inside it, and what is out right now (§2.17).
Run proposing a place: check who may propose or join, show nearby proposals and how many have joined, let our team review them, and tell the people who joined when the place opens (§2.16).
Show the tell PESCO step on a power outage card and the Board's 118 row, and count how many people here have used it (§2.20).
Recognise you by your verified phone number, so signing in with that number reaches your existing account, and resolve cases where a number is already on another account (§2.1).
Protect anonymity mechanics for anonymous posts and comments as described in product requirements.
Detect abuse, spam, and fraud; enforce our terms; comply with legal obligations.
Operate moderation and human review where automated means are insufficient.
Analyse aggregates and trends to improve performance and product quality.

We do not build a social graph based on following individual users. Relationships in the product are oriented around place and zones, not “follower” links between people.

4. Legal bases (where applicable)

Depending on your country, we may rely on one or more of the following:

Performance of a contract: Providing the Service you request.
Legitimate interests: Securing the Service, understanding usage in aggregate, preventing abuse, and improving reliability—balanced against your rights.
Consent: Where required for optional processing (for example certain marketing or optional analytics, if we configure them that way).
Legal obligation: Responding to lawful requests from authorities when we are required to.

For the features described in §2.12 to §2.16 specifically:

Showing a post on its public web page, and to guests reading a place, is part of the Service you use when you post (performance of a contract).
The guest bot check and the hashed device and IP rate limits rely on our legitimate interest in keeping the Service free of automated abuse. The data involved is limited to short-lived hashes (§2.12).
The note of an opened invite link, and the "probably invited by" record made from it, rely on our legitimate interest in understanding which invitations bring people to the Service. The data is limited to a hash kept for 7 days and a staff-only record (§2.13).
Outage vote checks (one vote per phone, and who may vote) rely on our legitimate interest in keeping outage reports trustworthy (§2.14).
The told-PESCO marker (one per person per power outage) relies on our legitimate interest in keeping that count trustworthy, the same basis as outage vote checks (§2.20).
Proposing or joining a place — checking where you are, and keeping who proposed and joined and an approximate point — is part of the Service you ask for when you propose or join (performance of a contract) (§2.16).
Product analytics, including linking a guest's earlier events to the account they later sign in with on the same installation, rely on our legitimate interest in understanding and improving the Service (§2.6).

5. How we share information

We share information only as needed to operate the Service:

Infrastructure and database: Hosted backend and database providers (for example Supabase) that store and process data on our behalf under appropriate contractual terms.
Push notifications: Notification delivery services (for example Expo push services together with Apple Push Notification service and Firebase Cloud Messaging on Android).
Authentication and messaging: Identity providers you choose (Apple, Google) and SMS or verification vendors for OTP. When a code is sent on WhatsApp, WhatsApp (Meta) carries that message and receives your number for that purpose.
Media and safety: Image hosting or processing (for example resizing or moderation-classification providers) where we use them.
Cloudflare: runs the Turnstile bot check for guest reading, serves our website and the public pages for shared posts (including a short-lived edge cache), and delivers media.
Rate limiting: a hosted data store (Upstash, in Singapore) holds short-lived, hashed rate-limit records (§2.12).
Public by design: content on a shared post's or outage's web page is visible to anyone with the link, and other apps that display a link preview may keep their own copy (§2.13, §2.14).
Analytics and reliability: Analytics and error-reporting subprocessors as configured for the app.
Payments: App stores and payment processors when you make purchases, as described in section 2.7.
Professional advisers: Lawyers, accountants, or auditors under confidentiality obligations.
Legal and emergency requests: We may disclose information if we believe in good faith that disclosure is required by law, court order, or to protect the rights, safety, or property of users, us, or the public.

We do not sell your personal information in the traditional sense of “selling” lists of individuals to advertisers. Paid Boost-style surfacing in the product, if offered, is a paid distribution of your own content to nearby users—not sale of personal data dossiers to third-party advertisers. Paid features may still involve payment processors as described above.

6. Retention

Ephemeral content: Posts, comments, reactions, and related activity are designed to expire after their time-to-live. After expiry, they should no longer appear in the app; backend retention for backups, logs, or legal holds may continue for a limited period consistent with operations and law.
Account deletion: If you delete your account, we may use a grace period (for example several days) during which restoration is possible, then complete deletion or anonymisation steps. For anonymous historical content, our model may retain posts while detaching or anonymising internal ties to your account where specified in product policy. Your outage votes, updates and filed reports are an exception to that grace period: they are deleted immediately, not after it (§2.14). So are your place proposals, joins, founder records and requests for a place, as described in §2.16.
Private saves: Retained until you delete them or delete your account, subject to product rules.
Unfinished phone sign-ins: an account that only asked for a code and never entered it is deleted within about a day (§2.1).
Verified phone number: kept with your account while it exists, and removed from it when you delete your account (§2.1). A record that a number was already on another account holds no number and is kept until we have resolved it.
An invitation by phone number: the number's fingerprint is kept for up to 14 days and deleted as soon as the invitation reaches an account, is withdrawn or runs out; the rest of the invitation (the team, the job and the last two digits) is deleted within about a day after that. An invitation that reached you becomes an ordinary invitation on your account (§2.1).
Guest reading: Salted rate-limit hashes expire within 20 minutes; guest passes after 30 minutes (§2.12).
Share links: A post's link stops showing content as soon as the post expires or is removed (within about 60 seconds). Copies held by other apps are outside our control (§2.13).
Outage share links: An outage's page keeps its live or "back" state for up to 24 hours after it clears, then shows only "faded" (reflected within about 15 seconds) (§2.14).
Outages: Updates are deleted 30 days after the outage ends. Cleared or removed outages, their votes, and any outage reports on them, are deleted 90 days after the outage ended; deleting your account removes your own votes, updates and reports immediately (§2.14).
Place presence: Day-level records of the places you have been in are kept for up to 90 days (§2.15).
First day you belonged to a place, and your badge choice: kept while your account exists, and deleted when you delete your account (§2.2, §2.3).
Founder badge and founder pin: kept while your account exists, and deleted with it; the place itself stays (§2.16, §2.17).
Place proposals: an open proposal closes after 60 days without reaching the number it needs. Proposals, joins, their record, founder records and requests for a place are kept while your account exists; deleting your account deletes yours, except that a proposal which became a place is kept with your account removed from it (§2.16).
Board notices: deleted 30 days after they end, or 30 days after we remove them (§2.17).
Telling PESCO: your reference number and any ticket number live only on your phone — we never store them. A ticket number is removed from your phone automatically after 7 days. The told-PESCO marker is deleted one day after the power cut it belongs to is over (§2.20).
Events: an event's details, its sharer tags and its link-open counts are deleted with its post, which fades two hours after the event ends (§2.21).
Follows: kept until you unfollow, which deletes the record outright, or until your account is deleted, which deletes all of them (§2.22). A follow you have not used for 180 days stops notifying you but is kept, so one tap can start it again.
The one question: your answer, or the fact that you closed the card, is kept while your account exists and is deleted when you delete your account (§2.24).
Listed masjids: your request to run a listed masjid, with any phone number and note, is deleted 90 days after you send it; a report about a listing after a year; a listing we remove, a year after its removal (§2.18).
Logs and analytics: Retained for troubleshooting and insights on rolling schedules typical for such systems, then deleted or aggregated. Our hosting providers' request logs (§2.13) are kept for a short period set by those providers. Where the law requires us to keep certain data for longer, we keep it only as long as required.

Exact retention windows can evolve; material changes should be reflected in updates to this policy.

7. Security

We use administrative, technical, and organisational measures appropriate to the risk, including access controls, encryption in transit for modern clients, and database policies (for example row-level security) designed to limit who can read or change data. No method of transmission or storage is perfectly secure; we encourage you to protect your device and accounts.

8. Your choices and rights

Depending on applicable law, you may have rights to access, correct, delete, or export certain personal data, or to object or restrict certain processing, and to withdraw consent where processing is consent-based.

Device permissions: You can revoke location or notification permissions in your device settings; some features will stop working as a result.
Notifications: You can set quiet hours in the app, and mute or unsubscribe from any zone you subscribed to; those also control its outage alerts, of every kind (electricity, water, gas and roads). A place you only belong to (by having been there) can be muted from the outage card in current versions of the app — see §2.15.
Guests: Guest reading is not linked to an account, and we keep only short-lived hashes, so we generally cannot find data about a specific guest. Those hashes expire within 20 minutes, so there is usually nothing left to access or delete; you can still contact us. If you sign in later on the same installation, earlier analytics events are linked to your account (§2.6), and you can then exercise your rights through that account.
Founding member badge: off unless you switch it on in your profile; you can switch it off at any time, and it disappears everywhere at once (§2.3).
Founder badge: the same, for a place you started: off unless you switch it on, off again whenever you choose, and separate from your pin — losing the pin never touches the badge (§2.16, §2.17).
Proposing or joining a place: never automatic; you choose each one. You can leave a proposal you joined, though not one you made, and it then no longer counts you. Once the place is live you can mute or unsubscribe from it like any zone (§2.16).
Calling a Board contact: your phone's dialler is opened with the number filled in, and nothing is dialled until you choose to call; the call goes through your mobile operator, not us (§2.17).
Telling PESCO: saving a reference number is optional, and you can change or remove it from your phone at any time from the tell-PESCO sheet. You can take back "I told PESCO" while the power cut is still on (§2.17, §2.20).
Events: "remind me" is always your choice, and you can undo it at any time, which cancels the reminders on your phone. Telling your group is optional, and nothing is shared unless you choose an app and send it (§2.21).
Following a place: following is always your choice. Settings → Notifications lists every place you follow, lets you unfollow any of them, and has one switch that turns off new-event notifications from all of them at once (§2.22).
Verified resident: it is one choice in the composer, per post, and never a default (§2.3).
Verified phone number: you can ask us to remove the number from your account. You will then no longer count as phone-verified, and features that need verification (for example photo posting) will stop working until you verify again (§2.1).
Account: Use in-app account tools where available, or contact us to exercise rights.

We may need to verify your identity before fulfilling requests. If you are unsatisfied with our response, you may have the right to complain to a data protection authority in your country, where one exists.

9. Children

The Service is not intended for children below the minimum age required by the app stores or applicable law (often 13, or higher where local rules require). We do not knowingly collect personal information from children in a targeted way. If you believe we have done so, contact us and we will take appropriate steps.

Reading as a guest (§2.12) shows only content that is already visible to members of the app, and collects no account information.

10. International transfers

Your account and posts live in our main database, which is hosted in Singapore. Short-lived rate-limit records (§2.12) are held by Upstash, also in Singapore. Analytics events go to PostHog in the United States. Cloudflare — which runs the bot check, our website and the media store — operates a global network, so a request may be handled in a data centre near you or elsewhere. SMS and WhatsApp verification go through Twilio, a United States company. An SMS code reaches you through your own mobile operator; a WhatsApp code is carried by WhatsApp (Meta), which may process it outside Pakistan.

So data about you is processed outside Pakistan. Where required, we rely on appropriate safeguards such as standard contractual clauses or equivalent mechanisms.

11. Automated decision-making

We may use automated systems for ranking feeds, detecting abuse, and similar functions. These systems do not make solely automated decisions with legal or similarly significant effects about you in the GDPR sense without human review where required by law. If that changes, we will update this policy.

12. Changes to this policy

We may update this policy from time to time. We will post the updated version with a new effective date and, where the law requires, provide additional notice (for example in-app or by email). Continued use of the Service after the effective date constitutes acceptance of the updated policy where permitted by law.

Change history

14 October 2026 (opened invite links): Added that opening a vaibli.app/i/<handle> invite link is noted with a salted hash of your IP address and the kind of phone, for 7 days; that a new account from the same network and kind of phone within a day is recorded as probably invited by that person; and that this record is seen only by Vaibli staff, is never shown in the app and sends no notification (§2.13, §4). Why: the app loses the link when someone installs from the store, so almost no invite was being credited, and the policy has to describe this before it is switched on.
5 October 2026 (inviting by phone number): Added that a verified business or official account can invite you to its team by your mobile number; that we keep a keyed fingerprint and the last two digits rather than the number, for up to 14 days; that nobody is told whether the number is on Vaibli or whose it is, and the inviter sees your handle only if you accept; and that we send nothing to the number ourselves (§2.1, §6). Why: this is built and switched off, and the policy has to describe it before it is switched on.
25 September 2026 (private invitations): Replaced "not offered yet" with how private invitations work: what they keep, that the place and note are shown only to people who are in, that only the host sees who replied and guests never see each other, the notifications, reporting and staff access only after a report, and deletion 30 days after the last part or on account deletion (§2.21). Why: invitations are built and switched off, and the policy has to describe them before they are switched on.
25 September 2026 (events from residents): Added that, where we switch it on, a person with a verified phone who belongs to a place can make their own post an event; that it is always posted under their handle, never anonymously; that it must say where it is and is never placed at their home; the limits (2 a week, 3 coming up); that deciding whether you can host uses only your verified phone, your belonging to the place and a count of your own events; and the "this is someone's home" report (§2.6, §2.21). Why: this is built and switched off, and the policy has to describe it before it is switched on.
22 September 2026 (following a place, and a place's own web page): Added following a verified shop or institution: what can never be followed (a person, a place of worship, a political office-bearer, a clinic or anything else marked sensitive); that a follow carries one notification about a new event and nothing else, capped per place, per day and by quiet hours; that a follow is known to you and us alone, that the place is told only a rounded count from 5 upward and never who, and that no one else sees any count; that unfollowing deletes the record and deleting your account deletes all of them; and that a follow goes quiet after 180 days unused. Added the read-only page at vaibli.app/h/<name> and its printable QR poster, which show no phone number, no exact address and nothing about any person, and an institution featuring another host's event, which notifies nobody (§2.6, §2.22, §2.23, §6, §8). Why: the same reason as the events lines below — this is built and switched off, and the policy has to describe it before it is switched on.
21 September 2026 (the one question): Added the single question we may ask once in your feed — how likely you are to tell someone about Vaibli, answered by tapping 0 to 10. Said that it is asked at most once and that closing it counts as an answer we keep so we do not ask again; that the card has no text box, so there is nothing typed to store; what is kept beside the number (app version, phone type, reading language), and that it is tied to your account only so that you are not asked twice; that nobody at Vaibli can see who gave which score and that we can read it only as totals; that our analytics are told a card was shown, answered or closed and are never told the number; and that your answer is deleted with your account (§2.24, §6). Why: this is built and switched off, and the policy has to describe it before it is switched on.
20 September 2026 (events): Added events from verified businesses and official accounts (never places of worship): what an event keeps; that "remind me" is a private save whose reminders are scheduled on your phone; the going count, shown only from 5 people, rounded, and never naming anyone; the random tag on "tell your group" links, used only to count shares, opens and new accounts; link-open counts that hold no IP address, device or account; the host's results, which are totals with a floor of 5 and no names; and that everything is deleted with the event's post (§2.6, §2.21, §6, §8). Said that private invitations are not offered yet. Why: events are built and switched off, and the policy has to describe them before they are switched on.
19 September 2026 (listed masjids): Added masjids that Vaibli lists on the map before anyone from the masjid has joined: what a listing shows (name, address, area and azan times worked out on your phone — never jamaat times, posts or announcements) and that it does not speak for the masjid; that you can tell us you help run a listed masjid, optionally with a phone number and a note, which only Vaibli staff see, which never reaches analytics except as a count, and which is deleted after 90 days or when you take it back; that you can report a listing as wrong, that three people's reports hide it until staff look, and that reports are deleted after a year (§2.18, §6). Why: this is built and switched off, and the policy has to describe it before the switch goes on.
17 September 2026 (telling PESCO): Added the tell PESCO step on a red power outage card and the Board's 118 row: that your bill's reference number and any PESCO ticket number are kept only on your phone and never sent to us; that calling 118, texting 8118 and PITC's complaint site are PESCO's and PITC's own channels, opened through your phone's own dialler, SMS app and browser, under their terms and normal call/SMS charges; and that "I told PESCO" stores a one-way marker that counts one person per power outage, cannot be read back to your account, carries no reference or ticket number, can be taken back while the power cut is on, and is deleted one day after the power cut is over (§2.6, §2.20, §3, §4, §6, §8). Why: the feature is built and switched off, and the policy has to describe it before the switch goes on.
17 September 2026 (masjid announcements): Added masjid announcements (janaza, Eid prayer, gatherings and masjid needs); what a janaza announcement contains, that it needs the family's agreement, and how a family can have one taken down; the opt-in "janaza alerts near me" notification, its audience and limits; that needs are checked before they appear; and retention (§2.5, §2.8, §2.19). Why: these are built and switched off, and the policy has to describe them before any of them is switched on.
17 September 2026 (masjid prayer times and nearby lists): Added masjid prayer times and Ramadan sehri and iftar times, published by the masjid; the announcement a masjid's account can post when a time changes, which never names the person; that azan, sehri, iftar, countdowns and "your area" times are worked out on your phone; the nearby masjids and businesses lists, which use your current location to sort without storing it (a guest's use the place they are viewing); and that your masjid and masjid reminders are saved and scheduled only on your phone and never reach us, with only the fact of a change counted, never which masjid (§2.6, §2.18). Why: these are built and switched off, and the policy has to describe them before any of them is switched on.
16 September 2026 (founder badge and pin): Said what founding a place gives you: an opt-in founder badge reading "founded {place}", off by default and showing the place name only, on the same terms as the founding-member badge; and one pin on that place's Board, which carries your handle only when the badge is on and otherwise names nobody. Added that a pin can be reported like a notice, that two removals end the pin but never the badge, that a pin has no end date and is deleted with your account, and that badge switches are counted without the place (§2.6, §2.16, §2.17, §6, §8). Why: both are now built, and the policy has to describe them before found-your-block or any Board is switched on.
16 September 2026 (place Boards): Added a place's Board: notices from Vaibli or a verified official account, which never show the person who posted them; key contacts that are institutions' published numbers, not residents'; the verified shops inside the place; and the line for what is out now. Said that tapping a contact hands the number to your phone's dialler and that we do not see the call, that we record only the kind of contact tapped, how a notice is reported and how its account is told why one was removed, and that notices are deleted 30 days after they end or are removed (§2.6, §2.17, §3, §6, §8). Why: Boards are built and switched off, and the policy has to describe them before any place's Board is switched on.
16 September 2026 (proposing a place): Added proposing and joining a place where none covers you yet: what we keep (the name and type, who proposed or joined, and an approximate point about 150 m across — never exact coordinates), that only Vaibli staff can see who proposed or joined while other users see the name, type and count, the notification and subscription when the place goes live, the founder record, the 60-day close, and what deleting your account removes. Also described the list of people asking for a place in their area, which proposing or joining adds you to (§2.6, §2.16, §3, §4, §6, §8). Why: the feature is built and switched off, and the policy has to describe it before it is switched on for anyone.
14 September 2026 (WhatsApp codes only): Sign-in and verification codes are now sent on WhatsApp; the app no longer offers to send them by SMS (§2.1). Why: a WhatsApp code works for the people we serve and costs a fraction of an SMS.
14 September 2026 (phone sign-in): Added signing in with your phone number, with the code sent on WhatsApp or by SMS, where your version of the app offers it; the number becomes your sign-in phone, counts as verified, and a number already kept with an account signs you in to that account. Added that asking for a code sets up an account holding only the number, which we delete within about a day if the code is never entered. Named WhatsApp (Meta) as the carrier of WhatsApp codes (§2.1, §5, §6, §10). Why: phone sign-in is being prepared, and the policy has to describe it before the app offers it.
14 September 2026 (verified phone number): When phone verification succeeds, we now keep the confirmed number with your account, so signing in with that number later reaches the same account; it is never shown to anyone. If the number is already on another account we do not move it, and keep a record of the two accounts without the number (§2.1, §3, §6, §8). Why: until now the number was checked and not kept, which meant a person who verified could not be recognised by it later; this is being added before sign-in with a phone number is offered.
14 September 2026 (WhatsApp withdrawn): Removed the section on messaging vaibli on WhatsApp (§2.16) and its lines in §3, §5, §6, §8 and §10. The feature was never switched on, no WhatsApp number was ever connected, and no WhatsApp message or phone number was ever received or stored. Verified resident is unchanged (§2.3). Why: we decided not to build messaging on WhatsApp after all, and the policy should not describe something we do not do.
14 September 2026 (WhatsApp, verified resident): Added messaging vaibli on WhatsApp: what we keep of your number and messages, that only a button tap reports anything, that a tap counts only from a linked account, the alerts you can ask for and how to stop them, Meta as the carrier, and the 7-day, 90-day and 30-day retention windows (§2.16, §3, §5, §6, §8, §10). Added the verified resident way of posting: anonymous in every way, naming only the place, offered to phone-verified people posting inside a place they belong to, and visible to moderators like any anonymous post (§2.3, §8). Why: both are being built, and the policy has to describe them before the WhatsApp number answers anyone or the composer offers the row.
13 September 2026 (founding member badge): We now keep the first day you came to belong to each place, for as long as your account exists, to offer the opt-in founding member badge; the badge is public only if you switch it on, shows only the place name, and is deleted with your account (§2.2, §2.3, §6, §8). Why: the badge is being added to the app, and the policy has to describe it before it ships.
13 September 2026 (outage kinds): Outage reports and alerts now cover water, gas and blocked roads as well as electricity, on the same terms, switched on place by place (§2.14, §2.15, §8). The mute option on the outage card is now worded "mute outage alerts" and covers every kind. An electricity outage may show the power company's published load-management schedule, which uses no personal information (§2.14). Why: these kinds and the schedule line are being added to the app, and the policy has to describe them before they are switched on.
13 September 2026 (update): If you get outage alerts only because you have been in a place, you can now mute that place from the outage card in current versions of the app; older versions still have no per-place mute (§2.15, §8). Why: the mute shipped in app version 1.7.0, which is rolling out in the app stores.
13 September 2026 (effective): This version takes effect on 13 September 2026. Guest reading is described as available where your version of the app offers it (§1, §2.12).
13 September 2026: Guests no longer see any photo or video on an anonymous post (§2.12), and the app no longer attaches a coarse area to its app-open analytics unless you are signed in, so a guest's location plays no part (§2.12). Named Singapore as where our rate-limit store (Upstash) holds its records (§5, §10). Said which legal basis applies to guest reading, public web pages, outage vote checks and analytics linking (§4). Disclosed the day-level record of places you have been in alongside the other location data (§2.2). Added that hosting providers keep short-lived request logs (§2.13, §6), that link-preview copies are made by the recipient's app (§2.13), how guests can exercise their rights (§8), and a note on guest reading under Children (§9). Why: answers to the legal review questions for this release.
12 September 2026 (revision): Salted the guest-mode rate-limit hashes so a device or IP hash can no longer be reversed, and made the server refuse the request rather than fall back to an unsalted hash (§2.12). Added a 90-day purge for cleared or removed outages, their votes and their reports, and made account deletion remove your own outage votes, updates and reports immediately instead of leaving them behind (§2.14, §6). Documented that outage updates can now be posted anonymously, on the same terms as comments (§2.14), and documented the outage web page at vaibli.app/s/<code> (§1, §2.14, §3, §5, §6). Why: these were open questions in the same day's first draft; they were resolved and shipped before legal review, so the policy now describes the fixed behaviour instead of flagging it as open.
12 September 2026: Added reading without an account (§2.12), public share links and web pages (§2.13), outage reports and confirmations (§2.14) and outage alerts (§2.15). Added a note on who can see your posts (§2.3), the new analytics events and the linking of pre-sign-in events (§2.6), Cloudflare and rate-limit storage as service providers (§5), and matching retention, choices and transfer notes (§3, §4, §6, §8, §10). Why: these features ship in the next app release, and the policy has to describe them before they reach users.
2 May 2026: First published.

13. Contact

For privacy questions or requests, contact:

Bircube (Vaibli)
privacy@vaibli.app