read a sealed person, verified before rendering
This reader fetches the sealed lineage corpus, re-hashes every byte it shows, and renders a person's research page only after the page's own digest matches the seal. Anything missing or corrupted fails closed — an unverified byte never renders.
who, and against which root
The pin is the trust boundary. Take it from a channel no rail controls — the committing git history or the lane dispatch — never from a fetch. Without a pin this reader can only check internal consistency, and says so. the commit history on GitHub (opens a new tab) is one independent channel.
rails
- GitHub Pages — bootstrap — same-origin static fetch of the committed corpus (qualified)
- Arweave — declared rail; adapter-arweave browser route not yet qualified
- Autonomi — declared rail; adapter-autonomi browser route not yet qualified
- x0x — declared rail; ops/x0x mesh route not yet qualified
A rail that serves bytes disagreeing with the pin is named in the reading log and the next qualified rail is tried — the pin, not the rail, decides what is sealed. There is one qualified rail today.
the reading
idle — nothing fetched, nothing rendered
- person
- era
- familysearch refs
- record arks
- page html
- page json
- state root
- served by