Custom logic over IPFS

Hi everyone here!

I’m planning to store my content in IPFS, but after getting content I want to use custom logic like custom-protocol-decoding . What is proper way to do that on high loads? (need to have as small network-overhead as possible)

As I understand, I can just create custom-logic-go-app and deploy it on same machine, so it’ll just proxy content from IPFS. But what is proper way to get content from IPFS? Should usual GET localhost:8080/ipfs/<cid> be enough or do I need to use p2p connection like swarm or etc?

Or should I extend kubo -library, add some extra logic here and build my own Custom-IPFS-Docker?

Thanks a lot, guys!

Dear @hector I think I need your help here :pray:

Should usual GET localhost:8080/ipfs/<cid> be enough

That would be enough I guess, depending on what you are trying to read from ipfs and for what.

2 Likes

Thanks a lot, Hector! :handshake:

Could you say what should I use as transport - net/http or golang.org/x/net/http2?

@hector thanks a lot again! Everything works!

net/http is enough. Btw, don’t you know why IPFS does not support http2?

net/http imports golang.org/x/net/http2 BTW.

1 Like

The default implementation of net/http is a bit google opinionated so it only follows google’s early drafts at http2 (you NEED encryption (TLS) to have http2 which Kubo does not ship with).

You can get http2 without tls (called h2c) working, however doing this you do not have http1 support (so you would need two listeners, one for http and one for h2c).

h2c isn’t widely support also.

Edit: nvm it seems you can do upgrades, however the lack of widespread client supports make this kidna meh

Not sure fully understand how it works, but heard same, yes :slight_smile:

The first request on an h2c connection is read entirely into memory before the Handler is called. To limit the memory consumed by this request, wrap the result of NewHandler in an http.MaxBytesHandler.

I was about to open a new issue on Kubo to add h2c support, but this is a deal breaker, we REALLY need to support streaming BIG requests. (a file upload can be GiBs big for example)

1 Like

Yes, fully agreed… We can try to do this :smirk: