Looking for links: REST API replacement using IPFS

Coding
#1

TL;DR:
I’m looking for tips and links for further research that might have covered this topic. I’m looking into developing a protocol that would use IPFS pub-sub channels to replace REST API CRUD calls. If you have come across any code or research on this subject, please drop a link so that I can look into it. What I don’t want to do is re-invent the wheel.

Let me explain the why of what I’m looking to achieve before I describe the how:

I run wallet.FullStack.cash, which is a Bitcoin Cash (BCH) web wallet. I syndicate the front-end over IPFS and Tor as a backup, in case of censorship. A woman in China tried to use my web wallet, but it was censored. She was able to successfully access the IPFS-based front end, but it didn’t work, because the back end REST API server was also censored by the Chinese firewall.

I’ve done some experiments with IPFS pub-sub and see how it could be used as a medium for replacing a typical REST API. I’m looking for any previous work or standards around replacing typical CRUD (create, read, update, delete) commands that REST APIs are commonly used for.

I have an idea of how to approach this problem, but I don’t want to reinvent the wheel if some good work on this front has already been accomplished. I’d appreciate any links and information to any research that has been done on this front.

IPFS replacement for REST API
#2

This YouTube video captures my initial ideas around creating an IPFS pub-sub scheme to replace a REST API:

If there are any JavaScript developers that want to team up on this, please reach out to me. Check the footer in my blog for ways to contact me:

1 Like
#3

This is an interesting idea, but I’d be curious to know first the deeper reason why China is “currently able” to censor Tor traffic and not IPFS traffic?

For example if China Firewall is using some kind of deep packet inspection to detect Tor, you’d want to first “prove” (not guess) that they can’t simply start doing the same thing with IPFS, any day. I don’t know enough about wire protocol to say if that is or isn’t possible. Also I personally don’t know how China stops (or even detects) things like VPNs. VPNs encrypt and anonymize everything so that IPFS should work, secretly, right?

So I’m just saying you may want to know the root reason China cannot censor IPFS, before you rely on that fact as the underpinning of your entire circumvention solution.

#4

From people I’ve talked to in China, the issue is more cultural than technical. If a Chinese citizen goes to all the effort to figure out how to download, install, and use Tor… well, it looks very, very suspicious and is hard to justify without running afoul of party lines.

But in China, if someone on WeChat sends you a link that just ‘happens’ to be an IPFS gateway, well that’s easy to explain and hard to stop. And most people wouldn’t understand the difference between an IPFS gateway and any other website.

My limited understanding of Chinese laws are that they are pretty ‘squishy’ by western standards. ‘Intent’ seems to matter much more than objective proof or fact.

#5

I see what you’re saying, but relying on IPFS for obscurity would be just living on borrowed time, because IPFS is precisely the same kind of “tool for freedom and free speech” as Tor is, so China will target it. If I had to place a bet, I’d say that if China is censoring Tor now, they’ll be censoring IPFS in the very near future unless there is something physically stopping them from having that technical capability (like a VPN).

Another example is the Fediverse. I just added ActivityPub (A REST-like protocol) to my own platform (Quanta.wiki), although it’s not documented/official yet, and I’m wondering what China is going to do to try to censor the Fediverse. Bottom line is, anything that’s not based on encryption that hides 100% of traffic is vulnerable to censorship.

#6

To be clear, I would add e2e encryption to the message passing between nodes. Other than that, obscurity isn’t a goal.

Can you expand on how China would censor a pubsub channel on IPFS? Like mechanically, how could that be possible?

One of the thoughts I had to protect against censorship, would be a bootstrap scheme that each web app would run on startup. This would include things like creating the IPFS node, trying to connect to circuit-relay peers, and a system for looking for circuit-relays to connect to if a default set are censored.

My understanding is that if the nodes at each end use pubsub and can each find a circuit-relay, then there isn’t an effective way to block two IPFS nodes from talking to one another. Please correct me if there is an error in my thinking.

#7

I don’t know how China is doing their censorship or packet filtering. I was merely saying if IPFS works today, that doesn’t mean it will therefore work tomorrow. I could have just said it that simply to start with, because that’s the only point I was making.

#8

I thought I’d give an update on this thread. This is the latest step in my research:

#9

Hi Chris, Thanks for sharing the info. I read most of it and watched the video. Really interesting stuff you’re doing.

1 Like