Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why build this blog, or anything, on IPFS?

teetotality.blog

Post reply on HN
Print view View original

111–120 of 156 posts

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

#111

Post by qqii »

MiroF wrote: post #109
Polylactic_acid wrote: post #38

Earlier quoted context omitted.

Honestly I think the simplest and most effective method is to keep things as they are and have archive.org/.is keep backups of websites. A backup on archive.org is much more likely to stick around after 10 years than the users seeding a file.

Not if there is a government issued takedown notice it isn't.

IPFS has the same problems given a takedown notice[0]. Although you could continue serving the content and convince others to serve the content, any entity can take the next step and go after you.

[0]: https://github.com/ipfs/notes/issues/284

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

#112

Post by woodandsteel »

charles_f wrote: post #85
singron wrote: post #81

Earlier quoted context omitted.

Isn't this kind of an unreasonable demand? It's not like software isn't ready for anyone one day and ready for everyone the next. Considering just about nobody can give an accurate software development forecast for even objective milestones, it seems ridiculous that there would be any reasonable answer to this.

Beyond the question of the possibility of giving a precise answer, did OP lose sight of basic courtesy? As far as I know IPFS is an open system contributed to by volunteers. Making those kind of demands for deadlines in such an aggressive tone is way out of place.

No, I am just asking for honesty. Either they have some sort of idea when it will be basically usable, or they don't. I am not saying they have to meet a deadline, I am asking when they think they are going to get there.

And why do they need to be defended by others? If I am being unreasonable, why don't they just say that themselves?

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

#113

Post by sriku »

skybrian wrote: post #100
tetrisgm wrote: post #41

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…

I'm wondering if IPFS might be better thought of as a common data-publishing protocol that might be used to push content to any number of CDN's? So, you could publish content to IPFS and tell your favorite CDN to pick it up, and you pay them to keep it active. But IPFS isn't limited to one CDN, so you could always pick another one. And your users could also go through a different CDN. Or some people who really want t…

The Dat protocol was supposed to play that role (https://dat.foundation/)

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

#114

Post by woodandsteel »

singron wrote: post #81
woodandsteel wrote: post #73

Earlier quoted context omitted.

>You're right, there are a ton of great ideas and suggestions for how to make IPFS better that we haven't gotten to yet I love the idea of IPFS, but let me ask you the question, when is it finally going to be ready for people to easily deploy? A year from now, 3 years, 5 years? Or maybe you have no idea? Don't give some vague answer about how you are working on it. Give me a reasonably specific prediction, or say you…

Isn't this kind of an unreasonable demand? It's not like software isn't ready for anyone one day and ready for everyone the next. Considering just about nobody can give an accurate software development forecast for even objective milestones, it seems ridiculous that there would be any reasonable answer to this.

I am not asking for an exact answer, just an approximate one. And if they honestly have no idea, then they should say that.

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

#115

Post by MiroF »

qqii wrote: post #111
MiroF wrote: post #109

Earlier quoted context omitted.

Not if there is a government issued takedown notice it isn't.

IPFS has the same problems given a takedown notice[0]. Although you could continue serving the content and convince others to serve the content, any entity can take the next step and go after you. [0]: https://github.com/ipfs/notes/issues/284

This also seems to be true in theory regarding torrents but not in practice.

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

#116

Post by bardan »

woodandsteel wrote: post #112
charles_f wrote: post #85

Earlier quoted context omitted.

Beyond the question of the possibility of giving a precise answer, did OP lose sight of basic courtesy? As far as I know IPFS is an open system contributed to by volunteers. Making those kind of demands for deadlines in such an aggressive tone is way out of place.

No, I am just asking for honesty. Either they have some sort of idea when it will be basically usable, or they don't. I am not saying they have to meet a deadline, I am asking when they think they are going to get there. And why do they need to be defended by others? If I am being unreasonable, why don't they just say that themselves?

Who says they need to defend themselves? If I come across somebody making unreasonable demands I ignore them.

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

#117

Post by anderspitman »

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 path/URL approach where I have a single large file. I know where it lives and how big it is. Moving/copying/deleting/updating/etc are all intuitive and map to analogs in the physical world. Content addressing (and object storage system I might add) isn't as easy to reason about.

Don't get me wrong. Content addressing is very cool, and may revolutionize everything. It's very elegant. I'm just a bit skeptical.

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

#118

Post by marknadal »

nullstyle wrote: post #29

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…

I know so many projects with barely any popularity being forced to move off of IPFS cause of performance problems.

DAT,SSB don't work in browser.

WebTorrent is the original better choice.

But I'm seeing most big projects move to GUN (mine, https://github.com/amark/gun). Internet Archive, HackerNoon others using it in production, with over 10M+ users, decentralized.

If IPFS team doesn't seriously fix their performance issue within 2 years, they're gonna see a lot of backlash. With $250M+ raised and 100+ employees this should be possible, I know they can do it, dWeb would be better for it.

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

#119

Post by TheColorYellow »

woodandsteel wrote: post #114
singron wrote: post #81

Earlier quoted context omitted.

Isn't this kind of an unreasonable demand? It's not like software isn't ready for anyone one day and ready for everyone the next. Considering just about nobody can give an accurate software development forecast for even objective milestones, it seems ridiculous that there would be any reasonable answer to this.

I am not asking for an exact answer, just an approximate one. And if they honestly have no idea, then they should say that.

I want to call out this attitude as incredibly entitled and related to the exact root cause of all the open-source drama we've been seeing lately.

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

#120

Post by nullstyle »

momack2 wrote: post #50
nullstyle wrote: post #29

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…

Hey IPFS person here. We actually made a change to ipfs-desktop back in Feb of last year to reduce the default connection limit to ~300 ( https://github.com/ipfs-shipyard/ipfs-desktop/pull/828 ), and also to set desktop nodes into DHT-client mode (so they don't get lots of requests from other nodes for where to find content). If you've been running your node since back then, you can change your defaults in the deskto…

Hi! Thanks for taking the time to respond and correct my outdated info. Unfortunately, It seems your info is also outdated: I just installed 0.10.2 for Mac and it's by default using (600,900) for the low and high watermarks and routing type is set to dht rather than dhtclient.

Since I've got you here, I'd be happy to give a little feedback: The constellation of websites for the protocol labs projects, their different visual styles, their different states of decay/maintenance, the interlinking back and forth with source files in github, and the undocumented status of all these projects really lend to a maze-like and poor learning/browsing experience. If it were my project, I would dump all the different sites and consolidate under one web presence. I never know if what I'm reading is current, or planned and not done, or old and out of date, or just bugged. As an example, there are even broken links on the readme at https://github.com/ipfs/ipfs. The number of TODOs or unresponsive links in README files in the various github repos (under the various github organizations) adds to the frustration of trying to learn your work. As an example, take the readme at https://github.com/ipfs/go-hamt-ipld : It's been recently worked on, and yet the entire table of contents are broken links and the examples section is literally just "//TODO". I think y'all should consolidate efforts, kill or privatize the projects that are unusable by the outside world, and in general start developing things to a more complete state before adding new stuff.

I've tried several times now to incorporate IPFS into my developer toolbelt and have aborted my attempt each time due to this or that rough edge that you don't learn about unless you spend time trolling through the github issues. It seems like each time I've come back y'all have added more unfinished stuff (congrats on the filecoin testnet!) and the rough edges still remain. As an example, I just added a 7 gigabyte file (an xcode disk image) through the desktop client: It peaked at around 15gb of ram during the process and the client offered _zero_ visual feedback while it was working. In fact, while the client says my repo is the correct size, the xcode image I added doesn't actually show up in the file browser. It's all very painful to work with. ipfs, ipld and libp2p hit the right notes in their promotional material to entice someone who wants to help the decentralized web grow, and I would love for these projects to be what they aspire and claim to be, but it all just seems to fall apart rather quickly when you actually start to use them for something beyond your tutorials.

Post reply on HN