chore(vault-pinning): remove the legacy nft-storage alias
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 54/100
- Issue type
- Refactor
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- typescript
- Domain
- backend
Research direction
Start with types.ts, services/nft-storage.ts, services/index.ts, and hooks/use-pin.ts to trace how pinning services are selected and how audit records are read and unpinned. Then inspect the existing tests for those paths and add coverage for records with service: "nft.storage". Done means the alias is removed from the type and services, the hook uses DEFAULT_SERVICE, and legacy records still display and unpin correctly.
Written by the indexing model from the issue text.
Description
Summary
nft.storage is still a valid PinningService value, but the adapter behind it is really Pinata.
Estimated size: S
Current state in this repo
types.ts:PinningService = "nft.storage" | "pinata" | "lighthouse".services/nft-storage.tsreadsNEXT_PUBLIC_PINATA_JWT, and its header comment says NFT.Storage is a Filecoin archival service.hooks/use-pin.tsdefaultsserviceto"nft.storage"whileDEFAULT_SERVICEinservices/index.tsis"pinata".
Proposal
- Remove the alias from the type, delete the adapter, and make the hook default to
DEFAULT_SERVICE. - Decide and document how existing audit records with
service: "nft.storage"are read (map topinataat read time, or migrate).
Acceptance criteria
- No
nft.storagevalue remains in the type or services. - Old audit records still display and unpin correctly.
- Tests cover the legacy record case.
Dependencies
- None; can be picked up independently.
Testing plan
- Unit test for the read-time mapping.
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.
- 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
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from QMeshPy/distributed-quantum
-
enhancement good first issue helia storage tier-1
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
QMeshPy/distributed-quantum#53 ·
Maintainers usually reply within 1 day
-
chain-integration enhancement payments research-spike tier-2
Difficulty 4/5 3-5 days Newbie friendliness 55/100
QMeshPy/distributed-quantum#78 ·
Maintainers usually reply within 1 day
-
chain-integration enhancement payments research-spike tier-2
Difficulty 3/5 1-2 days Newbie friendliness 66/100
QMeshPy/distributed-quantum#77 ·
Maintainers usually reply within 1 day
-
chain-integration enhancement payments tier-2
Difficulty 5/5 Over a week Newbie friendliness 35/100
QMeshPy/distributed-quantum#76 ·
Maintainers usually reply within 1 day
-
documentation good first issue kubo storage tier-1
Difficulty 2/5 1-3 hours Newbie friendliness 42/100
QMeshPy/distributed-quantum#75 ·
Maintainers usually reply within 1 day
All issues in QMeshPy/distributed-quantum
Similar issues
-
infrastructure
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
khuisman/mcp-gee-sweet#1152 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
backroom bug
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
ditto-assistant/ditto-subnet#3069 ·
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 67/100
open-webui/open-webui#32901 · 1 comment ·
Maintainers usually reply within 1 day
-
0.3.3 bug
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day