Ipfs: Liaisons API IPFS

Je peux proposer une revue de code pour Ruby

J'ai les débuts des liaisons API Rust .

Je serais intéressé à travailler sur les liaisons Ruby, mais je ne connais pas encore assez le projet, j'aurais donc besoin de conseils.

C/C++ Je suis prêt à faire du bénévolat.

J'aimerais ajouter une implémentation pour Julia .

Merci @lgierth @rschulman @Fryie @PayasR et @rened -- je vais faire un suivi rapide ici.

En attendant, consultez https://github.com/ipfs/node-ipfs-api pour un aperçu de son fonctionnement. Les pièces clés sont dans :

• https://github.com/ipfs/node-ipfs-api/blob/master/src/index.js -- les méthodes api. pas complet, mais assez bon pour la plupart des cas d'utilisation simples
• https://github.com/ipfs/node-ipfs-api/blob/master/src/request-api.js -- en envoyant chaque requête HTTP au serveur API. (ce code pourrait probablement être nettoyé un peu, mais c'est simple).
• https://github.com/ipfs/node-ipfs-api/blob/master/src/get-files-stream.js -- le flux de fichiers. c'est très spécifique à js, mais fondamentalement, nous utilisons un flux en plusieurs parties où chaque partie a un en-tête spécifiant le nom de fichier cible. Nous pouvons également implémenter le support d'un tar-stream (et bientôt d'un car-stream) à la place dans go-ipfs, si c'est plus facile pour les gens (j'ai déjà 50% du code pour ça).

@jbenet peut-être mettre à jour le PO avec des liens vers des projets de liaison existants? ipfs/py-ipfs , etc.

@cryptix py-ipfs je pense que ce ne sont pas des liaisons, mais visant à être un impl? peut-être que quelqu'un peut gagner ipfs/py-ipfs-api

Merci à tous ceux qui aident ! D'accord,

• J'ai implémenté le drapeau ipfs --api <multiaddr> <cmd> pour cibler un démon distant ( voir ce PR ) -- ce qui est très utile ici pour inspecter : target nc .
• j'ai fait une doc préliminaire très simple : https://github.com/ipfs/go-ipfs/blob/master/docs/implement-api-bindings.md
• la prochaine étape consiste à générer une spécification de démarque de l'ensemble de l'API go-ipfs basée sur le code (quelqu'un peut-il prendre un coup de couteau ?)

mais peut déjà commencer, étant donné que node-ipfs-api est si trivialement simple.

Je commence une implémentation Java. Je posterai un lien une fois que j'aurai quelque chose de non trivial.

API Blueprint est une spécification de démarque pour décrire les API. Il a une conceptualisation des points de terminaison et des types de demande et des réponses et ainsi de suite.

C'est un sous-ensemble de démarques, il sera donc toujours rendu, mais apiary.io fournit un affichage plus complexe.

Par exemple, voici la démarque et le rendu d'un plan sur lequel j'ai travaillé récemment.

J'ai parcouru l'index node-api et suppose que je connais les noms des points de terminaison. Je n'ai toujours aucune idée du modèle de données.

Si quelqu'un qui examine les structures de données et les interactions est intéressé par le jumelage à ce sujet, j'aimerais contribuer, mais je ne maîtrise pas encore assez le système pour le faire.

Mon implémentation Java se passe ici : https://github.com/ianopolous/IPFS-API-Java Je vise à la rendre autonome et simple.

Je viens de terminer les liaisons python rudimentaires : https://github.com/amstocker/python-ipfs-api

Tout conseil ou test serait grandement apprécié. Il est déjà un peu testé sur ma machine locale (Ubuntu 14.04.2/Python 2.7.6).

Je m'attends à faire des progrès lents mais réguliers sur les liaisons Ruby ici . :)

Déplacement des liaisons python https://github.com/ipfs/python-ipfs-api/ (merci !). Si quelqu'un d'autre veut aussi déménager, faites-le moi savoir. (il est plus facile pour la communauté de tous collaborer dans un ensemble de liaisons)

@dysbulic heureux d'aider avec le modèle de données API. peut-être passer par #ipfs ou poser des questions sur https://github.com/ipfs/go-ipfs ou https://github.com/ipfs/node-ipfs-api ?

@Fryie coolio, je vais essayer de jeter un œil à ce que vous avez déjà, mais si vous voulez que je regarde quelque chose en particulier, n'hésitez pas à me contacter sur IRC

J'ai le début d'une liaison API C++ ici : https://github.com/MichaelMure/Arbore-qt/tree/master/src/ipfs

Ce n'est pas vraiment généraliste et basé sur Qt, mais quand même ...

Bonjour, j'ai commencé sur un wrapper dans Scala pour l'API HTTP IPFS ici : https://github.com/cboddy/scala-ipfs-api/

Si quelqu'un d'autre est intéressé à contribuer (ou a des demandes ou des suggestions), veuillez me le faire savoir, sinon je mettrai à jour une fois qu'il sera terminé.

Vous cherchez bien ! @MichaelMure et @cboddy me font savoir quand il atteint un certain niveau d'achèvement et nous pouvons les déplacer dans ipfs/ org (si vous le souhaitez)

@jbenet les

ipfs --help

message, ainsi que la plupart des commandes de structure de données et une certaine couverture des autres. Le reste devrait être directement intégré dans la semaine prochaine avec des tests d'intégration plus formels, n'hésitez pas à l'ajouter à ipfs/ en attendant.

@cbody c'est une excellente nouvelle !! Souhaitez-vous transférer le dépôt vers l'organisation ipfs , comme nous le faisons pour les autres ? Je vous ai ajouté à l'organisation - transférez simplement le dépôt à l'utilisateur ipfs (ou à moi si cela ne fonctionne pas). Je vais ensuite m'assurer que vous avez admin et ainsi de suite.

@jbenet merci et bien sûr, c'est fait !

J'ai mis à jour la liste dans le premier article pour inclure les nouvelles liaisons d'API Python, Java et Scala ! Merci beaucoup à toutes les personnes impliquées ! :Clap clap:

Nous devrions rendre nos fixations Go aussi belles... @whyrusleeping

Je ferai Lua !

Je ferai Lua !

Grand merci! Lmk lorsque vous avez un dépôt à mettre dans l'organisation ipfs ! :)

Je travaille sur les liaisons d'API Swift.

Des exemples amusants d'une ligne utilisant cURL que je peux exécuter directement à partir de la ligne de commande (Linux) ?

En regardant les ipfs --help ipfs add --help et autres, en combinant avec
le document API ( https://ipfs.io/docs/api/ ) et vous devriez être en mesure de comprendre l'API HTTP.

Peut ou non correspondre à votre exigence "amusante" :)

Sincèrement,
Victor Bjelkholm
(+34) 672 15 90 89

Le jeu. 5 novembre 2015 à 8h24, bitcoinmeetups.org < [email protected]

a écrit:

Tous les exemples amusants d'une ligne utilisant cURL que je peux exécuter directement à partir de la commande
ligne (Linux) ?

-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/ipfs/ipfs/issues/83#issuecomment-153976500 .

J'ai travaillé sur une liaison API en PHP . Pour le moment, il ne s'agit que du sous-ensemble de commandes IPFS dont nous avions besoin pour ipfs.pics, mais envoyez-moi un ping si vous en avez besoin de plus et je les ajouterai !

@cloutier si tu veux, on peut te faire un repo sous l'org ipfs appelé php-ipfs-api et tu peux y mettre le code

@whyrusleeping J'aimerais le publier avec la même licence de copyleft et je sais que cela pourrait être un peu controversé. Est-ce que cela te va?

J'ai maintenant terminé le premier passage des liaisons de l'API Swift . N'hésitez pas à commenter et à utiliser pour vos superbes projets IPFS iOS/OS X et à vous déplacer dans l'organisation ipfs :)

@whyrusleeping J'aimerais le publier avec la même licence de copyleft et je sais que cela pourrait être un peu controversé. Est-ce que cela te va?

Hum. Je suis indécis à ce sujet, mais je pencherais fortement pour que tout reste permissif sous ipfs org afin que les utilisateurs ne fassent pas d'erreurs accidentellement.

@cloutier curieux pourquoi avoir besoin d'un exemplaire fort laissé pour les reliures ? qui exclut strictement l'utilisation commerciale, l'endroit où les utilisateurs auraient le plus besoin de reliures.

orthogonal à cela -- en y pensant davantage -- nous aurons certainement besoin de liaisons officielles en php qui soient permissives (MIT/BSD/Apache2). si @cloutier ne veut pas qu'il en soit ainsi, il nous en faudra un autre.

@cloutier @jbenet LGPL serait-il un compromis raisonnable ?

Non, AFAIK LGPL n'est pas compatible avec MIT/BSD/Apache2.0

J'y ai réfléchi un peu plus et il serait préférable de l'avoir sous une licence laxiste afin d'obtenir plus de projets utilisant un standard ouvert comme IPFS, et donc mieux pour le logiciel libre en général. Apache 2.0 serait bien.

@davidar LGPL pourrait être une bonne idée. Cela permettrait d'intégrer de nombreuses licences (y compris le MIT et même le code propriétaire) si le code source d'au moins la liaison est disponible, mais PHP est un cas particulier car il n'est presque exécuté que sur des serveurs et la clause copyleft n'est pas déclenché sur le code d'un serveur . Autant le publier sous une licence permisive.

@jbenet Pour mémoire, AGPL ne veut pas dire non commercial . Je n'ai pas besoin d'un copyleft fort pour des raisons techniques, mais je le veux pour des raisons politiques.

merci beaucoup @cloutier !

@cloutier Oui, je pense que le copyleft est plus logique pour les applications _sur_ IPFS (comme ipfs.pics), plutôt que pour les bibliothèques de niveau inférieur comme celle-ci.

De https://www.gnu.org/licenses/license-recommendations.html

Certaines bibliothèques implémentent des normes libres qui sont en concurrence avec des normes restreintes, telles que Ogg Vorbis (qui concurrence l'audio MP3) et WebM (qui concurrence la vidéo MPEG-4). Pour ces projets, l'utilisation généralisée du code est vitale pour faire avancer la cause du logiciel libre, et fait plus de bien qu'un copyleft sur le code du projet ne le ferait.

Dans ces situations particulières, nous recommandons la licence Apache 2.0.

@davidar Résume très bien ce à quoi j'ai pensé, merci ! :+1:

J'ai le début des bindings PHP : https://github.com/cloutier/php-ipfs-api

C'est fondamentalement le même code que nous avons en production sur ipfs.pics, mais sous licence Apache 2.0.

cc @mekarpeles

Merci, et si j'agrégeais ces bibliothèques clientes d'API dans un fichier dans ipfs/ipfs/clients (et de même ipfs/ipfs/implementations) que nous pouvons tenir à jour ?

Ce sera probablement aussi une meilleure expérience pour les personnes essayant de rechercher dans les bibliothèques clientes (que ce problème). Nous pouvons également créer un lien vers ce problème dans le document afin que les gens puissent contribuer à la discussion.

Y a-t-il des oppositions ?

C#/.NET ici . J'utilise ce projet pour le travail, il sera donc soutenu/amélioré pendant au moins un an ou deux.

Bonjour à tous et @PayasR @jbenet @MichaelMure en particulier,

J'ai implémenté une liaison API C++ ici : https://github.com/vasild/cpp-ipfs-api et je viens d'obtenir sa couverture de test à 100% après quelques combats avec Travis et Coveralls.

Jusqu'à présent, l'ensemble de méthodes block, config, files, generic, object, pin et swarm de l'API (https://github.com/ipfs/interface-ipfs-core/tree/master/API) a été implémenté. Ce qui reste, ce sont les dag et dht que je vais essayer de faire bientôt.

Bravo !

Bonjour à tous! J'espère que vous allez bien! Je me demandais s'il était prévu de créer une liaison API dans Visual Basic .NET ?

Il y avait une référence à la mise en œuvre de .NET .

@Coder206 Voir https://github.com/richardschneider/net-ipfs-core et https://github.com/richardschneider/net-ipfs-api.

Il est écrit en C# mais devrait être accessible depuis VB.Net.

@jbenet je voudrais dédier mon client php pour ipfs https://github.com/digitalkaoz/php-ipfs. son api complète, couvre à la fois les "drivers" http+cli, générés automatiquement à partir des docs officiels et bien testés (au moins dans quelques jours ;) )

sa licence sous le MIT , donc il n'y a pas de problèmes je pense.

j'adorerais voir mon repo transféré à l'organisation ipfs ...

@digitalkaoz c'est génial. Voulez-vous me le transférer et je l'ajouterai à l'organisation IPFS ? Vous souhaitez également l'ajouter à la liste sur https://github.com/ipfs/ipfs#api -client-libraries ?

d'ailleurs tout le monde, il y a maintenant un logo génial pour les bibliothèques du client HTTP. J'ai communiqué avec tous ceux qui étaient sur -- https://github.com/ipfs/ipfs#api -client-libraries --, si le vôtre n'y était pas, le voici :

Aussi, si vous avez fait une implémentation, pensez à la référencer sur https://github.com/ipfs/ipfs#api-client-libraries et laissez une note sur son exhaustivité :)

@diasdavid permet d'ajouter à la liste des bibliothèques clientes :) ferez-vous un PR ou devrais-je?

@digitalkaoz vas-y :)

@diasdavid qu'en est-il du déplacement de https://github.com/vasild/cpp-ipfs-api vers https://github.com/ipfs/cpp-ipfs-api ? Il était complet la dernière fois que j'en ai profité, mais je n'ai pas eu le temps de vérifier si de nouvelles fonctions API ont été ajoutées par la suite.

@vasild, nous pouvons le faire. Êtes-vous toujours disponible pour continuer à être le capitaine de cette bibliothèque ?

@diasdavid J'ai changé de travail récemment et je n'ai pas trouvé assez de temps pour aimer cpp-ipfs-api (par exemple, vérifiez si de nouvelles fonctions ont été ajoutées à l'API principale et implémentez-les si tel est le cas). Le déplacer sous /ipfs/ augmentera sa visibilité, donc peut-être que d'autres contribueront également. OTOH si vous ne voulez pas adopter du code écrit par un seul développeur qui ne travaille pas dessus activement, alors il serait peut-être préférable de le laisser sous /vasild/. OMI, il serait préférable de le déplacer vers /ipfs/ et je finirai par trouver le temps de jouer davantage avec. Qu'est-ce que tu penses?

@vasild a compris. Je pense que la meilleure approche est de suivre votre suggestion et de décrire l'état de la mise en œuvre sur le README + les problèmes ouverts pour les problèmes connus + les nouveaux contributeurs bienvenus. Tout cela + déplacement vers l'organisation IPFS.

Je mentionnerai les bibliothèques clientes IPFS dans le prochain IPFS All Hands :)

@diasdavid https://github.com/vasild/cpp-ipfs-api/commit/b1c557e7a1165ea38d20d5806a35979bfc0a2575 d' accord ? (il n'y a pas de problèmes connus !)

@diasdavid a ouvert un PR pour la liste des bibliothèques clientes

Le 23 août 2017, 17h37, Vasil Dimov [email protected] a écrit :

@diasdavid https://github.com/diasdavid vasild/ cpp-ipfs-api@b1c557e
https://github.com/vasild/cpp-ipfs-api/commit/b1c557e7a1165ea38d20d5806a35979bfc0a2575
d'accord? (il n'y a pas de problèmes connus !)

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/ipfs/ipfs/issues/83#issuecomment-324374905 , ou couper le son
le fil
https://github.com/notifications/unsubscribe-auth/AAR611I4GWv1OJkoJNiLvIVJXQnwE_rzks5sbEcygaJpZM4FuFH9
.

@jbenet bonjour ! Ce serait bien de changer le lien de rouille actuel par le nouveau, car il n'a pas été mis à jour depuis 2 ans déjà .. rust-ipfs-api
Mon implémentation est encore brute, mais ça marche !

@rmnoff super ! Veuillez ouvrir un PR pour l'inclure dans la liste. (Exemple https://github.com/ipfs/ipfs/pull/265)

@vasild Ca me va bien :)

@diasdavid terminé ! :)

Y a-t-il un intérêt pour une implémentation Dart et/ou Elixir de l'API ? Je sais qu'aucune des langues n'est spécifiquement répertoriée, mais personnellement, j'utiliserais les deux pour diverses applications différentes.

Plus c'est mieux :)

Le samedi 7 octobre 2017, 11 h 00 Tensor-Programming [email protected]
a écrit:

Y a-t-il un intérêt pour une implémentation Dart et/ou Elixir de l'API ? je
Je sais qu'aucune des langues n'est spécifiquement répertoriée mais j'utiliserais personnellement
à la fois pour diverses applications différentes.

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/ipfs/ipfs/issues/83#issuecomment-334917974 , ou couper le son
le fil
https://github.com/notifications/unsubscribe-auth/ABL4HIInzOWvWTAIWjeRqR_mRuz22HC7ks5spy-ZgaJpZM4FuFH9
.

J'ai un peu avancé (environ 65-70% des commandes) sur l'API Elixir. Si vous voulez y jeter un coup d'œil et voir si c'est à la hauteur; Je l'apprécierais. J'ai encore besoin de construire de nombreuses commandes ainsi que la documentation et le module de test (et circleCI). J'ai pu surmonter la plupart des difficultés (prise en charge des formulaires en plusieurs parties, etc.), donc ce n'est qu'une question de jours/semaines à ce stade jusqu'à ce que j'aie une quantité assez décente de fonctionnalités implémentées.

Voici le repo : https://github.com/tensor-programming/Elixir-Ipfs-Api

Edit : je vais abandonner le repo parce que personne ne semble s'en soucier ? Je n'ai même pas eu de réponse de votre part et ça fait un mois. Inutile de maintenir un logiciel que personne ne va utiliser. Toute personne intéressée à prendre le repo et à s'appuyer dessus, n'hésitez pas à me le faire savoir. Tous les points de terminaison de l'API ont été implémentés avec uniquement les fonctionnalités de base. Il ne serait pas difficile de les étendre et d'ajouter le reste.

Qu'en est-il d'une liaison elm-ipfs, est-ce que quelqu'un est intéressé à rendre cela possible?

Peut écrire la liaison Perl si nécessaire.

haskell Je suis prêt à faire du bénévolat.

je peux écrire Objective-C, y a-t-il une liste de travail à faire ?

Voir https://github.com/ipfs/ipfs#api -client-libraries

Qu'en est-il du développement d'une application mobile à l'aide d'IPFS ?
Il existe plusieurs projets pour l'application Android, ce qui est plutôt bien.
L'étape principale consiste d'abord à démarrer le démon ipfs sur un mobile, et à télécharger des fichiers, etc.
J'essaie de créer une application mobile basée sur l'application Android actuelle et je peux les extraire sur un SDK Android.
À mon avis, si nous pouvons amener plus de développeurs ou d'entreprises à stocker et à récupérer leurs données dans le système ipfs dans les applications mobiles, alors il est probable que le système puisse être utilisé par de nombreux utilisateurs courants.
Avez-vous un plan à ce sujet ou y a-t-il une discussion à ce sujet?
@jbenet

API objc ?

oui, le client et le serveur peuvent parler avec au lieu du fichier, ce qui sera plus
efficace.

Notifications [email protected]于2018年9月13日周四 下午3:45写道：

API objc ?

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/ipfs/ipfs/issues/83#issuecomment-420914945 , ou couper le son
le fil
https://github.com/notifications/unsubscribe-auth/ABPHvCWs76QmmERDY7oqtQOuSPJ2eF54ks5uag0JgaJpZM4FuFH9
.

J'ai écrit un autre ensemble de liaisons Common Lisp il y a quelque temps (l'autre refusait de travailler sur l'un de mes PC même après quelques manipulations, et ne supportait pas pubsub).

C'est juste ici - il y a aussi un miroir GitHub .

Merci à tous, nous nettoyons ce référentiel. Si vous avez des contributions supplémentaires, veuillez nous en informer sur https://discuss.ipfs.io .