ipfs/kubo

canonical method for checking locality of a block via coreAPI

Open

#6 726 ouverte le 24 oct. 2019

Voir sur GitHub
 (5 commentaires) (0 réactions) (0 assignés)Go (2 725 forks)batch import
help wantedkind/enhancement

Métriques du dépôt

Stars
 (13 906 stars)
Métriques de merge PR
 (Merge moyen 4j 2h) (28 PRs mergées en 30 j)

Description

Location

:wave: 👨‍👧‍👧! I'm looking for the best way to ask "hey is this block local"?

Given that we're in IPFS user land, we should be using core API for this stuff. Which means we're trying to do stuff that's easiest accomplished with a blockstore via coreapi.

Blockstore method that works exactly as we'd like:

https://github.com/ipfs/go-ipfs-blockstore/blob/3eee0dff760dea94c59381e9a18b9aa290361b28/blockstore.go#L36

Relevant coreAPI subsystem:

https://github.com/ipfs/interface-go-ipfs-core/blob/1c94e6217184ed07abab840143aa1f417e314c3d/block.go#L20-L37

Description

We also have the same question about complete DAGs, happy to file a separate issue if you'd prefer. I'd love to be pointed to the canonical methods of determining if a block or dag is local via core API.

Thanks!

Guide contributeur

Direction de recherche
Le problème demande un moyen canonique de vérifier si un bloc est local en utilisant l'API principale. L'utilisateur mentionne la méthode blockstore.Has et le sous système de blocs coreAPI. Pour résoudre, examiner d'abord les méthodes de bloc coreAPI existantes (voir interface go ipfs core/block.go) et déterminer s'il existe déjà une méthode pour vérifier la localité. Sinon, proposer d'ajouter une méthode telle que `IsLocal` ou `Has` à l'interface de bloc coreAPI et l'implémenter dans le dépôt Kubo. Considérer également la question sur les DAG complets. Se référer à l'interface blockstore et s'assurer que la nouvelle méthode l'utilise en interne.
Stack technique
go
Domaine
backendapi
Type d'issue
Recherche
DifficultéDifficulté estimée pour un nouveau contributeur, de 1 pour un très petit changement à 5 pour un travail expert.
2
Temps estiméFourchette de temps approximative pour investiguer, implémenter, tester et préparer une pull request.
Une demi journée
Statut d'activitéDisponibilité apparente de l'issue : fraîche, active, ancienne, bloquée ou en attente d'un mainteneur.
Active
ClartéClarté avec laquelle l'issue explique le changement attendu, les critères d'acceptation et la prochaine étape.
Claire
Prérequis
GoIPFS
Accessibilité débutantScore de 1 à 100 estimant l'accessibilité de cette issue pour un premier contributeur.
70