Signet

Privacy Policy

Last updated 10 July 2026 · Operator: the signets.social relay operator (contact in-app)

Summary

Signet is an end-to-end encrypted messenger. The content of your messages, calls, and attachments is encrypted on your device and can only be read by you and the people you talk to. The relay server cannot read message content. We collect no analytics, run no ads, and use no tracking SDKs. We keep the minimum metadata needed to deliver messages, and delete it on a short schedule.

What is end-to-end encrypted (the server never sees the plaintext)

• Message text, attachments (photos/video/voice/files), stickers, reactions, edits, and “pin”/delete actions — encrypted with the Signal protocol (X3DH + Double Ratchet) hardened with a post-quantum hybrid (X25519 + Kyber-1024).
• Calls — audio/video are peer-to-peer WebRTC with DTLS-SRTP; the call setup (SDP/ICE) is itself end-to-end encrypted. A TURN relay, when used, forwards only already-encrypted media and cannot decrypt it.
• Sender identity of a message — “sealed sender”: the server stores the sender field as NULL for sealed messages. Known gap (be aware): that is not yet the same as the server being blind to who sent a message. Today a sealed message still carries a server-issued sender certificate next to it, which the relay can read and which names the sending account; it is kept for the same retention window as the message (up to the TTL below). So the operator, or anyone who can read the relay’s database or a backup, can currently determine who sent a given sealed message. A fix that encrypts the certificate to the recipient — so the relay genuinely cannot read it — is built and tested but not yet deployed to this relay. This page will be updated when it is, and not before.
• On your device — the local database is encrypted at rest (SQLCipher).

What the relay server necessarily processes (metadata)

To route and deliver messages the server handles:

• Your account identifier and public keys (so others can start an encrypted session with you), and an optional username if you choose to be discoverable.
• Routing/delivery metadata for each message: the recipient, a server-private routing token, timestamps (sent/delivered/read), and delivery status — kept until an automatic expiry (TTL), then deleted. Known gap: today this metadata persists until TTL rather than being purged the moment a message is delivered; purge-on-delivery is on the roadmap.
• Encrypted message blobs and attachments queued only until delivered/expired.
• Calls — placing a call is not end-to-end blind the way a message is. The relay brokers the connection, so for each call it records both accounts and the time. A call you miss additionally leaves a marker row naming caller and callee in the clear, kept for 7 days so your phone can show the missed call when it next connects; that marker is not deleted when it is delivered, only when it expires. The audio and video themselves are end-to-end encrypted and, when a direct path exists, do not pass through the relay at all.
• Typing indicators — while you are typing, the app pings the relay roughly every four seconds with the recipient's id, under your own token. That tells the relay you are writing to that person, in real time. The switch is in Privacy.
• Presence (online / coarse last-seen) — shared only with contacts you allow, and timestamps are coarsened. Turning it off stops both halves: the app stops announcing you AND stops asking the relay about your contacts, which is what actually keeps your contact list off the server. Being corrected: this page previously said presence was shared "only if you opt in". It is not — in the build you can download today, presence and typing indicators are on unless you turn them off, so nobody opted into anything. The defaults are changed in the source and both will be off in the next build; until that build is the one being served here, this paragraph describes the current one. Both switches are in Privacy and work today.
• Connection metadata inherent to any internet service (IP address at connection time), used for rate-limiting and abuse prevention, not profiling. Known gap: the relay also writes its own operational logs, and those logs currently retain more than that sentence implies. Measured on this relay on 3 August 2026: the request log recorded the connecting IP address, and separate lines recorded the account identifier at the same moments, with no size or age limit on either — so the two could be matched up, and nothing was deleting them. That is a record of which account connected from which address, which is exactly what the rest of this page says the service is built to avoid holding. A fix that stops writing the account identifier on routine lines and caps how long any log is kept is built and tested; it is partly deployed (the log size cap is live for one component) and the rest is not deployed yet. This page will be updated when it is, and not before.

We do not collect: your contacts list (it stays on your device), message content, location, advertising identifiers, or behavioral analytics.

Push notifications (be aware)

The app prefers a persistent encrypted connection (no Google services) for delivery. The build may also include Google's Firebase Cloud Messaging library as an optional wake path; in the current build the FCM project is a placeholder and FCM is effectively inert. If a real FCM project is configured in a future build, a wake “ping” (carrying no message content) may transit Google's servers to wake the app. This will be disclosed and made opt-out at that time.

Retention & deletion

• Undelivered messages: until delivered or TTL expiry, whichever first.
• Delivered-message metadata: until TTL (see gap above).
• Disappearing messages: if enabled, messages are securely erased from devices after your chosen timer.
• Delete for everyone / account wipe: removes the conversation/your account and broadcasts a wipe to your contacts (best-effort; offline contacts wipe on next connect).
• Server-side blocking stops new messages from a blocked sender.

Your controls

• Disappearing-message timers (per chat / global).
• Username discoverability: Everyone / Contacts / Nobody.
• Presence on/off. Read receipts on/off. Per-contact mute and block.
• App lock (biometric/PIN) + optional duress PIN that wipes on entry.
• Screenshot protection (FLAG_SECURE), on by default.
• A built-in network log showing exactly what leaves the device (bodies shown as ciphertext only).

Security verification

You can verify a contact's identity out-of-band via a safety number (derived on-device from both identity keys) or a QR scan. A changed safety number is flagged and clears any prior “verified” mark.

Government / legal requests

The operator can only provide what the server holds: account identifiers and limited routing metadata within its retention window. The operator cannot provide message, call, or attachment content because it is end-to-end encrypted and the server never has the keys. (Jurisdiction-specific transparency commitments to be added after legal review.)

Children

Not directed to children under the age required by your jurisdiction (commonly 13/16). (Adjust after legal review.)

Contact the operator

Signet has no support email: the relay does not run a mail server, and a published address would only invite spam to a project run by one person. Reach the operator inside the app instead — add the contact @signet and send a message. It travels end-to-end encrypted like any other, so a privacy question is not itself leaked to reach us.

If @signet is not yet resolvable in your build, the operator account is being provisioned; the handle on this page is the one to use once it is.

Changes

Material changes will be announced in-app and/or on the download page with an updated “last updated” date.

Signet · a no-Google, end-to-end encrypted messenger · signets.social