IPFS API Client

1

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

2

Just want to point out a third option: we announce it/release it and maybe try to get the protocol lab folks or other interested parties to maintain it if there is interest.

···

On Thu 14. Mar 2019 at 14:18, Kim Altintop kim@monadic.xyz wrote:

Hey all,

with the release out the door, I thought it might be a good time to bring up some next steps topics 8)

For starters, here is the easy one: is there interest from the Radicle team to adopt the IPFS API client[0] I started for use with the git remote helper?

As I explained elsewhere, this is auto-generated code which, due to the way the IPFS API is designed and implemented, will need a fair amount of hand-tweaking. Since the IPFS folks don’t provide a swagger (or somesuch) spec of their API - and I believe they even made a conscious decision to not do so - it will also be a bit painful to test and maintain over time. On the other hand, if there are people out there who are interested in building apps using Haskell on top of IPFS, we might get some help on that front.

In total, I think whether we want to invest in this depends somewhat on the level of commitment to IPFS we want to make going forward.

A negative response would be totally fine by me: in that case, I’d just sunset the thing and inline just the endpoints required by the remote helper (which itself should probably graduate from the repo into it’s own, but that’s a separate discussion).

What say?

  • K

[0] https://github.com/oscoin/ipfs/tree/master/ipfs-api

3

Hey all,

with the release out the door, I thought it might be a good time to bring up some next steps topics 8)

For starters, here is the easy one: is there interest from the Radicle team to adopt the IPFS API client[0] I started for use with the git remote helper?

As I explained elsewhere, this is auto-generated code which, due to the way the IPFS API is designed and implemented, will need a fair amount of hand-tweaking. Since the IPFS folks don’t provide a swagger (or somesuch) spec of their API - and I believe they even made a conscious decision to not do so - it will also be a bit painful to test and maintain over time. On the other hand, if there are people out there who are interested in building apps using Haskell on top of IPFS, we might get some help on that front.

In total, I think whether we want to invest in this depends somewhat on the level of commitment to IPFS we want to make going forward.

A negative response would be totally fine by me: in that case, I’d just sunset the thing and inline just the endpoints required by the remote helper (which itself should probably graduate from the repo into it’s own, but that’s a separate discussion).

What say?

  • K

[0] https://github.com/oscoin/ipfs/tree/master/ipfs-api

4

Since the work is already done, I think we can start using it. If it
becomes clear the burden of maintaining it is too high then we can
just inline at that point?

James

···

On Thu, Mar 14, 2019 at 5:14 PM Alexis Sellier <alexis@monadic.xyz> wrote:

Just want to point out a third option: we announce it/release it and maybe try to get the protocol lab folks or other interested parties to maintain it if there is interest.
On Thu 14. Mar 2019 at 14:18, Kim Altintop <kim@monadic.xyz> wrote:

Hey all,

with the release out the door, I thought it might be a good time to bring up some next steps topics 8)

For starters, here is the easy one: is there interest from the Radicle team to adopt the IPFS API client[0] I started for use with the git remote helper?

As I explained elsewhere, this is auto-generated code which, due to the way the IPFS API is designed and implemented, will need a fair amount of hand-tweaking. Since the IPFS folks don't provide a swagger (or somesuch) spec of their API - and I believe they even made a conscious decision to not do so - it will also be a bit painful to test and maintain over time. On the other hand, if there are people out there who are interested in building apps using Haskell on top of IPFS, we might get some help on that front.

In total, I think whether we want to invest in this depends somewhat on the level of commitment to IPFS we want to make going forward.

A negative response would be totally fine by me: in that case, I'd just sunset the thing and inline just the endpoints required by the remote helper (which itself should probably graduate from the repo into it's own, but that's a separate discussion).

What say?

- K

[0] ipfs/ipfs-api at master · monadic-xyz/ipfs · GitHub