Quorum

Privacy

Privacy Policy

How Quorum’s website and private external beta collect, use, disclose, retain, and delete account, club, reading, note, notification, diagnostic, feedback, and support data.

Effective October 4, 2026

1. Scope

This policy describes how Quorum’s public website and private external beta handle information. Quorum is the product name used for this project and is operated by the owner of lukerykta.io. It applies to beta access requests, website feedback, the invited-reader app, support and moderation, notifications, and the limited diagnostics described below. The private beta is not a public App Store release.

2. Information Quorum handles

  • Account and profile data. Quorum handles the internal account identifier, authentication provider and provider subject, session state, and the email claim a provider supplies to the authentication service. Google sign-in may also supply a profile image URL that Supabase Auth retains as provider metadata. Quorum does not use that email as an app password or copy it into the product profile. It does not display the provider image as the in-app avatar or accept photo or video uploads. The stored product profile contains the display name, selected avatar key, and optional bio. When no avatar is selected, Quorum derives initials from the display name instead of storing initials as a profile field. Quorum separately keeps the signed-in reader’s current-club preference in device-local storage.
  • Club, invitation, book, and read data. Quorum handles a club’s name; membership role, join order, and active, suspended, or departed state; invitation code state and recipient eligibility; and the selected club. A read records the book title and author, physical edition identifier and page total, reading target, lifecycle state, and predecessor or successor relationships needed for rollover.
  • Progress data. Each accepted progress event records the read, exact page, durable ordering and request references, and accepted time. Quorum derives current progress and spoiler eligibility from that append-only history. Progress is not published as a public score.
  • Notes, revisions, and deletion state. A published note records its author, read, exact page, kind, text, publication time, current revision, edit history, and deletion or moderation state. Before another reader reaches the note’s page, the server returns safe locked metadata but no note text, kind, reaction field, current-content length, revision, or edited state. Note text that remains after account deletion can still identify its writer.
  • Hearts and attention state. Quorum keeps one private heart slot per eligible note and reader, the reader’s own current selection, replay and reconciliation state, and a monotonic spoiler-gate high water. Readable views may receive only the eligible aggregate count and that viewer’s own selection. Reactor identities are not shown and a heart does not create an author-facing read receipt. Private attention records identify still-unseen, already-readable notes for the eligible reader and are acknowledged only after authorized rendering.
  • Safety reports and blocks. A report records the reporter, selected club, target, reason, submission and review state, and, for a note report, the exact text, kind, and revision the reporter observed. Review events and action state are retained separately. Private blocking records apply within the selected club.
  • Beta access requests. The website handles the submitted email, optional first name, phone choice, reading situation, usual formats, reading frequency, willingness to share feedback, optional written answer, contact permission, request time, and bounded delivery state. A beta request does not create an app account.
  • Website feedback. The website handles the message, optional reply email, random submission identifier, submission time, and bounded delivery state. Feedback is stored separately from beta requests and safety reports. It does not create an app account or add the sender to a mailing list.
  • Support messages. The support channel handles the sender address, subject, message, and information needed to route and answer the request. Support correspondence is not imported into the moderation queue.

3. Notifications

The installed notification choices are New notes for you, Notes just ahead, Reading check-ins, New club members, and Likes on your notes. Quorum stores the global on/off choice and each category choice. A new All notifications selection enables all five categories; existing saved choices remain intact. Before sending, Quorum checks current preferences and access to the relevant club, read, or note.

Registration binds the signed-in account, app environment and application identifier, iOS or Android platform, a cryptographically random installation UUID, and the FCM registration token. Delivery coordination retains a token digest, content-free source event and per-installation outcome references, attempt number, provider message reference, delivery state, and relevant timestamps. On the device, Quorum keeps at most 16 pending and 32 handled content-free notification responses; ordinary entries expire after seven days. One latest native authorization cursor is retained until it is replaced or consumed and does not expire merely because seven days pass.

When an eligible reader expressly enables readable previews, a New notes for you alert may show the current author display name and a short, whitespace-normalized note excerpt of at most 96 grapheme clusters outside Quorum. The title is “Quorum.” Quorum constructs that presentation only at final dispatch and does not retain the author name or excerpt in its notification records. FCM data fields contain only the category, schema version, and an opaque content-free authorization reference. Notes just ahead and Reading check-ins use their content-minimized presentations. Alert text grants no access; a tap reauthorizes current account, club, read, and note state before showing anything.

Readers can change each category, pause all Quorum notifications, or use iOS or Android Settings. On supported devices, sign-out requests dismissal of presented readable New notes for you alerts, detaches this installation’s server binding when one exists, clears that binding locally, and abandons an unfinished first-entry notification claim. Account deletion removes server-side recipient, preference, installation, event, delivery-outcome, response, and token state for that account; other offline installations clear local state when they can reconcile or when their app data is removed. Push permission is not required to use Quorum.

4. Privacy-filtered diagnostics

When privacy-filtered remote diagnostics are enabled in a supported staging or production build, Quorum sends only newly constructed, allowlisted error events to separate Sentry projects. An event may contain schema version; bounded event name; UTC occurrence time and severity; constant service name; environment; iOS or Android platform and OS version; app version, native build, release channel and profile, full source commit, and approved SDK version; bounded operation, failure site, error family, error code, cause, coarse duration bucket, outcome, handled, expected, retryable, and attempt values; random per-operation observation ID, random cold-launch ID, and short random support reference; a fixed generated-bundle frame with numeric line and column and, after protected source-map processing, an exact tracked app:///src/… file path without source content or function name; and a fixed safe message, bounded exception-kind enum, and grouping fingerprint. The bounded auth-resolution diagnostic may also contain closed categories for origin, first and optional second failure, recovery and revalidation result, bearer-age category, failure source, HTTP status category, and provider-independent error-code category.

Diagnostics exclude names, email addresses, account/member/club/read/note, progress, report, installation, device, provider, database, receipt, and other business identifiers; note or support text; exact pages or page totals; IP address; locale, time zone, location, model, screen, battery, storage, carrier, and network identity; tokens, credentials, sessions, cookies, OAuth or invitation data; URLs and parameters; headers, bodies, queries, SQL, raw errors, provider values, cache or local-storage content; screenshots, view hierarchy, replay, attachments, source snippets, variables, registers, and memory; and automatic network, HTTP, console, navigation, touch, UI, or device breadcrumbs. Tracing, profiles, performance monitoring, app hangs, metrics, logs, sessions, release health, native crash capture, and automatic analytics are disabled. The SDK is configured with default personal-information sending off, zero breadcrumbs, no integrations, no cookies, no request capture, no HTTP bodies, no client reports, and a memory-only queue of at most five events.

A diagnostic event does not contain an account identifier, and Quorum has no general way to look up an account from its support reference. If a participant deliberately sends the same reference in a Support message from an email address associated with them, Quorum can match that otherwise identifier-free event to the sender for that support request. Quorum does not perform this identity correlation unless the participant takes that step.

5. How information is used

Quorum uses information only to:

  • review access requests and contact consenting beta applicants;
  • review website feedback, improve Quorum, and reply about that feedback when an email is provided;
  • authenticate invited readers and maintain their sessions and profiles;
  • provide private clubs, books, progress, notes, spoiler gates, hearts, and notifications;
  • protect club boundaries and investigate security or reliability failures;
  • review safety reports and apply the Community Standards;
  • answer support, privacy, correction, withdrawal, and deletion requests; and
  • meet legal obligations that apply to the service.

Quorum does not sell reading data, use note content for advertising, run targeted advertising, or use notification content for marketing.

6. Providers and disclosure

  • Supabase provides authentication, the application backend, database, and protected server functions.
  • Apple provides Sign in with Apple, APNs notification delivery, and TestFlight and App Store Connect beta distribution and review. Those beta services process tester contact, device, usage, crash, and feedback information.
  • Google provides Google sign-in, FCM notification delivery, Google Play internal testing, and the Gmail mailbox used to receive and send beta-request, website-feedback, and Support messages.
  • Expo/EAS provides app build and submission services.
  • Sentry receives only the privacy-filtered diagnostic fields described above when that adapter is enabled.
  • Cloudflare hosts and protects the public site, runs Turnstile, stores beta requests and website feedback separately in private D1 storage, sends their notification emails, and routes Support mail to Gmail.

Quorum limits each provider to the information needed for its stated role. After reviewing the providers’ applicable terms, processing roles, subprocessors and transfer safeguards, security measures, and retention and deletion controls, Quorum confirms that each provider receiving user data will provide the same or equal protection of that data as stated in this policy and required by the App Review Guidelines. Some providers also process limited account, device, service, security, or de-identified information as independent controllers under their own privacy notices.

Information may also be disclosed when required by law, to protect a person’s safety or the service, or as part of a future service transfer where this policy continues to apply. Quorum is not a data broker and does not disclose club content for marketing.

7. Report-review access

Authorized operators use an audited review path for the exact reported target. For a note report, this exposes only the reporter-observed copy of that note’s text, kind, and revision, together with current target and action state. For a member report, it exposes the current profile and selected-club membership and action state. This review can bypass the operator’s reading-progress boundary, but grants no general club browsing or access to unrelated notes. Reports are not published to other members.

8. The public website

This website uses no advertising pixel, analytics service, or remote font. The beta and feedback forms use Cloudflare Turnstile to prevent spam. Turnstile and the hosting layer process ordinary security and delivery signals such as IP address, user agent, requested path, time, browser, and device information; Quorum does not use those signals for advertising. The website does not receive in-app club, progress, note, reaction, or notification data.

Beta answers and feedback messages are stored privately in Cloudflare and sent to support@lukerykta.io for review. They are available only to operators and providers who need them, and are not published or added to a club profile. See Cloudflare’s Turnstile Privacy Addendum.

9. Retention and deletion

Beta-request and website-feedback records are automatically removed from the active database after 180 days. Notification emails, operator exports, and related support messages are reviewed separately and removed when no longer needed. Provider backups may retain copies for their normal recovery period. To correct or withdraw a request, stop beta email, or request deletion of the request and its operator copies, email support@lukerykta.io from the submitted address. Quorum may need to verify control of that address.

To correct or request deletion of website feedback and its operator copies, contact Support with enough information to identify the message. When no reply email was supplied, Quorum may be unable to verify who sent a message or identify it reliably.

Sentry error-event availability follows the active plan and is no more than 90 days. Deleted copies may remain in Sentry backups for up to 90 days. Quorum’s operational target is to delete an accepted staging issue after acceptance or by day 14 and a production issue by day 30 where whole-issue deletion is safe. These are best-effort purge targets, not guaranteed shorter retention periods. Sentry does not support editing, redacting, or age-deleting one already-ingested event, so uncertain or prohibited scope requires deletion of the whole issue or project and a provider deletion request. Source maps may remain for 90 days after last use.

Quorum keeps account, club, reading, note, reaction, notification, and safety data while needed to operate the beta, maintain surviving shared records and spoiler integrity, secure the service, or meet legal duties. Resolved-report metadata, review events, submission receipts, and detached reported-note evidence expire 90 days after resolution unless an explicit legal or child-safety hold applies. Unresolved reports remain available for review. Releasing a hold does not restart the original period. A minimal action and reversal audit may remain so enforcement can be corrected. Account deletion severs the report’s link to the reporter’s account; it does not automatically erase held evidence or make retained note text anonymous. The minimal audit contains no reporter identity, note content, or content-derived evidence.

The authenticated deletion path removes the requesting person’s identifying profile, club access, authentication account, and disposable private account and notification state. On the normal path, the installation completing deletion also clears its drafts, keys, session, and saved local state. If local storage fails after server acceptance, saved session data and up to one inert invite-reconciliation record per affected club may remain until storage recovers or the app’s data is removed. The server deletion remains authoritative, but clean account replacement on that installation cannot be guaranteed until cleanup completes. Another offline installation retains local app data until it safely reconciles or its app data is removed.

In a club with other active members, published notes remain under Deleted user with no portrait, bio, or profile link; current hearts remain eligible aggregates. Note text is not rewritten and may still identify its writer. If the deleted person held an owner role, including while suspended, and no other valid active owner remained, ownership passes to the earliest-joined eligible member. An existing valid active co-owner remains without another promotion, and non-owner deletion transfers nothing. If no active member remains, the club and all of its data are deleted. Limited opaque internal ancestry and content-free history may remain where a surviving shared artifact requires it for integrity or spoiler gates, or where needed to prevent abuse or meet a legal obligation. See Account deletion for the current path.

10. Security and choices

Quorum uses access controls, separate environments, least-privilege credentials, encrypted transport, and server-side spoiler boundaries. No system can promise perfect security. If an account or invitation may be exposed, contact Support promptly without including a password, token, invitation link, note text, or another member’s private information.

For questions or corrections, email support@lukerykta.io. Supported builds provide authenticated deletion in Settings. The app-independent deletion workflow is not yet operational. Apple and Google account information can also be managed through those providers.

11. Changes and contact

Material changes will be posted here with a new effective date. Questions about this policy can be sent to support@lukerykta.io.