Case study — Flashy Network
Counting an intention once, however many ways it is observed
- Scale
- A fan-in step on an RFC 6962-style transparency log covering every property in a nine-property estate.
- backlog/1 domains newly folded into the log
- 6
- Self-published sources excluded to prevent double-counting
- 3, named with reason
- New tests covering the fold path
- 8
The challenge
An append-only transparency log records hashes, never content, and it is only honest if each underlying fact lands on it once. backlog/1 items — a property’s stated intentions, filed privately and either decaying unpromoted or promoted to public — needed to become leaves on the log. But three properties already ran their own emitter, publishing an already-shaped intent/1 fragment directly into the log’s source register. backlog/1 and intent/1 describe the same underlying fact — an org’s stated intention — under two different version keys. Fold the new format in by property name and those three properties’ items would land on the log twice: once through their existing intent/1 source, once again through the new backlog/1 path.
The approach
Reuse the shared leaf-shaping helper, not a second implementation of "hash this"
backlogToFragment, the new fold path, builds each leaf through the same leafFromBytes helper every other kind in the fetcher already uses — the notary log stays what it always is, hashes never content, and a new source shape does not mean a new way of sealing one.
Filter at the fold as defense in depth, even though the source should already be clean
A leaf is only built from an item where visibility === 'public' && promoted — the fold refuses to seal anything not already public, even though a correctly served backlog.fragment.json should never contain a private item in the first place.
Exclude the three properties by name, with the reason written down beside the exclusion
notary-sources.json’s own comment names it directly: gdagroup, goldholdings and intentmesh are deliberately left out of the new backlog register because they already self-publish a fully-shaped intent/1 fragment under the existing sources list, and listing them a second time under backlogs "would fold the same items under two different source names." Six other backlog/1 adopters — flashyos, flashygold, flashynetwork, claimyourgold, academy, flashyid — were verified live against their own /.well-known/backlog.json before being added; a seventh, flashygroup, is named as adopting the format but withheld from the register until its host can actually be reached to confirm the URL.
The outcome
The fold path shipped with its own describe block in the fetcher’s test suite — eight tests covering the shape conversion, the public-and-promoted filter, the deterministic hash, and the ref format a holder can refetch — alongside the existing coverage for checkpoints, shiplogs and devlogs the same fetcher already folds. The three properties publishing under intent/1 keep exactly one source name each; the six new backlog/1 adopters gained a fine-grained presence on the log with zero per-property emitter, because every one of them already publishes the shape by re-vendoring the same backlog script the rest of the estate runs.
The platforms this evidences
Considering something similar?
The capability above is licensable independent of this engagement — see the platform page for what is and is not white-labelled.