Privacy
what we know about you, and what we refuse to.
Effective [EFFECTIVE DATE] · Draft last revised 25 August 2026
Draft. Not in force. This document has not yet been reviewed by a lawyer and nCommunity is not yet open to the public. It describes the system as it is actually built, so that the review has something true to work from. Do not rely on it as a binding statement until the effective date above is filled in and this notice is gone.
The short version
nCommunity exists to get people out of the app and into a room with other people. That is not a slogan for this page. It changes what is worth collecting. A product that made money from your attention would need to know how long it held it. We do not measure that, and the list of things we have written down as forbidden to measure is in section 4.
What we do need is narrow: a way to reach you, roughly where you are so we can show you what is nearby, what you are interested in, and a record of the events you said you would attend and actually attended. Verified attendance is the spine of the product; almost everything else follows from it.
Two things get special handling throughout, because they are the ones that can hurt somebody. Your precise location is never returned to another member, to a host, or to a business. Not coarsened, not delayed; the server measures distance and returns the distance. And anything shown to a business about the people around it is an aggregate with a floor of five distinct people, so a number can never be about one identifiable person.
Who this covers
This policy is issued by [LEGAL ENTITY NAME], of [REGISTERED ADDRESS] (“nCommunity”, “we”). It covers the nCommunity mobile app, this website, and nCommunity Studio, the portal that venues, local businesses, creators and brands sign into.
It covers you whether you are a member looking for something to do, a host putting an event on, or somebody running a venue. Where a rule applies to only one of those, it says so.
For members in the EEA and the UK, nCommunity is the data controller for the processing described here. For members in California, the categories below map onto “personal information” under the CCPA/CPRA; we do not sell personal information and we do not share it for cross-context behavioural advertising.
What we collect
Getting you in the door
An email address, or a phone number, which is how you sign in. We send a one-time code rather than asking you to invent a password. A display name, a handle, and optionally a short bio and a profile photograph. Whether your email or phone has been confirmed, and when.
A date of birth. We need it because some events are age-restricted by law and because the platform is 18+. Once it is set you cannot change it yourself. An age gate you can edit is not an age gate. Correcting a genuine mistake means contacting us.
What you are into
The interest categories you pick during sign-up and change later, any narrower interests under them, and the preferences you set: how far you are willing to travel, what languages you speak, accessibility needs, whether you are comfortable going to things on your own. Some interests are marked sensitive in our taxonomy; those are handled separately and are described in section 7.
Where you are
One point per member: the location you use for discovery, either taken from the device with your permission or set by choosing a place from a list. A coarse label alongside it (“Brooklyn, NY”) which is the only part ever displayed. See section 8, which is the whole story.
What you did
Events you saved, RSVP’d to, joined a waitlist for, or cancelled. Whether you were checked in at the door, by whom, and how late. Reviews and ratings you leave. Communities you join. Connections you make after an event, and the messages you send to people you are connected with.
From these we derive a reliability record: how many places you held and how many you kept. It exists so that hosts holding twenty seats are not repeatedly let down by the same people. It never leaves our servers as a score. You see counts and a plain description; nobody sees a percentage, including you, because “62% reliable” is a label rather than something you can act on. Cancelling early counts exactly the same as attending. The failure we are trying to prevent is the silent no-show, not the change of mind.
Money
When you pay for a ticket or support a host, we never see your card number. Card details are entered directly into Stripe’s own payment sheet. What we store is the brand, the last four digits, the expiry month and year, and an identifier Stripe gives us, enough to tell two cards apart in a list and no more. There is nowhere in our database to put a card number and no route that would accept one.
We also store what you paid, for what, when, and whether it was refunded. If you allow a card to be charged for a waitlist place while you are not there, we store the exact wording of the sentence you agreed to, not merely the fact that you agreed.
Photographs
Profile photographs and event photographs you upload. We remove location metadata from every image before it is stored. Cameras write GPS coordinates into photograph files, and the picker’s own resize does not remove them. We checked, by uploading through the real flow and reading the file back out. Our own code rebuilds the file’s metadata and keeps only the orientation flag, which has to survive or the picture arrives sideways.
Devices and sessions
For each device you are signed in on: a label the app knows (“iPhone 17 Pro”), the operating system and app version, when the session started, and the IP address it was created from. This exists for one reason: so that somebody who thinks their account has been got at can see what is signed in as them and end it. The IP address is shown to you in full, because it is the field most likely to tell you “that was not me”.
Safety and enforcement
Reports you make, reports made about you, blocks, and any enforcement action taken on your account together with the reason for it. Private safety feedback left after an event is stored where no client application can read it at all. It is readable only by our safety team through direct database access.
Product analytics
A small, fixed set of named events: signed up, completed onboarding, viewed an event, RSVP’d, checked in, reviewed, created an event. The full list is a single file in our source tree rather than a general-purpose tracker, which means adding a new measurement is a deliberate change somebody has to make and review.
What we deliberately do not collect
These are not oversights, and they are not promises we intend to quietly retire. Each one is written into the product as a rule that something in our test suite enforces.
No engagement metrics. We do not measure time in app, session length, scroll depth, or video watch time. Those five names are listed in our source as forbidden metrics, so adding one means deleting a line that says not to.
No follower counts, anywhere. Not on profiles, not on hosts, not in search. A host’s credibility is their rating, their reviews, how many events they have run and how long they have been hosting.
No read receipts, no typing indicators, no last-seen. Nothing that pressures a reply. Whether you have read a message is private to you.
We do not read your calendar or your contacts. Adding an event to your calendar hands it to your operating system, which asks you to confirm what gets written. We do not request contacts access at all, on either platform.
No impression counts. Hosts are told how many people opened their event, never how many it was shown to. Counting impressions is the first step towards optimising for them.
No shadow profiles. We do not build records about people who are not members, and we do not buy personal data about our members from anybody.
What we use it for
- To show you what is on near you. Ranked on four things: how well it matches your interests, how far it is, how soon it is, and the host’s reputation, which is itself derived from verified attendance. None of those four is a measure of your behaviour in the app.
- To let you hold a place and pay for it, and to pay hosts what they are owed afterwards.
- To verify that you were actually there, which is what makes reviews and host reputation mean anything.
- To keep people safe: to act on reports, to enforce our rules, to make blocking work, and to prevent fraud at the door.
- To tell you things you asked to be told: that an event you are going to has moved, been repriced or been cancelled.
- To tell venues and businesses, in aggregate, what the area around them wants and whether people came through their door. Always as numbers, never as a list of people. See section 8.
- To meet our legal obligations, including tax and accounting.
Where we rely on legitimate interests (safety, fraud prevention, making the service work), we have weighed that against your interests and you can object. See section 10. Where we rely on consent (device location, notifications, storing a card to be charged when you are not present), you can withdraw it, and the product is built to keep working without it.
What other members can see
Your profile shows your display name, handle, photograph, bio, your non-sensitive interests. If you host, it also shows your rating, review count, events hosted and how long you have been hosting.
Your profile deliberately does not show your date of birth, your location, or what you are going to. Who can see that you are attending a particular event is controlled per event by the host’s attendee-visibility setting and enforced on the server, and a profile that listed your plans would be a way around a setting you already made.
A sensitive interest never appears on your profile, whatever your visibility settings say. Setting a control is not informed consent to being labelled in public with a category that could put you at risk. Sensitive interests still count towards the broader category they sit under, so they keep working for recommendations without naming you.
Going solo is only ever an aggregate. An event can say six people are coming on their own. It never says who.
If you hide a host, a venue, a community or an interest from your recommendations, the party you hid can never learn that it happened. There is no count, no aggregate and no reverse lookup. That is deliberate, because a host who could see how many people had hidden them would be reading a number about individuals who chose it precisely because it was not a public act. It is not a report, nothing is sent to a moderator, and hiding somebody does not affect them in any way.
Location, in detail
This is the most sensitive thing we hold, so here is exactly what happens to it.
We store one point per member: the place you search from. You can set it by letting the app read your device location once, or by picking a place from a list. The product works either way, and refusing the permission costs you nothing but precision.
That point is never returned by any interface a member, host or business can call. When a distance is shown (“1.1 mi” on an event card), the server calculates it and returns the number. The coordinate stays in the database. The same is true of the coarse label: “Brooklyn, NY” can be displayed, the point cannot.
When a business asks what the area around it is interested in, the answer is counts of interests within a radius, and nothing else. The shape of that answer cannot carry a coordinate or a person’s identity, and it is subject to a floor of five distinct people. Below that, nothing is returned at all. A business can raise that floor and cannot lower it. Sensitive interests are excluded from it at any count.
The same floor of five applies to the aggregate signals we produce about unmet demand: searches that found nothing, interests with no supply nearby. Below five distinct people it stops being a market signal and becomes a report on one identifiable person, which is the entire reason the floor exists.
We do not track you in the background. We do not build a location history. There is one row per member and it is overwritten when you change it.
How long we keep it
While your account is open, we keep what is described above so the product works. When you close it, we delete or irreversibly anonymise your personal information, with four exceptions:
- Financial records. Payments, refunds and payouts are kept for as long as tax and accounting law requires, generally seven years.
- Safety records. Reports, enforcement actions and the evidence behind them are kept so that somebody who was removed for harming another member cannot erase the record by deleting an account and opening a new one.
- Reported messages. When a message is reported, its contents are snapshotted at that moment. Deleting the message afterwards does not erase evidence already captured, and reported messages are excluded from any bulk deletion.
- Attendance records held by other people. A review you wrote and an event you attended are also facts about the host and the venue. Those are retained in a form that no longer identifies you.
Messages
Messages persist by default. There is no timer. We decided against automatic expiry deliberately: a conversation that quietly disappears is one you cannot show anybody if the person in it starts behaving badly. You can delete a message yourself, which empties it for both people. A bulk-deletion tool exists but is not scheduled and cannot be run for anything under thirty days old.
Your rights, and how to use them
Depending on where you live you have some or all of these rights: to know what we hold, to get a copy, to correct it, to delete it, to object to or restrict certain processing, to withdraw consent, and to take your data elsewhere. In California you also have the right not to be discriminated against for exercising them. Since exercising them costs us nothing, we do not.
Some of these you can exercise in the app right now: your profile, interests, preferences, radius, notification settings and blocked accounts are all editable, you can see and end every signed-in session, and you can see every enforcement action on your account with the reason for it and appeal it once.
What is not yet a button. There is no self-serve “delete my account” control in the app today, and no automated data export. Both are handled by writing to [PRIVACY EMAIL], and we will complete a request within 30 days. We would rather say this plainly than describe a control that is not there. Building both is on the list before launch.
Correcting your date of birth is also a support request, for the reason given in section 3: an age gate you can edit yourself is not an age gate.
We may ask you to confirm you are who you say you are before acting on a request, because acting on a forged deletion request is itself a privacy failure. If you are in the EEA or the UK and you think we have got this wrong, you can complain to your national data protection authority; we would appreciate the chance to fix it first.
Age
nCommunity is for adults. You must be 18 or over to hold an account, and we ask for a date of birth at sign-up to enforce that as well as the age limits on individual events, some of which are set by law rather than by the host.
We do not knowingly collect information from anybody under 18. If you believe a minor has an account, write to [PRIVACY EMAIL] and we will remove it and the data with it.
Security
The design principle is that the client is never trusted with anything it could profit by lying about. Browsing events happens directly against the database under row-level security. Anything that matters (holding a place under capacity, taking a payment, marking somebody as having attended, issuing an enforcement action) goes through our server, which holds the only credentials that can do it.
- Every table denies access by default and grants it back explicitly.
- The mobile app holds no privileged secret. Neither does Studio. Our build fails if one appears in what gets shipped to a browser.
- Check-in codes are tied to a single event, expire quickly, are validated on the server and cannot be replayed. We test that by actually replaying one.
- Columns that hold a venue’s emergency and booking contacts are revoked at the column level, not merely omitted from a query.
- Automated systems may flag things for review. No automated system bans anybody, issues a refund, or moves money. Every enforcement action records which person took it.
No system is perfectly secure and we will not claim otherwise. If you find a vulnerability, please tell us at [SECURITY EMAIL] before telling anybody else, and we will not pursue you for having looked.
If a breach affects you and creates a real risk, we will tell you and the relevant regulator within the time the law allows, and we will say what actually happened rather than that we “take your privacy seriously”.
Where the data lives
Our database and our servers are in the United States (AWS us-east-1 and
equivalent). If you are in the EEA or the UK, using nCommunity means your information
is transferred there. Where those transfers require a safeguard, we rely on the
European Commission’s Standard Contractual Clauses and the UK Addendum with our
providers.
Changes
We will post any new version here with a new effective date. If a change materially reduces your privacy (a new category of data, a new purpose, a new recipient), we will tell you in the app or by email before it takes effect, not afterwards.
We will keep the previous version available so you can see what changed rather than having to take our word for it.
Contact
Privacy questions and requests: [PRIVACY EMAIL]
Security reports: [SECURITY EMAIL]
Post: [LEGAL ENTITY NAME],
[REGISTERED ADDRESS]
Our terms of service are at nCommunity terms.