Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

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

Ouverte
  • Quelque chose ne va pas ?
#48 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
48/100
Type d'issue
Fonctionnalité
Clarté
Plutôt claire
Activité
Active
Stack technique
javascript, python
Domaine
backend, distributed-systems

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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.

Langage dominant
Python
Étoiles
2
Forks
4
Merge moyen
5 h 19 min
PR mergées (30 j)
11

Préparer son environnement

  • Fournit un Dockerfile ou un fichier Docker Compose
  • Aucun modèle de pull request
  • Aucun guide de contribution

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de QMeshPy/distributed-quantum

Toutes les issues de QMeshPy/distributed-quantum

Issues similaires

Plus d'issues Python

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.