Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

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

Offen
  • Stimmt etwas nicht?
#43 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Anfängerfreundlichkeit
25/100
Issue-Typ
Feature
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
python
Bereich
data, distributed-systems, infrastructure

Rechercherichtung

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.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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.

Vorherrschende Sprache
Python
Sterne
2
Forks
4
Ø Merge
6 Std. 54 Min.
Gemergte PRs (30 T.)
7

Entwicklungsumgebung

  • Enthält ein Dockerfile oder eine Docker-Compose-Datei
  • Keine Pull-Request-Vorlage
  • Kein Beitragsleitfaden

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus QMeshPy/distributed-quantum

Alle Issues in QMeshPy/distributed-quantum

Ähnliche Issues

Weitere Issues zu Python

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.