Check the claim
Last updated
The claim is that an operator running the relay, including us, cannot read message bodies, ticket text or media. An unverifiable claim is marketing, so this is the procedure for checking it. A reviewer with a terminal should get through it in under an hour, and every step here has an automated counterpart in our own build.
Each step below is independent and has its own link. Step 4 is the one that convinces people, and it takes about two minutes.
1. Reproduce the build
Clone the relay source at the tag matching the digest your client shows, run the reproducible build, and compare the digest it produces.
git clone --branch wealdrelay-v0.1.5 https://github.com/Weald-Protocol/wealdrelay && cd wealdrelay && ./scripts/relay-reproduce.sh
2. Compare against the published release
The release feed is public and unauthenticated, so a self-hoster can check a relay they run without an account.
curl -s https://api.weald.team/v1/releases | jq '.latest_digest, .latest_version'
Your client shows the digest its relay reported, in the encryption panel. A relay running something no release carries raises a banner for every connected user.
Note what this is worth. A modified relay can misreport its own digest, so this catches deployment drift and operator mistakes rather than proving what a remote host executes.
3. Watch the traffic
Capture the relay socket and confirm the envelopes are opaque, and that the only fields the relay reads are the header ones: group, epoch, sequence, size, time.
tcpdump -i any -w relay.pcap port 443 and host $YOUR_RELAY
4. Dump the database
Send yourself a message containing a distinctive phrase, then look for it in the relay's own Postgres.
psql $RELAY_DATABASE_URL -c 'select * from envelopes limit 5' | grep -i 'your phrase'
It returns nothing but blobs. The ciphertext column is MLS output and the relay has no key for any of it.
5. Compare safety numbers
Open a channel's member list on two devices and read the safety number aloud to each other. Sixty digits, derived from the group's ratchet tree.
If somebody was added silently, the numbers differ. That is the whole check, and it is the one a member can do without a terminal.
6. Verify the transparency log
Every epoch change is hash-chained from a genesis entry naming the trust root your relay printed at first run. Verify the chain, then check the genesis entry against the fingerprint you recorded when you enrolled.
weald verify --transparency-log --since genesis
7. Prove the relay cannot fork history
On two clients, compare head attestations for one group and confirm they agree. Then block one client's attestations at the relay and confirm both raise a split-view warning within two rounds.
Silence has to alarm as loudly as contradiction. This is the step that proves it does.
8. Revoke a device
Confirm the relay reports access-set enforcement, then revoke a test device and watch its connection drop within seconds. Repeat with a device that joined minutes earlier on a still-live invite.
9. Check the recovery wraps
Dump the recovery wrap table. The index rotates every epoch and no value recurs across two groups, which is what stops the wrap index being a membership graph.
psql $RELAY_DATABASE_URL -c 'select group_id, wrap_index from recovery_wraps'
What we will never ship
- A server-side search index, in any form.
- A support tool that reads workspace content.
- A notification service that renders previews on a server.
- A hosted-only relay build.
- Client telemetry carrying content-derived values.
- A key escrow, or an operator-held group membership.
Any feature needing one of these is a change to the trust boundary, and it gets argued in those words rather than shipped as an improvement.