Okani — Privacy Policy

Effective date: August 30, 2026

This English version is a master text. A French translation is produced from it. In France, the French version is the authoritative version. Where the two differ, the French text prevails for users in France.

This policy explains what personal data Okani collects, why, on what legal basis, how long it is kept, and the rights you have. It is written to comply with the EU General Data Protection Regulation (GDPR), the French loi Informatique et Libertés, and the German Bundesdatenschutzgesetz (BDSG).

1. Who is responsible for your data (data controller)

The data controller is:

Xav Harrigin-Ramoutar Contact: privacy@okani.io Service: Okani (okani.io)

At launch, Xav Harrigin-Ramoutar is an individual acting as controller. If a company is later formed to operate Okani, that company will become the controller and this policy will be updated with its name and registered address. Your rights and the way your data is handled will not change because of this.

We have not appointed a Data Protection Officer, because we are not legally required to. You can contact us about any privacy question at privacy@okani.io.

2. Who can use Okani

Okani is only for people aged 16 or older. At sign-up you must confirm you are 16 or older.

We set the minimum age at 16 so that we do not need to collect parental consent. Under GDPR Article 8, the digital-consent age is 15 in France and 16 in Germany. A floor of 16 covers both countries. If we learn that an account belongs to someone under 16, we will delete it.

3. What data we collect and why

We only collect what we need to run the service. Below, each category lists the purpose and the legal basis under GDPR Article 6.

3.1 Account data

• Data: email address, display name, the timestamps recording that you accepted this Privacy Policy and the Terms of Service (privacy_accepted_at, tos_accepted_at), and the record that you confirmed being 16 or older, with its timestamp (age_confirmed, age_confirmed_at).
• Purpose: to create and secure your account, log you in, and prove that consent was given and that you confirmed meeting the minimum age (section 2).
• Legal basis: performance of a contract (Article 6(1)(b)) — we cannot provide the service without an account. The consent timestamps and the age-confirmation record are kept to meet our legal accountability duty (Article 6(1)(c) / Article 7(1) / Article 8).

3.2 Profile photo (avatar) and group photo

• Data: an optional photo you choose to upload.
• Purpose: to display your avatar to other members of your groups.
• Legal basis: consent (Article 6(1)(a)) — it is optional; you can add or remove it at any time.

Group photo. Data: an optional picture a group's admin uploads for the group. A group's admins can set a picture for the group, shown to the group's members wherever the group appears in the app. Unlike your profile photo, a group photo belongs to the group, not to the admin who uploaded it: it stays when that admin leaves the group or deletes their account, it is replaced or removed when an admin changes it, and it is deleted with the group (Sections 7 and 8). If you set a group photo that shows people, make sure you are entitled to share it with the group (Terms of Service, Section 5). Legal basis: performance of a contract (Article 6(1)(b)) — a group's picture is part of the group feature, like its name.

3.3 Group, event, and RSVP data

• Data: the groups you create or join, your role in each group (member or admin), the city attached to each group (Paris or Berlin — chosen by hand by the group's admin, at creation and changeable later in the group's settings; it is a label for the group, never taken from GPS or from anyone's location, and is used to show the group local vendors, Section 11), events you create (their title, description, date and time, location, and an optional cover photo the event's creator can set, which is shown to the same people as the event's other details), and your RSVPs. An RSVP can optionally include your planned arrival time (arrival_time — for example "around 19:30"), a short arrival note (arrival_note — free text of up to 200 characters, for example "I'm bringing dessert"), and a check-in you make by tapping "I'm here!" during the event, which records the date and time you were present (checked_in_at). All three are optional and user-initiated — an RSVP works without them, and you add each yourself; because the check-in is physical-presence information, we only record it at the moment you tap it. They are visible to exactly the people who can see your RSVP: the group members who can see the event, and — for an event shared by link (Section 10.1) — any guest the host has approved. The arrival note is free text that those people will read: please do not put other people's information, or anything sensitive, in it.
• Purpose: to let you plan events with your private groups — the core function of the app.
• Legal basis: performance of a contract (Article 6(1)(b)). This covers your RSVP together with its optional arrival-time, arrival-note and check-in fields: when you choose to use them, recording them and showing them to the other people at your event is what makes the coordination feature you asked for work. They are ordinary personal data, not a special category under Article 9.

Requesting to join a group. Groups are join-by-approval: when you use a group's invite (a QR code or invite link a member shows or sends you), you send that group a join request, and a group admin decides whether to approve it. While your request is pending, the group's admins can see your profile — your display name, your profile photo, and any optional profile details you have added (such as your "about" text and interests) — so they can decide. This visibility starts when you send the request and ends as soon as it is decided or you cancel it; other members of the group do not see your request, and you see nothing of the group until you are approved. We keep the request itself (group_join_requests) only while it is pending — approving, declining, or cancelling it deletes the record (an approval creates your membership instead) — and requests are subject to the anti-abuse limits in Section 3.10. A short notice that you requested to join, visible only to the group's admins, remains in the group's history and is deleted with your account. Legal basis: performance of a contract (Article 6(1)(b)) for making and processing your request, and legitimate interest (Article 6(1)(f)) for letting a group's admins see who is asking to join before letting them in.

Sharing an event by link. As the creator of an event, you can generate a private share link for it and forward it to people you choose. Anyone who holds that link — including people who have no Okani account and are not in your group — can see that event's title, date and time (for a repeating event, the date and time of its next occurrence), and location — plus, once the event has ended, the number of photos added to it in the app (a number only, never the photos themselves, and never who added them) — and nothing else (no host name, no description, no attendee list). See Section 10.1 for how this works and what is and is not disclosed.

Legal basis for the disclosure: legitimate interest (Article 6(1)(f)) — providing an invitation feature that lets you share an event you created, the same way you would forward a calendar invite. The disclosure is deliberately minimal (three fields plus, after the event, a photo count — no identities), happens only when you choose to generate and send a link, and stops when the link is deactivated (Sections 7 and 10.1). Because you decide what an event's title and location say, you are responsible for the link and for only sharing events you are entitled to share (see the Terms of Service).

Replying from the share page ("guest reply"). Someone who opens a share link can answer the invitation directly on the web page — "I'll be there", "Maybe", or "Can't make it" — by typing a first name only. No account is created, and no email address or phone number is asked for or accepted. We store just that first name, the answer, and the time of the reply, and show them — marked as a guest reply — to the event's host and to the people who can see the event in the app. Replies are protected by a Cloudflare Turnstile anti-bot check (Section 5) and by rate limits (Section 3.10), and are deleted automatically no later than 30 days after the event ends (Section 7). The host can remove any reply (by tapping it in the app). A reply can be changed by submitting the same first name again — replies are tied to the first name typed, not to a verified identity, so anyone holding the link could alter a listed name's reply; if that happens, the host can simply remove it. A person who replied can also ask the host to remove their reply, or ask us to delete it (Section 16). Legal basis for guest replies: legitimate interest (Article 6(1)(f)) — carrying an invitee's answer back to the host is the purpose of an invitation; the reply is initiated by the guest, and the data is minimal — a first name the guest chooses, which need not identify them.

Requesting access to a shared event as a guest. When you open an event share link (above), you can ask the event's host to let you take part as a guest, without joining any group. The host — the person who created the event — decides whether to approve or decline your request. While your request is pending, the host sees it together with your display name and profile photo, so they can decide. If you are approved, you can see everything a group member sees about that event: its title, description, date and time, location and map preview, cover photo, and the host's display name; its list of participants — the display names and profile photos of the members who have replied and of the other approved guests — together with each person's reply and any planned arrival time, arrival note, and check-in they have added (above); and the photos added to the event with their captions (Section 3.4). You can RSVP for that event only, with the same optional fields, and in return your display name, profile photo, reply, and those optional fields are visible to the same participants. You still do not join the group or see any of its other content — not its other events, its members, its discussion, or its photos. If your request is declined, you are simply not added. We keep a record of your request and the host's decision (event_guests) so the feature can work; it is deleted when you delete your account or when the event is deleted, and requests are subject to the anti-abuse limits in Section 3.10. Legal basis: performance of a contract (Article 6(1)(b)) for your own participation in the event, and legitimate interest (Article 6(1)(f)) for letting a host see and decide on the people asking to join their event.

Event location on a map. When you save an event with a location, the app asks your device's built-in map service — Apple Maps on iPhone, Google Maps on Android — to turn the venue text you typed into map coordinates ("geocoding"), and stores those coordinates (latitude/longitude) with the event so that everyone who can see the event also sees a small map preview. Three disclosures happen, and we name them precisely: (1) at the moment you save, the venue text is sent to Apple or Google to be geocoded; (2) when someone opens the event, their device fetches the map image from Apple Maps (on iOS) or Google Maps (on Android), which technically discloses their IP address and the event's coordinates to that provider — this is true for every viewer of the event, not just its creator; (3) if you tap the location or the map, the maps app or website you choose receives the location to display. This feature never uses your device's GPS. Coordinates are always derived from the venue text the host typed; Okani never asks for, records, or has access to your physical position (the optional check-in above records only a date and time, not a place). Guests opening an event share link (Section 10.1) see the location text only — the stored coordinates are never returned to them. Coordinates are visible to exactly the same people as the location text, are included in your data export, and are deleted with the event.

Legal basis: performance of a contract (Article 6(1)(b)) for storing and displaying the map preview; legitimate interest (Article 6(1)(f)) for the technical requests to the platform's map service, which acts as an independent controller under its own privacy policy (Section 5).

3.4 Uploaded media (photos, videos and files)

• Data: photos, videos and media you upload and share within a group. A video you share is stored together with a still frame taken from its start (the preview shown before it plays), which is visible to the same people as the video and is deleted with it.
• Purpose: to share event photos with the members of that group.
• Legal basis: performance of a contract (Article 6(1)(b)) for delivering the sharing feature. You control what you upload. See Section 8 for how media is deleted.

Your photos and videos are visible only inside Okani, to members of the groups you share them with — or, for photos added to an event, to the people that event is shared with (see "Photos added to an event" below). No feature shows them to anyone beyond those audiences. The people in those audiences can, however, keep a copy — see "Photos and files can be saved outside Okani" below.

Captions. When you share photos in a group you can add a short caption (up to 1,000 characters); it is posted with the photos in the group's discussion and is visible to exactly the same members as the photos, and deleted with them. Captions on photos added to an event are described below.

Files (documents) you attach to a group discussion. You can attach a document to a group discussion — a menu, a ticket, an itinerary, a spreadsheet. This is a different kind of content from a photo, so it is described separately here.

• Data: the file itself, plus its original filename, its file type and its size. We store the filename you chose because it is how you and the other members recognise the file. Please keep in mind that a filename can itself reveal something (for example "medical results 2026.pdf") — rename a file before attaching it if that matters to you. The same care applies to what is inside a document: please do not attach files containing other people's sensitive information — identity documents, medical or financial records — without their agreement.
• Which types: only these — PDF, Word, Excel and PowerPoint documents, plain text, and CSV. Other file types are refused when you try to attach them.
• Purpose: to let group members share the practical documents an outing needs.
• Legal basis: performance of a contract (Article 6(1)(b)).
• Who can see it: the members of the group you attached it to, and only them. Files appear in the group discussion only — never on an event's public share page, and never on the web.

Important — photos, videos and files can be saved outside Okani. Anyone who can see a photo or video can save it to their own device's photo library or send it to another app on their phone (for example a messaging or email app), and a file you attach can be opened in another app on the phone, or saved to the phone's own storage, by any member of that group. (Voice messages have no save option.) Once someone has saved a copy, that copy is outside Okani and outside our control: deleting a photo, video or file in Okani removes it from the app and from our servers, but it cannot remove a copy someone already saved. Only share a photo or video, or attach a document, if you are comfortable with everyone who can see it being able to keep a copy of it.

Photos added to an event. Photos can be added directly to an event (as opposed to a group's media tab). Photos added to an event are visible to everyone who has access to that event: the members of every group the event is shared with, and any individual guests the organizer has approved via the event's invite link. The app tells you this before you confirm the upload. A photo added to an event can carry a short caption you write (up to 300 characters); the caption is visible to exactly the same people as the photo and is deleted with it. If the organizer later shares the event with another group or approves another guest, they can also see the event's photos — the audience is the event's guest list, and it can change with the event. Equally, anyone removed from the event (a group it is no longer shared with, or a guest who is removed) loses access to its photos. Nothing about this feature shows the photos to anyone without access to the event (the public event link never shows photos — though once the event has ended, its share page shows how many photos the event has, never the photos or who added them; Section 10.1) — but, as with any photo, everyone in the event's audience can save a copy to their own device (see above).

Legal basis for photos added to an event: performance of a contract (Article 6(1)(b)) — showing the photos you attach to an event to the people the event is shared with is the coordination feature itself, exactly as with the event's other details (Section 3.3). You choose the audience by adding photos to the event rather than to a single group; removing your photo, or deleting your account, removes it for the entire audience (Section 8). The event organizer and the admins of groups the event is shared with can also remove any photo from the event (content moderation, Section 10). Photos you add to an event stay with the event until one of those people removes them, until the event is deleted, or until you delete your account — leaving or being removed from the event does not remove the photos you added (Section 7).

3.5 Discussion posts

• Data: messages you post in a group discussion.
• Purpose: to let group members communicate about events.
• Legal basis: performance of a contract (Article 6(1)(b)).

Replying to a message. You can reply to a specific message in a group discussion. Your reply stores a link to the message you answered (reply_to_id) and shows a short quote of it above your reply, visible to exactly the same members as the reply itself. If the quoted message is later deleted, the quote and the link disappear; your reply stays. Legal basis: performance of a contract (Article 6(1)(b)).

Mentioning someone. In a group discussion you can tag another member of that group by typing @ and picking their name. We store, with your message, who you tagged (the tagged member, the message, and the group — up to 20 members per message; only current members of that group can be tagged). Your message shows the tagged name in bold to the same members who can see the message itself; a member you tag sees nothing more than any other member of the group. A member you tag who has push notifications turned on (Section 3.8) receives the usual discussion notification, worded "Name mentioned you: …" followed by the first 140 characters of your message — unless they have turned message previews off (Section 3.8), in which case it reads "Name mentioned you" only. If they have chosen the "Mentions & replies only" setting, tagging them — like replying to one of their messages — is what lets that notification through; a tag never overrides a notification category they have switched off, notifications they have paused, or a group they have muted. A tag lives with the message: it is deleted when the message is deleted, when the group is deleted, or when your account or the tagged member's account is deleted (Sections 7 and 8), and it cannot be edited or removed separately. Leaving the group does not remove tags of you in messages already posted there. Messages in which you were tagged are listed in your data export (Section 9). Legal basis: performance of a contract (Article 6(1)(b)).

Reacting to a message. You can react to a discussion message — a text message, a GIF, or a photo — or to a private message (Section 3.5 bis) with one emoji from a fixed list we provide: a quick row of five, plus a larger picker. For a few hand gestures (such as 👍 or 🙏) you can pick a skin tone. We store which message you reacted to, the emoji you chose (including any skin tone), and when. A skin tone is an expressive choice, like the emoji itself: we do not treat it as information about your origin, we draw no conclusions from it, and we show others only the exact emoji you picked. If you set a preferred skin tone, the app remembers it on your device only — it is not stored on our servers or linked to your account. Your reaction is visible, with your name, to the same members who can see the message itself: the reaction counter under a message shows the emoji and how many, and tapping it shows who reacted with what. You can change your reaction by picking a different emoji, or remove it by tapping your current emoji again — removing it deletes it from our servers immediately. A reaction is also deleted when the message it is attached to is deleted, when the group is deleted, or when your account is deleted (Section 8). Legal basis: performance of a contract (Article 6(1)(b)).

Forwarding a message. A member who can read a text or GIF message in one of their groups can forward it into another group they also belong to. The forwarded copy is a new message, posted in the forwarder's name, without your name attached — it does not show who originally wrote it or which group it came from. Like a saved photo (Section 3.4), a message you post can therefore travel: only write in a group what you are comfortable with its members repeating elsewhere in Okani. A forwarded copy belongs to the person who forwarded it: deleting your original message, or your account, does not remove copies other members have already forwarded. Those copies are deleted when the forwarder deletes them, when the forwarder's account is deleted, or when the group they were forwarded into is deleted (Section 7). Legal basis: performance of a contract (Article 6(1)(b)) — carrying and displaying the forwarded message for the member who sends it, like any other discussion post.

3.5 bis Direct messages

Some people you share a group or an event with can send you a private one-to-one message ("direct message"). This is separate from group discussion posts (Section 3.5): a direct message is between you and one other person only.

• Data:
• the content of the private messages you send and receive (dm_messages) — text, voice messages, photos, videos (each stored with a still frame taken from its start) and animated GIFs (Section 3.5 ter); a photo or video you send is visible only to the two of you, and can be saved or shared outside Okani by either of you, exactly as described in Section 3.4 — and — when you reply to a specific message — the link between your reply and that message (reply_to_id), which shows a short quote of it above your reply. If the quoted message is later deleted, the quote and the link disappear; your reply stays;
• your emoji reactions on private messages (dm_message_reactions): which message you reacted to, the emoji you chose, and when. A reaction works exactly as in group discussions (Section 3.5, "Reacting to a message"), except that the only person who can see it is the other person in the conversation. You can change or remove it at any time; removing it deletes it from our servers immediately, and it is also deleted when the message it is attached to is deleted or when either account is deleted;
• a read status — the time you last opened a conversation and how far your app has received its messages (dm_thread_reads). It shows you which conversations have new messages, and — unless you turn read receipts off — it shows the other person a tick mark under their message: one tick when sent, two once your app has received it, and two in colour once you have opened the conversation. See "Read receipts" below;
• the people you block (dm_blocks) and any abuse report you file about a message or a person (dm_reports).
• Purpose: to deliver private messaging, to let you stop unwanted contact by blocking, and to let us review reports and keep the service safe.
• Legal basis:
• Message content, replies, reactions and read status: performance of a contract (Article 6(1)(b)) — we cannot carry a message between two people, or show you your unread conversations, without storing this. We do not read your private messages, and the app gives us no way to browse them; the only time we see a message's content is when you or the other person reports it for abuse, and then only to review that report.
• Blocks and abuse reports: legitimate interest (Article 6(1)(f)) — protecting users from abuse and harassment. Balanced against your privacy: a block records only who blocked whom and when; a report keeps a limited snapshot of the reported message and a record of who was reported, so we can review it fairly even if that message is later deleted. You can object (Section 9); where you do, we will stop unless we have overriding safety grounds to keep a report.

Who can send you a direct message. Only people you already share a group with, or — if you turn it on — people you share an event with, can start a conversation with you. A setting in your profile (allow_dms_outside_groups) controls the event case; it is off unless you turn it on, and you can change it at any time. Blocking someone stops messages in both directions.

Read receipts. By default, the other person in a conversation can see whether their message has reached your app and whether you have opened the conversation since — two timestamps, shown only as tick marks under their own messages. They see only that you opened the conversation after a message arrived — not whether you actually looked at that message, how long you spent, or anything else. The setting is mutual: a switch in Settings → Privacy (dm_prefs.read_receipts, on unless you turn it off; we do not publish the setting itself, though someone you message can of course notice that the tick marks are absent) hides your read status from everyone and, in return, hides theirs from you. Blocking someone hides read status in both directions as well. Turning the switch off takes effect immediately on our servers, for every conversation. Only what happens while the switch is on is ever shown: a conversation you opened while it was off, or before read receipts existed, is never revealed later by turning it back on. Legal basis: performance of a contract (Article 6(1)(b)) — delivery and read indicators are part of the direct-messaging feature described in the Terms of Service, shown to both people alike and limited to two timestamps per conversation; the switch is a setting of that feature, and turning it off does not affect anything else in the app.

3.5 ter Animated images (GIFs)

The group discussion and direct messages (Section 3.5 bis) include a GIF picker powered by GIPHY (a service of Giphy, Inc., a Shutterstock company, in the United States). Two things happen, and we name them precisely:

1. When you search for a GIF, the word you type (and your app's display language) is sent to GIPHY to fetch matching GIFs. This request goes through our server, not directly from your device — so GIPHY receives your search word only, and never your IP address, your device, or any identifier. Your device only ever talks to Okani. Opening the picker before you type anything shows trending GIFs; that request is also made by our server and contains nothing about you at all. To avoid asking GIPHY the same thing twice, our server keeps recent search words and the results they returned for up to 30 days. That cache is stored without any link to an account — no user id, nothing that connects a search to you — and it is used only to answer a repeated search without contacting GIPHY again. 2. When a GIF is shown in a discussion or a private message — whether you sent it or someone else did — your device loads the GIF image directly from GIPHY's servers. As with any app that displays an image hosted by a third party, this discloses your IP address and the GIF's address to GIPHY, and it is true for everyone who sees the GIF, not only the person who sent it.

A GIF you post becomes a discussion post (Section 3.5) or a private message (Section 3.5 bis); we store only its GIPHY web address and pixel size — never the image itself.

• Legal basis: legitimate interest (Article 6(1)(f)) — offering a familiar, expressive way to react in a conversation. Balanced against your privacy: your searches are relayed by us so your identity and IP stay with us; the only unavoidable disclosure is the IP address that any device reveals when it loads an image from the web. GIPHY acts as an independent controller under its own privacy policy (Section 5), exactly like the map providers. You can object to this processing (Section 9). You can also simply not use the GIF picker — though, like any image in a conversation, a GIF that someone else has posted will still load from GIPHY when you view that discussion.

3.6 Vendor pins and vendor interactions

• Data: vendors you pin to an event, and a log of your taps on vendor listings (which vendor, which screen the tap came from, and when). This is stored in vendor_interactions.
• Purpose: to power the local-vendor discovery feature and to suggest relevant vendors for your events. We also use aggregated, non-identifying counts to understand which vendors are useful.
• Legal basis: legitimate interest (Article 6(1)(f)) — improving vendor suggestions and measuring the feature. Our interest is balanced against your privacy: the log records only your user id, a vendor id, an optional event id, and a screen name; it never records message content, and it is not readable inside the app. These records stay linked to your account for at most 90 days; after that they are irreversibly anonymised (see Section 7). You can object to this processing at any time (Section 9).

3.7 Device locale

• Data: your device language/region setting.
• Purpose: to show the app in the right language. (Local vendors are selected by the group's city — Section 3.3 — not by your device setting.)
• Legal basis: legitimate interest (Article 6(1)(f)) — providing a localised experience.

3.8 Push notifications

• Data: a device push token issued by Expo's push service for your device, and — each time we send you a notification — the notification itself: the name of the group or of the person it is about and the kind of content (for example "Léa sent a photo", "3 new messages", or an event cancellation with the event's title) and, for a plain text message in a group or a direct message, the first 140 characters of that message (for example "Léa: see you at 8?" or "Léa mentioned you: …") — unless you turn message previews off in Settings → Notifications ("Show message text"), in which case the notification names only who wrote and never what; a caption, a filename, or the content of a photo, video, voice message or file is never included either way — plus the number of your conversations with unread messages, a single integer used only to set the badge number on the app icon.
• Purpose: to send you notifications about your groups, events, and direct messages, if you turn notifications on.
• How it travels: our server sends each notification to Expo's push service (Expo, Inc., USA — Sections 5 and 6), which passes it to Apple's or Google's notification service for your device. Expo and Apple or Google therefore handle the push token, the notification text, and the badge number. The unread count is computed on our server from your own read status and is shown to no one but you.
• Legal basis: consent (Article 6(1)(a)). Push notifications are opt-in. You turn them on yourself, and you can turn them off at any time in your device settings or in the app. Notifications are never a condition of using Okani. Message previews (above) are shown by default once notifications are on; the "Show message text" switch turns them off at any time without turning notifications off.

3.9 Device calendar export (added before public launch)

• Data: when you choose to add an event to your device calendar, Okani writes that event into your calendar using the calendar permission you grant.
• Purpose: to let you save an event to your own calendar.
• Legal basis: consent (Article 6(1)(a)) — you trigger the export and grant the OS calendar permission. Okani does not read your existing calendar entries; it only writes the event you asked to add.

3.10 Security and abuse-prevention data

• Data:
• A pseudonymous security audit log (audit_log) recording sensitive actions — account deletion, data export, admin grants, member removals, invite rotations — as user ids, an action name, a group id, and a timestamp. It contains no message content and no email addresses.
• Pseudonymous rate-limit logs recording only a user id and a timestamp when you post a message, send a direct message, redeem an invite, request access to a shared event, or upload a photo, video, voice message, or file — used to enforce anti-abuse rate limits. For uploads, the log also records the size of the file in bytes (nothing about its content or name), so that each account's daily upload allowance — a maximum number of files and a maximum total size per 24 hours (Section 12) — can be enforced. These logs contain no message content, and (unlike the posts, messages, or files themselves) they survive deletion of that content so the limits cannot be bypassed; the message, direct-message, and upload logs are kept for 7 days (Section 7). When someone replies to an event from its share page (Section 3.3) — where there is no account — the equivalent log records a one-way code derived from the sender's IP address instead of a user id, plus a timestamp; these entries are kept for at most 2 days.
• Anti-bot check at sign-up, sign-in, and password reset, and on the event share page's reply form, via Cloudflare Turnstile (see Section 5).
• IP address and browser/device user-agent, seen transiently by our infrastructure providers when your app talks to our servers.
• Purpose: to keep accounts secure, prevent fraud and abuse, and meet our security accountability duties.
• Legal basis: legitimate interest (Article 6(1)(f)) and legal obligation (Article 6(1)(c)) for security record-keeping.

Reporting content for abuse. You can report content that is not a private message — a message in a group discussion, a photo, video or file shared in a group, a photo added to an event, or a person's profile — by holding the message, by opening the photo or video in the viewer, or from the person's profile screen, and choosing to report it. This is the same kind of record as a direct-message report (Section 3.5 bis), kept separately (content_reports).

• Data: that you filed the report, what kind of thing you reported and which one, an optional reason you type (free text, up to 500 characters), the time, and a snapshot of the reported content, taken by our server at the moment you report it — for a message, its text; for a photo or file, a pointer to the stored file together with its caption and its filename; for a profile, the display name, the "about" text and the avatar. The snapshot is written by our server and not by your app, so it cannot be forged, and the reported person cannot destroy it by deleting the content afterwards. Reporting something does not remove it: the content stays where it is unless we, or a group's admins, take it down. Where a report points at a stored photo or file, we hold that file back from deletion while the report is open, so that we can still review it if it is removed from the app in the meantime. One exception: if the person you reported deletes their account, their files are erased with it — their right to erasure comes first — and only the report's description of what was reported remains.
• Who can see it: only us, to review the report. The app gives no one a way to read reports back — not even the person who filed them. The reported person is not told who reported them. Filing a report also adds a line to the security audit log described above, recording that a report was filed, and we receive an hourly count of new reports (a number only — no content and no identities).
• Limits: you can file at most 5 reports per hour, you can only report something you can currently see, and you cannot report your own content.
• Your data export: the reports you filed are included in your export (what you reported, the reason, and when — not the snapshot, which is the other person's data). Reports about you are not included, so that the person who reported you cannot be identified.
• Purpose: to let you flag content that breaks our rules, and to let us review it and act on it (Terms of Service, Section 7).
• Legal basis: legitimate interest (Article 6(1)(f)) — protecting users from abuse and keeping the service safe. This is the same purpose and the same basis as for direct-message reports (Section 3.5 bis), applied to the rest of the app's content. Balanced against your privacy: the snapshot is limited to the item reported, it is never readable inside the app, and it is deleted on the schedule in Section 7. You can object (Section 9); where you do, we will stop unless we have overriding safety grounds to keep a report.

3.11 Crash reports

• Data: technical error reports when the app crashes.
• Purpose: to find and fix bugs.
• Legal basis: legitimate interest (Article 6(1)(f)).
• We use Sentry for this. Before a crash report leaves your device, Okani removes personal data: email addresses, authentication tokens, and invite codes are stripped, and your identity is reduced to a pseudonymous user id. We do not send default personal data to Sentry.

3.12 App update check (over-the-air updates)

• Data: each time you open Okani, the app contacts Expo's update service (u.expo.dev, run by Expo, Inc., USA) to check whether a newer version of the app's code is available and, if so, to download it. That request carries your device's IP address, the platform and operating-system version, the app's version and update channel, and a random installation identifier that the app generates on first launch and stores on your device. The identifier is not linked to your account, and the request contains nothing about you or your content.
• Purpose: to deliver bug fixes and security fixes to the app you already have, without waiting for an app-store release.
• Legal basis: legitimate interest (Article 6(1)(f)) — keeping the app correct and secure. This is the same kind of request your phone makes to an app store; the app offers no setting to turn it off, so the only way to avoid it is not to use the app. Expo acts as our processor for it (Section 5); the request reaches the United States (Section 6).

4. What we do NOT do

• We do not sell your personal data.
• We do not use your data for third-party advertising.
• We do not run behavioural advertising trackers.
• We do not make automated decisions that produce legal or similarly significant effects about you.

5. Processors and third parties

We use a small number of service providers ("processors") who handle data only on our instructions, under a data processing agreement (DPA) as required by GDPR Article 28.

Three sets of providers in this table are not our processors — they act under their own terms and privacy policies: Apple Maps / Google Maps for map requests (Section 3.3), GIPHY for the GIFs it serves (Section 3.5 ter), and the Apple and Google notification services, which deliver push notifications as platform services of your phone (Section 3.8). For a GIF search, your device talks to us and we relay only your search word to GIPHY; when a GIF is displayed, your device fetches it directly from GIPHY. In each case this happens under the provider's own terms, not on our instructions, exactly as when any other app shows a map or an embedded image.

We will keep this list current. A signed DPA is in place, or is being put in place, with each processor before it handles production data.

6. International data transfers

Our core data is stored in Frankfurt, Germany, inside the EU. In normal operation your personal data does not leave the EU/EEA, apart from the limited cases described below.

One exception to be transparent about: Cloudflare Turnstile runs on a global network, so the anti-bot check at sign-up, sign-in, or password reset — or when replying to an event from its share page — may be processed on a server outside the EU. This involves only a short-lived challenge token and your IP address at that moment — not your account content. Where such a transfer happens, it is covered by the European Commission's Standard Contractual Clauses (SCCs). If we identify any other transfer outside the EEA, we will rely on an adequacy decision or SCCs and will update this policy.

A second exception is our web host, Vercel (Section 5), which serves the pages that open from event share links. The computing that builds those pages is restricted to the Frankfurt (EU) region — the same region where our data is stored — and the pages are served as non-cacheable responses, so they are not stored on Vercel's global edge network; that network delivers only static assets containing no personal data. Vercel may process operational metadata — request logs, including IP addresses — as part of operating its service, including in the United States. For that metadata, Vercel is certified under the EU-US Data Privacy Framework; for the data it handles on our instructions, its data processing agreement incorporates the SCCs.

The same transparency applies to maps (Section 3.3): map lookups and map images for event locations are requests your device makes directly to Apple Maps or Google Maps, whose networks are global. Such a request carries the event's venue text or coordinates and your IP address at that moment — never your account content. These requests happen under the map provider's own terms, as with any app that displays a map.

A third exception is Expo (Sections 3.8, 3.12, and 5), established in the United States. Push notifications and the app-update check are processed there: in each case this involves your push token or IP address and the notification text (including, unless you have turned previews off, the first 140 characters of a text message — Section 3.8) or the update metadata described in those sections — never any other account content. This transfer is made under Expo's data processing terms, which incorporate the European Commission's Standard Contractual Clauses. Apple's and Google's notification services then deliver the notification under their own terms, as for any app on your phone.

The same transparency applies to the GIF picker (Section 3.5 ter), served by GIPHY in the United States. Your GIF search words reach GIPHY through our server, so without your IP address or identity; and when a GIF is displayed, your device fetches the image directly from GIPHY, which discloses your IP address at that moment — never your account content. These requests happen under GIPHY's own terms, as with any app that displays a third-party image.

7. How long we keep your data (retention)

About the security audit log: these records intentionally survive account deletion, because their purpose is to keep a tamper-resistant history of sensitive security actions (for example, "an admin removed a member"). After you delete your account, the user ids in this log are pseudonymous — they no longer link back to a named person, because the profile and account they referred to are gone. Legal basis for keeping them: legitimate interest and our security accountability duty (Article 6(1)(f) and Article 6(1)(c)).

8. Deleting your account and your data (right to erasure)

You can delete your account from inside the app at any time. When you do:

• Your profile, group memberships, RSVPs, discussion posts, emoji reactions, vendor pins, and the abuse reports you filed about other people's content (Section 3.10) are deleted. An event you created stays for the group members it was shared with, so as not to erase their plans — but every link to you is removed (your name no longer appears on it) and its share link is deactivated (Section 10.1). (A copy of one of your messages that another member forwarded into another group is that member's post and is not deleted with your account — Section 3.5.)
• Your vendor interactions still linked to you (less than 90 days old) are deleted with your account. Older records were already irreversibly anonymised — the link to you and to any event removed, the timestamp reduced to the week — and can no longer be connected to you, so they are unaffected (Section 7).
• Your uploaded photos, videos, voice messages and files are deleted from storage — from every group they were shared in and from every event you added them to. A group photo you set as an admin belongs to the group and is not deleted with your account — ask another admin to replace it first if you want it gone (Section 3.2). We do not keep or anonymise them; they are removed. One limit we cannot remove for you: copies of a photo, video or file that other people saved to their own devices before deletion are outside our systems and cannot be recalled (Section 3.4).
• Your direct messages, your reactions and reply links in them, read status, blocks, the reports you filed, and your message send-log are deleted. The whole conversation — messages in both directions, with their reactions and reply links — is removed from the other person's copy as well (Section 7).
• Your account (login) is deleted.
• After deletion, the only records that can remain are the ones listed here (the same list is on our delete-account page, okani.io/delete-account), and we keep each only for the reason given:
• the events you created, unlinked from you as described above;
• a group photo you set as an admin, which belongs to the group (Section 3.2);
• copies other people already hold — a photo, video or file another person saved to their device, or a message another member forwarded (Sections 3.4, 3.5 and 3.5 bis);
• the pseudonymous security audit log described in Section 7, whose user ids no longer link to a named person; and
• if another user reported something of yours for abuse before you deleted your account — a private message, a discussion message, a photo or file, or your profile — a limited snapshot of what was reported and the report reason (Sections 3.5 bis and 3.10). We remove the link to your profile and delete the snapshot no later than 12 months after the report is closed (Section 7).

Deletion is immediate in the database. Any database backups held by our database hosting provider are retained for a maximum of 7 days, so backup copies of deleted data are erased within 7 days at the latest. These backups cover the database only — uploaded photos and media files are not included in them.

9. Your rights

Under the GDPR you have the right to:

• Access — get a copy of the personal data we hold about you.
• Portability — receive your data in a structured, machine-readable format.
• Rectification — correct data that is wrong (for example, edit your display name in the app).
• Erasure — delete your account and data (Section 8).
• Restriction — ask us to pause processing in certain cases.
• Objection — object to processing based on legitimate interest, including the vendor-interaction log (Section 3.6), the direct-message safety records — blocks and abuse reports (Section 3.5 bis), the reports filed about other content (Section 3.10), language/locale adaptation (Section 3.7), the technical map requests for event locations (Section 3.3), the GIF picker (Section 3.5 ter), the event share-link disclosure (Section 10.1), and the app update check (Section 3.12 — we will consider each objection; because that check is what delivers security fixes, we expect in most cases to have compelling grounds to continue it, in which case the alternative is to stop using the app).
• Withdraw consent — for anything based on consent (avatar, push notifications, calendar export), at any time, without affecting past processing.

How to use these rights inside the app:

• Export / access / portability: use the in-app "Export my data" function. It returns everything we hold about you — account, profile, groups, events, RSVPs, posts, emoji reactions, the messages in which others tagged you, direct messages, media records, vendor pins and interactions, and your own security-log entries — as one machine-readable JSON document. (This is throttled to one export per minute to protect the service.)
• Erasure: use the in-app "Delete my account" function (Section 8).
• Rectification: edit your profile in the app.

For any right you cannot exercise directly in the app, email privacy@okani.io. We will respond within one month, as required by Article 12(3).

10. Content you share with your groups

Okani is built around private groups. Photos, files, posts, emoji reactions, events, RSVPs, and a group's photo are visible to the members of the groups they were shared with — with the exceptions described in Sections 3.5 (forwarding a message between a member's own groups) and 10.1 (event share links, which let event details be shown to people outside the group when you choose to share a link). Photos you add directly to an event are also visible to any guests the host has approved for that event (Section 3.4). Please only share content you are comfortable sharing with those members.

You keep ownership of the content you create. You grant Okani a limited licence to store and display it only to operate the service — this is set out in the Terms of Service. We do not use your group photos or posts for any other purpose.

10.1 Sharing an event by link (outside your groups)

Most content in Okani stays inside your private groups. Only one feature can show anything to people outside Okani altogether: event share links, which can show event information — never photos, files, or other group content. Separately, a member can forward a text or GIF message from one of their groups into another group they themselves belong to (Section 3.5): the copy is visible only to the members of that other group, inside the app. Forwarding never makes anything public and never shows anything to anyone without an Okani account. (Saved copies are a separate matter: no Okani feature shows photos or files beyond the audience you shared them with (Section 3.4), but anyone who can see a photo or file can save their own copy out of the app.)

If you created an event, you can generate a private link for it. You forward that link to whoever you want. When someone opens the link, they see a simple web page showing only three things about the event:

• its title,
• its date and time (for a repeating event, its next occurrence),
• its location.

They see nothing else — not your name, not the description, not who is invited, not who has replied, and not the group. From that page they can send you a guest reply — a first name and an answer, described in Section 3.3 — or download Okani to take part fully. The person opening the link does not need an account, and we do not create one for them.

After the event. Once an event has ended, its share page shows one more thing: how many photos were added to the event in the app — a number only, never the photos themselves, and never who added them. The count reflects only photos added up to 7 days after the event ends; photos added later are never shown to link holders. If a photo is deleted, the count goes down accordingly. If no photos were added, the page simply says the event has ended.

Please treat a share link like a paper invitation. Anyone who holds the link can view those fields (and, after the event, the photo count), and can pass the link on. The link contains a long, unguessable code, so it cannot be found by chance — but it is not password-protected, by design, so that you can forward it as easily as a calendar invite. Only share links to events you are entitled to share.

A title or a location can itself be personal data. For example, a title may contain a person's name, and a location may be a home address. Share links keep the disclosure as small as possible — three fields and an after-the-event photo count, no identities — but for this reason you should be thoughtful about what you put in an event's title and location before you share its link, and only share when you have the right to disclose that information.

Turning a link off. You control the link. It also stops working automatically if you delete your Okani account: when you delete your account, any share links for events you created are deactivated, so the web page stops showing anything. Deactivating an external link does not remove the event for the group members who still use it inside the app (see Section 7).

The share page itself. The web page that opens from a link is a plain page. It sets no advertising or tracking cookies. To show you the event it uses only the link's code, plus your IP address seen transiently by our infrastructure to serve the page (Section 3.10). If you use the reply form, the Cloudflare Turnstile anti-bot check (Section 5) runs on that form, and the reply data described in Section 3.3 is stored. We do not build a profile of people who open share links.

11. Vendors

Okani shows listings for local vendors (venues, caterers, and similar). Vendor listings are business information, not your personal data. When you tap a vendor listing, we record that interaction as described in Section 3.6. We may share aggregated, non-identifying interest data with vendors (for example, how many people viewed a listing). We do not share your identity with vendors.

12. Data security

• Data is hosted in the EU (Frankfurt) with access controlled by row-level security, so members only see data from their own groups.
• All uploaded media (photos, videos, voice messages and documents) is stored in private storage and served through short-lived signed links.
• We do not open, scan, or virus-check the documents you attach. When you open one, Okani hands the file to your phone's operating system, which applies its own protections.
• Authentication tokens are stored in the device's secure keystore.
• Sign-up, sign-in, and password reset are protected by an anti-bot check.
• Each account has a daily upload allowance — a maximum number of files and a maximum total size per 24 hours — enforced on our servers to limit abuse (Section 3.10). The app tells you if you reach it.

No system is perfectly secure, but we design to limit what any single failure can expose.

13. Data breaches

If a personal-data breach occurs that is likely to create a risk to your rights, we will notify the competent supervisory authority within 72 hours of becoming aware of it, and we will inform affected users where the law requires.

14. Complaints

If you think we have mishandled your data, please contact us first at privacy@okani.io. You also have the right to complain to a supervisory authority:

• France: Commission Nationale de l'Informatique et des Libertés (CNIL) — www.cnil.fr.
• Germany: the Federal Commissioner for Data Protection (BfDI) or your regional state data protection authority (for Berlin: Berliner Beauftragte für Datenschutz und Informationsfreiheit).

You may complain to the authority in your country of residence.

15. Changes to this policy

We may update this policy. If we make a material change, we will notify you in the app or by email before it takes effect. The "Effective date" at the top shows the current version. Continuing to use Okani after a change means the updated policy applies to you; where a change requires your consent, we will ask for it.

Summary of the most recent changes. This version (a) names the optional arrival note on RSVPs and an event's cover photo, and spells out exactly what an approved event guest can see and what the event's participants see of a guest (Section 3.3); (b) names the captions on event photos and how long event photos are kept (Sections 3.4 and 7); (c) names group photos and explains that they belong to the group (Sections 3.2, 7, and 8); (d) describes what a push notification contains, including the unread-count badge number, and how it travels (Sections 3.8, 5, and 6); (e) adds the over-the-air app-update check and Expo's role in it (Sections 3.12, 5, 6, and 9); (f) sets a 12-month deletion schedule for closed abuse reports (Sections 7 and 8); (g) names the upload log and the daily upload allowance (Sections 3.10, 7, and 12); (h) names captions on photos shared in a group and corrects the list of what remains after you delete your account, including that an event you created stays for its group without any link to you (Sections 3.4 and 8); (i) describes replies that quote an earlier message — in a group discussion and in a private message — and emoji reactions on private messages, including that a quote and its link disappear if the quoted message is deleted while your reply stays, that only the other person in the conversation can see a reaction on a private message, that reply links and reactions are erased together with the conversation (Sections 3.5, 3.5 bis, 7 and 8), and that a few hand-gesture emoji can carry a skin tone you choose, treated as an expressive choice and never as information about you (Section 3.5); (j) extends to the rest of the app's content — a discussion message, a photo or file shared in a group, a photo added to an event, or a profile — the abuse-reporting record already described for private messages, under the same purpose and the same legal basis, and sets out what a report keeps and for how long (Sections 3.10, 7, 8 and 9); and (k) describes tagging another member of a group in a discussion message with “@” — what is stored with the message, who sees the tag, the “Name mentioned you” notification it can trigger for a member who has push notifications on, that a tag lives and dies with the message, and that messages in which you were tagged are part of your data export (Sections 3.5, 3.8 and 9); (l) adds videos to the media you can share in a group, stored with a preview frame, saved and deleted like photos (Sections 3.4, 3.7, 8 and 12); (m) adds photos, videos and GIFs to private messages, visible only to the two people in the conversation and savable by either, and notes that a GIF in a private message loads from GIPHY like one in a group (Sections 3.5 bis and 3.5 ter); and (n) describes message previews in push notifications — the first 140 characters of a text message, shown by default once notifications are on, never for captions, filenames or media — and the "Show message text" switch in Settings → Notifications that turns them off (Sections 3.5, 3.8, 5 and 6); and (o) adds read receipts in private messages — the tick marks that show the sender when their message reached your app and when you opened the conversation — on by default, mutual, and switched off in Settings → Privacy (Section 3.5 bis). None of these changes adds a new purpose for your data or a new legal basis: items (i), (j), (k), (l), (m) and (o) describe new features that rely on legal bases already set out in this policy; items (n) and (o) each change who sees, or what is in, something you already share with us — a notification you opted into, a read status that used to be yours alone — which is why we are telling you before they take effect and how to switch each one off; the rest describe existing features and safeguards more precisely.

16. Contact

Questions about this policy or your data: privacy@okani.io.