Check the claim
Last updated
An operator running the relay, including us, cannot read message bodies, ticket text or media. This page is the procedure for checking that claim. A reviewer with a terminal can finish it in under an hour, and every step has an automated counterpart in our own build.
Each step below is independent and has its own link. Step 4 takes about two minutes and is the most direct check.
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.43 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.
A modified relay can misreport its own digest. This step catches deployment drift and operator mistakes and cannot prove what a remote host executes.
3. Watch the traffic
Capture the relay socket and confirm the envelopes are opaque. The relay reads header fields and nothing else: group, epoch, sequence, size and 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'
The query 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. It is sixty digits, derived from the group's ratchet tree.
If somebody was added silently, the numbers differ. A member can run this check 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.
This step proves that a silent relay raises the same alarm as a contradicting one.
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, so the wrap index cannot serve as 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 changes the trust boundary and is argued as that change.