API: which of this node's batches stamp a chunk, or the chunks under a reference

オープン
  • 何か問題がありますか？
#5,682 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 3 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
22/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
活発
技術スタック
go
領域
api, backend

調査の方向性

Start from the stamp issuer records: postage.StampItem in pkg/postage/stampissuer.go, and how stamper.go reads an existing item so a re-stamped chunk keeps its slot. The first endpoint needs one lookup of that item by batchID/chunkAddress, returning index, timestamp, or 404. The second reuses the traversal behind GET /stewardship/{reference} and counts per-batch hits. The issue's privacy limits are part of the design, so settle who may call these routes before writing code. Done means both routes return correct answers in tests, with the existing stewardship tests still passing.

索引モデルが issue の本文から書いたものです。

説明

Summary

Two read-only endpoints through which a node reports, from its own stamp
issuer's records, which of its batches stamp a chunk:

  1. GET /stamps/{batch_id}/chunks/{address}: whether this node stamped the
    chunk with this batch, with the stamp's index and timestamp; 404 when
    it did not.
  2. GET /stewardship/{reference}/stamps: walk the tree as
    GET /stewardship/{reference} does and report, for each of the node's
    own batches, how many of the tree's chunks it stamps, and how many
    chunks none of them stamp.

They answer only from the node's own records, about its own batches. Nothing
is asked of other nodes, and the protocol does not change.

Motivation

Whoever keeps content alive has to know which of their batches stamp it.
After moving it onto a new batch with PUT /stewardship/{reference}, they
also need to know whether all of it moved. Today the node can say only
whether content is retrievable (GET /stewardship/{reference}), and that
can't tell the batches apart: while the old batch lasts, a chunk the move
skipped is still retrievable. It shows only when the old batch expires,
which is too late.

So tools keep their own records of what went where, with no way to check
them against the node. Examples are swarm-keep's
keep-lists (it checks and moves content onto a new batch before the old one
runs out), Freedom's publish history and the Swarm Desktop File Manager's
drives.

swarm-keep's first real rotation, on 2026-10-31, moved six keep-lists onto a
new batch about nine days before the old one ran out: 47,003 addresses
(sites, apps, feeds and the blobs of record stores), none failed.
GET /stewardship then answered retrievable for a sample of each list. It
could not show that any of them is on the new batch.

How long a batch lasts stays with the caller. The node already serves what
the estimate needs: the batch's value from GET /batches/{id}, and
totalAmount and currentPrice from GET /chainstate. So these answers
name batches and nothing about time.

Implementation

The node already keeps the record. A stamp issuer stores a
postage.StampItem
(batch ID, chunk address, index, timestamp) for every chunk it stamps,
keyed batchID/chunkAddress. stamper.Stamp reads it so that a chunk
stamped again on the same batch keeps its slot
(stamper.go L42–L65).

  • (1) is one Get of that item.
  • (2) is the traversal GET /stewardship already does, with one such
    Get per chunk for each of the node's usable batches (/stamps).
Drawbacks
  • Privacy. A stamp links a chunk to a batch, through the batch to its
    owner's address on chain, and to every other chunk the same batch
    stamped, encrypted ones included.
    • These endpoints answer only the batch's owner, about chunks it stamped
      itself, through its own API, like /stamps and /wallet. They tell
      no one anything they did not already know.
    • A gateway that stamps uploads for others should keep them closed, as
      it keeps /stamps closed.
    • Deliberately not asked:
      • Stamps in retrieval. Delivery.Stamp has been empty since
        1.17.0. Filling it again would let anyone who downloads content link
        it to its uploader.
      • Storers telling anyone a chunk's batch or expiry. An expiry
        alone nearly identifies the batch, and a storer could answer falsely.
  • Cost. (2) walks the whole tree, as GET /stewardship does, so it is
    as slow on a large tree: it fetches every chunk it does not hold. The
    stamp lookups themselves are local.
AI Disclosure
  • This issue contains suggestions and text generated by an LLM.
  • I have reviewed the AI generated content thoroughly.
  • I possess the technical expertise to responsibly review the AI generated content mentioned in this issue.
主要言語
Go
スター
1.5k
フォーク
390
平均マージ
2日 22時間
マージ済み PR（30日）
24

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

ethersphere/bee のほかの issue

ethersphere/bee の issue をすべて見る

似ている issue

Go の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。