Privacy
Last updated: October 24, 2026.
Sideverse keeps account information, community and event activity, signed publications and your existing private records. A signature verifies a key, not a legal identity or physical presence. This page explains what the service receives.
What we collect
- Account email and name. Required to log in, send security and account notices, and provide a contact for handle disputes.
- Your handle's public key. Required for resolving your handle across clients. This is public data by design.
- Signed page bundles. The CBOR wire and Ed25519 signature for each page you publish. This is public data by design.
- Community and event activity. We store the communities you join, messages and experiences you share, events you create, and event responses. Visibility follows the community, event and selected Side. Guest event responses use the name and response supplied by the guest.
- Shared costs. Tabs store participant names, expenses, shares, repayment records and confirmations. They record money owed; they do not transfer money. People on a tab can see its records.
- Existing private place records. Records saved before the map feature was removed remain scoped to the selected Side and available in account exports. They can include place labels, coordinates, visit dates, notes and provider place identifiers. They are not end-to-end encrypted; service operators with database access can access them. A saved record does not prove a visit.
- Side ownership and hosted keys. The service stores the private account-to-Sides relationship. Each Side has its own identity and key, but the host knows which account owns it. Browser-hosted signing keys are encrypted at rest and used by the service for authorized signing. Separate identities do not make you unlinkable to the host or erase historical links.
- Membership and invitations. We store membership status, hashed invitation codes, the invitation relationship and activation timestamps. Normal activation records the exact inviter’s account and their personal vouch after email verification. It does not record a physical encounter and is not biometric, government-identity or presence verification. Separate administrative bootstrap or activation records may include an operator, encounter time and optional note.
- Session metadata. IP address, user-agent and last-activity time are stored in session records to manage signed-in devices and detect abuse.
- Aggregate entry metrics. The invitation-to-first-action metrics store only the date, event name and count. They do not include account IDs, Side IDs, invitation tokens, IP addresses or precise location. Each Side also records its first-action date so that action is counted once.
- Native-client telemetry. The current protocol implementation sends event, version and channel by default in release builds; it is not opt-in. This registry stores accepted telemetry events with a country code when available and receipt dates, without an IP address or client identifier in that event record. Read the telemetry policy.
What we don't collect
- Device-held signing seeds. Native clients may hold their own keys. Browser-hosted identities are different: this service holds an encrypted signing seed so it can act for that browser identity. Do not assume a hosted identity is a key only you possess.
- Advertising identifiers. We do not use advertising identifiers to build a profile, and there are no ad networks on the registry. Published pages can have aggregate view counts and service-side analytics, separate from native-client telemetry.
Cookies and storage
We set a session cookie when you sign in. It identifies your session row in our database and is removed when you log out or the session expires. The service worker caches static assets and a generic offline screen, but not authenticated page contents for offline viewing.
Event locations and external links
Organizers can enter a venue name or address and an optional external link. These details are shown to people who can view the event. Entering an event location does not verify attendance or physical presence.
When the Google Maps place picker is configured, the event editor loads Google Maps and sends place searches to Google. A selected place can add coordinates to the event. The editor does not request your device location. You can also enter a place manually.
If you choose an external venue, directions or other link, that site receives your visit and handles your data under its own privacy policy.
Connected WhatsApp groups
A connection links an existing WhatsApp account. The bridge receives group details and member names. For groups connected to Sideverse, it can copy messages, sender names, message references and timestamps into the selected community room. Messages sent in that room can be sent to the connected group through the linked number. Other personal chats are not copied into Sideverse.
Copied messages are stored by Sideverse and can be read by people with access to the room and by service operators with database access. They are not end-to-end encrypted within Sideverse. Group photos can enter a review inbox when photo collection is enabled; an organizer chooses which photos to add to an event album.
The group receives a notice when message copying is enabled. Send !tpsocial off in the WhatsApp group to stop copying your future messages, or !tpsocial on to resume. This does not remove earlier copies. Disconnecting stops future copying; it does not recall copies already held by other people or services.
Your rights
You can update your email and name, revoke sessions, export account data and delete your account through settings.
Published page bundles are already public; deleting your account removes the registry’s copies. Account deletion also removes your stored private place and membership records. Copies already shared or held outside this service cannot be recalled by that action.
Contact
Privacy questions: [email protected].