The whole record, in one place.

The registry is operated by Whisper Security (viaGraph B.V.), Amsterdam, the Netherlands, on infrastructure we hold ourselves. The number resources are real and registered in the RIPE NCC region.

Every agent identity is a normally-allocated, DNSSEC-signed, registry-anchored IPv6 address. The registry record for each /128 refers up to RIPE's own record for 2a04:2a01::/32, so the ground under it is independently confirmable. See the live statistics for current counts.

The registry record is served on the protocols you already speak. None needs a key.

Confirm the DNSSEC trust anchors yourself: the parent carries a DS for each served zone, so a validating resolver can build the chain and set the AD flag.

$ dig +short DS agents.whisper.online @1.1.1.1
54705 13 2 99B88E7C1FD2A815F3DA0374D9FED2C4735F7EFDDB864CB1A79F9D55 43DFE06D
$ dig +short DS whisper.online @1.1.1.1
50855 13 2 3B33E9998425C1F43FCC3B8D4696DB587DB7CEA3F2A235E1556C4C4F 47E247D3

Algorithm 13 is ECDSA P-256 with SHA-256; digest type 2 is SHA-256. The DS values rotate with the keys, so treat the above as a worked example and read your own live answer. Add +dnssec to any forward query (for example dig +dnssec AAAA ae3b051ff3bf7f478.tdc38e7c55bad3306a92b830f9bb1e4f9.agents.whisper.online) and require the ad flag.

Every identity can be checked from a plain terminal. The examples use a live resident, 2a04:2a01:b69a:6717:e3b0:51ff:3bf7:f478; swap in any agent's /128 or its name. Each command is run against the live service and pasted verbatim.

1. Reverse DNS names the address (the address spells itself back, signed):

$ dig -x 2a04:2a01:b69a:6717:e3b0:51ff:3bf7:f478 +short
ae3b051ff3bf7f478.tdc38e7c55bad3306a92b830f9bb1e4f9.agents.whisper.online

2. The forward name points back to the same address (the loop closes):

$ dig +short AAAA ae3b051ff3bf7f478.tdc38e7c55bad3306a92b830f9bb1e4f9.agents.whisper.online
2a04:2a01:b69a:6717:e3b0:51ff:3bf7:f478

3. The agent's key is pinned in DNS itself (DANE-EE 3 1 1, anchored by DNSSEC, no certificate authority in the path):

$ dig +short TLSA _443._tcp.ae3b051ff3bf7f478.tdc38e7c55bad3306a92b830f9bb1e4f9.agents.whisper.online
3 1 1 9EC1EF18A1F15E5480A0FC3C8D6E9690B2CCF1A7FA7146201940F28C 422BB47D

4. The TLS leaf on the wire matches that pin (a DANE-aware client validates the cert against the TLSA record, with no public CA):

$ openssl s_client -dane_tlsa_domain ae3b051ff3bf7f478.tdc38e7c55bad3306a92b830f9bb1e4f9.agents.whisper.online \
    -dane_tlsa_rrdata "3 1 1 9EC1EF18A1F15E5480A0FC3C8D6E9690B2CCF1A7FA7146201940F28C 422BB47D" \
    -connect [2a04:2a01:b69a:6717:e3b0:51ff:3bf7:f478]:443 </dev/null 2>/dev/null | grep "DANE TLSA"
DANE TLSA 3 1 1 ...c273b8184b29... matched EE certificate

The agent's certificate is anchored by the TLSA record in signed DNS, not by a public CA, so a plain curl that only trusts public CAs will reject it — that is the point. Use a DANE-aware client, or the keyless gateway check in step 5, which validates the chain for you.

5. One keyless call checks the whole chain (DANE + the signed identity document + the registry record), returning a plain verdict:

$ curl -s https://rdap.whisper.online/verify-identity/2a04:2a01:b69a:6717:e3b0:51ff:3bf7:f478 | jq '{is_whisper_agent,dane_ok,jws_ok}'
{
  "is_whisper_agent": true,
  "dane_ok": true,
  "jws_ok": true
}

6. The registry knows it by address and by name (RDAP, the canonical record; WHOIS, the same on the legacy protocol):

$ curl -s https://rdap.whisper.online/ip/2a04:2a01:b69a:6717:e3b0:51ff:3bf7:f478 | jq -r .name
scout
$ whois -h whois.whisper.online 2a04:2a01:b69a:6717:e3b0:51ff:3bf7:f478
inet6num    2a04:2a01:b69a:6717:e3b0:51ff:3bf7:f478
netname     scout
...
origin      AS219419
aggregate   2a04:2a01::/32

RDAP also serves the name as a domain object: curl -s https://rdap.whisper.online/domain/ae3b051ff3bf7f478.tdc38e7c55bad3306a92b830f9bb1e4f9.agents.whisper.online returns the signed-DNS / referral view of the same identity.

7. The signed identity document and the did:web record live at the agent's own name. They are DANE-anchored, so fetch them with a DANE-aware client; the keyless check in step 5 already verifies the signed document for you:

$ curl -s https://ae3b051ff3bf7f478.tdc38e7c55bad3306a92b830f9bb1e4f9.agents.whisper.online/.well-known/whisper-identity   # signed JWS identity statement
$ curl -s https://ae3b051ff3bf7f478.tdc38e7c55bad3306a92b830f9bb1e4f9.agents.whisper.online/did.json                        # W3C did:web document (same key)

8. And the agent's SSH key fingerprint is in DNS too (SSHFP, so an SSH client can verify the host key from signed DNS):

$ dig +short SSHFP ae3b051ff3bf7f478.tdc38e7c55bad3306a92b830f9bb1e4f9.agents.whisper.online
3 2 9335418b3b03a5180ada334724917ca2a5d529066305f8a404a139f6 fa1370c8

Every one of these is independent, runs against the live service, and depends on signed DNS and your own tools, not on trusting us. The registry record links straight up to RIPE's own record for 2a04:2a01::/32, so even the ground under it is theirs to confirm.

You can put the registry under a domain you already own. You bring the domain; we run the network and the registry that vouch for the identities inside it. The proof is the delegation itself, observed live in the wild — there is no token to copy.

example.com.   NS   ns1.whisper.online.
example.com.   NS   ns2.whisper.online.
example.com.   DS   <digest 2 (SHA-256) and 4 (SHA-384)>

You keep your own zone signed end to end; an unsigned parent breaks the chain at your boundary, not ours. We tell you not to add glue for our out-of-bailiwick nameservers. This onboarding flow is being rolled out under this campaign; until it lands for your account, your agents live under agents.whisper.online exactly as the rest of this record describes. The plain-language walkthrough, with copy-paste examples under YOUR-DOMAIN.COM, is on the main site: whisper.online/bring-your-own-identity.

Once a domain is onboarded and proven, new agents are minted directly under it, as a<hex>.<yourdomain>, instead of under agents.whisper.online. The whole record — reverse DNS, RDAP, WHOIS, DANE, and the signed identity document — follows the name into your domain.

The multi-zone serving engine that makes this possible is live; the per-account onboarding and the full RDAP/WHOIS/reverse coverage for custom domains are rolling out under this campaign. Until then, every identity is minted under agents.whisper.online.

Each identity carries an append-only, hash-chained record of its events — issuance, rotation, revocation — signed by a dedicated log key with a published key id. You can read it today, per /128:

$ curl -s https://rdap.whisper.online/ip/2a04:2a01:b69a:6717:e3b0:51ff:3bf7:f478/transparency | jq '{count,root_hash,root_signature_alg}'
{
  "count": 1,
  "root_hash": "...",
  "root_signature_alg": "ES256"
}

The record returns the event chain plus a signed root, so a revocation cannot be quietly erased from an identity's history. As of the transparency-log rollout (live since 0.112.0), this per-identity feed is anchored in a single append-only Merkle log of all identity commitments, with the public proof surface below.

The public proof surface live

The whole log is published, keyless, on the same gateway. Every endpoint below is run against the live service and pasted as it answers.

Fetch the log key and the signed checkpoint (the trust anchor; the checkpoint Link header points at the key):

$ curl -s https://rdap.whisper.online/checkpoint/key
{"object":"whisper-ledger-key","origin":"whisper.online/ledger","alg":"Ed25519",
 "key_id":"8a3a5df0","public_key":"pyTBKL3bSJO7kBbdw4FqJsjREW23jNP07HybKByIabg="}
$ curl -s https://rdap.whisper.online/checkpoint
whisper.online/ledger
1
Ux6ZqO3+QDdWjTWSnyLJAeAu0WlkD70+AcJWSuJURIM=

— whisper.online/ledger ijpd8L311mCaWM1DkXyS8P0NgPH5F+YZmftiifaUoYbMq680avzBKRe6wI1yCNTakRWvK8ha1C5d6OaPXLoO43Vn3Qg=

Lines are: the origin, the tree_size, the base64 root hash, then the signature line — <origin> <base64(key-id || Ed25519 sig)>. The first four bytes of the signature blob are the key id 8a3a5df0, which you can re-derive yourself as SHA-256(origin || 0x0A || 0x01 || pubkey)[:4] — so the key the checkpoint is signed with is the one published at /checkpoint/key, with nothing to trust in between.

A worked example, from the tree

A real resident in the log: ae3b051ff3bf7f478.tdc38e7c55bad3306a92b830f9bb1e4f9.agents.whisper.online at 2a04:2a01:b69a:6717:e3b0:51ff:3bf7:f478. Its ledger arm shows it at leaf index 0. The tree currently holds a single leaf, so the inclusion proof is empty and the leaf hash is the root:

$ curl -s https://rdap.whisper.online/ip/2a04:2a01:b69a:6717:e3b0:51ff:3bf7:f478/transparency \
    | jq '.ledger'
{
  "object": "ledger-inclusion",
  "origin": "whisper.online/ledger",
  "tree_size": 1,
  "leaves": [
    {
      "index": 0,
      "leaf_hash": "531e99a8edfe4037568d35929f22c901e02ed169640fbd3e01c2564ae2544483",
      "inclusion_proof": []
    }
  ]
}

Identities minted before the log do not yet carry a leaf — their ledger.leaves is [] until a genesis back-fill folds them in. An empty leaves means “no Merkle leaf yet,” not “not an agent”; the per-/128 hash-chained feed above still covers them.

Verify it yourself, with stock tools

No SDK, no key. The leaf commitment is sha256(salt || event); the Merkle leaf is sha256(0x00 || commitment); interior nodes are sha256(0x01 || left || right). Fold the published inclusion_proof up to the root in the signed checkpoint, then check the Ed25519 signature with the published key. For the single-leaf tree above the proof is empty, so the check reduces to “leaf == root” — which the published bytes prove outright:

# 1. the published Merkle leaf hash for index 0 (raw 32 bytes from the tile):
$ curl -s https://rdap.whisper.online/tile/0/0 | sha256sum   # the tile IS the 32-byte leaf
$ curl -s https://rdap.whisper.online/tile/0/0 | xxd -p -c64
531e99a8edfe4037568d35929f22c901e02ed169640fbd3e01c2564ae2544483

# 2. the root in the signed checkpoint (base64 line 3), decoded to hex:
$ curl -s https://rdap.whisper.online/checkpoint | sed -n '3p' | base64 -d | xxd -p -c64
531e99a8edfe4037568d35929f22c901e02ed169640fbd3e01c2564ae2544483

# 3. empty inclusion_proof => leaf == root: the two hex strings match. Done.
#    For a multi-leaf tree, fold each proof step instead:
#      node = sha256( 0x01 || left || right )   # RFC 6962 interior hash
#    until you reach the checkpoint root, then verify the Ed25519 signature
#    line with the key from /checkpoint/key.

Or one command with the CLI verifier (same stock crypto — Ed25519 + SHA-256 + RFC 6962 folding — wrapped up). checkpoint verifies the signed root; verify proves a disclosed event is in the tree (the subject hands you the salt and the canonical event out of band — that is the selective disclosure):

$ whisper ledger checkpoint                         # fetch + verify the signed checkpoint
whisper: checkpoint VERIFIED — signed tree of 1 leaves
$ whisper ledger verify 2a04:2a01:b69a:6717:e3b0:51ff:3bf7:f478 \
    --salt <hex> --event-file event.bin           # prove a disclosed (salt, event) is in the tree
whisper: VERIFIED — the disclosed commitment is in the signed ledger at leaf 0 of 1