Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

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

Open
  • Is something wrong?
#43 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
python
Domain
data, distributed-systems, infrastructure

Research direction

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.

Written by the indexing model from the issue text.

Description

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.

Dominant language
Python
Stars
2
Forks
4
Avg merge
6h 54m
Merged PRs (30d)
7

Getting set up

  • Ships a Dockerfile or Docker Compose file
  • No pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from QMeshPy/distributed-quantum

All issues in QMeshPy/distributed-quantum

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.