Completeness?

[jbenet]

What is the completeness of this api? in relation say to https://github.com/ipfs/js-ipfs-api ?

Many people are using ipfs from python and they've asked me this question lots. I think it would be good to have a spec completeness markdown checklist.

[whereswaldon]

As far as I am aware, this is where things are. This is drawn from here.

There were a few items in the spec that I'm not sure how to implement (node_start and node_stop), and a few that people on IRC said to hold off on because they might have security implications.

Core

• version
• node
  • id
  • start - not implemented due to unclear spec
  • stop - not implemented due to unclear spec
• block
  • get
  • put
  • stat
• object
  • data
  • get
  • links
  • new
  • patch
  • put
  • stat
• refs
  • local
• repo
  • init - not implemented due to security concerns
  • stat
  • gc
  • config get - not implemented due to security concerns
  • config put - not implemented due to security concerns
• pin
  • add
  • ls
  • rm

Extensions

• name (ipns)
  • name publish
  • resolve
• dns
  • resolve
• tar
  • add
  • cat
• tour
  • list
  • next
  • restart
• files
  • add - see Files add accepts unused filename filter #49
  • cat
  • get - see Files get has no way to specify the name of the file once it is retrieved #48
• stat
  • bw
• mount
• bootstrap
  • add
  • list
  • rm
• bitswap - see Add bitswap commands #55
  • stat
  • unwant
  • wantlist
• log
  • level
  • tail

[whereswaldon]

Actually, the above is a checklist from the wrong API? I'm confused about the discrepancies between this and this.
@jbenet What is the difference in intention between those two specs?

Here is the functionality of py-ipfs-api compared against the Apiary:

NOTE: Not all of the following are tested currently.

• add
• bitswap
  • stat
  • wantlist
  • unwant
• block
  • get
  • put
  • stat
• bootstrap
  • add
  • list
  • rm
• cat
• commands
• config
  • config
  • replace
  • show
• dht
  • findpeer
  • findprovs
  • get
  • put
  • query
• diag
  • cmds
  • cmds clear
  • cmds set-time
  • net
  • sys
• dns
• file ls
• files
  • rm
  • flush
  • mv
  • cp
  • ls
  • mkdir
  • stat
  • read
  • write
• get
• id
• log
  • level
  • ls
  • tail
• ls
• name
  • publish
  • resolve
• object
  • data
  • diff
  • get
  • links
  • new
  • patch append-data
  • patch add-link
  • patch rm-link
  • patch set-data
  • put
  • stat
• pin
  • add
  • ls
  • rm
• ping
• refs
  • refs
  • local
• repo
  • fsck
  • gc
  • stat
  • verify
  • version
• resolve
• stats
  • bitswap
  • bw
  • repo
• swarm
  • addrs
  • addrs local
  • connect
  • disconnect
  • filters
  • filters add
  • filters rm
  • peers
• tar
  • add
  • cat
• tour
  • tour
  • list
  • next
  • restart
• update
• version

And some pythonic candy:

• add str
• add json
• get json
• add pyobj
• get pyobj

[jbenet]

cc @diasdavid @RichardLitt they can maybe explain more.
On Mon, Aug 15, 2016 at 17:28 Christopher Waldon notifications@github.com
wrote:

Actually, the above is a checklist from the wrong API? I'm confused about
the discrepancies between this
http://docs.ipfs.apiary.io/#reference/bitswap/get and this
https://github.com/ipfs/specs/blob/master/public-api/core/README.md.
@jbenet https://github.com/jbenet What is the difference in intention
between those two specs?
Here is the functionality of py-ipfs-api compared against the Apiary:

NOTE: Not all of the following are tested currently.

• add
• bitswap
  • stat
  • wantlist
  • unwant
• block
  • get
  • put
  • stat
• bootstrap
  • add
  • list
  • rm
• cat
• commands
• config
  • config
  • replace
  • show
• dht
  • findpeer
  • findprovs
  • get
  • put
  • query
• diag
  • cmds
  • cmds clear
  • cmds set-time
  • net
  • sys
• dns
• file ls
• files
  • rm
  • flush
  • mv
  • cp
  • ls
  • mkdir
  • stat
  • read
  • write
• get
• id
• log
  • level
  • ls
  • tail
• ls
• name
  • publish
  • resolve
• object
  • data
  • diff
  • get
  • links
  • new
  • patch append-data
  • patch add-link
  • patch rm-link
  • patch set-data
  • put
  • stat
• pin
  • add
  • ls
  • rm
• ping
• refs
  • refs
  • local
• repo
  • fsck
  • gc
  • stat
  • verify
  • version
• resolve
• stats
  • bitswap
  • bw
  • repo
• swarm
  • addrs
  • addrs local
  • connect
  • disconnect
  • filters
  • filters add
  • filters rm
  • peers
• tar
  • add
  • cat
• tour
  • tour
  • list
  • next
  • restart
• update
• version

And some pythonic candy:

• add str
• add json
• get json
• add pyobj
• get pyobj

—
You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub
#42 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAIcoeefNHtrOTwH2s1IzOn6UGHDXbsiks5qgNoSgaJpZM4IuHG1
.

[daviddias]

@whereswaldon with regards to bitswap, they both list the same commands, care to list what is the discrepancy you see?

Another great resource to help is: https://github.com/ipfs/interface-ipfs-core, we have a bunch of the API defined at https://github.com/ipfs/interface-ipfs-core/tree/master/API and with tests (for js, but that can be translated to python, here https://github.com/ipfs/interface-ipfs-core/tree/master/src). Currently, both js-ipfs and js-ipfs-api follow this interface.

[whereswaldon]

@diasdavid Not with regards to bitswap, but in general. Both of those seem like feature inventories, but not necessarily the same features. One lists "files add", "files get", and "files cat" while the other has "get", "add", "cat" a tons of different commands under the "file" and "files" namespaces. They just don't seem to align, and I don't understand why.

I'll take a look at those tests. It would be nice to port them to Python. Thank you!

[daviddias]

The "files" is a specific case, see: ipfs/specs#98