ipns-link-gateway VS ipns-link

For your implementation, you can follow the specs, which you are welcome to discuss, criticize, improve upon and contribute to, and reference the existing version. Once you start working on an implementation, please create an issue here to keep the community updated and to encourage collaboration. Once it's working, your implementation will be proudly featured in IPNS-Link's GitHub organization and you would receive a public membership invitation.

Due to a full go-ipfs node at its core, long running Gateways at small VM (virtual machine)s (with 1GB RAM) might suffer from periodic OOM (Out-Of-Memory) outages. Periodic restarts are enough to get around this. ipns.live currently restarts hourly causing just a few seconds downtime every hour. This memory leak issue will be fixed with future go-ipfs releases or in future implementations of IPNS-Link-Gateway.

I saw this project, IPNS-Link, that seems promising, but I wasn't able to make it work yet and seems to require specialised IPNS-Link gateways, they can't use just any IPFS gateway, and their freely available gateways seem to be all down rn, so I'd probably have to host my own gateway anyways.

Install and run a free and open-source app on your local server (the Pi in your case), following this easy tutorial.

To access your site anytime, all they need to do is go to any public IPNS-Link-Gateway, such as ipns.live and put your UUID in there. Or, better yet, they can run their own private gateway locally on their computer, and access your site directly, without any middle-man.

We welcome you to implement the IPNS-Link project, especially the Gateway, in a proper server-side language - be it Go, JS, Rust, Ruby, Python - whatever you are good at. The existing prototype, in the spirit of playful experimentation, has been rather hurriedly hacked in Bash 🙈. Thankfully, it works! But of course, we need to evolve.

Loading an ipns-link-exposed website for the first time might take a while. This is because the Gateway has to locate your site and peer with its host node. Subsequent requests for the site, however, are served faster because the Gateway maintains persistent peering with the site's host node.

Here's an overview and a quick-start tutorial. And here's a prototype gateway.

A reverse proxy is meant to hide the backend (origin) servers from the world. That is, to reach those servers, one must go through the proxy. Now, when you expose a server with a public IP address using the ipns-link app, anyone can access its public IP address and port from its IPNS post. She can then connect to the origin server directly from her browser, thus bypassing the gateway. So, the gateway in this case is anything but a reverse proxy.

The static blue background is missing. This might happen due to the following. The background is embedded in the html and sourced from a root-relative URL. Now, being a path-gateway, ipns-link.herokuapp.com requires the Referer header (with absolute URL) in the http request, so that it can resolve the PeerID when requested a relative path without the /ipns/PeerID prefix. Although the Gateway wants a complete referrer URL, the embedded tags may override it with a different ReferrerPolicy. If overridden in this way, the Gateway can't resolve the PeerID and fails. NOTE: this problem WILL GO AWAY once the IPNS-Link-GATEWAY supports wildcard subdomains, hopefully in the near future. Then, there wouldn't be any dependence on the Referer or cookie or server-side cache for resolving root-relative URLs, and everything would work as intended. Subdomain Gateway has always been the end-goal, but due to the lack of a domain I went with a path-gateway for prototyping.

To make your server at localhost: accessible through any IPNS-Link-gateway you just need to expose it with the ipns-link app. I haven't used Termux, but AFAIK, it gives you a Bash shell by default. ipns-link is written in Bash so there should not be any problem.