Disclaimer: I run the unofficial IPFS Discord and Matrix (found at https://permaweb.io/discord and /matrix) and have helped organize IPFS Meetups in SF. We also run an IPFS gateway and have built a groups app on top of IPFS and Textile. I generally agree with the conclusion, but there's a few downsides that aren't conveyed here. Let's look at the proposed upsides: 1) Ownership, control, censorship: That's partly corr…
> IPFS doesn't encrypt the content, or the connectivity, or hide the hosts. Solutions exist around that, but they're niche, and honestly I question the motives besides just ideology. Hiding connectivity metadata and host identity are essential to protect users from adversaries.
Why build this blog, or anything, on IPFS?
121–130 of 156 posts
Re: Why build this blog, or anything, on IPFS?
#122Re: Why build this blog, or anything, on IPFS?
#123Earlier quoted context omitted.
Well, one can use IPFS through Tor, and use gateways that are Tor onion services.
Obfuscating your IP doesn't solve the problem. If a malicious actor knew someone's info (such as address), they could give them an ipfs link with CP and report them.
Re: Why build this blog, or anything, on IPFS?
#124Earlier quoted context omitted.
> IPFS doesn't encrypt the content, or the connectivity, or hide the hosts. Solutions exist around that, but they're niche, and honestly I question the motives besides just ideology. Hiding connectivity metadata and host identity are essential to protect users from adversaries.
I agree with you, but I suspect your observation is circular in this context. If we define "protect" and "adversaries" appropriately, couldn't this be true of any measure?
What I'm recommending would protect all sorts of users from all sorts of adversaries. So it's nonjudgmental.
But that doesn't mean that it's "circular".
Re: Why build this blog, or anything, on IPFS?
#125> even go super old-school and run a web server at home. It's not as if we're short on options in 2020. Though it's old school, it's incredibly difficult to run server at home now at least in India. The network I connect to is behind a NAT which is behind another NAT. At least that's what I saw when I tried to host my blog on Raspberry PI at home over a year ago. Ultimately I gave up on that endeavor. If anyone has s…
1. Talk to your ISP. Most of them will assign you a public static IP for a fee (5000 INR/yr was what I was quoted last time)
2. Setup a simple proxy on a $5 droplet on Digital Ocean. I run OpenVPN server on the droplet, a client on the homeserver, and `simpleproxy` that forwards the relevant ports. You can do the same with iptables as well.
3. Any other approaches involving ngrok-like solutions are much costlier, unless you host it.
Re: Why build this blog, or anything, on IPFS?
#126IPFS still has a long way to go until it is useable in my opinion. The default configuration for the desktop client will gladly keep open 1000+ peer connections and will happily degrade your usual internet experience. In addition the ecosystem is filled with technical/community debt that makes navigating the system a nightmare for anyone who isn't an expert. As an example: https://github.com/ipfs/go-ipfs/issues/1482…
To add to this there are* serious issues with naming. I wrote an app that ran on IPFS last year and throughout testing there was a persistent problem with needing to issue the testers with a new hash/link for each new version because IPNS, IPFS' decentralized naming solution, effectively doesn't work. It's supposed to give each node a unique name which can be repeatedly mapped to different hashes but publishing a new…
IPFS is good at content-addressed storage. IPNS is not part of content-addressed storage. Tutorials about IPFS should ignore IPNS, and talk about alternative ways to link to IPFS links, like using DNS.
Re: Why build this blog, or anything, on IPFS?
#127IPFS still has a long way to go until it is useable in my opinion. The default configuration for the desktop client will gladly keep open 1000+ peer connections and will happily degrade your usual internet experience. In addition the ecosystem is filled with technical/community debt that makes navigating the system a nightmare for anyone who isn't an expert. As an example: https://github.com/ipfs/go-ipfs/issues/1482…
Now we just need to figure out what to use it for. I think the largest successful experiment of distributed file storage was Wuala. At the beginning it was similar to IPFS, using random home devices to store data, doing some clever calculation and splitting of files to guarantee that a file is likely always available. Emphasis on likely.
They had nice features:
- keep files private
- share files with other registered users
- share files with unregistered users, through a keyed hyperlink
- publish files
- backup
- file synchronization
- file versioning
At the end they migrated away from using random home nodes for storage and went for central servers. Not sure about the motivation behind it but I would really like to know. Did that happen because of business requirements or some technical limitations?
Re: Why build this blog, or anything, on IPFS?
#128Re: Why build this blog, or anything, on IPFS?
#129When I first learned about content addressing a couple years ago, it sounded like the holy grail. I'm less certain now. It seems much better from the machine perspective, but I'm not sure it matches closely enough the way humans interact with data. We are spatial and temporal creatures. There's something unsettling about my video file being chopped up into a million chunks and stored who-knows-where. Compared to the…
Re: Why build this blog, or anything, on IPFS?
#130Stopped reading after "Medium's engineers are much better at all of this than you will ever be"; can't take this writer seriously.
I dislike this formula of "Stopped reading after ..." that I seem to be seeing more frequently. Why not just make your criticism of the quoted text straight up? Why the rhetorical flounce out of the room?