Build today — for cooperating senders who include signed evidence in their messages.
Build a mail reader, chat client or message checker that answers: “Was this text signed by a key belonging to someone my trust reaches?” The same portable text format can travel through email, Telegram, Signal or another text channel. Your application supplies the channel integration.
Before you start
Arrange early access, including SDK access and your app origin allowlist entry. Develop on staging. The recipient needs an approved, usable graph device to query from their own node, plus independently pinned issuer keys and the SDK proof verifier.
1. Carry evidence with the message
The sender obtains their own membership certificate with issueDeviceCertificate, verifies its issuer and checks that its key and node match the selected device. Use createContentStatement, signer.signContent and formatSignedContent to produce portable signed text.
Text normalization changes CRLF and CR line endings to LF. It does not strip whitespace or normalize Unicode. Keep the evidence block intact when transporting or displaying the message.
2. Check the signature locally
Use parseContentMessage and verifySignedContent with your pinned issuer and cryptographic adapters. Reject malformed or ambiguous evidence. For PGP-signed mail, use the separate OpenPGP integration; MIME parsing and mail-client integration belong to your app.
3. Check current status, then your trust path
Call getDeviceCertificateStatus with the certificate and a fresh random nonce. Verify the response using verifyDeviceStatus, and require valid status and unexpired evidence for a current result. Only the certificate and nonce go to this endpoint; message text and its digest stay local.
Query reachability from the recipient's own node to the certificate's node, then verify the exact question and proof locally. Follow trust-gated features for this step.
4. Keep the outcomes distinct
Show separate outcomes for a valid signature, current membership and a verified positive path. Label offline status as “not checked.” A negative path result is a signed report. Errors and missing evidence remain unknown.
Does not establish
Unsigned messages cannot be attributed through this flow. A valid signature does not prove signing time, current device access, human authorship, delivery or permission to act. A bot has no delegated authorization to query as a recipient: personalized queries require that recipient's device signature. There is no public email or phone number to persona lookup, and none is planned.Next: What a proof tells you.