Overview
| Comment: | RFC 0005: state what the clone counters count |
|---|---|
| Timelines: | family | ancestors | descendants | both | clone-counts |
| Files: | files | file ages | folders |
| SHA3-256: |
c83148c71de0ee3dd7e258217f4c1736 |
| User & Date: | dmestas on 2026-08-24 19:16:49.423 |
| Other Links: | branch diff | manifest | tags |
Context
|
2026-08-24
| ||
| 20:16 | Suite green; merges clean. Proven against a real server: two clones read 2, a pull leaves it at 2. check-in: bc4fbd1c79 user: dmestas tags: trunk | |
| 19:16 | RFC 0005: state what the clone counters count closed check-in: c83148c71d user: dmestas tags: clone-counts | |
| 19:16 |
Count clones and fetches
A clone reads and writes nothing, so it is the one kind of forge activity that leaves no trace in the DAG at all. The sync edge classifies the protocol's cards: clone SEQNO 1 opens a new clone, later rounds do not, so a big store cloned in forty rounds still counts once. Two sinks: the vocabulary event for anything reacting, and a JetStream counter for how many, which converges across nodes instead of losing increments to a read-modify-write. check-in: dc058fa551 user: dmestas tags: clone-counts | |
Changes
Modified docs/rfcs/0005-event-vocabulary.md
from [db6350e4d1]
to [439334fe0a].
[diff]