Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#43 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

@ishikabhoyar ya está trabajando en esto.

Desde el 22/10/2026.

  • #83 de @ishikabhoyar — abierto

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
python
Área
data, distributed-systems, infrastructure

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
Python
Estrellas
2
Forks
4
Merge medio
5 h 19 min
PR fusionados (30 d)
11

Preparar el entorno

  • Incluye un Dockerfile o un archivo de Docker Compose
  • Sin plantilla de pull request
  • Sin guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de QMeshPy/distributed-quantum

Todos los issues de QMeshPy/distributed-quantum

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.