- Participate - Witness-network mailing lists

Participation request: Thelemail key transparency log (staging)
by Vladislav Gorokhov 28 Aug '26

28 Aug '26

Hello Witness Network maintainers, We would like to enroll Thelemail’s key-transparency log in the Witness Network staging environment. Operator: Thelemail Origin: thelemail.com/keys Log public key (Ed25519 vkey): thelemail.com/keys+76ead63c+ASduViYkPgYHzuTuDnuTdEkjR/DIprnavuFA3vom4YZT Checkpoint URL: https://tlog.thelemail.com/checkpoint Add-checkpoint rate: At most one request per second per witness. In practice, the rate should be significantly lower while the log receives few updates. Requested log list: staging/log-list-10qps-4klogs.1 Contact: security(a)thel.email Purpose: This is a long-lived transparency log used by Thelemail’s encrypted email service. It records privacy-preserving, VRF-addressed statements binding Thelemail addresses to their public encryption and signing keys. The log is already serving real users, although current traffic and log growth are small. We are happy to dogfood the staging Witness Network while production is unavailable. Public information: https://thelemail.com/keys Current checkpoint: https://tlog.thelemail.com/checkpoint Open-source log implementation: https://github.com/thelemail/keylog The log uses Tessera and C2SP-compatible checkpoints and proofs. Please let us know if you need additional information or would prefer a different staging log list or request rate. Best, Vlad Thelemail

2 1

Witness participation request: GBLIN Protocol (testing/log-list.1)
by GBLIN 23 Aug '26

23 Aug '26

Hello, We would like to participate in the Witness Network as a witness operator, starting with the testing list. Operator name: GBLIN Protocol Lists: testing/log-list.1 About page: https://gblin-mcp.gblin-mcp-worker.workers.dev/witness Witness name: gblin.digital/witness Verifier key: gblin.digital/witness+c335a002+BF54nC8Q1wHAlKirQexRC5phxjLtbEhcq8udv8TXPwXx add-checkpoint: POST https://gblin-mcp.gblin-mcp-worker.workers.dev/witness/add-checkpoint Contact: info(a)gblin.digital Discovery works as your guidelines ask: the list is downloaded once a day and used only to discover logs we do not know yet. A log we have already configured is never removed or modified because the list changed - the list is not our configuration file. As of today the witness has configured all nine logs currently in testing/log-list.1 and accepts pushed checkpoints from each of them; the about page enumerates them with the date each was added. To be precise about what is actually exercised: we accept pushes from all nine, but we actively poll only one log today, markovianprotocol.com/log, which we have been co-signing every ten minutes since 18 August. That is where the implementation was first tested against a real tree. On the protocol side we implement c2sp.org/tlog-witness: a checkpoint is accepted only if it verifies against that log's key, and, when we already hold a smaller tree for that origin, against a consistency proof; on success we return a c2sp.org/tlog-cosignature line. Sizes we hold are returned as 409 with the held size, a shrinking or forked tree gets 422. We keep one persistent record per log plus the history of cosigned notes. Two things you should weigh honestly. First, we are a small operator running this on Cloudflare Workers, so please read it as a testing-grade witness, not a production guarantee. Second, we also operate our own application transparency log (gblin.digital/receipts-log) and would eventually like it witnessed - but we are asking to give before we ask to receive, and the two requests are separate. Happy to answer questions or fix anything that does not match your expectations. Best regards, GBLIN Protocol https://gblin.digital Inviato con la posta elettronica sicura [Proton Mail](https://proton.me/mail/home).

2 1

Log participation request: gblin.digital/receipts-log (testing list)
by GBLIN 22 Aug '26

22 Aug '26

Hello, We would like our log added to the testing list. Origin line: gblin.digital/receipts-log Public key: gblin.digital/receipts-log+00c6e18c+AY8/YnCHXTnsECT2EGv0M5RTqlVvFobctLv3WSihYkoG Checkpoint: GET https://gblin-mcp.gblin-mcp-worker.workers.dev/log/checkpoint add-checkpoint rate: at most 24 times per day, in practice far less - the log only grows when an agent seals something, which today is a handful of records per day Log list: testing Contact: info(a)gblin.digital - https://gblin.digital What the log is, briefly: an append-only RFC 6962 log whose leaves are records of AI actions - an agent submits the SHA-256 of its input and output plus a public label, and receives a portable receipt (signature, inclusion proof, signed checkpoint). The tree root is additionally anchored once a day on a public chain. Design note, including what a receipt does NOT prove: https://github.com/gblinproject/gblin-treasury-risk-regime/blob/main/docs/a… We implement the log side of c2sp.org/tlog-witness as of 21 August: on every size change we POST "old <n>", an RFC 6962 consistency proof and the signed note to each configured witness, retry from the size a witness reports in a 409, and store the returned cosignature bound to the exact (origin, size, root) it was issued for. A stored cosignature is served in /log/checkpoint only while it still matches the current size, never re-attached to a later tree. Who cosigns, and at which size, is public at /log/witnesses. Useful for your decision: the log is tiny - 18 leaves today, most of them our own tests - so the load is negligible and so, honestly, is the current utility to anyone but us. It is operator-signed only, which is exactly why we are asking. Anyone can check it without trusting us: /log/checkpoint, /log/consistency, /log/leaves (raw records, rebuild the tree yourself) and a zero-dependency offline verifier in the repository. If you would rather we come back when the log carries real third-party usage, that is a fair answer. We are separately asking to participate as a witness operator for testing/log-list.1. Best regards, GBLIN Protocol https://gblin.digital Inviato con la posta elettronica sicura [Proton Mail](https://proton.me/mail/home).

1 0

Re: participation question for an autonomous-agent action log
by Blake Morrison 19 Aug '26

19 Aug '26

Hi Tony, I subscribed to the list after your post so this is not threaded to it. Not a maintainer, so take the first half as a reader of the same archive rather than an answer. On process, the intake reads as plumbing rather than scale. Origin line, key format, a declared rate budget, a contact that answers. Rasmus Dahlberg has replied to nearly every thread on that list since October, and the testing tier says expect breakage, so the bar looks like sincerity. Two of the recent requests have no reply at all, which is worth knowing before you read silence as a no. On substance, the thing I would nail before submitting. A log of allowed and stopped actions carries a claim the log cannot recompute, which is who authorised the allow. Inclusion and consistency a verifier recomputes from your bytes with no issuer in the path. The authorisation is attested by whoever ran it. Worth saying which of your claims rests on which, because independent witnessing fixes the first and leaves the second where it was. Blake

1 0

markovianprotocol.com/log — staging list interest
by hello＠quantsynth.net 17 Aug '26

17 Aug '26

Hello, markovianprotocol.com/log has been on the testing list since July. We'd like to be considered for a staging list when smaller logs can move up. Since enrolling we've built the surface out; everything below is live and checkable: - Quorum-gated publication: /checkpoint serves only checkpoints cosigned by at least 4 of our 7 pinned witnesses, each cosignature cryptographically verified before publication. The policy is machine-readable at https://log.markovianprotocol.com/policy (c2sp.org/tlog-policy) - Offline proof bundles per leaf at /proof/<index> (c2sp.org/tlog-proof) - c2sp.org/tlog-tiles static tiles, RFC 9942 COSE receipts at /receipt/scitt/<index>, and hourly OpenTimestamps anchoring of the checkpoint bytes, with anchor roots checked against self-validated Bitcoin headers (state at /anchor). - A public hash-only submission door: POST /submit takes a sha256 and returns a receipt with proof URLs; nothing but 32 bytes of hash ever enters the log. Browser drag-and-drop version at https://markovianprotocol.com/log.html. - A standing open-source monitor (https://github.com/MarkovianProtocol/log-monitor) that verifies the log signature, every cosignature against pinned keys, consistency from its last head, and recomputes the root from served leaves, hourly. Anyone can run their own copy against us. - Dense-sequence completeness streams inside the log, so a reader can verify statements were not withheld, not just unaltered. We also run a witness on the test witness table (witness.markovianprotocol.com) and cosign whisper.online's log. Our declared rate stays 24 add-checkpoints/day. What would you need from us for a staging move? Thanks, Colin Winter Markovian Protocol — hello(a)markovianprotocol.com

2 1

Pre-application: intent to submit a log for witnessing
by Christopher Baber 10 Aug '26

10 Aug '26

Hello, I'm writing ahead of a formal participation request to introduce our log and ask two questions. We operate AControlLayer, an agent governance platform. We're building a transparency log over authorization records - each leaf is a commitment (hash plus signature) to an attestation held in our own storage; no payload content goes into the log. We intend to run Tessera emitting C2SP tlog-checkpoint v1.0.0 checkpoints, with a low publication rate - on the order of 24-96 checkpoints per day, batched rather than streamed. We don't have a stable origin or checkpoint key yet, which is why this isn't a formal request. Two questions: 1. Is there a timeline for the production witness tier? Both the witness table and log list pages currently read "Production - Not available yet," and we'd like to plan our cutover rather than guess at it. 2. Is a log of this kind - governance attestations rather than software supply chain artifacts - in scope for the network? We saw non-CT third-party logs in the staging and testing lists and want to confirm before we build toward it. Happy to provide anything useful. We'd rather establish the relationship early than arrive at enrollment with questions. Thank you, Christopher Baber AControlLayer chris(a)acontrollayer.com (828) 275-1315 www.acontrollayer.com

2 1

Re: Witness participation request: markovianprotocol.com/witness
by hello＠quantsynth.net 29 Jul '26

29 Jul '26

Hello, Following up on my witness participation request from July 20 (markovianprotocol.com/witness, testing list). Since then the witness has moved to a datacenter and has been cosigning the testing-list logs continuously — current state at witness.markovianprotocol.com/about. With the Rekor production log onboarding in witness-network#48, I'd like to get the listing settled. Happy to provide anything else you need. Colin Winter

2 1

Witness Network participation — markovianprotocol.com/witness (testing tier)
by Colin Winter 20 Jul '26

20 Jul '26

Hi, I'd like to add my witness to the Witness Network at the testing tier. Operator: Colin Winter / markovianprotocol.com List: testing Verifier key: markovianprotocol.com/witness+41b8827f+BJKLl8rBYM0oUxSaWh9rjTldTprEpYj/SWVI… About: https://witness.markovianprotocol.com/about Add-checkpoint: https://witness.markovianprotocol.com/add-checkpoint It implements c2sp.org/tlog-witness (cosignature/v1) and follows the testing log-list, refreshed hourly, configuring new logs automatically and never removing or re-keying a log it has already configured. It currently cosigns two of Mullvad's sigsum test logs, vindex.gopherwatch.org, and whisper.online/ledger; /checkpoints shows the latest per log. Gregoire at Mullvad suggested I list here. Happy to follow whatever the process is. Colin Winter markovianprotocol.com

1 0

Log participation request: whisper.online/ledger (C2SP tlog-tiles)
by Kaveh Ranjbar 14 Jul '26

14 Jul '26

Hello, We'd like to enroll our transparency log with the Witness Network. It's a self-hosted C2SP tlog-tiles / RFC-6962 log for per-operator agent network identities. It emits conformant C2SP signed-note checkpoints (Ed25519, log-signed) and serves RFC-6962 consistency proofs, so a stock tlog-witness can cosign it with no bespoke integration. origin line : whisper.online/ledger vkey : whisper.online/ledger+8a3a5df0+AackwSi920iTu5AW3cOBaibI0RFtt4zT9Ox8mygciGm4 checkpoint : https://whisper.online/checkpoint <https://www.google.com/url?q=https://whisper.online/checkpoint&source=gmail…> (verbatim C2SP signed note) key : https://whisper.online/checkpoint/key <https://www.google.com/url?q=https://whisper.online/checkpoint/key&source=g…> consistency : https://whisper.online/consistency?from= <https://www.google.com/url?q=https://whisper.online/consistency?from%3D&sou…><a>&to=<b> (RFC-6962) tiles : https://whisper.online/tile/ <https://www.google.com/url?q=https://whisper.online/tile/&source=gmail&ust=…><level>/<index> (tlog-tiles) add-cp rate : bursty; we will throttle add-checkpoint submissions to at most a few per minute and respect each witness's stated rate limit tier : testing (to shake out conformance first; then move to staging) contact : kaveh(a)whisper.security The checkpoint is a proper signed note: line 1 = origin, line 2 = tree size, line 3 = base64 RFC-6962 root, followed by a 68-byte Ed25519 note signature whose key-hash 8a3a5df0 matches the vkey above. We keep the origin and key immutable and never rewind the tree. Thank you, Kaveh Ranjbar, Whisper Security (viaGraph B.V.)

2 1

Log participation request: markovianprotocol.com/log (testing)
by Colin Winter 14 Jul '26

14 Jul '26

Requesting addition to the testing log list. Origin line: markovianprotocol.com/log Public key (vkey): markovianprotocol.com/log+0302c6c8+ATkpOWo95UuEiW2EhNZAol4f0CS8hMluJfPcTSzr… (key type 0x01, Ed25519) Add-checkpoint rate: at most 24 per day (hourly) Log list: testing Contact: hello(a)markovianprotocol.com The log implements c2sp.org/tlog-checkpoint and serves: checkpoint https://log.markovianprotocol.com/checkpoint consistency https://log.markovianprotocol.com/consistency?old=<n>&new=<m> inclusion https://log.markovianprotocol.com/inclusion?leaf=<i>&size=<m> The add-checkpoint client is implemented and tested against a tlog-witness; consistency proofs are served from size 1. Colin Winter

2 1