XPlorer following the chain as its own read-only node

height 25517 of 25517 on the network. 9 peer(s) connected, 92 in its peer directory; 2813 block(s) followed and 2293 pulled in by sync since this follower started. Caught up: this follower holds every block any peer has claimed, so every panel below is the whole chain. Genesis 1cf8655125cc1bbb…, producers genesis.

What this follower is, locally

Following 7 seed(s) — their addresses are not published here, for the reason the peer table gives. Its store is held under its own Cerberus lease — no other node’s store is opened, touched or stopped.

STR.talk

STR.talk puts on the chain that a message passed and never what it said. A post carries a position in the thread and a salted commitment; the envelope stays off chain, because a chain stores a thing once and every node then keeps it forever — ciphertext in a block is ciphertext held by whoever breaks that cipher in twenty years. The inbox keys below are public by nature and are the reason a sender cannot be handed a man in the middle by a relay. The thread figures are counts and stay counts.

Inbox keys published0

published whole and on purpose. A sender who asks a relay where to seal a message has been handed a man in the middle by construction, and no amount of post-quantum in the key agreement repairs an answer from the wrong party

Threads opened0

carrying 0 message commitment(s) and 0 acknowledgement(s). A census and not an index: no participant, sender or reader is named anywhere on this page

Messages on this chainnone, by construction

the chain holds commitments. The messages themselves are not on it, were never on it, and there is no field on this surface one could be rendered from — which is why this reads as a refusal and not as a zero

What this page will not show, and why. An index of which domains are in threads together is a social graph, which is the one property STR.talk does not hide — so it is the one a public explorer should not make easy. Held back here:

which domains are in which thread — the participant sets on open and rekey records
who sent which message — the sender domain on a post record
who acknowledged which message — the reader domain on a receipt record
any per-domain thread or message count, which reconstructs the first three

Each of these is on the record, in the records root, and held by every node on the network. The individual rows are rendered in the block that carried them, under /block/{height}/occultation, with the same fields withheld.

Folded from 25,518 block(s), genesis to 25517

Folded from every block this node holds, genesis to 25517. Each of these registers is state the chain keeps and the explorer’s read-only port does not expose, so the records in the blocks are replayed here — the same arithmetic every node performed to accept them.

Inbox keys (0)

Published whole, deliberately. A sender who asks a relay where to seal a message has been handed a man in the middle by construction, and no amount of post-quantum in the key agreement repairs an answer from the wrong party. The chain carries these so that two nodes cannot disagree about them.

No domain has published an inbox key

An inbox key is where a sender is entitled to seal a message to a domain, and it is on the chain precisely so that nobody can answer that question differently to different senders. None has been published in a block this node holds, so there is nowhere on this chain a message can be sealed to anybody yet.

What would put something here

a proved STR.domain, which is what may publish a key at all
a publish record carrying the suite and the public key to seal to
a replacement, which is a later record and never an edit — a superseded key cannot be replayed back into force

The domains that could publish one · The suite it would use