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

feat(vault-pinning): pin original blocks as a CAR so the pinned CID equals the Helia CID

Offen
  • Stimmt etwas nicht?
#48 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
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
48/100
Issue-Typ
Feature
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
javascript, python
Bereich
backend, distributed-systems

Rechercherichtung

Start by reading the current provider adapters and their JSON-pin paths, then check the broker dependency in #45 and verify the CAR upload endpoints supported by Pinata and Lighthouse. Reproduce CID behavior with provider mocks or a test account before choosing an upload path. Done means tests show both providers return the Helia CID, mismatches raise a clear error, and the JSON path remains available behind a flag.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

enhancement helia storage tier-2

Summary

Upload the blocks Helia already holds, instead of re-submitting the JSON for the provider to re-encode.

Estimated size: M

Motivation

A provider that re-encodes JSON can return a different CID than the one the user shared, which breaks citation.

Current state in this repo

  • Adapters send JSON content to the provider's JSON-pin endpoint.
  • The Helia integration overview reports that the returned CID can differ; this has not been reproduced in this repo yet.

Proposal

  • Step 1: add a test or script that reproduces any CID mismatch for each provider.
  • Step 2: export the DAG with @helia/car and upload it through the provider's CAR (or Pinning Service API) endpoint; verify each provider's supported endpoint first.
  • Step 3: fail with a clear error if the CID the provider reports does not match the local CID.

Acceptance criteria

  • For Pinata and Lighthouse, the CID returned after pinning equals the Helia CID, checked in a test.
  • A mismatch is surfaced as an error, never silently recorded.
  • The JSON path remains available behind a flag until CAR upload is proven.

Out of scope

  • UnixFS and large files.

Technical notes and risks

  • Coordinate with the broker work: if it lands first, upload from the browser to the broker route; otherwise start against the current adapters.

Dependencies

  • Soft: #45 (uploads will move to the broker).

Testing plan

  • Provider mocks plus one manual run against test accounts.

Part of #43. Ground rules for the content layer: no secrets in the repo, content-layer failures must never block or discard quantum execution, and tests and docs ship with every PR.

Vorherrschende Sprache
Python
Sterne
2
Forks
4
Ø Merge
5 Std. 19 Min.
Gemergte PRs (30 T.)
11

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.