IPFS-family services: IPNS, gateways, pinning services and IPLD records #34

Closed
opened 2026-10-05 06:49:57 +00:00 by rvnminers-A-and-N · 2 comments
Owner

Deeper use of the IPFS family beyond block storage, self-hosted by default with public services as an opt-in.

IPLD

  • Represent a job as linked data: manifest, task graph, per-task receipts, result. One root CID then names a job's whole history, which is what a chain would commit to (#20).

IPNS

  • Stable names for things that change: a node's capability record, the current version of a workload manifest, a pool's member list. Signed by the node key from #8.
  • Not for anything time-sensitive; updates propagate slowly.

Gateways

  • A read-only HTTP gateway built into sisyphusd, so a browser or the web UI can fetch a result by CID without running a node.
  • Access control: a gateway on a private pool must not serve private data to the world.
  • Opt-in publishing to public gateways for data the owner marks public.

Pinning services

  • Speak the IPFS Pinning Service API as a client, so a user can send results to their own cluster or to a commercial service.
  • Expose the same API from a node, so standard IPFS tools can pin to a Sisyphus pool.

Default posture

  • Everything runs on infrastructure the pool controls unless the owner opts in to a public service. Document exactly what each opt-in reveals.
Deeper use of the IPFS family beyond block storage, self-hosted by default with public services as an opt-in. **IPLD** - [ ] Represent a job as linked data: manifest, task graph, per-task receipts, result. One root CID then names a job's whole history, which is what a chain would commit to (#20). **IPNS** - [ ] Stable names for things that change: a node's capability record, the current version of a workload manifest, a pool's member list. Signed by the node key from #8. - [ ] Not for anything time-sensitive; updates propagate slowly. **Gateways** - [ ] A read-only HTTP gateway built into `sisyphusd`, so a browser or the web UI can fetch a result by CID without running a node. - [ ] Access control: a gateway on a private pool must not serve private data to the world. - [ ] Opt-in publishing to public gateways for data the owner marks public. **Pinning services** - [ ] Speak the IPFS Pinning Service API as a client, so a user can send results to their own cluster or to a commercial service. - [ ] Expose the same API from a node, so standard IPFS tools can pin to a Sisyphus pool. **Default posture** - [ ] Everything runs on infrastructure the pool controls unless the owner opts in to a public service. Document exactly what each opt-in reveals.
Author
Owner

The gateway is in #115: --gateway-listen serves a node's stored files read-only by content ID, behind the node's token unless started with --gateway-open, and never serves a sealed file. Still open here: a job as linked data, IPNS names, the pinning service API as client and as server, and opt-in publishing to public gateways.

The gateway is in #115: `--gateway-listen` serves a node's stored files read-only by content ID, behind the node's token unless started with `--gateway-open`, and never serves a sealed file. Still open here: a job as linked data, IPNS names, the pinning service API as client and as server, and opt-in publishing to public gateways.
Author
Owner

Done across four PRs:

  • Gateway (--gateway-listen, GET /ipfs/<cid> and /ipns/<name>).
  • Pinning Service API (#117-series: --pinning-listen, blob pin-remote | pins-remote | unpin-remote).
  • Names (#119: name publish | resolve, a node's ID standing for what it last published).
  • IPLD job records (#120: a finished job's history as linked dag-cbor, job record --verify; private jobs commit to their results with keyed hashes rather than naming them).

Anything further (publishing names to the public IPNS DHT, records for running jobs) would be a new issue.

Done across four PRs: - **Gateway** (`--gateway-listen`, `GET /ipfs/<cid>` and `/ipns/<name>`). - **Pinning Service API** (#117-series: `--pinning-listen`, `blob pin-remote | pins-remote | unpin-remote`). - **Names** (#119: `name publish | resolve`, a node's ID standing for what it last published). - **IPLD job records** (#120: a finished job's history as linked dag-cbor, `job record --verify`; private jobs commit to their results with keyed hashes rather than naming them). Anything further (publishing names to the public IPNS DHT, records for running jobs) would be a new issue.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Sisyphus/Sisyphus#34