Hacker News Reader

Comment by adfrhgeaq5hy | Hacker News Reader

IPFS needs to decide what it wants to be. Is it about being a decentralized caching layer? Is it about permanently storing content? Is it about replacing my web server? Is it about replacing DNS? Is it about censorship resistance?

Right now it does none of those things well. The client chews through CPU and memory when seemingly doing nothing. If I try to download content, it is far slower than BitTorrent unless I go through a centralized gateway. If I add content it takes ages to propagate, making it utterly unsuitable as a replacement for a web server. There is no system to keep content alive so links will still die. The name system is byzantine and I don't think anyone uses it.

Unfortunately, they are now unable to pivot because they did that asinine ICO. The right thing to do is to give up on the FileCoin nonsense and build a system that solves a problem better than anything else, but that is no longer allowed because they already sold something else to their "investors"

View on HN

IPFS's design makes it so that it's all of those things, or none of them. Picking one of them doesn't fit the shape of the technology. IPFS is basically the answer to the question "what is the RIGHT way to decentralize the web?". If you think about that question hard enough, then anyone can see that their way of doing it is the "right" way. It's just obvious. The problem is that all of these mutually supporting components need to be bootstrapped in order to make it work. You can't take the storage of content and federate it out across the entire internet without being able to refer to it by a content id. You can't just have content addressing by itself, because then it's inconvenient to find things on a day-to-day basis. So that means you need a DNS equivalent. And you can't assume a decentralized graph of network participants will bother to serve this information unless there's reward in it for them. So you come to filecoin. Etc.

Point being, they didn't just bite these pieces off randomly: they see a picture of how the internet _could_ work, and they're trying to realize it. If they can get it working, then boom! You have decentralized internet, and you also have a ton of bonuses that just fall out from this being the right way to do things: resistance to censorship, better archiving, reduced influence of web megacorps, etc. But you have to have it -all- to actually be better. The sum is WAY greater than the parts.

The trouble is, this statement:

> Right now it does none of those things well.

is true.

So I get what you're saying. To build user-adoption, they need to find a way to deliver an improved experience, not just an improved model that would be better if more people used it. But I object to the idea that the solution is to choose one of those things at the exclusion of the others. The whole idea doesn't make sense if they choose one. If I were advising them, I wouldn't tell them to reduce their scope in terms of "doing all the things", but rather reduce their scope in terms of doing all the things for the entire internet. They should find some kind of sub-network or community that gets extra value out of the decentralization, and prove out the concept there. Maybe it's a big company's intranet, or a network of (paging ARPA) universities?

I would have preferred IPFS to do the storage and propagation of data really well and not implemented stuff like IPNS in the core.

To me this should be a separate codebase. And I see this in other features they have been including too.

I'm using IPFS quite heavily to store content generated on https://pollinations.ai but there is no way I could run it without a centralized node that I have control over at the moment because otherwise it would just be painfully slow and unusable.

I love the idea of content addressed decentralized data. I have no real use for IPNS at the moment and many of the other features of the core IPFS stack.

Have you had a chance to try Skynet? It provides all of the same features as IPFS, but it's also a lot more performant and higher uptime. You wouldn't need a centralized node that you run yourself.

Do you have any good links to Skynet? I could just find an old GitHub repo. Is it in active use ?

I found this, I think it's what @Taek's referring to - https://siasky.net

Check out the pinned repos: https://github.com/SkynetLabs

Also https://docs.siasky.net/

Very much an actively developed project, with over 100,000 monthly active users.

The second link claims that it will store data without payment and allow extracting money in the future, with 0 mention of who is paying for the space. This is so suspicious that I almost cannot believe this is not addressed immediately.

Skynet operates on a freemium model where users get 20mbps and 100 GB of storage for free and significantly more if they pay (80mbps and 1 TB for $5/mo). This is what pays the bills, and also how things stay pinned.

I haven't used IPFS so I was trying to see what the IPFS image URL would look like but when I tried to inspect the images using (right click -> inspect element), Chrome selects the whole division tab (class=MuiCardContent-root) in the Elements tab in web console. I found that it's happening because of (style="pointer-events: none;"). When this style attribute is removed from web console, I'm able to inspect individual elements like image, paragraph correctly. Just out of curiosity, do you know why (style="pointer-events: none;") is used here?

Check an URL with results: https://pollinations.ai/p/QmbhMnkgrqqwQ39BP7S3F8qNSqHueaQz42...

The landing page is a bit of a mess

> IPFS is basically the answer to the question "what is the RIGHT way to decentralize the web?"

There is no RIGHT way to decentralize the web. I don't think IPFS is the right way to do it either.

Tim Berners-Lee's Solid (https://solid.mit.edu/) offers a much more practical path to a decentralized web. The advantages with Solid's approach over IPFS is that:

Solid doesn't throw out what we already have, and recommend a new layer on top of the internet (example: ipns).

Solid handles access control which pretty much every application needs (encryption is btw, a poor substitute for access control).

Solid has the ability to revoke access, and delete data (very important).

It can work in browsers without extensions.

Solid is not muddied with talk of the Blockchain. It's disappointing that cryptocurrency has very nearly hijacked this space.

Solid is conceptually simple. You own a pod that has a unique address (using familiar schemes). You put your stuff on it and allow access to people; like DropBox but standards based. Companies can offer paid hosting services to run your pod - more space, bandwidth etc.

IPFS is not commercialization friendly. IPFS performance is unlikely to be great, ever.

Disclosure: I am invested in an open protocol similar to Solid, but simpler. So not entirely unbiased.

What is that simpler protocol?

I'll do a Show HN in a month.

Although a reference implementation (https://github.com/webpods-org/podmaster) is kind of ready, there's no documentation yet (which will go up on webpods.org soon).

The only way to see the feature-set is to look at some of the tests. https://github.com/webpods-org/podmaster/blob/master/src/tes...

If you're interested, please email me. I'm looking for collaborators.

I tried to use Solid, but having a protocol to store your data did not seem very useful without being able to swap the applications that use them at will. Each application needs to understand not only the Solid protocol, but the format you are using for your data too.

The specification naively says that the data is saved in interoperable formats. Sure, you can store your data in an interoperable data formats, suppose it is JSON, but it is of little use if the various applications do not know how to interpret and manage correctly the information contained therein.

It's been a while, have the applications improved?

> Each application needs to understand not only the Solid protocol, but the format you are using for your data too.

I don't think we'll be able to avoid that hurdle; we'll need to make sure that the protocol is really simple.

But having to know the data format of the app itself is to be expected. If an app "instagram-on-solid" stores data in a certain way, the alternate app will need to understand those schemas as well to be compatible. That's how interop has always worked, even in the pre-internet age when we were exchanging files on disk.

> It's been a while, have the applications improved?

I haven't looked at apps in a while - but that was indeed moving very slowly.

I realize you plan to do a Show HN but in case I don't see it, could you answer a few quick questions:

1. How is this meaningfully different to WebDAV?

2. Is the assumption that web apps export stuff to your pod from time to time, or actually use it as the primary storage? If the former, isn't it more or less the same idea as Google Takeout, if the latter how do apps handle the possibility of slow pods, outages or the need to use relational databases for storage? When building server side apps you do normally need tight control over storage.

> 1. How is this meaningfully different to WebDAV?

Webpods is more like git than WebDAV. It allows apps/users to store data in logs, and the data can be records (strings) or files. If bob is syncing from alice, he'd pull all entries from the commit-id until which he has previously synced.

An app will store data in a pod (which has a unique hostname) such as instagram.jeswin.someprovider.com. Each pod can have multiple logs, such as "friends", "albums", "comments" etc. Logs have permissions attached to them, which control who can read those logs. There are similarities to WebDAV here, but again it's more like how we use git.

> Is the assumption that web apps export stuff to your pod from time to time, or actually use it as the primary storage? If the former, isn't it more or less the same idea as Google Takeout, if the latter how do apps handle the possibility of slow pods, outages or the need to use relational databases for storage? When building server side apps you do normally need tight control over storage.

Apps are expected to be local-first, though they aren't forced to. You'd write to the local database, and simultaneously sync with the pod. Similarly, if you're pulling data from friends, those would (most likely) be stored locally as well.

Slow pods are a problem, but I hope people would generally prefer reliable pod service providers. In the same way Dropbox gives you some guarantees of reliability. If the app is designed to be local-first, the user is not immediately prevented from using the app while the network is down; and syncing can happen once connectivity is regained.

Relational databases and schemas are not supported on Pods, it's just an immutable log. Most apps should do event-sourcing (https://martinfowler.com/eaaDev/EventSourcing.html), wherein they write to an event log. But this stream (of events) could be processed into an more easily queryable view.

Of course, this won't work for all kinds of apps. It works well for apps handling personal data or for collaboration tools; such as slack, project management tools, instagram, google photos, music collections etc. On the other hand, it's not a good fit for apps in which the data needs to be centralized. Such as ecommerce, banking, insurance, delivery services etc.

I see, thanks. Sounds like it's a sort of Apple Time Machine but for the rest of us?

The problem is their goal isn't to do these things well by the usual metrics, it's to do them using a decentralised implementation. It's the implementation model that is the product, not rapid replication, not fast access, not long term access to data, not large scale storage.

The problem is that their architecture by it's nature takes all the quality related qualifiers out of those goals. Replication, but not rapid, access but not fast, access to data but not long term or actually resilient, storage but not large scale. So it's only advantage is if you value decentralisation above all other characteristics.

I agree with you but I think compared to Http or even bittorrent It’s extremely easy to attack IPFS.

Anyone can register a lot of fake “seeder” for a file chunk making it hard to download that chunk.

Same problem for the name server.

as in government, even if you have the mythical unicorn, the actual behavior of the users is what decides what is right and will push that forward.

Note that the Filecoin network (which was designed to be the incentive layer for IPFS storage) has been operational for some time. If you look at the current status at https://file.app/ , you can see that storage costs there are extremely low for large amounts of data. If you can get your data verified as open, public data by applying for datacap with a Filecoin+ notary, it's currently free. See https://plus.fil.org/ (you can get 32GB of free datacap to play with just for having a github account).

If you want to use the Filecoin network as a "provider of last resort" for IPFS data, there's https://estuary.tech which will mark your data as verified, sort out the deals with storage providers, and then mirror it to IPFS.

There's also third-party tools like https://fission.codes/ , https://docs.textile.io/powergate/ , https://web3.storage/ and https://www.pinata.cloud/ for making this easier.

(Disclosure: I work at the Filecoin Foundation.)

> If you look at the current status at https://file.app/ , you can see that storage costs there are extremely low for large amounts of data.

We were looking at this at work the other day.

We noticed the storage price vs S3 saying "0.03% the cost of Amazon S3" and then someone (who's been trying to get adequate performance out of IPFS for a while) said "0.03% of the price, and even lower performance".

Imagine if we said that about web sites at the begining. The Web needs to decide what it want to be? A plaftorm to sell stuff? Contact people? Write? Listen to music?

But the web wasn't about listening to music at the start! It started with organizing documents on a network, at CERN. And it took over existing document platforms by adding a simple point-and-click browser user interface to them, inspired by HyperCard (where do you think the "hyperlink" got its name?)

The modern, more economic web, wouldn't come until Netscape added form fields and cookies, at the behest of some of the original owners. And there were a ton of people at Netscape making these decisions about their vision of the future of the web. In-browser music listening wouldn't come until Macromedia, Disney and Microsoft pushed their vision for a "multi-media web"; browsers wouldn't build native support until much, much later.

So yes, we absolutely decided what the web would be about, and built technology to match that vision.

I don't see how the first two paragraphs support your conclusion here

The first two paragraphs reiterate that the early web was very much a reflection of the hypertext transfer protocol and hypertext markup language in that it literally just handled text pages with links in them. and it did it pretty well. It wasn't designed to handle streaming video or client-side processing/page rendering via Javascript or any of the innumerable other elements added on to it later. It was designed to do one thing well.

> inspired by HyperCard (where do you think the "hyperlink" got its name?)

I'm as much of a HyperCard fan as (almost) anyone else, but that is almost certainly not where the term "hyperlink" comes from. Ted Nelson used the word "link" back in the mid 1960s, in the context of another coinage of his, "hypertext". The historical record is already a little unclear about whether or not he was using hyperlink that early, but by the time HyperCard came to be, the term was already differentiated from a "simple link", with some level of implication caused by the "hyper" prefix that it was most likely on another computer/server. The most HyperCard could offer was a link into a different stack.

The "hyper" prefix predated Hypercard, and it's meaning in the context of information processing/retrieval/presentation meant more than the majority of links that HyperCard offered (even though they were also great). Yes, I know that the wikipedia page on the word "hyperlink" claims that HyperCard "may have been the first use", but the cited reference for that claim offers no evidence for it whatsoever.

I remember a whole fascinating section about various hypertext system in a mid-80s issue of Byte. I spent hours pouring over the screenshots in it.

EDIT: here's a good summary article of pre-WWW hypertext systems from the 80s https://fibery.io/blog/hypertext-tools-from-the-80s/

Mosaic supported form fields, before Netscape even started. Eg, https://www.w3.org/People/Raggett/book4/ch02.html .

As I recall, one of the example CGI programs from NCSA presented a form to fill out a Papa John's order, which was then sent via the email-to-fax gateway. Which, now that I think of it, was indeed more "economic".

Cookies was definitely a Netscape thing, for profit making - a shopping cart for MCI.

Exactly. To get the beginnings of real adoption, a technology has to do something better. A specific thing. Better enough that people switch.

The early web's competition was things like FTP, Gopher, and email-driven apps (e.g., Listservs, the Usenet Oracle). Plus paper-based stuff, like department phone books, mailing documents around, etc. It was hugely better than any of those for many common uses, so adoption was rapid.

Once you have a critical mass of users, then it can make sense to add other things in. But for that first audience, we can't be vague, selling some shining future that will happen eventually.

and much better, to justify switching costs.

Why is it that people trot out this argument in response to any criticism of any technology? You could apply exactly the same sort of reasoning to Microsoft Bob. Do you think that had the potential to be revolutionary?

I can't see the future. I can, however, look at the world and think about what I see.

I think that the question of what user-facing purpose(s) a technology can be put to is somehow qualitatively different than what backend roles it might play. I could be wrong.

> Imagine if we said that about web sites at the begining.

The web was fast (for documents on 56k) and extremely useful almost immediately. It was obvious to everyone watching that the technology was going to change everything.

I do not understand the downvotes here. "It was obvious to everyone watching that the technology was going to change everything": how to disagree?

I wasn't a down-voter, but I didn't have 56k in 1994.

14.4 baud iirc. You wouldn't call it fast.

I think something regulatory changed about 1995, such that there were instantly tons of ISP startups, and I think that 33.6k modems were available about then.

I had a 14.4K Zoom modem, but I'm pretty sure the ISP I worked for around '95-'96 was buying lots of US Robotics 33.6 modems.

I agree that 56k came a bit later, and didn't necessarily work on any particular phone line.

IMHO what changed in 1995, was MS adding TCP/IP to Windows 95. Prior to that you had fight with dial-up, Trumpet Winsock, PPP and PPTP to get on the internet at all. Most normal people still couldn't do it without help, but it moved into the realm of possible.

During 95 or 96, I was explaining to customers over the phone how to set up Trumpet Winsock and MacTCP/PPP. Most people didn't instantly get Windows 95, so it wasn't the reason that the ISP existed. And it was already possible to access the internet to some extent through an established online service, I think I'd used Delphi, AOL, maybe others during high school.

Something made it feasible right then for anybody to set up a bank of modems in their apartment, to provide direct internet, and there was an explosive growth in small ISPs before they consolidated. At the time, I was kind of oblivious to the historic moment, but the one I worked for was literally a few modems in the closet of a crummy apartment downtown when I started and within months we'd moved to an office a few blocks away and were installing modems like mad.

I found this, not necessarily authoritative:

"In 1994 the National Science Foundation commissioned four private companies to build four public Internet access points to replace the government-run Internet backbone: WorldCom in Washington, Pacific Bell in San Francisco, Sprint in New Jersey, and Ameritech in Chicago. Then other telecom giants entered the market with their own Internet services, which they often subcontracted to smaller companies. By 1995 there were more than 100 commercial ISPs in the USA."

I think that was probably it - right then and there anyone could buy a pipe to the internet and connect some modems. It was around then that I heard the term "T1" which was a lot back then.

Maybe there was some connection to:

https://en.wikipedia.org/wiki/High_Performance_Computing_Act...

What was Apple's market share of desktops at the time? And whether you were talking people through a Trumpet WinsSock install or I was doing it in person, it wasn't going to get done that way, just too slow. Sure lots of physical infrastructure (modems etc...) had to be added, no disagreement there. Anyway, it's all a long time ago now. A funny aside, thinking of Apple in those days reminded me of "Cyberdog" - https://en.wikipedia.org/wiki/Cyberdog. I wonder if anybody has done a side-by-side of Cyberdog vs Safari. Things change.

>What was Apple's market share of desktops at the time?

I don't know, but probably significantly better than a few years later, due to how vast an improvement 95 was.

There really, in my view, and in some of the magazine reviews I read back then, was nothing to recommend Windows 3.1(1) except if (a) you couldn't afford a Mac, or (b) you wanted to run software that wasn't available for one.

Suddenly, once 95 got traction, people promoting Macintoshes had to make excuses for the lack of memory protection or pre-emptive multitasking, on top of the high prices. And Windows just wasn't as godawful ugly any more.

But at the moment that ISPs were all sparking into existence, I don't think the wave had quite arrived. I mean, people were getting it and I do remember vaguely the initial version of IE, but 95 wasn't even the majority of PC users for a little while.

A browser for 3.1 that I kind of remember from those days, that lapsed into obscurity, was Cello:

https://en.wikipedia.org/wiki/Cello_(web_browser)

Yea, I'm afraid that's not so. In 1993, I was running a WildCat BBS and I was way more hyped about that and it's RIP graphics, lol. The only way I could get on the internet at all was through other peoples university accounts, which required dial-up, Trumpet Winsock, and PPP. It was a chore to get running and was very slow on the 14.4k (and slower) modems of the day. 56k modems weren't introduced until the late 90s. So yea, between 90 and 95 other technologies seemed more appealing like BBSs, Gopher and places like "The Well", at least to me.

In 1993, iirc, I borrowed a Mac and 2400bps modem from my high school that I used to call the library and AOL.

Before that, the way to get software (for me, because I wasn't a college student) was to go to a local computer store and copy their disks containing free or shareware.

https://en.wikipedia.org/wiki/Fred_Fish

But everything changed about 1995.

I think you misremember. I was definitely on the net and the web with a 14.4k modem. It was not that useful. The web was a pretty small part of the net iirc until the mid-90s. I preferred IRC channels and BBSes then since I was very young and didn't have the patience for most websites to load and I couldn't instantly join the "conversation" like I could with a BBS or an IRC channel.

There are two problems with this line of argument:

1. The web succeeded but many things whose backers made similar comparisons failed. Knowing that one technology had a big impact doesn’t say that a given unproven technology will be the next one to go big. It’s more likely that you’re looking at the next Groove Networks or something like that.

2. The web was immediately useful for many people and you could get started easily. IPFS has some interesting but far from unique properties and trying to be a network increases the amount of adoption and maturity needed for it to be worth using for most people. This is especially true for peer-to-peer sharing where the most useful participation requires up-front risk and costs which many people aren’t going to want to accept. Without that, it’s basically just harder to use web hosting which may or may not be cheaper.

It's been 6 years now and IPFS is still stuck with the same problems it had at the start with no real pathway to being useful. Most technology does something useful early on. I don't know the timeline for the web but I don't imagine it involved 6 years of marketing and selling to investors while not serving any purpose well.

HTTP was invented in 1989.

Netscape was founded in 1994.

So, if you’re comfortable with either of those a starting point, 6 years is somewhere in the dot com boom.

I'd argue the WWW was instantly useful, even during its halcyon days.

IPFS on the other hand is a horrible "jack of all trades" that has mediocre performance even in the best of times, and it hasn't really gotten any better since it first launched 6 years ago.

And that's not even bringing up the cryptocurrency cohort souring the project with its stench.

I don't object to the existence of IPFS, rather I prefer more efficient and focused projects instead. Someone in the comment threads mentioned Solid, which sounds like a decent decentralized information protocol or system of sorts.

And for those that want censorship resistance... who can forget Freenet? That project has been around since 2000 and seems to do a pretty bang up job, even if the performance is not much better.

Saying "imagine if we said that about a technology that doesn't suck" doesn't make a technology that clearly sucks, not suck.

The Web was a hit because it was really obviously useful for real work from the moment of its creation. IPFS is BitTorrent with magnet: links, and the seeding problems that implies, and the rest is janky nonsense.

- A complex system cannot be “made” to work. It either works or it doesn’t

- A simple system, designed from scratch, sometimes works.

- Some complex systems actually work.

- A complex system that works is invariably found to have evolved from a simple system that works.

- A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over, beginning with a working simple system.

Systemantics, John Gall, 1978

This only sounds ridiculous because you replaced the things the OP was talking about, with your own, to make it sound ridiculous.

"Is it about being a decentralized caching layer? Is it about permanently storing content? Is it about replacing my web server? Is it about replacing DNS? Is it about censorship resistance?"

websites at the beginning did not decide to be a caching layer - they decided to be websites. they did decide to permanently store content. they did decide to use web servers. they did not decide to replace dns. they did decide to be about censorship resistance.

now imagine you put up a website, put some time into it, and it may or may not be up at a random time in the future. not a product that's usable.

> There is no system to keep content alive so links will still die.

Torrent trackers solved this in a very interesting way. They created an economic system where bandwidth was the currency, incentivizing the permanent seeding of content. It was illegal to take more than you gave. I've even seen an academic paper studying their system!

Bandwidth as a currency eventually proved to be a failure. It enabled the rise of seedboxes, dedicated servers featuring terabytes of storage and connections to high capacity network links. Just like the IPFS centralized gateways you mentioned. They would eventually monopolize all seeding, removing any normal person's ability to gain currency. In some trackers, if you wanted to consume content, your only options were renting one of these seedboxes or uploading new content to the tracker. You always stood to gain at least as much bandwidth as the size of the content you uploaded. The seedboxes would monitor recent uploads and instantly download your new content from you so that they could undercut you. I suppose it was a form of market speculation.

They also failed to realize that there is no uploading without downloading. By penalizing leechers economically, they disincentivized downloading. This led to users being choosier: instead of downloading what they like, they'd download more popular stuff that's likely to provide higher bandwidth returns on their investment. Obscure content seeders would not see much business, so to speak, due to the low demand for the data. Users would stock up on popular and freeleech content so they could get any spare change they could. The more users did this, the less each individual user would get. Then seedboxes came and left them with nearly nothing.

This was eventually solved by incentivizing what was truly important: redundancy. Trackers created "bonus points" awarded to seeders of content every hour they spent seeding, regardless of how much data they actually uploaded to other users. These points can be traded for bandwidth. This incentivized users to keep data available at all times, increasing the number of redundant copies in the swarm. People will seed even the most obscure content for years and years. In some trackers, these rewards were inversely proportional to the amount of seeders: you made more when there were fewer seeders. This encouraged people to actively find these poorly seeded torrents and provide redundancy for them.

We can learn from this. People should be compensated somehow for providing data redundancy: keeping data stored on their disks, and allowing the software to copy it over the network to anyone who needs it. The data could even be encrypted, there's no reason people even need to know what it is. Perhaps a cryptocurrency could find decent application here. Isn't there a filecoin? Not sure how it works.

> Bandwidth as a currency eventually proved to be a failure.

I'm not sure why everyone assumes that bittorrent was about currency. It wasn't, and that was its superpower. No matter how much you were able to contribute, you were able to strengthen its system, redundancy and availability.

The only problem bittorrent had in practice was a legal one that finally led to a problem of availability of discovery.

All that filecoin hype will lead to only one thing, and one thing only: the people that are popular will decide what files are worth to the system, and the masses will simply dump everything else and forget about it.

Add an inflation for every modification of any file in the whole system, and you have a perfect way to destroy real incentives.

I don't believe in most web3 projects because they always think it's about trading files with each other. It is not. Discovery and access to data should not be limited by your financial capability to buy things. The internet exploded because people got access to vast amounts of knowledge, for basically free compared to before.

> I'm not sure why everyone assumes that bittorrent was about currency. It wasn't

Torrent trackers were and are to this day. The most successful trackers have proven to be those with a ratio economy. The late what.cd, often described as the library of alexandria of music, had the harshest ratio economy of them all.

> All that filecoin bullshit will lead to only one thing, and one thing only: the people that are popular will decide what files are worth to the system, and the masses will simply dump everything else and forget about it.

That's certainly a possibility. I don't know. I welcome discussion about this.

> Discovery and access to data should not be limited by your financial capability to buy things. The internet exploded because people got access to vast amounts of knowledge, for basically free compared to before.

Absolutely agree. Unfortunately, this is not possible with current copyright laws. This sort of utopia is currently only possible in underground networks such as private bittorrent swarms. It's been proven by history that some sort of incentive is necessary to get people to commit their personal resources -- storage and bandwidth -- to those networks. Ratio economies were created to address the leecher problem: users who simply downloaded what they want, without providing neither bandwidth or redundancy in return.

Oh, very good comment. I didn't realize that trackers now incentivize availability (haven't used BitTorrent in a while). Very cool.

Reminds me of maker incentives in markets. Providing liquidity is sometimes paid for.

Yeah, I have to agree. We have working examples of immutable copy/append only web apps. Email/mailing lists didn't need crypto to succeed. Neither did bit-torrent. Baking in a coin seems like a me-too sort of move.

I think you've hit the thing that many new techs have, they don't 100% cover old techs it's a bit of one and a bit of another, but not 100% of each.

and recently, a crypocurrency subsystem

what did they sold to investor? The idea that people will pay for hosting using filecoin?

Decentralized DNS, apparently:

https://handshake.org/

That is based on yet another shitcoin. IPFS is not.

Hence the "apparently"...

Filecoin

Reply on news.ycombinator.com