mirror of
https://github.com/Twigpine/node.git
synced 2026-11-12 19:13:02 -10:00
f426fe8399
* docs: document the two-tier storage and pinning model * docs: clarify pin de-duplication is best-effort, not atomic * docs: address review — fix table/no-op/peer/budget claims, link from README * docs: name the hot tier as the unbounded side of the parked-list memory Also record the two wording residuals from the same round: dedup isolation is one-directional (warm row presence suppresses a later hot pin), and an unset Pinata JWT disables uploads but not the tail's permit + walk cost. * docs(node): narrow the storage doc to its pinning charter, fix the Durability bullet - opening now says what the page is: optional post-push pinning tiers in ipfs_pin.rs and pinata.rs, with one pointer to bare-repo storage so the page does not read as the answer to "where is my data?" - the "Running both" Durability bullet now carries the warm-first caveat the dedup paragraph already documents: an object warm-pinned before Kubo was configured keeps only the warm copy - README links the doc from the pin configuration row, where operators configuring pins actually look; the original staking-list link stays * docs(pinning): keep the config table contiguous, document local_ipfs_provenance - README: the duplicate GITLAWB_MAX_CONCURRENT_PIN_TASKS row and the free-standing paragraph it introduced broke the table; the single row now carries the STORAGE-AND-PINNING cross-link inline - dedup: the hot tier skips on has_ipfs_cid (local_ipfs_provenance = TRUE), not row presence; a Pinata-only row is local_ipfs_provenance = FALSE, so it enters the hot path on later pushes once Kubo is configured instead of being permanently suppressed - the "Running both" durability bullet now agrees: enabling Kubo backfills local copies for warm-only objects * docs(pinning): qualify pin admission, per-copy durability, and loop sizing - the opening now names the admission gates: publish-durability confirmation plus root replication; private and non-replicating repos and withheld objects are out of "every push pins" wording - warm-table and durability copy drop the Filecoin backing claim the v3 API does not document - the JWT-unset paragraph now says the permit and re-derivation walk only run when the push was admitted, and an empty IPFS_API can still briefly touch the pin pool on a non-empty list - the semaphore section and README row state the two-loops-per-push fan-out so the default of eight reads as roughly four dual-tier pushes - the backfill and running-both wording is conditional on object selection and per-sink success, naming the reconciliation sweep * docs(pinning): drop unsupported Filecoin claim, normalize punctuation (#576) * docs(pinning): qualify warm admission and loop count for coalesced pushes (#576) A push that coalesces onto an in-flight encrypt/pin task never runs its own withheld walk, yet still spawns the warm Pinata worker, which re-derives the withheld set inside its pin permit. Scope "up to two loops per push" to pushes that start their own hot task; a coalesced push adds at most one warm loop. --------- Co-authored-by: andreolf <[email protected]> Co-authored-by: Kevin Codex <[email protected]>