ipns-link VS Go IPFS

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.

You might wanna take a look at ipns-link.

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

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.

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.

nice/renice isn’t what it used to be[0].

Bandwidth limiting is not built in[1].

[0] - https://stackoverflow.com/questions/10342470/process-nicenes...

[1] - https://github.com/ipfs/go-ipfs/issues/3065

For me, https://github.com/ipfs/go-ipfs/issues/9044 is the main blocker atm and https://github.com/ipfs/go-ipfs/issues/2167 is still around and annoying.

It makes me wonder if you use the IPFS FUSE mount and symlink an IPNS address of files that you want to sync if it would be read by Dropbox.

I'm using the IPFS fuse mount to load mine into Plex/Jellyfin. It's nice that I can load a movie into a virtual directory on IPFS and my home and remote servers get updated automatically. (when I update my IPNS) So you could run an official solidaritycinema IPNS address that people load into their Plex as a library.

Maybe tangentially related, I've been interested in IPFS as a network medium. ( Using the IPFS fuse mount ) Rather than syncing the entire file it syncs the Library list. When the Plex server makes the request for the file, IPFS negotiates the download. It makes it more like Netflix.

I've been messing with Plex + IPFS and I think it's pretty cool. The IPFS FUSE Mount gives IPFS network access to Plex as just a regular filesystem. To keep it private within my family I'm using a Private Swarm.

"Implement bandwidth limiting" https://github.com/ipfs/go-ipfs/issues/3065

Going on six years now. You can use external tools (like "trickle") or your OS knobs.

So my plan is to setup plex on a relative's Raspberry Pi so that it works off the IPFS mounted network directories in the same way. They'll have a virtual library that takes basically no memory on their Pi unless they request a video, then it'll start caching to their machine.