breadcrumbs — proposal

Magnet or Manifest

Should a dataset reachable only by a magnet link be an attestation's subject directly, or should something more durable sit in front of it? A tradeoff worth drawing out before it's designed around.

For Aaron, re: the torrent/PDS-peer dataset layer on panproto — a proposal to react to, not a spec to implement.

breadcrumbs attests that some author made some contribution to some subject — deliberately any URI, so it can point at an artifact wherever it actually lives rather than defining a new document format. Torsten described your torrent/magnet-link work on layers.pub datasets as a plausible way to let a rich dataset itself be that subject: "this dataset is a real contribution," attestable the same way a project or a claim is. Before designing around it, here's the tradeoff and a sketch to react to.

Three ways to point at something

An AT-URI and a DOI both resolve through a maintained middleman that's built to stay up. A magnet link resolves through whoever happens to be seeding right now — which can go quiet with no warning to anyone holding the link.

AT-URI DOI Magnet link at://did:plc:…/tid resolves via DID Document serves Record, from PDS 10.1234/abcd resolves via DOI registry redirects to Publisher URL magnet:?xt=… if reachable Live seeders / DHT no fallback Content, or nothing swarm can go quiet with no warning
AT-URI and DOI both resolve through a maintained middleman built to stay up. A magnet link's only "resolver" is whoever's currently seeding — the one path with no guaranteed fallback.

The sketch: don't attest the magnet link — attest a record that carries it

Rather than putting a bare magnet URI straight into trail.subject, where a dead swarm would silently orphan every attestation pointing at it, add one durable hop: a small manifest record (whether that's pub.layers.* or a thin breadcrumbs-side wrapper) whose own AT-URI becomes the subject, and which carries the magnet link as just one field alongside a fallback.

BEFORE — rejected trail.subject points directly at magnet:?xt=… (fragile) AFTER — proposed trail.subject at-uri Manifest record carries magnet (bulk transfer) lastKnownMirror format / lens ref
The manifest record's AT-URI is what attestations actually accumulate against — durable via DID → PDS resolution — while the magnet link becomes one updatable field inside it, not the identity itself.
illustrative shape, NSID not decided 
{
  "$type": "pub.layers.dataset.manifest",
  "title": "…",
  "format": "…",               // e.g. a panproto lens/schema ref
  "magnet": "magnet:?xt=urn:btih:…",
  "lastKnownMirror": "https://…", // optional fallback
  "createdAt": "…"
}

This also gives panproto's own dev.panproto.schema.lensAttestation a natural home: a format/lens reference on the manifest is exactly what that lexicon could attest to independently — breadcrumbs on the dataset-as-contribution, panproto on the lens it's encoded in, side by side rather than overlapping.

Questions for you

1

Does a manifest-record-in-front-of-the-magnet-link match the shape your PDS-peer torrent idea is actually heading toward, or does it assume something about swarm/peer discovery that doesn't hold?

2

Is lastKnownMirror worth having from day one, or premature given the torrent layer itself is still an idea in conversation, not code yet?

3

Whose lexicon should the manifest actually be — pub.layers.* (yours), a new shared one, or does breadcrumbs define its own thin wrapper and just reference whatever pub.layers.* ends up being? No opinion yet, genuinely asking.