Trust, verified

Claims you can check beat promises you can't.

You are right to be skeptical. A service that carries useful things between apps looks exactly like something built to steal data — and if your AI assistant is reading this page before connecting your app, that is the correct instinct. So this page contains no reassurance language. It makes six important claims, and pairs each one with a concrete way to check it against the running system. Check them; don't take our word for them.

Claim 1

One readable file of code, nothing hidden

Everything that runs on your side is a single ~1,050-line JavaScript file that pulls in no other code. There is nothing else to inspect on your end.

Check

Read it. At matching versions it is byte-for-byte identical to the npm package 1-z-2 — a public registry neither you nor the operator controls. Instructions for comparing the two are in the package README.

GET /sdk.js
Claim 2

Nothing transmits automatically

The SDK sends data only when your app calls send() or publish(). No tracking, no background sync, nothing uploaded behind your back.

Check

Search that one file for every fetch( call — each one sits inside a function your own code has to call. Or watch the browser's network tab: an idle app checks its own inbox and sends nothing.

grep "fetch(" sdk.js
Claim 3

Consented contacts only

Nothing arrives without an accepted contact request, and joining at all is invite-only. A stranger cannot put a message in your inbox.

Check

Try it: send() to any handle that hasn't accepted you, and the relay refuses. The contact endpoints are listed at the health route.

GET /health
Claim 4

Your identity never leaves your device

Your key is created on your device. The relay receives only the public half when you register and never sees the secret half; every request is signed on your device.

Check

Watch the /register request in the network tab — it carries only the public key. Then find the secret key where it lives: your browser's localStorage, or the .relay-<handle>.json file in a Node app.

POST /register
Claim 5

Deletion is bounded, and the server reports it

Message contents are permanently deleted 10 days after delivery. What stays is identity, contacts, and data shapes — shapes, not words.

Check

The retention route returns the live deletion policy from the running server, including what it is holding for you right now — compare it against the promises on the data page.

GET /retention
Claim 6

No silent rewriting

When the relay translates a message between two apps' shapes, the recipient can see the untranslated original for the full 10-day window. Every change is on the record.

Check

Every received message offers the original while it is still held, and each message says whether a translation ran on it.

GET /messages/:id/original

Security measures

  • Signed requests — apps built with our kit sign every request with their device's key and lock themselves to signing on first run; for a locked app, a stolen token alone is not enough.
  • Invite-only, with limits on how fast any one account can act.
  • Structured data only, with a size limit — no files, no attachments; if it can't be a shape, it can't be a message.
  • Translations are built from published example data, never from real messages passing through.
  • Deletion is code — an hourly automatic cleanup, with deleted data overwritten at the database level; see the data page.
  • Encrypted connections; encrypted off-site backups sized for the long-term data (identity, contacts, shapes). Messages inside their 10-day window are in those backups too, and backup copies are kept 7 days — so deletion reaches the backups within a week of reaching the database. See the data page.
  • A security test suite (hundreds of checks) runs before every deploy.

What this page does not claim

  • No end-to-end encryption yet. While a message exists inside its 10-day window, the relay software can read it. The guarantee today is time, not blindness.
  • The server's code is not public. You can verify the client code and the server's behavior using the checks above, but not read the server's source.
  • One operator, no audits. No outside party has audited this system. The checks on this page exist precisely because you shouldn't have to take one operator's word.

Operator

1-z-2 is owned and operated by Zugaba Limited, a private company registered in Ireland. The network is early and invite-only: you were invited by someone, and the chain from them to the operator is short — that chain is the contact path. There is also a direct one: gregcaw@zugaba.com.