The prototype is live.
Overview of the project: ipns-link/specs: Technical specifications for IPNS-Link-app and IPNS-Link-gateway (github.com)
Quick start tutorial : ipns-link/QuickStart.md at main · ipns-link/ipns-link (github.com)
A prototype gateway : https://www.ipns.live. Tutorial for self-hosting here.
If you have had your first taste of IPNS-Link, we are eager to hear from you. Join the community and help the project grow. Consider contributing in any way you can.
If you have any questions or comments feel free to email us.
We also take this opportunity to thank the IPFS and Libp2p developers without whose hard work and commitment, IPNS-Link would never exist.
Here’s our first blog post. Hope you like it 
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 freely 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 wanna say hello and show your support, or if you just wanna school us, always feel free to get in touch: contact@ipns.live.
Thanks for chipping in.
Another blogpost on IPNS-Link : Introducing IPNS-Link - DEV Community
Looks interesting. Please forgive me, because I haven’t dug too deeply into this yet, but what does IPNS-Link to that isn’t already in stock IPFS? Does it just automate some of the functionality already there? Does it add something new?
@zacharywhitley Glad you asked 
The current implementation of IPNS-Link consists of simple Bash scripts dependent on go-ipfs (v0.10.0 onwards) and some standard *nix tools. In this sense, IPNS-Link indeed just automates some of the functionality already there in vanilla IPFS. So what’s all the fuss about, you might ask. Well IPNS-Link shows you a new way to use IPFS, if you will, harnessing its full potential – something I haven’t found elsewhere. Allow me to explain.
IPFS is mostly associated with static web-publishing. IPNS-Link, on the other hand, exposes any web-app, including dynamic sites.
To access an website pinned to IPFS, you need an IPFS-gateway. To access a web-app exposed with IPNS-Link, you need a new type of gateway, called an IPNS-Link-gateway. These gateways are purpose-built to serve dynamic websites efficiently. They are way more than simple http-proxies. When they are asked to perform as a simple IPFS gateway, they would shake their head and redirect you to a subdomain IPFS gateway such as cf-ipfs.com.
When exposing your website with IPNS-Link, you can specify which public gateways you trust. All other gateways will redirect your users to your trusted gateways.
You can instruct IPNS-Link-gateways to redirect users to a preset URL when your local server is offline.
You can instruct IPNS-Link-gateways to serve the static contents of your website - such as logos, images, css, javascripts and knowledge-base from the IPFS cache (compare CDN). Only requests for dynamic contents are proxied to the origin-server. Gateways can be instructed to cache streaming content too.
IPFS, in conventional usage, consumes a lot of bandwidth, even in dhtclient mode. IPNS-Link doesn’t. It takes lots of pains to make sure your internet bill is minimal without sacrificing performance.
In an upcoming feature, you would be able to enforce geo-restriction at the gateway level. Third parties can’t censor your site, when exposed with IPNS-Link. But you may choose to geo-restrict yourself, and gateways would respect that.
Very cool. Thanks for the response. All very good into to know about your project. It’s really helped me to understand it a lot better.
IPNS-Link has a Matrix community now. All welcome: https://matrix.to/#/#ipns-link:matrix.org
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.
I kinda just built a DHT on my own, then use that to keep track of immutable CID so it looks mutable to me while I can swap the underlying unmutable part, there’s already library that does this pretty well, especially in amazon’s s3.SDK since they support torrenting
it would be nice if ipfs supports mutable object out of the box, so I can just edit / change files. sigh must I do everything myself.
You don’t have to. You can use Mutable File System (MFS) for that.
You are right.
I do hope IPFS add support for mutable object with constant CID so we can share files across ipfs network without an alternative way to notify people that the object has changed though.
Although in MFS you can set whatever file name you want using, this filename isn’t CID so while you can change its content to whatever you like it’s CID also changes making it something new that you can’t use the CID you shared with people to get to.
Which is what I think people currently would have to do, is see if ipns works for them, or go ahead and make a tracker that gives a link you can share to people, which then looks up its record on your server for the CID to get the data from for your object that the linked you shared represent.
it would be nice to see ipfs heads to this direction where they implement Constant ID instead or as supplement to the current CID in the future, and make api calls faster too, and more through put to close the gap to bittorent
(post deleted by author)
Maybe it’s possible to use Github for this, you already got a file system on github, so just upload your stuffs to ipfs MFS root directory and put the CID inside git