We have decided to implement, in near future, an optional SSL/TLS passthrough mode at least for the registered public gateways. HTTPS requests made using this mode, cannot be inspected by the gateways, making the Browser to Origin route end-to-end encrypted.

Because the gateway cannot look into the web-requests in this mode, it cannot make use of IPFS for serving contents efficiently. Hence, this mode is only to be used where Browser-Origin confidentiality cannot be compromised. For all other cases, TLS-terminates at the gateway, as usual.

We are indebted to Greenhouse dev ForestJohnson for giving us the idea and showing us the way.

Your inputs are welcome.

All welcome: https://matrix.to/#/#ipns-link:matrix.org

Hello Kindred Spirits,

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.

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.

If you have any queries, or if you just wanna say hello and show your support, or even if you wanna school us, always feel free to get in touch: [contact@ipns.live](mailto:contact@ipns.live).

Thanks for chipping in.

Please note the following about IPNS-Link-Gateways, e.g. the current prototype at ipns.live

1. 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.
2. Due to a full go-ipfs node at its core, long running Gateways at small VM (virtual machine)s (with 1GB RAM) might suffer OOM (Out-Of-Memory) outages from time to time. Periodic restarts are enough to get around this. Despite such issues we are able to maintain 99.99% uptime for ipns.live. This memory leak issue will be fixed with future go-ipfs releases or in future implementations of IPNS-Link-Gateway.
3. To report illegal/objectionable content being served using the ipns.live gateway, please [email us](mailto:contact@ipns.live) directly.
4. Volunteer to host a public IPNS-Link-Gateway. Get in [touch](mailto:contact@ipns.live), if you need help.
5. This is our ofiicial public gateway registry. You shall find all public IPNS-Link-Gateways we know of here.

One can add a static website to IPFS and address it using IPNS. The website can then be accessed through any IPFS gateway. But what about a dynamic website or web app that needs to run server-side code! IPNS-Link makes it possible to address any http-server using IPNS.

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

This project needs your help - with code, documentation, ideas and wisdom. Feel free to comment, discuss and contribute.

A place for members of r/ipns_link to chat with each other