Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

epic: content layer — Helia in the browser, Kubo as the platform node, Boxo where needed

Aperta
  • Qualcosa non va?
#43 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
python
Ambito
data, distributed-systems, infrastructure

Direzione di ricerca

Start with docs/HELIA_INTEGRATION.md and the linked child issues to understand the planned content layer; this epic groups browser Helia, platform Kubo, optional Boxo work, and separate Stripe work. The production host, Kubo version policy, and need for custom Boxo code are still open. Done means the scoped child issues are completed and those design questions are resolved.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

boxo epic helia kubo needs-decision storage

Summary

Track the content layer for distributed-quantum: Helia in the browser for content addressing, Kubo as the always-on platform node, and Boxo (Go library) only where Kubo cannot meet a need. Also tracks Stripe stablecoin work as a separate group.

Source material: the Helia integration overview (docs/HELIA_INTEGRATION.md, added separately).

Design stance

  • Compute and content stay separate planes. Content-layer failures never block or discard quantum execution.
  • Prefer configuring Kubo over writing Go. Custom Boxo code needs a written justification (spike).
  • Provider credentials move behind a server-side broker.

Open questions

  • Where does the platform node run in production (hosting, who operates it)?
  • Kubo version policy and upgrade cadence.
  • Is a custom Boxo service justified? (see the Boxo spike)

Child issues

Tier 1 - good starting point (small, well-scoped, builds on existing code)
  • #44 helia fix(vault): drain and replay the pin retry queue
  • #46 helia refactor(vault-pinning): use the broker and remove NEXT_PUBLIC provider credentials
  • #47 helia chore(vault-pinning): remove the legacy nft-storage alias
  • #49 helia feat(vault): publish circuits to the vault
  • #50 helia feat(vault): versioned, validated record schemas
  • #51 helia feat(vault): request persistent storage and warn about eviction
  • #53 helia test(vault): unit tests for local-index and sync-queue
  • #56 helia docs(helia): post the open design questions to the IPFS community and record answers
  • #68 kubo test(content-node): compose-based integration test for the Kubo client
  • #75 kubo docs(helia): add the content node to the architecture and target diagrams
Tier 2 - needs a new service, SDK or deeper design
  • #45 helia feat(vault): server-side pinning broker routes
  • #48 helia feat(vault-pinning): pin original blocks as a CAR so the pinned CID equals the Helia CID
  • #52 helia feat(vault): export and import the vault as a CAR file
  • #54 helia feat(vault): open any CID from a link or paste, with trustless-gateway fallback
  • #58 helia feat(vault): link runs to circuits with dag-json instead of a string field
  • #59 kubo feat(infra): run Kubo in docker-compose (server profile, pinned version)
  • #60 kubo feat(content-node): lock down the Kubo RPC API and gateway
  • #61 kubo feat(backend): async Python client for the Kubo RPC API
  • #62 helia/kubo feat(vault): platform Kubo node as a pinning provider
  • #64 helia/kubo feat(content-node): delegated-routing endpoint used by Helia
  • #65 kubo feat(content-node): reprovide only pinned content
  • #66 kubo feat(ops): Kubo storage limits, garbage collection and Prometheus metrics
  • #67 kubo feat(provenance): publish each provenance bundle to Kubo, best effort
  • #73 kubo feat(backend): Python gateway client that fetches by CID and verifies content
  • #74 kubo feat(provenance): IPFS storage adapter for bundle verification
Tier 3 - distinct stack or research; start with a small scoped deliverable
  • #55 helia spike(vault): one Helia node per browser (SharedWorker vs Web Locks)
  • #57 helia spike(vault): large artefacts with UnixFS in an IndexedDB blockstore
  • #63 helia/kubo feat(content-node): browser-reachable multiaddrs for Helia nodes
  • #69 kubo spike(content-node): Kubo pubsub bridged to py-libp2p GossipSub
  • #70 kubo spike(vault): IPNS author feeds with Kubo-held keys
  • #71 boxo spike(content-node): what Kubo cannot do, and whether a custom Boxo service is justified
  • #72 boxo feat(content-node): CID allowlist and takedown denylist for the public gateway

Ground rules: testnet-first, no secrets in the repo, tests and docs with every PR.

Lingua principale
Python
Stelle
2
Fork
4
Merge medio
6h 54m
PR unite (30g)
7

Preparare l'ambiente

  • Include un Dockerfile o un file Docker Compose
  • Nessun modello di pull request
  • Nessuna guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di QMeshPy/distributed-quantum

Tutte le issue di QMeshPy/distributed-quantum

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.