IPFS replacement for REST API

I previously started this thread on the topic of building a general purpose IPFS-based API that could replace the REST API standard:

I recently created this blog post to further flesh out the approach I’m thinking of taking, including the prototype that I’ve coded up:

My question to the IPFS community: Has this already been done? Is anyone aware of a body of work to build this kind of infrastructure? I don’t want to reinvent the wheel, if significant work has already been accomplished.

1 Like

For those who want more technical details, one of the first applications I intend to use this for is CoinJoin transactions on the Bitcoin Cash network. Here is a rough-draft specification that includes more details on the peer-discovery that I plan to implement.

Have you looked into p2p http proxy? It’s experimental but sounds a bit like what you’re doing.

Do you have a link? I’m not completely sure what you’re talking about.

1 Like

Thank you for that link!

I was able to get two go-ipfs nodes to pipe a REST API over IPFS using p2p http. However, I was not able to get it to work in the browser.

I got something back on the browser, but no indication that the ‘server’ saw a request. Some sort of error webpage came back. But it appears that even with circuit-relay, a web app is not able to make use of this feature. It does not appear to have been implemented in js-ipfs as far as I can tell.

I’ll have to think hard about if I want to settle for the current implementation on the server-side, and hope that it’s developed for the browser in the future; vs pushing forward with the pubsub-based API I’ve been contemplating.

I can see now that the blog post I created on this topic is too generic to get the kind of specific help that I’m looking for. I need to develop the prototype a little further to add peer discovery and a request/response workflow, so that it’s clearer how my idea differs from something like p2p http or the built-in parts of ipfs with those same names.

1 Like

Or… I suppose what I need to clarify is the communication protocol from the service/peer discovery portion. I’m confusing the question by not separating them.

That p2p http is one way to solve the communication portion. I had planned to use pubsub for that, but I could also just pipe http over IPFS using that p2p http feature. The communication part could be solved either way.

But the part that isn’t clear from that blog post, is the peer discovery, and a way for nodes to interrogate peers to discover what API endpoints (and thus features) that they offer.

Essentially what I envision is:

  • A node enters a pubsub room and starts listening for other peers.
  • When a new peer is discovered, it would set up a private e2ee pubsub channel between the peers.
  • The node would then interrogate the peer to find out what APIs it’s running, and what endpoints of that API that it can interact with.

Example: A wallet app, for example, could listen for peers to find the least expensive full node and indexer, which it needs to perform basic wallet functionality.

Not only is this creating incentive for participants to offer services, its creating a decentralized marketplace that makes it easy to circumvent government firewalls and geofencing.

It’s this basic peer-interrogation protocol that is the heart of the idea. I’m wondering if anything like that has been developed on IPFS?

1 Like

Latest update in this research:

I coded this node.js JavaScript npm lib:

Chat-app proof-of-concept:

There is no e2e encryption implemented yet.