Live data from Hacker News

Why build this blog, or anything, on IPFS?

teetotality.blog

121–130 of 156 posts

Re: Why build this blog, or anything, on IPFS?

#121
post #99

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.

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?

Re: Why build this blog, or anything, on IPFS?

#123
post #33

Earlier 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.

What is the legal standard for say YouTube about not carrying illicit content? Just follow that. Make a list of banned hashes or something of the sort.

Re: Why build this blog, or anything, on IPFS?

#124
post #121
post #99

Earlier 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?

I'm not sure what you mean by "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…

I've been running my homeserver for a couple of years now (in India), even gave a talk about it at RootConf last year. It is definitely doable. Two approaches that I'd suggest:

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?

#126
post #32

IPFS 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…

I really wish everything written about IPFS would just ignore IPNS, and stop presenting it as a standard part of IPFS. The thing IPNS tries to do can be done better by the existing DNS system (which works fine combined with IPFS) or blockchain-based systems like ENS. IPNS is a slow incomplete tech demo glued to the rest. Ignoring IPNS won't impact your understanding of the rest of IPFS. I don't think people relying on IPFS even use IPNS for anything but a curiosity, and it's so bad that I expect many people get turned off of IPFS because they get confused by IPNS's flaws or assume that the rest of IPFS works as badly.

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?

#127

IPFS 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…

> IPFS still has a long way to go until it is useable in my opinion.

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?

#129

When 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…

Technically content addressing and chunking (chopping up files) are two orthogonal techniques. You could envision a system where the hash of a single raw file (no matter how big it is) is it's identifier, and you can then have a mapping between that identifier and the locations (e.g. IP addresses) of servers who store the whole file.

Re: Why build this blog, or anything, on IPFS?

#130
post #86

Stopped 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?

I agree with your observation on how to improve my comment but the comment was past the edit grace period so i could not update it.
Post reply on HN