Uniform Technical Information

Privacy Architecture for Everyday Users and Technical Reviewers

This page is designed to answer one core fear first: could an employer identify you through Uniform? Then it shows the technical controls behind that answer.

Last updated: March 6, 2026

Jump to a section

Start Here

Uniform is designed for private organizing. In active app runtime records, we do not store real-name, personal email, phone, or auth/session IP/fingerprint fields tied to your account.

Your anonymity level is mostly determined by how you pay. A non-identifying crypto wallet or payment alias can support full payment-side anonymity. If you use a card or app-store payment provider, that provider may still store your billing identity outside Uniform, and we cannot control that provider-side retention.

Our billing-vault architecture is built to reduce that linkability from the Uniform side: app account records and payment-processor references are split into separate systems. Billing claim and recovery codes let you manage access without associating processor IDs.

1. What people worry about

Can my employer get my real identity from Uniform?

No, from Uniform app-runtime records alone. We do not store real-name, personal email, or phone identity fields in active account/session/content records. Uniform is designed to be as close to zero-knowledge as possible while still running the app: we keep only what is needed for operation, like handle/account status, membership and authorization metadata, device-key session references, encrypted ciphertext payloads for messages/posts/media, and in-app feedback payloads (message text plus optional encrypted image attachment metadata) tied to internal account IDs (not contact fields). Signed union authorization card content stays on your local device (server-side storage is limited to anonymous receipt artifacts).

Does Uniform store IP addresses for account auth or sessions in the app database?

No. The account auth/session model uses device-key challenge/response plus short-lived app-managed JWTs. IP address and browser/device fingerprint metadata are not persisted in app auth/session tables.

Can Uniform read my messages and posts in plaintext?

No. Messages, posts, comments, and media are stored as encrypted ciphertext envelopes or encrypted blobs.

Does Uniform store my signed card content?

No. Card signature content stays on your device. Server-side card storage is limited to anonymous receipt artifacts (hashes, location, timestamp).

Identity Controls

2. What we do to protect your identity

Worker Privacy Report Card

PASS

Last verified (UTC): Mar 9, 2026, 7:20 PM

View latest report

This report card runs automated checks and tests for worker privacy controls on each pull request and main branch commit.

Device-key session authentication

Technical: Session setup uses a short challenge signed by your registered signing key, then mints a short-lived app JWT.

In plain English: Your session is tied to device keys instead of a traditional password cookie flow.

Proof

No auth/session IP persistence in app DB

Technical: Auth/session tables store challenge hashes, account/device key references, TTL, and usage timestamps, not IP/fingerprint columns.

In plain English: Our account session records are designed without stored IP/fingerprint metadata.

Proof

Wake-only push payloads

Technical: Push notifications are sent as action/ref hints (wake-only mode), without sender text or message body content.

In plain English: Notifications tell the app to wake up, not who wrote what.

Proof

Actor-ID content identity mode

Technical: In post, comment, and message records, identity is represented by scoped actor IDs (per context or thread). Direct internal account ID fields are omitted from active content payloads.

In plain English: For you, this means your handle is what appears in the app, while your core account ID is removed from normal post/message data. That makes routine content records much harder to trace back to your underlying account.

Proof

Billing vault separation

Technical: The Billing Vault is a separate database that stores processor billing identifiers and unified entitlement state (Stripe/Apple/Google/crypto) under vault subject IDs. The main app runtime tables store neither processor customer/subscription IDs nor a deterministic account->billing join key. For billing-gated accounts, session minting succeeds only when a vault-issued, device-bound membership pass verifies as active; missing/invalid/inactive (or vault unavailable) denies session issuance.

In plain English: Payment identity data is kept in a separate billing system, and the app only checks a pass to allow access. So Uniform database records can in no way tie your Uniform account to your Stripe/App Store/Play/crypto billing profile.

Proof

Data Limits

3. What Uniform does not store

XNo IP address or browser/device fingerprint.
XNo real-name, personal email, or phone identity fields in active app runtime account/session/content records.
XNo card numbers, billing names, or billing addresses.
XNo message/post/comment/media content.
XNo union authorization card signature content or account links (only receipt artifacts).

Database Scope

4. What our database records can and cannot reveal

Scope of this section: what Uniform-controlled database records alone can reveal. This is the core database-only disclosure.

Cannot reveal from Uniform database records

•Your real name, personal email, or phone number.
•Card numbers, billing names, or billing addresses.
•Plaintext message/post/comment/media content.
•Signed union authorization card content.
•Auth/session IP addresses or browser/device fingerprints.

Can reveal from Uniform database records

•Your in-app handle and whether the account is active.
•Which organizing spaces your account can access, and what role permissions it has there.
•Encrypted app data (not readable message/post text).
•Anonymous union authorization card receipt hashes used for location-level totals. Our database can tell how many union authorization cards were submitted for a location, but not which accounts submitted them.
•Whether an account is in the billing-gated cohort (not provider/customer billing identity).

This page is technical disclosure, not legal advice.

Technical Profile

5. Technical protocol profile

For technical readers, this is the active runtime profile. Each item also includes a plain-language translation.

Content envelope format

Technical: Protected content uses envelope v2 (`envelope_version=2`, `ciphertext_version=2`, `alg=nacl-secretbox-v1`) with a random nonce per encryption event; non-v2 envelopes are rejected.

In plain English: Content is wrapped in a versioned encrypted envelope instead of stored as readable text.

Key identifier structure

Technical: `kid` values follow `ctx:<context_id>:<epoch>` or `dm:<thread_id>:<epoch>`, and APIs validate scope/target matches before accepting writes.

In plain English: Every encrypted payload points to the right key scope and rotation period.

Epoch binding in stored records

Technical: Post/comment/DM writes store `key_epoch` from the envelope `kid`, so readers can request the exact context/thread key version needed for decryption.

In plain English: Every stored ciphertext is tagged with the key period it was encrypted with.

Group key distribution

Technical: Context/thread symmetric keys are wrapped per recipient using `nacl-sealed-box-v1` envelopes; bulk key fan-out updates `current_epoch` and supports epoch-specific key fetch (`?epoch=` plus `all=1` context history).

In plain English: Each member gets their own encrypted copy of the group key.

Session auth + billing gate

Technical: Session auth uses signed challenges (120s TTL) and short-lived app JWTs (15m TTL). Billing-gated accounts must also present a valid device-bound membership pass before session issuance succeeds.

In plain English: You prove device ownership each sign-in, and paid-access accounts also need an active pass.

Capability enforcement

Technical: Protected social/DM/media/key APIs require `x-uniform-e2ee-capability: v2`; unsupported clients receive HTTP 426 (`E2EE_CLIENT_UPGRADE_REQUIRED`).

In plain English: Old clients that do not meet encryption requirements are blocked.

Media encryption + scoped access

Technical: Media upload/retrieval uses encrypted endpoints and encrypted blob payloads, with access controlled by uploader ownership or context/thread membership via encrypted-media ACL records.

In plain English: Uploaded files are treated as encrypted objects, not open image/text blobs.

Plaintext media path removal

Technical: Image posts require encrypted `media_ids`; plaintext `image_url` submissions are rejected, and legacy plaintext upload/moderation routes are removed or disabled.

In plain English: Images must go through encrypted upload flows, not direct plaintext URLs.

Crypto Payments

6. Crypto payments and anonymity conditions

Complete anonymity is possible when payment is made from a non-identifying wallet/payment alias and no personal billing info is provided.

If identifying billing information is used with any payment provider, that provider may hold identity records outside Uniform app tables.

Uniform’s main app DB does not store processor customer/subscription references and is not the authority for paid access. Paid access is granted only after vault membership-pass verification at session issuance.

The separation reduces linkability from app-side records, but payment-provider-side identity depends on how payment is made.