Well… it isn’t, really. Consider this:
This should probably:
Define a proper sum for the “chunker” parameter
Use Data.IPLD.CID.Version for the “cid-version” parameter
Use multihash for the “hash” parameter
Define the return type as:
Stream 'POST 200 NoFraming PlainText (SourceIO ApiV0AddResponse)
ApiV0AddResponse is a sum of either the progress report (if “progress”
is True), or the actual response.
As we found out, the IPFS API is a bit sparsely documented, so all of these have
to be manually reverse-engineered from the “reference” implementation, and by
trying it out.
There’s also some mangling of responses the Golang client performs. For example,
it never seems clear if “/ipfs/” needs to be stripped from a path or not.
So, no, the work isn’t done.
The path of least resistance is surely to keep using the ad-hoc code already
written for Radicle resp. the remote helper. IMHO, only if we want to position
ourselves as IPFS users, and/or expect to use more features of the API in the
future, it seems worth investing the extra time to polish the thing into a
proper IPFS client library which is useful also for others.
On Thu, Mar 14, 2019 at 9:24 PM James Haydon firstname.lastname@example.org wrote:
Since the work is already done