Effective November 8, 2026 · Last updated October 25, 2026 · Version 2026-11-08

Privacy Policy

Bloom Space (“Bloom”, “we”) is built around the idea that the internet should feel safer. This Privacy Policy explains what data we collect, why we collect it, how we use it, who we share it with, and the rights you have over it. It applies to the Bloom mobile app, our website, and related services.

1. Who is the Data Controller

Untecho Labs LLP, Innov8 Okhla, 3rd Floor, 211 Okhla Industrial Estate Phase 3, New Delhi 110020, India, operating as Bloom Space, is the data controller for personal data processed through the Service. You can contact our privacy team at contact@bloomspace.social. For users in the EU/UK, we will appoint a Data Protection Officer / EU Representative as required.

2. What we collect

2.1 Information you give us

• Account data — email address, sign-in identifier (Google ID, Apple ID), date of birth (required at sign-up to enforce the 18+ minimum age for new accounts and the legacy 13+ floor for accounts created before October 27, 2026, and to apply minor-account safeguards to legacy accounts), display name, persona names, and — if you add one — your phone number.
• Profile data — avatar, bio, pronouns, sanctuary memberships, persona settings.
• Content you create — posts, stories, clips, direct messages, reactions, comments. Direct messages are stored on Bloom servers in a form our staff can access under our internal access-control policy; see §9 Encryption. Voice rooms are not recorded (see §9.5).
• Address-book hashes — only if you use Find friends; see §2.6.
• Support data — messages you send to our help team and any attachments.

2.2 Information collected automatically

• Device data — device model, OS version, app version, language, time zone, notification-permission state, crash logs.
• Usage data — sanctuaries you visit, features you use, session duration, in-app events. Used in aggregate to improve the product.
• IP address and coarse location — each request carries your IP address; from it our edge provider derives a country code and a city name. We store the latest IP, country and city on your device record and sign-in session so we can flag unusual sign-ins and show you where your devices last signed in. These are cleared automatically once a device or session has been inactive for 90 days, when you remove the device, or when you delete your account.
• Security event log — sign-in attempts, rate-limit hits and similar security signals. The IP address inside each event is removed after 90 days; the de-identified event itself is kept for 12 months.
• Aggregate analytics — country-level usage statistics derived from the device/session country code. Aggregate counters never contain IP addresses or user identifiers.
• Cookies & similar — only essential cookies on the website; no advertising or third-party tracking cookies.
• Website analytics (cookie-free) — our marketing website uses a self-hosted, open-source analytics tool (Umami) running on our own servers. It records aggregated page views, referrers, browser/device type and country, does not set cookies, does not store your IP address or any persistent identifier, and does not share anything with third parties. You cannot be recognised across visits or across other sites. The website also reports JavaScript errors to Sentry (see §4) without personal identifiers.

2.3 Location data — exact use cases

Bloom never collects precise location in the background and never uses it for advertising. Precise location (GPS, latitude/longitude) is only read when you tap a feature that needs it. The table below lists every place location data appears in Bloom, the specific use case, the legal basis (GDPR Art. 6), the retention period, and who can see it.

Background location: Bloom does not request, declare, or use any background-location permission on iOS or Android. Location is only read while the app is in the foreground and only after you tap one of the actions listed above.

2.4 Permissions we may ask for (mobile)

• Camera — to take photos, record clips, and (when you join one) participate in video calls or video voice-rooms. Only used while the camera surface is open and you have started the action. Disclosed in our App Store and Google Play data-safety listings.
• Microphone — for voice rooms, voice and video calls, voice notes, and clip audio. Only active for the duration of the recording or call. Disclosed in our App Store and Google Play data-safety listings.
• Photos / Media — to let you pick existing media to upload and to save media you choose to download. On Android we also read a photo’s embedded location (ACCESS_MEDIA_LOCATION) only when you choose to tag a post with where it was captured.
• Contacts — only when you tap Find friends / Sync contacts; see §2.6. We never write to your address book.
• Face ID / Touch ID / biometrics — to unlock chat lock and sealed conversations on your device. Biometric data never leaves the device’s secure hardware and is never sent to Bloom.
• Notifications — to send you push notifications you have opted in to.
• Location (when in use) — only requested when you tap one of the flows in Section 2.3 (chat share, post tag, nearby-place search, profile location, verified location). We do not request “always” / background location.

2.5 Sensitive data

We do not require you to share sensitive data (race, religion, health, sexuality, political opinion). If you choose to share such data in your content, you are doing so voluntarily and consent to it being processed for the purpose of operating the Service.

2.6 Find friends from contacts

If you choose to find friends from your address book, the app reads your contacts on your device and, for each phone number, computes a one-way SHA-256 hash of the number in international format. Only those hashes are uploaded. Names, numbers, emails and photos from your address book never leave your phone.

• What the hashes are used for — mutual matching only: we show you a person who is on Bloom if their verified number is in your contacts and yours is in theirs, and both of you have discovery switched on. The hashes are never used for advertising, suggestions to other people, or anything else.
• Contacts who are not on Bloom — their hashes are stored only to complete future mutual matches and are never used to contact them. If you invite someone, the invitation is sent from your messaging app, not by Bloom.
• Your controls — Discoverable by contacts toggle, Hide from this contact, and Remove synced contacts, all under Settings → Privacy & Safety → Contacts. Removing synced contacts deletes every uploaded hash immediately.
• Retention — hashes are kept until you remove them or delete your account; account deletion deletes them in the same transaction.
• Legal basis — consent (the OS permission prompt plus your explicit tap to sync). Where you upload hashes of other people’s numbers, you confirm you are entitled to do so.

3. How we use your data

We use your personal data to:

• Provide, operate and maintain the Service (legal basis: contract);
• Authenticate accounts and prevent fraud, abuse and unauthorized access (legitimate interest / legal obligation);
• Show you the right content within sanctuaries you belong to (contract);
• Moderate content and enforce our Terms (legitimate interest / legal obligation);
• Send transactional and safety notifications (contract);
• Send optional product updates if you opt in (consent);
• Improve the Service via aggregated analytics and crash reporting (legitimate interest);
• Comply with legal obligations and respond to lawful requests (legal obligation).

4. Who we share data with

We do notsell your personal data and we do not share it with advertisers or data brokers. The companies below process data on our behalf under data-processing agreements, each for the single purpose listed. “Receives” describes the data that actually reaches them.

We also disclose data in these situations:

• Other users — according to the visibility you choose for your content, profile and personas.
• Store owners and brands — when you place an order, submit a lead form or respond to a sponsored campaign, the details you enter go to that business, which is responsible for them under its own privacy terms (see Terms §7.3).
• Trust & Safety reviews — when a user reports a direct message, the reported message and a small amount of surrounding context are shown to our internal reviewers.
• Law enforcement and regulators — when legally required, with a valid order. Request volumes are published in our transparency report.
• Successors — in the event of a merger, acquisition or asset sale, subject to the same protections.

5. International transfers

Bloom is operated from India and your data is stored on servers in India. Some of the providers in §4 process data in the United States or at their nearest point of presence. Where we transfer EU/UK personal data outside the EEA/UK, we rely on Standard Contractual Clauses, the UK Addendum, or other lawful mechanisms. Transfers from India are made in accordance with the Digital Personal Data Protection Act, 2023 and any country restrictions notified under it.

6. How long we keep data

• Account data — for as long as your account is active, then a 30-day grace period after you request deletion, after which identifiers are erased (see Delete account).
• India registration record — for accounts registered from India, a minimal sealed record (hashed email and phone, sign-up IP and country, account creation and deletion dates) is kept for 180 days after deletion, as required by Rule 3(1)(h) of the IT Rules, 2021, and then purged. It is accessible only to respond to lawful requests.
• Content — until you delete it; deletions propagate within 30 days, with up to 90 days for encrypted backups. Content removed for a rule violation may be kept for up to 180 days for investigation and appeals.
• Direct messages — kept until either party deletes them; we may keep abuse-flagged messages longer for safety review (max 12 months).
• Contact hashes — until you remove synced contacts or delete your account.
• Location data — see the per-purpose retention column in Section 2.3.
• Device / session IP and city — until 90 days of inactivity on that device or session.
• Security event log — IP removed after 90 days; de-identified event kept 12 months.
• Support emails — up to 24 months.
• Platform logs — 30 days.

7. Your rights

Depending on where you live (EU, UK, California, India, Brazil, etc.) you have some or all of the following rights:

• Access — request a copy of your data.
• Correction — fix data that is wrong or out of date.
• Deletion — request that we erase your data.
• Portability — receive your data in a machine-readable format.
• Objection / restriction — object to certain processing.
• Withdraw consent — at any time, where processing is based on consent.
• Lodge a complaint with your local data protection authority.
• California / CPRA — right to know, delete, correct, limit use of sensitive personal information, and not be discriminated against for exercising these rights.

In the app: Profile → Manage → Policies → User Data Policy gives you an instant data export; Manage Account → Delete Account starts deletion; Privacy & Safety holds the contact-discovery, location and content controls. Or email contact@bloomspace.social.

7.1 Grievance redressal — India (DPDP Act & IT Rules)

For users in India, Bloom provides a grievance-redressal mechanism under the Digital Personal Data Protection Act, 2023, the Information Technology Act, 2000 (including the SPDI Rules, 2011) and the IT (Intermediary Guidelines and Digital Media Ethics Code) Rules, 2021:

• Grievance Officer: Om Prakash Ojha — Grievance Officer, Bloom Space Trust & Safety.
• Contact: grievance@bloomspace.social (or contact@bloomspace.social). You can also raise a grievance from inside the app via Settings → Help & Support → Data Grievance (India).
• Timelines: we acknowledge every grievance within 24 hours and resolve it within 15 days of receipt.
• Expedited removal: complaints about content that exposes you in a sexual act or impersonates you (including artificially morphed images) are actioned within 24 hours of receipt, as required by Rule 3(2)(b) of the IT Rules, 2021.
• Escalation: if you are not satisfied with our resolution, you may escalate your complaint to the Data Protection Board of India.

8. Age requirement & legacy minor accounts

Bloom is for adults. Every account created on or after October 27, 2026 must belong to a person aged 18 or older, everywhere in the world. We do not operate a verifiable parental-consent flow (COPPA / DPDP Act §9), so we do not admit anyone under 18 and we do not knowingly collect personal information from children. If we learn that a user is under the age that applies to their account, we lock the account and delete it with its data unless proof of age is provided.

Legacy accounts.Before October 27, 2026 the minimum age was 13 (18 in India). Accounts created under that rule remain active. Where the account holder is still 13–17 (“legacy minor accounts”), the safeguards in §8.2 apply automatically until their 18th birthday. No new minor accounts can be created.

8.1 Age verification

Every account must enter a real date of birthat sign-up. This is not a single “tap to confirm” checkbox — we collect day, month and year and use the resulting age to drive the rules below. The date of birth can be corrected at most twice; after that, or if the account is reported as under-age, the account is locked and we ask for proof of age before it is reinstated. The date of birth itself is only used for age-gating and applicable legal compliance; it is not shown to other users and is not used for advertising.

8.2 Safeguards for legacy minor accounts (13–17)

Legacy accounts whose holder is 13–17 are subject to the following non-overridable safeguards, applied automatically on the server:

• Direct messages from strangers are blocked. Inbound DMs and message-requests from users who do not share an active sanctuary with the minor are rejected at the server. The minor's messagePrivacy preference is locked to “mutual sanctuary” and cannot be relaxed.
• No in-app purchases or subscriptions are offered to minor accounts. Any paid feature requires an adult account.
• No targeted advertising. Bloom does not run third-party advertising on any account; minor accounts additionally cannot receive any sponsored placement.
• Sensitive-content filter that cannot be turned off on feeds, search, explore and clip recommendations; adult-only sanctuaries and channels are hidden.
• Fewer notifications — non-essential push notifications are capped per day — and a once-a-day reminder after an hour of use.
• Limited discoverability — minor profiles do not appear in people search, suggestions or contact matches for adults who do not share a sanctuary with them.

8.3 Reporting an under-age user

Parents, guardians or anyone else who believes a person under the applicable age is using the Service can contact contact@bloomspace.social. We lock the account, request proof of age, and delete the account and its personal data if the age cannot be established. We respond to verified parental requests within 7 days.

9. Encryption — what is and isn't protected

We want to be precise here, because “encrypted” is often used loosely. The following is an accurate description of how Bloom protects your content today, and what we are working on next. If anything in this section is ever overstated in marketing copy, this section governs.

9.1 In transit

All traffic between your device and Bloom — REST API calls, WebSocket events, media uploads and downloads, voice and video signalling — is encrypted using TLS 1.2 or higher with modern cipher suites. Certificates are issued by recognised public CAs.

9.2 At rest

Account data, posts, comments, direct messages and other server-side records are stored on managed databases and object storage with disk-level AES-256 encryption. Backups are encrypted with separate keys held by our cloud provider under our control.

9.3 Direct messages and channel messages

Direct messages (1-on-1 and group DMs) and sanctuary channel messages are stored on Bloom servers in a form that our authorised staff can access. They are not end-to-end encrypted. This is the same model used by Discord, Slack, Reddit and most mainstream community platforms, and we have made this trade-off deliberately so that:

• You can report abuse in a DM and our Trust & Safety team can act on it.
• We can comply with lawful orders in the limited circumstances where we are required to.
• Sanctuary moderators and our staff can moderate channel content for safety.
• You can read your own history after reinstalling the app or signing in on a new device.

Internal access to message content is governed by least-privilege controls, audit logging, and our access policy described in §10 Security. We do not proactively read your DMs, we do not use them to train advertising or recommendation models, and we do not sell their content.

Screenshot notices.If you take a screenshot inside a direct-message conversation, the app detects this on your device and posts a visible system notice to that conversation (“Nametook a screenshot”). The notice is stored as part of the conversation history like any other message. The screenshot image itself never leaves your device — we only record that the event happened, who triggered it, and when.

Encryption is never used to obscure rule-breaking content. When end-to-end encryption ships for voice and video (§9.5), it will not exempt anyone from our App Policy. Reported content remains actionable, metadata-based abuse signals continue to operate, and accounts that misuse encrypted surfaces to evade moderation will be removed.

9.3.1 Stranger DMs and public group chats

• No anonymous messaging to strangers by surprise. Personas are visible to recipients, every message includes the sender's persona handle and a Report action, and the receiving user always knows who is messaging them. We do not offer a “send anonymous DM” feature.
• Adult accounts can opt to receive message-requests from users outside their sanctuaries; these arrive in a separate “Requests” tray that must be accepted before a real conversation begins. Legacy minor accounts (13–17) cannot receive these requests at all (see §8.2).
• Public sanctuary channels and group chats are moderated. Every sanctuary has an owner with kick / ban / mute / message-delete tools, server-side rate limits, automated abuse and image-safety classifiers on every message, and a one-tap report flow. Bloom does not launch public chats as un-moderated free-for-alls.
• Sanctuary roles and permissions (owner, moderator, member, restricted) are enforced server-side and let community owners structure who can post, who can speak in voice, and who can DM members of the community.

9.4 Direct-message media (images, voice notes, files)

Media you attach to a direct message is encrypted on your device before it is uploaded, and what we keep in media storage is the encrypted blob. To let the other participants view the media, the decryption key is uploaded alongside the blob and stored on our servers, where it is returned only to the conversation's authorised participants. This is not end-to-end encryption, and it is not a guarantee that Bloom cannot access DM media: while the media is retained, our systems hold both the ciphertext and a key capable of decrypting it. You should treat the privacy of DM media as equivalent to DM text — protected by the access controls, audit logging and policies described in §9.3 and §10, not by cryptography alone. What this design does provide:

• Media blobs in object storage are ciphertext and the keys are stored separately — a compromise of the storage system alone does not expose your media.
• Encrypted media is held temporarily and its server copy is deleted after delivery or expiry; long-term copies exist only on your and your recipients' devices.

Practical consequences today:

• If you delete and reinstall the app, media whose server copy has already been deleted cannot be re-downloaded.
• Some older encrypted media may not appear on a second device signed into the same account.
• The plaintext content of the message itself (text, mentions, reactions) is still stored as described in §9.3.

We are working on per-recipient key wrapping so that our servers no longer hold usable keys for DM media. Until that ships, this section describes the current behaviour and governs over any looser wording elsewhere.

9.5 Voice and video calls (today and roadmap)

Voice rooms and video calls today are relayed through a Selective Forwarding Unit (SFU) operated using LiveKit Cloud. Streams are encrypted in transit (DTLS-SRTP) but the SFU can, in principle, see the media. Nothing is recorded — Bloom has no recording feature today; if one is introduced, participants will be told before any recording starts and this section will be updated first.

We are working on end-to-end encryption for voice and video callsusing an MLS-based scheme similar in spirit to Discord's DAVE protocol. When this ships, the SFU will only see opaque encrypted frames and only call participants will hold the keys needed to decrypt. We will update this section, in-app, and our changelog when this is live; until you see that update, please assume voice and video are not end-to-end encrypted.

9.6 Internal access controls

Bloom employees and contractors do not have access to your data by default. Access to production systems and message content is granted on a need-to-know basis, requires multi-factor authentication, is logged, and is reviewed periodically. Trust & Safety staff can review reported messages; engineers may access narrow slices of data to debug or restore service. We will challenge or push back on government requests we believe are unlawful or overbroad.

10. Security

In addition to the encryption described in §9, we apply strict access controls, least privilege, secret rotation, regular dependency scanning, regular penetration testing, and a documented incident-response process. No system is perfectly secure; please use a strong, unique password and enable available account-protection features.

11. Apple App Store & Google Play disclosures

This section summarises information also reflected on our store listings:

• Data linked to you — account identifiers, contact info (email), user content, identifiers, usage data, diagnostics.
• Data not linked to you — aggregated, de-identified analytics and diagnostics.
• Data used to track you — none. Bloom does not track users across other companies' apps and websites, does not share identifiers with data brokers or ad networks, and our iOS Privacy Manifest declares NSPrivacyTracking = false. Because we do not perform tracking as defined by Apple's App Tracking Transparency framework, we do not show the ATT prompt; if we ever introduce a feature that would require tracking, we will request your permission via the standard ATT system prompt before doing so.
• Google Play Data Safety — our Data Safety form on the Play Console declares the same categories as this policy: account info (email, phone number if added), user content, app activity, device IDs and crash diagnostics, user-initiated precise location and IP-derived coarse location, and contacts (hashed phone numbers, only when you use Find friends). None of these are sold or shared with third parties for advertising.
• Permissions disclosed in store listings — Camera, Microphone, Contacts and Location are declared in both Privacy Nutrition Labels (App Store) and Data Safety (Play) for the uses described in §2.3, §2.4 and §2.6.
• Age rating — Bloom is listed for adults (18+). It is not designed for children and is not part of any Family or Kids program.

12. Changes to this policy

We will notify you of material changes in-app or by email at least 14 days in advance. Each version of this policy carries a version identifier (the effective date shown at the top); the app records which version you accepted and shows you an in-app notice when a new version is published. Continued use after the effective date means you accept the updated policy.

13. Contact

Privacy questions: contact@bloomspace.social. EU/UK residents may also contact our DPO at dpo@bloomspace.social. Users in India may contact our Grievance Officer at grievance@bloomspace.social — see §7.1 Grievance redressal. By post: Untecho Labs LLP, Privacy Team, Innov8 Okhla, 3rd Floor, 211 Okhla Industrial Estate Phase 3, New Delhi 110020, India.