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 |
|---|---|---|---|
| yes | Local id of the transfer. | |
| yes | The sending peer. | |
| no | The account the peer had authenticated as. | |
| yes | The scope the sender claimed. | |
| yes | When received. | |
| yes | Blobs received. | |
| yes | Blobs that validated into the claimed scope and were indexed. | |
| yes | Blobs kept but not yet applied. | |
| 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
}See also
Do you like what you are reading? Subscribe to receive updates.
Unsubscribe anytime