Part of Stem. This page defines the transfer record.

A transfer says: from this peer, authenticated as this account, I received these blobs for that claimed scope, and this many were indexed, stashed or rejected.

Fields

field	type	required	meaning
`id`	string	yes	Local id of the transfer.
`peer`	peer id	yes	The sending peer.
`account`	principal	no	The account the peer had authenticated as.
`scope`	scope	yes	The scope the sender claimed.
`ts`	timestamp	yes	When received.
`received`	integer	yes	Blobs received.
`indexed`	integer	yes	Blobs that validated into the claimed scope and were indexed.
`stashed`	integer	yes	Blobs kept but not yet applied.
`rejected`	integer	yes	Blobs refused.

Rules

Every batch that enters the peer creates a transfer: the result of a Fetch the peer made, an Offer it accepted, a Publish from a local client, or a web upload. The claimed scope is what the blobs are validated into: a Node whose space or parent is outside the scope, or whose signer lacks authority there, is rejected rather than indexed somewhere else. Per-blob verdicts are kept alongside the record so a rejected blob can be explained. The transfer log is local state and is the input to the abuse limits in The sync protocol.

Today (HM24)

Sync performance counters per site exist, and stashed blobs are recorded, but nothing records who sent what for which scope.

Example

{
  "id": "tr-7f3a",
  "peer": "12D3KooWRxtB3kQ7q2fZ5mXvN9pLaW4cJ8uHsYdE2gV6iTbMnKoP",
  "account": {"/": {"bytes": "7QEE...Collaborator"}},
  "scope": {"space": {"/": {"bytes": "7QEE...Starlight"}}, "node": "bafyreiujzdegxdncf32epf3dhodzdocis2jhtlgmxgedn73u55xtplpft7", "depth": "subtree"},
  "ts": 1759910800000,
  "received": 14, "indexed": 13, "stashed": 1, "rejected": 0
}

Fields

Rules

Today (HM24)

Example

See also