Well… it isn’t, really. Consider this:
https://github.com/oscoin/ipfs/blob/master/ipfs-api/gen/Network/IPFS/API.hs#L24
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)
Where 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 james@monadic.xyz wrote:
Since the work is already done