نظرة عامة

What you'll find here

These docs cover everything you need to publish to a Sideverse registry, verify a signed page yourself, or implement a client that talks the protocol.

If you're new, start with Quick start — it explains the supported publishing paths. Browser entry depends on this registry’s admission settings. Open registration can be available. When invitation admission is enabled, members use an invitation, verify their email and receive their inviter’s confirmation. Email-dependent steps require a working mail provider.

If you're building tooling, Protocol is the canonical reference for handle naming, the resolve endpoint, the signing scheme, and the sandbox model that lets clients render untrusted HTML safely.

If you're integrating an existing system, the API reference lists every HTTP endpoint this registry exposes, the bodies they accept, and the responses they return.

If you're building the TrustPlane app or anything on the social layer, the API reference has three sections for you: The app: pairing and what a side sees, Experiences, people, groups inside a group, and A group's look. This registry is also the namespace authority for trust://sa/@handle names — see Names on the trust web.

The product name is Sideverse, formerly TP Social. Existing tpsocial API names and signed-data formats remain unchanged for compatibility.

Using these docs with the website

These technical documentation bodies are currently available in English. The website also offers Arabic navigation and account controls; changing the interface language does not translate these technical references or member-authored content.

Use Sign in for an existing browser account; no app download is needed. Device sign-in is an optional separate path for compatible clients. When new entry is paused, approved members can still sign in. Official website controls include Light, Dark and System appearance; member-authored page and community themes keep their own design.

The browser workspace connects Discover, Communities, Events and Your Sides. Use the displayed Side when publishing or participating. Account recovery, invitation quota and security settings belong to the account; custom-domain settings let you select the Side whose handle you are managing.

Start with Discover to find upcoming events and communities available to your selected Side. Open an event to see its details and RSVP, or open a community to learn about its membership rules and join when permitted. Organizers enter venue names or addresses and optional external links. When a Google Maps browser key is configured, the event form also offers place search and a map pin. Manual venue entry remains available when the map provider is not configured.

Feature availability depends on this registry's configuration. The status page describes configured availability and reported incidents. Native download links show an unavailable page when no release asset is available. For the data recorded by the website and the separate native sender, see Telemetry and Privacy.

A few principles to set expectations

Signed pages can be verified independently. A preserved page and its signed records remain verifiable against their public key; availability still requires a copy and a working host.

Custody depends on how you use Sideverse. Browser Sides use encrypted keys held by this hosting service. The service knows which account owns each Side. A paired external client can retain its own key; pairing that Side grants no access to sibling identities or account recovery. Account password, passkey and TOTP recovery are separate from recovering an external Side key. Trustee or threshold recovery is not available.

The spec is plain English. We try to keep it short, exact, and free of optional behaviour. If you find ambiguity, file it — that's a bug in the doc, not a bug in your implementation.

Conventions in these docs

• Code blocks contain text you can paste verbatim.
• §9.3-style references point at the canonical Protocol Spec sections.
• We use @alice for the example handle and hello for the example slug throughout.

WhatsApp connections

Account holders can connect an existing personal or community WhatsApp number. A community manager links a WhatsApp community to a Verse; announcement messages stay in the parent community and other groups use sub-communities. Linked rooms can exchange text, event changes and reviewed event photos. The connection page shows queued work separately from provider confirmation.

A configured protocol 2 bridge and a phone scan are required. Only explicitly linked groups share content. WhatsApp users are not Sideverse members until they join. Unsupported attachments, disappearing messages and view-once content have separate limits. Read The WhatsApp bridge for the protocol, access checks and supported content.

Current content limits. New text in linked groups can be mirrored. Normal event photos enter organiser review. General media attachments and WhatsApp participant photos are not fully imported, and earlier chat history is imported only for the groups and days you choose. Hiding an incoming WhatsApp message in Sideverse does not remove it from WhatsApp. The connector links an existing number; it does not obtain or register a new number.

Language paths. The English and Arabic interface uses /en and /ar page paths. A language change keeps the current page and context. Existing links without a language prefix still work; signed protocols, APIs and media URLs keep their paths.