[HN Gopher] HTTP is obsolete - it's time for the distributed, pe...
___________________________________________________________________
HTTP is obsolete - it's time for the distributed, permanent web
(2015)
Author : Hakeemmidan
Score : 303 points
Date : 2021-10-17 15:57 UTC (7 hours ago)
(HTM) web link (ipfs.io)
(TXT) w3m dump (ipfs.io)
| hikerclimber1 wrote:
| Everything is subjective. Especially laws.
| unnouinceput wrote:
| So, they reinvented torrents? Or old timers, do you remember the
| peer-to-peer connection from 90's called DC++
| (https://en.wikipedia.org/wiki/DC%2B%2B)?
|
| Like this IPFS, you'd connect to a hub (IPFS calls this a node)
| and get what people were sharing. This IPFS only takes that step
| a little further with hashing and distributing. Also, if this
| gets implemented widely, hash collision is going to be wild
| abecedarius wrote:
| BitTorrent was invented to cut down the scope of an earlier
| IPFS-ish system https://en.wikipedia.org/wiki/Mnet_(peer-to-
| peer_network)#Ev...
|
| It's reasonable to try again at the bigger goals now that
| there's more infrastructure / theoretical progress / audience.
| Gigachad wrote:
| I see this kind of claim posted a lot, but what does IPFS
| actually do that torrents do not? What is a new use case
| which has been enabled?
| worldmerge wrote:
| This is very cool! Also should be noted this is from 2015, would
| love to hear a follow up to this.
| yewenjie wrote:
| What is one cool use-case/ semi-killer app for IPFS go get
| started with?
| [deleted]
| adfrhgeaq5hy wrote:
| 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"
| agumonkey wrote:
| and recently, a crypocurrency subsystem
| BiteCode_dev wrote:
| 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?
| echelon wrote:
| > 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.
| muxator wrote:
| I do not understand the downvotes here. "It was obvious to
| everyone watching that the technology was going to change
| everything": how to disagree?
| Gigachad wrote:
| 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.
| davidgerard wrote:
| 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.
| PaulDavisThe1st wrote:
| 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.
| Jasper_ wrote:
| 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.
| PaulDavisThe1st wrote:
| > 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.
| eesmith wrote:
| 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.
| corndoge wrote:
| I don't see how the first two paragraphs support your
| conclusion here
| bshipp wrote:
| 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.
| adfrhgeaq5hy wrote:
| 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.
| acdha wrote:
| 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.
| sebastos wrote:
| 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?
| thomashop wrote:
| 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 have no real use for IPNS at the moment and many of the
| other features of the core IPFS stack.
| [deleted]
| rackjack wrote:
| Decentralized DNS, apparently:
|
| https://handshake.org/
| pmlnr wrote:
| That is based on yet another shitcoin. IPFS is not.
| [deleted]
| rackjack wrote:
| Hence the "apparently"...
| short12 wrote:
| Filecoin
| jayd16 wrote:
| 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.
| d--b wrote:
| > it efficiently (20 hops for a network of 10,000,000) finds the
| nodes that have the data using a Distributed Hash Table
|
| See this is the part I always doubted. I haven't done the math,
| but does it really scale up to the size of the internet?
| jayd16 wrote:
| Does IPFS have an append only primitive? Something like the
| signed owner can add to an existing document? Is that built in or
| something you'd have to handle in the application layer?
| Flocular wrote:
| It sounds like freenet to me. How will this allow for governments
| to censor CSAM?
| 0xtr wrote:
| I really like IPFS but their standard desktop client sucks big
| time. I've had a lot of performance problems where it freezes
| whenever I click a tab or even doesn't go to the tab I click on.
| It makes the whole experience a lot worse than it needs to.
| doliveira wrote:
| On a side note, do you all know about some research or PoC in the
| direction of a globally distributed knowledge graph or something
| of sorts? Or at least a more technical name I could google.
|
| I think it's so bad that so much of the Internet information is
| siloed in walled gardens and that pages have to be dynamically
| generated and routed across the globe every single time...
| Imagine how it's gonna be when we get to Mars, for instance.
| Storing this knowledge graph in IPFS files seems like a logical
| step to me (as an absolute layman, though)
| breck wrote:
| The Internet in a Box project is an interesting angle:
|
| https://internet-in-a-box.org/
| noman-land wrote:
| There's a project at MIT that seems to be precisely this.
| Underlay.
|
| https://underlay.mit.edu/
| Ericson2314 wrote:
| I like to explain it by comparing Amazon warehouses to the post
| office.
|
| Post office send black-box data point to to point. Amazon gets
| you thinggy matching SKU from arbitrary location.
| Jasper_ wrote:
| Some might argue they fail to do the "thingy matching SKU"
| effectively these days.
| adrianmonk wrote:
| I guess it would be hard to do chess-by-mail via Amazon
| warehouses/shipping. And I can't order a bank statement from
| Amazon.
| Ericson2314 wrote:
| Of course. One does not replace the other.
|
| It's most like I think we should nationalize the Amazon
| warehouse system and put under the post office.
|
| Perhaps both are valid interpretations of the US
| constitution's postal clause, "To establish Post Offices and
| post Roads" even!
| yholio wrote:
| And therein lies the problem with content addressable networks:
| they make no sense in the economic world of the internet, where
| data transport and storage is not free, they make sense in a
| world owned by a single corporation.
| Ericson2314 wrote:
| Huh? The same efficiency gains should apply to both
| applications of content based routing.
|
| I do think there is a natural monopoly, but that is just and
| argument for nationalizing things. (And agreements like there
| being _one_ IP protocol or whatever.)
| TeeMassive wrote:
| Ok cool, I love decentralized content distribution frameworks
| too. But what do I have to install to use it? As with most of
| these attempts to decentralization, it fails because of the
| mostly absent effort spent on ease of use.
| grumbel wrote:
| Command line client can be found over at:
|
| * https://docs.ipfs.io/install/command-line/#official-
| distribu...
|
| Single pre-compiled binary, no dependencies. Starting it is
| just a matter of: ipfs daemon
|
| WebUI will show up at:
|
| * http://127.0.0.1:5001/webui
|
| Another useful command on Linux: ipfs mount
|
| This make IPFS available as fuse filesystem in the directory
| /ipfs/, so you can directly access IPFS content without
| manually downloading it.
| TeeMassive wrote:
| You are missing the point.
|
| Less than 5% of people are what most people would describe as
| coders and from my experience, I would say less than a third
| of those are not afraid of using a terminal. Why do you think
| people still pay for IDEs and fancy git clients with a UI?
| And of that, only a tiny fraction would have heard of
| decentralized social media / websites.
|
| If these kind of projects want any global attention then they
| should be as easy to install as most applications on Android
| or Apple. Bitcoin began becoming popular when easy to use
| wallet applications and currency exchange began being
| mainstream. Same for BitTorrent, Signal and IRC.
| CharlesW wrote:
| The author claims that IPFS enables a "permanent web" and
| eliminates 404-like experiences. How does IPFS guarantee that all
| published content will be available forever? (In my beginner-
| level knowledge of IPFS, this is the first I've heard that claim.
| It seems absurd.)
| jFriedensreich wrote:
| its more that ipfs enables a permanent web, not that this
| technology immediately has this property as a feature. it
| requires players like internet archive, libraries, website
| hosters and individuals to pin content and develop interesting
| pinning strategies. for example browsers could pin everything
| that is bookmarked and everything that is in browser cache.
| 6510 wrote:
| You can link to documents and keep them online as oppose to
| publications with unobtainable references.
| diegocg wrote:
| Basically with ipfs you try to download some content by
| referring to it by a hash. This means that the content will be
| available forever - as long as there is someone willing to
| cache that content. Which is, obviously, something that won't
| always happen. But it _can_ theoretically happen, so people
| with a cache of some old web page may revive it, even after the
| original site is gone.
| kzrdude wrote:
| How do you refer to something "by name"? Let's say the
| current version of Wikipedia's article on Lagrange multiplier
| - the data is changing, so can't use a hash of the content.
| sodality2 wrote:
| The hash is not a literal hash of the content- I think it's
| like a key that lets anyone looking for it ensure it's
| legitimate. Then the IPFS p2p search mechanism is what lets
| you find it.
| drdeca wrote:
| In what sense is it not a literal hash? Because it had
| the prefix at the start to specify what hash to use and
| the length?
| grumbel wrote:
| With IPFS you access content by hash. So if you have a
| plain IPFS link to "Lagrange multiplier", it will always
| point to exactly the same version you are looking at right
| now. No way to change or update that.
|
| If you want to update content, you have to point the user
| to a new hash. IPFS has the IPNS mechanism for that, this
| adds a layer of indirection, so instead of pointing to the
| IPFS hash directly, you point to the IPNS name which in
| turn points to the current hash. What an IPNS name is
| pointing to can be updated by the owner of that IPNS name.
|
| Another option is to do in via plain old DNS and have the
| DNS record point to the current hash of the website.
| davidgerard wrote:
| It absolutely guarantees nothing of the sort.
|
| A big problem in the NFT space of late is that OpenSea sells
| NFTs that link to an IPFS URL, then doesn't bother seeding the
| image after it's sold - so a pile of NFT images no longer exist
| anywhere on the IPFS.
|
| https://www.vice.com/en/article/pkdj79/peoples-expensive-nft...
| cma wrote:
| The claims are too strong, but it is strictly more available
| than today: if the original host stays it is guaranteed to
| stay, same as today. If they disappear, it may stay, which is
| stronger than today (ignoring internet archive).
| Semiapies wrote:
| It's the fundamental lie of IPFS. IPFS people will jump in and
| say that it's not a lie, what they're actually saying is _yadda
| yadda_ , but then they turn around and say exactly that five
| minutes later. It's the motte-and-bailey (
| https://en.wikipedia.org/wiki/Motte-and-bailey_fallacy ) of
| IPFS.
|
| In a world of finite storage, nobody's going to keep up a copy
| of everything. Nobody will have a copy of _most_ things. Even
| if IPFS worked acceptably, even if it worked as very narrowly
| promised, plenty of stuff would fall off the web. At best, we
| 'd see somewhat fewer temporary disruptions of very currently
| popular content.
| delaaxe wrote:
| I don't know about IPFS but Arweave solved the "permanent" part
| by asking nodes to periodically prove that they're actually
| storing what they're supposed to be storing:
| https://www.arweave.org/
| Jasper_ wrote:
| What happens when the servers then fail to provide that
| promise? Isn't the data lost?
| pfraze wrote:
| The IPFS version of Arweave is Filecoin
| grumbel wrote:
| IPFS doesn't give you any guarantees about if the content is
| actually stored anywhere, it however gives you reasonable
| guarantees that the addresses for that content stay the same.
| Meaning if somebody finds an old backup tape decades down the
| road, they can just stuff it back onto IPFS and all the dead
| links start functioning again. That's something that is
| impossible with HTTP, as there isn't even a guarantee that the
| same URL will return the same content when you access it twice.
| With IPFS anybody can mirror the content and keep it alive as
| long as they want, they don't have to hope that the server that
| hosts it right now keeps running.
|
| That said, IPFS isn't quite perfect here, as IPFS hashes do not
| actually point to the content itself, they point to a package
| that contains the content and depending on how that package was
| build, the hash will change.
| fabianhjr wrote:
| One of the spinouts of IPFS is Multiformats, particularly
| multihashes. It is a standard to describe hashes and provide
| interop: https://multiformats.io/multihash/ (Or the IPNS
| dnslink:
| http://multiformats.io.ipns.localhost:8080/multihash/ )
| zozbot234 wrote:
| Seems like this pointlessly duplicates the "Naming things
| with hashes" ni: and nih: URI schemes, standardised as
| https://tools.ietf.org/html/rfc6920 . (IPFS actually uses a
| proprietary "package" representation as parent points out,
| so there's little harm in it not using ni: URI's. But
| standard hashes of the underlying resource should use
| those. "Magnet" links are similarly problematic, but these
| at least support a few convenience features.)
| warkdarrior wrote:
| > Seems like this pointlessly duplicates the "Naming
| things with hashes" ni: and nih: URI schemes
|
| Wow, they have an URI scheme for Not Invented Here.
| Amazing!
| somenewaccount1 wrote:
| And quite annoyingly, it's the opposite of how IPFS works. IPFS
| nodes only cache the content as long as it's actively
| requested. Depending on the cache policy of the node, this can
| be as short as 24 hours. Yes, it could still exist on your
| private node that your running from your laptop, but this is
| the equivalent of saying that all published content is
| available forever _because it 's on your hard drive_.
|
| Honestly, I like IPFS as a tech, and blockchain isn't useless,
| but the entire community just makes me want to puke because
| it's full of so many extremely ignorant people (at best), but
| mostly just fraudulent liars (at worse and most common).
| pfraze wrote:
| To be fair, this is all hard work to get right. I think
| there's a third, much larger category of people who are
| pursuing the idea but just haven't solved all the problems
| yet.
| chriswarbo wrote:
| > Yes, it could still exist on your private node that your
| running from your laptop, but this is the equivalent of
| saying that all published content is available forever
| because it's on your hard drive.
|
| No, the difference is that IPFS will use _the same address_
| to fetch content from anyone who 's seeding it.
|
| If Hacker News shuts down, it will no longer be accessible at
| 'news.ycombinator.com'; all existing links to that address
| will die, or worse will start showing some unrelated content
| (probably domain-squatter spam). That cannot be prevented by
| making a copy on my hard drive (or even the Wayback Machine).
|
| On the other hand, an IPFS version will continue to exist at
| the same address for as long as anyone is seeding it. All
| links will remain working; anyone can join in the hosting if
| they like; even if it eventually stops getting seeded, it may
| still re-appear if someone re-inserts it, e.g. if they insert
| the contents an old hard drive they found in an attic (as
| long as the same hash algorithm is used, then the address
| will stay the same).
| jayd16 wrote:
| Doesn't a forum need things like user login? Is there an
| example of such a thing as a forum existing fully on IPFS?
| leesalminen wrote:
| I wonder if it could make running a service like archive.org
| easier. Or if it could allow for a distributed archive.org
| service where nerds worldwide can contribute x GB storage to
| the cause?
| Sargos wrote:
| This is one of the biggest stated use cases of IPFS as it
| effectively replaces archive.org with a better version that
| is more distributed, has better uptime, and more importantly
| has a much larger and nearly complete and pristine version of
| the entire internet for conceivably as long as the internet
| itself exists.
| acdha wrote:
| It does only the first of those things: using content
| hashes means that anyone can populate an archive which is
| easily discovered.
|
| For the rest, hosting takes money. People will not archive
| the entire internet for free and IPFS is not a magic wand
| which eliminates the need to have people like the skilled
| IA team. It could make their jobs easier but that's far
| from "nearly complete" and no more or less pristine.
| SavantIdiot wrote:
| Simple: you set up a few centralized servers with backups...
| jimpick wrote:
| People hating on IPFS DHT performance probably aren't using the
| experimental accelerated DHT client. https://github.com/ipfs/go-
| ipfs/blob/master/docs/experimenta...
| enz wrote:
| > "With HTTP, you search for locations. With IPFS, you search for
| content."
|
| Well, that's the difference between an URL and an URI, right?
| HTTP seems URL-oriented while IPFS seems URI-oriented.
| nivertech wrote:
| URL - Uniform Resource Locator URN - Uniform Resource
| Name URI - Uniform Resource Identifier
|
| URI is too generic, "I" in URI means "Identifier", which can be
| either a semantic/natural or a technical/surrogate key. And in
| many case it's the same Locator is in URL.
|
| IPFS is a CAS (Content Addressable Storage), so an "Identifier"
| there is a semantic key (i.e. hash of the content).
| capableweb wrote:
| Not quite. A URI is any identifier, a URL is a identifier to a
| location while a URN is identifier only containing a name. IPFS
| hashes are URIs/URNs while both URLs and URNs are URIs.
| enz wrote:
| Oh, I see. Thanks for the clarification!
| jrochkind1 wrote:
| Additionally, what the "for content" statement is trying to
| get across is that there is necessarily only one IPFS address
| possible for a given unique piece of binary content. Which is
| a quality not universal among URNs either.
| dools wrote:
| " As a result of liquifying information and making it the
| publication of it more egalitarian and accessible, HTTP has made
| almost everything about our culture better."
|
| That didn't age well ...
| NewEntryHN wrote:
| HTTP is an application protocol and most of this article doesn't
| make any sense.
| jeroenhd wrote:
| I like IPFS, I really do, but whenever I try to use it, it's
| either too slow to become usable or sometimes it plain doesn't
| work. I pinned a whole bunch of files on IPFS a while back to
| experiment with it and the system seems to work, but every time I
| try to fetch those resources from a location that hasn't cached
| the content yet, it takes several seconds to show me the
| HTML/JSON/PNG files.
|
| HTTP may be inefficient for document storage, but IPFS is
| inefficient for almost everything else.
|
| I like the concepts behind IPFS but it's simply not practical to
| use the system in its current form. I hope my issues will get
| resolved at some point but I can't shake the thought that it'll
| die a silent death like so many attempts to replace the internet
| before it.
| zozbot234 wrote:
| Sounds like it's working fine for you. "Several seconds" of lag
| is nothing for an "Inter-Planetary File System", in fact it's
| on par with other decentralised P2P networks.
| guntars wrote:
| Try browsing the IPFS example "website". I opens for me under a
| few hundred milliseconds. ipfs cat
| /ipfs/QmQPeNsJPyVWPFDVHb77w8G42Fvo15z4bG2X8D2GhfbSXc/readme
| wsjtho55 wrote:
| Wireguard and the usual tools for file search and retrieval
| works fine.
|
| Do we need all that comes with IPFS? Not just technically, but
| the user training and pivot of technical doers?
|
| So many of these projects feel like programmer vanity projects,
| there's really little difference between them and a guy on the
| corner telling me why Protestants are wrong, join his flock.
|
| That it's a technical project not entirely ephemeral nonsense
| doesn't matter; solutions exist already we just don't implement
| that way.
| [deleted]
| leesalminen wrote:
| I agree that the http caching layers are currently needed to
| achieve decent UX. But it's also possible that won't be
| necessary forever. The network could expand and get to the
| point where resolution time comes down to accessible levels.
| Only time will tell I suppose.
| carlhjerpe wrote:
| When downloading content using a magnet link downloads are
| usually quite slow started, while torrent files usually start
| directly. It's not a fair comparison since the torrents are
| from a private tracker with high quality peers, but it's
| noticeable that the DHT stuff is slower. Not sure how cjdns
| solves that.
|
| Will the network be faster the more people join it?
|
| Is centralized infra inevitable for fast things because of
| all assumptions and insight a centralized provider can use?
| BTC is also slow, I don't know of any cryptocurrency that can
| provide VISA transaction volumes, even if they use more power
| than some countries alone.
| Gigachad wrote:
| On what basis do you think this is likely? What part of IPFS
| gets faster when more users are online? If the file exists on
| a system in the network, it should make a connection and
| start fetching the file within milliseconds ideally. It's not
| like we are distributing multi gb files where more seeders
| means more speed, this is all just slowness in setting up a
| connection.
|
| Even torrents take 1-10 seconds to initiate downloads with an
| absolutely massive network.
| spicybright wrote:
| Wonder if it's practical to "buffer" popular content on IPFS by
| copying it to normal HTTP servers.
|
| Requesting an IPFS document would query a few popular
| repositories, then revert back to normal IPFS if it's not
| found.
|
| These buffer servers would also track what's popular and
| shuffle around what they store accordingly.
| CharlesW wrote:
| The irony is that this and other IPFS problems will (must?)
| be fixed by recentralization. Cloudflare is doing this with
| IPFS Gateway, and Google will surely embrace/extend/usurp
| IPFS if it becomes popular. The user experience of bare IPFS
| is just not good enough.
| alisonkisk wrote:
| Doesn't matter. the point of ipfs is that when cloudflare
| and google shut down their gateway, the ipfs content is
| still available at the same address.
| vmception wrote:
| I agree with a [previously] dead/deleted commented at this
| level:
|
| _" Doesn't matter. the point of ipfs is that when
| cloudflare and google shut down their gateway, the ipfs
| content is still available at the same address."_
| acdha wrote:
| ... if someone else paid to host a copy. Major companies
| hosting it makes that less likely and if their backing
| increases usage that also increases the cost of hosting
| everything, making it more likely that the content you
| want will be available. When Google shuts down their
| mirror, suddenly all of that traffic is hitting nodes
| with far fewer resources.
|
| The underlying problem is that storage and bandwidth cost
| money and people have been conditioned not to think about
| paying for what they consume so things end up either
| being ad supported or overwhelming volunteers.
| jacoblambda wrote:
| This really is one of the cruxes of decentralisation
| being built in at the protocol level. Even if centralised
| services exist, as long as one person exists who cares,
| the content lives on.
|
| Without decentralisation being supported at the protocol
| level, as soon as the host dies, it's gone. This is
| particularly problematic because centralised services
| slowly subsume small services/sites and this either cuts
| off the flow to the other small sites or eventually
| something changes on the big centralised site and a bunch
| of these little sites break.
| amelius wrote:
| > Wonder if it's practical to "buffer" popular content on
| IPFS by copying it to normal HTTP servers.
|
| I guess the approach would be to simply run IPFS on those
| servers, with the popular content in it, as a seed.
| jeroenhd wrote:
| I think this is exactly what Cloudflare's and ipfs.io's web
| proxies do. They won't cache your stuff forever, but they'll
| cache it as long as someone requests the content again before
| the content gets removed from cache.
|
| The downside of this approach is that it only works with
| popular nodes and you'd be back to the old, centralised
| internet architecture for all real use cases.
|
| I don't think you can accurately gauge what is and isn't
| popular in a P2P network like IPFS. You never have a view of
| the entire network, after all.
|
| There's also the problem of running such a system. Who pays
| for the system's upkeep and do we trust them? If we'd use
| Cloudflare's excellent features, who says Cloudflare won't
| intentionally uncache a post criticising their centralisation
| of the internet, forcing the views they disagree with to the
| slow net while the views they agree with get served blazingly
| fast.
|
| I don't think such a system would work well if we intend to
| keep the decentralised nature of IPFS alive. Explicit caching
| leads to centralization, that's the exact reason caching
| works.
|
| Instead, the entire network needs a performance boost. I
| don't know where the performance challenges in IPFS lie, but
| I'm sure there's ways to improve the system. Getting more
| people to run and use IPFS would obviously work, but then
| you'd still only be caching only popular content.
|
| Edit: actually, I don't really want to see caching happen
| through popularity of the service either, because as it
| stands IPFS essentially shares your entire browsing history
| with the world by either requesting documents in plain text
| or even caching the documents you've just read. I wonder if
| that IPFS-through-Tor section on their website ever got
| filled in, because the last few times I've checked that was
| just a placeholder in their documentation.
| zinodaur wrote:
| How much were you paying for your IPFS pin? E.g., if you
| are getting something via HTTP, there's a server somewhere
| with that content just waiting for you to request it,
| typically stored on an SSD, etc. V.s. IPFS pins which are
| typically packed on to massive disks shared with lots of
| other people
|
| IDK a whole lot about IPFS though. Maybe it was the
| metadata resolving / DHT lookup or whatever that was super
| slow. BitTorrent latency was always pretty high, but it
| didn't matter because throughput was also high
| jeroenhd wrote:
| My IPFS pin was just one or two of my servers running an
| IPFS daemon. Since that daemon was running on Oracle's
| free VPS's, the answer is probably "a small fraction of
| what it costs for Oracle to have you in their database".
|
| Paying for pinning sounds like something that could work
| but it would introduce some of the same problems that the
| real web suffers from back into IPFS. The idea "a web for
| the people, by the people" becomes problematic when you
| start paying people to make your content more accessible.
| zinodaur wrote:
| if it was slow running on a dedicated vps, not super
| encouraging.
|
| The thing I liked about the idea of IPFS pinning is that
| you are paying per byte stored, v.s. per byte accessed,
| as long as the p2p sharing works. I.e. hosting-via-
| pinning a website only you read would cost the same as
| hosting a website that the whole internet reads.
| jeroenhd wrote:
| To be fair to the software itself, the system was never
| pegged for CPU usage or anything, and it wasn't a fast
| VPS to begin with.
|
| From what I could tell the performance issue was mostly
| located in the networking itself, getting the client to
| resolve the content on the right server. That's something
| that could be improved through all kinds of algorithms
| without breaking compatibility or functionality, so
| there's hope.
|
| I agree that pinning comes with some interesting ways to
| monetize hosting without the need for targeted
| advertising that the web seems to have these days. Small
| projects like blogs, webcomics and animations could be
| entirely hosted and supported by the communities around a
| work, while right now giant data brokers need to step in
| and host everything for "free".
| Jasper_ wrote:
| > They won't cache your stuff forever, but they'll cache it
| as long as someone requests the content again before the
| content gets removed from cache.
|
| "It stays in the cache as long as it stays in the cache"
|
| ??? What on earth does this mean?
| jeroenhd wrote:
| Content is cached for a certain amount of time (default
| is 24 hours, I think?) before it gets deleted. If the
| content is requested again, the timer is reset.
|
| This is opposed to long-term caches like Cloudflare's
| that'll cache the contents of your website regardless of
| how many requests come in. Cloudflare will happily just
| refresh the contents of your website even if nobody has
| been to your website for weeks, and quickly serve it up
| when it's needed.
| acdha wrote:
| That's not how Cloudflare normally works: the HTTP cache
| is demand based and does not guarantee caching. What
| you're describing sounds like their Always Online feature
| which regularly spiders sites to serve in the event of an
| error.
| TuringTest wrote:
| I read it as saying that if someone downloads it before
| the cache timer deletes it, it resets the timer. So if
| the file is downloaded regularly, it is never removed
| from the cache.
| stavros wrote:
| This echoes my experience as well, and I (used to) run a
| pinning service.
| noman-land wrote:
| I love IPFS. It's one of my favorite recent technologies, but I
| think people have unrealistic expectations about such a young
| idea.
|
| Decentralized tech doesn't work well until the network effects
| build up.
|
| IPFS has the interesting quality that the more popular a piece
| of content is, the easier it is to get ahold of. If millions of
| people were using IPFS, the most popular content would be being
| served by many thousands of people, and finding it and
| downloading it would be extremely fast. Then subsequent
| viewings would be instantaneous because you can cache it for
| life.
|
| This leaves interesting incentives for monetizing pinning and
| caching for less popular content.
|
| It makes sense if you ask me. If I love a piece of music so
| much that I'm willing to give it to others for free then
| everyone benefits from being able to access it easier.
|
| Content that people care about organically becomes more
| resilient and nearly impossible to remove.
|
| Content that no one cares about is slow and inefficient because
| it has to be hauled out of cold storage the one time a year
| anyone cares.
|
| If someone thinks that content is more important than people
| are giving it credit for they can host it or pay for someone
| else to do it.
|
| If you have a website and you have "fans" that subscribe to you
| and help pin all your stuff, then your stuff becomes faster and
| easier to get. Your "fans" can even get paid for helping to
| serve your content.
|
| So, to me, it's early days for IPFS, and the way to make it
| better is to try to build apps that increase its usage, so the
| power of the network effects is felt.
| adfrhgeaq5hy wrote:
| It isn't that early. They have a stupendous amount of money
| and have been around since 2014. By now they should have
| something to show for their work.
| saurik wrote:
| > If millions of people were using IPFS...
|
| ...then IPFS would just get even slower and use even more
| resources to manage the index and find content as I am pretty
| sure the DHT they are using doesn't scale the way you seem to
| think it does.
| nephanth wrote:
| Why ? iirc the time I studied them, DHTs scale pretty well
| (like log(size of the network) complexity for everything).
| acdha wrote:
| > think people have unrealistic expectations about such a
| young idea.
|
| This interesting given your description:
|
| > IPFS has the interesting quality that the more popular a
| piece of content is, the easier it is to get ahold of. If
| millions of people were using IPFS, the most popular content
| would be being served by many thousands of people, and
| finding it and downloading it would be extremely fast.
|
| This idea hasn't been new since the turn of the century
| (BitTorrent offered exactly that in 2001) and nothing in that
| description explains why this is different than the many
| previous attempts. It'd be interesting to hear about how IPFS
| plans to maintain that without the problems with abuse and
| how it keeps competitive performance relative to non-P2P in a
| world where things like CDNs are much cheaper and easily
| available than they were around the turn of the century.
| Using P2P means giving up a lot of control for the content
| provider and that's a challenge both from the perspective of
| the types of content offered and the ability to update or
| otherwise support it on your schedule.
| noman-land wrote:
| IPFS is basically BitTorrent if all the torrents could
| share with each other. IPFS is as if each "torrent" is a
| single chunk of data instead of a siloed collection of
| stuff.
|
| IPFS expands BitTorrent into a global filesystem.
|
| You can mount IPFS on your filesystem and address files by
| pointing at local resources on your machine. So you could
| have an HTML file say `<img src="/ipfs/QmCoolPic" />`. You
| can't do that with BitTorrent.
| amelius wrote:
| > IPFS has the interesting quality that the more popular a
| piece of content is, the easier it is to get ahold of.
|
| So niche content is difficult to get a hold of?
|
| Sounds like a bad idea.
| haggy102 wrote:
| Yeah sounds like our existing situation where content is
| largely moderated by centralized governing bodies. Big -1
| wly_cdgr wrote:
| > IPFS has the interesting quality that the more popular a
| piece of content is, the easier it is to get ahold of.
|
| That sounds like the worst of the current internet, but even
| worse
| z3c0 wrote:
| Or, you know, BitTorrent, which works perfectly fine.
| vangelis wrote:
| There's a reason private trackers have to incentivize
| keeping the long tail alive.
| noman-land wrote:
| Look at any public tracker and you'll find torrents that
| are very old, swarming strong.
| azinman2 wrote:
| Along with those that have 0 seeders.
| kortilla wrote:
| IPFS solved that by making sure even popular stuff is
| difficult to get.
| retrac wrote:
| Survivor bias, there.
| kortilla wrote:
| It's not a young idea though. The basic technology for p2p
| networks has been around for decades. DHTs, voting, vouching,
| etc were all got academia topics like 10-20 years ago. It's
| just engineering skills at this point.
|
| I remember popcorntime was as responsive as Netflix at the
| time it came out and it scared the shit out of the MPAA so
| they killed it with prejudice.
|
| IPFS doesn't have an excuse for sucking beyond a basic lack
| of engineering effort.
| supperburg wrote:
| Just create an easy way to host stuff. Support a cultural shift
| toward dithered images and a universal text format. Make hiring a
| host cheap and easy and make hosting locally easy. Small sizes
| makes backing up easier and cheaper. Create a service where
| people can store a shard of the backup of the new internet and in
| return have their content added to the collective backup. I
| really think it's about a cultural shift more than anything.
| Because without a collective realization that bandwidth and file
| sizes need to be reigned in, the content on the internet will
| just live at the perpetually ascending ceiling of what the
| internet can handle. And in that situation there will never be a
| way to make the internet a robust, equitable and interesting
| place.
| warkdarrior wrote:
| > file sizes need to be reigned in
|
| Tell that to all of the content creators, corporate or not.
| f7ebc20c97 wrote:
| What's difference between IPFS and Oxen??
| syngrog66 wrote:
| I love the idea of IPFS but the last 2 times I tried using it, it
| simply didnt work. There was no "there" there. The simplest use
| cases like "I want file X from the ether, make it happen" like
| you could do with torrents -- nothing ever happened.
|
| I read the docs and tutorials but no luck. Felt like docs were
| missing some special incantation or setup step, or precondition.
| Or the CLI wasnt giving me feedback on some blocking error, and
| it was failing silently. Dunno. Gave up. Hope to revisit some
| day. Because in theory it would be useful tech to have in my
| toolbox.
| goodmachine wrote:
| Peergos is an interesting human-friendly project built on top of
| IPFS. Works great so far.
|
| Of interest: they provide a trustless way to store your data
| encrypted data on centralised boxes (S3, Backblaze) if you want.
|
| https://peergos.org/
| dleslie wrote:
| > All the static content stored with the site still loads, and my
| modern browser still renders the page (HTML, unlike HTTP, has
| excellent lasting power). But any links offsite or to dynamically
| served content are dead. For every weird example like this, there
| are countless examples of incredibly useful content that have
| also long since vanished.
|
| Perhaps I missed it, but I don't see where they claim that IPFS
| can provide a solution for dynamic content; which makes up a huge
| portion of what is served over HTTP.
| alvarlagerlof wrote:
| It won't, but much of the web could work well on JAMStack, and
| there's no reason that couldn't be supported.
| oefrha wrote:
| JAMStack != static site served entirely by a CDN. There's an
| A for API in there. Where's the A for IPFS? There's no such
| thing.
| encryptluks2 wrote:
| It can be built, but I don't think there are any frameworks
| that make it easy. A JSON file can be an API, but
| authentication and encryption using static publicly
| available files is more challenging, especially for a large
| number of users. That is where blockchain solutions come
| into place.
| dleslie wrote:
| JAMStack isn't much of an option for services that can't
| trust the clients and cannot rely on high latency consensus
| algorithms.
|
| It's also brutal for battery life.
| mwfunk wrote:
| You don't search for locations with HTTP, any more than a
| shipping company searches for addresses to deliver to. The
| problem with bad metaphors is it derails discussion, which I am
| arguably doing with this comment.
| simonebrunozzi wrote:
| The analogy is just plain wrong.
|
| search for content = it presumes that there's a google-like
| indexing of content, and then a DNS-like way to retrieve it.
|
| It seems to me that IPFS, in this analogy, is simply a different
| way to address a web page / document.
|
| note: I am very familiar with IPFS. I just think that this
| analogy is really poor.
| [deleted]
| [deleted]
| alfl wrote:
| In "The Innovator's Dilemma" Christiansen presents data from the
| storage market supporting the argument that disruptive
| innovations happen when inventions outcompete incumbent products
| on value criteria that appeal to engineers and enthusiasts but
| that don't have immediate commercial applications.
|
| I think that's what happening in the storage market, again, with
| IPFS.
| democracy wrote:
| Oh it's one of the "cryptocurrency" solution looking for a
| problem to solve? Thanks, no, thanks! :)
| anaphor wrote:
| Named-data networking is literally what this is describing,
| except NDN works as a replacement for TCP, not HTTP. In the long
| term I'd rather have it work at a lower level and not have to
| think about it much. https://www.youtube.com/watch?v=gqGEMQveoqg
| [deleted]
| yoursunny wrote:
| NDN can work as a replacement for IP too, running directly over
| Ethernet or other link layer technology.
| xccx wrote:
| NDN is the way
|
| p2p no huge IP infrastructure between nodes
|
| interest packets at narrow waist (like human attention, scarce)
|
| sign all packets, more secure, easier to trust|not
|
| hash for pointers, no surprises in containers
|
| crypto apply more cryptography, less web3 baloney
|
| broadcast radio native, no emulation of copper wire
|
| data, closer to where you want, find faster, keep
|
| content you want w/out intermediation, need to find "where"
| within IP/udp/tcp addresses
|
| https://youtu.be/P-GN-pYfRoo?t=1825 node to node
|
| https://youtu.be/yLGzGK4c-ws?t=4817 more application, less
| security hassle
|
| http://youtu.be/uvnP-_R-RYA?t=3018 hash name the data
|
| https://youtu.be/gqGEMQveoqg&t=3006 data integrity w/out need
| to trust foreign server
| Ericson2314 wrote:
| Well IPFS, or else something like it, need to establish the
| network/utility, and then we can increasingly optimize it with
| dedicated stuff at lower layers. I don't think going straight
| to the hard parts is going to work without _much_ more
| government policy to push through the investment -- seems
| strictly harder than going the 0-cost overlay-network only
| approach, because clearly we are demand-constrained not
| efficiency-constrained.
|
| I was tipped off to
| https://twitter.com/_John_Handel/status/1443925299394134016
| which I honestly think might be the approach to think about how
| networks in a broader sense than regular telecommunications are
| bootstrapped.
| dreyfan wrote:
| I'll just point to the millions of torrent files today that will
| remain unseeded forever. Durability with P2P only works as a
| complement to centralization.
| ugjka wrote:
| I think streaming is killing torrents and the fact that you
| need a VPN in many countries to avoid getting fined
| ativzzz wrote:
| I agree with this, I haven't torrented anything in a very
| long time as most of things I want are streamable somewhere
| (and I don't care about file ownership), or set up for direct
| download on some forum somewhere.
| topynate wrote:
| I like IPFS for making Libgen faster (with a little help from
| Cloudflare). If it also manages to solve hard problems of
| decentralization and content-addressable storage, that's just a
| bonus.
| jmull wrote:
| I wonder how people are incentivized to host content well?
|
| Whether HTTP or IPFS, you want content:
|
| (1) hosted/stored redundantly enough for availability but not
| over-hosted/stored because that raises costs.
|
| (2) hosted "near" to requesters to make efficient use of the
| network, which limits costs and increases speed. (Near in terms
| of the network infrastructure.)
|
| With HTTP I understand how this works (the content publisher
| figures out a hosting solution balancing what they are
| willing/able to pay and what kind of availability and speed they
| want/need).
|
| Not sure with IPFS though. If people are choosing what to host,
| wouldn't the hosting be uneven, with some content under-hosted
| (or not hosted at all) and some popular content greatly over-
| hosted? ...leading to an inefficient system? Under--hosted
| content would be slow to retrieve or simply unavailable. Over-
| hosted content is wasting resources, making the system more
| costly than it needs to be (somebody is paying for the storage
| and servers to make that storage available).
|
| I realize this a alpha/experimental, but without a strong answer
| to this, I don't see how the system can work at scale.
| dang wrote:
| Discussed at the time:
|
| _Neocities is implementing IPFS - distributed, permanent web_ -
| https://news.ycombinator.com/item?id=10187555 - Sept 2015 (235
| comments)
| [deleted]
| badrabbit wrote:
| How do you manage access control with IPFS? Just because someone
| knows a hash does not mean they are allowed to access the
| content.
|
| EDIT: It seems [1] they want you to encrypt content and do access
| control outside of ipfs. Imagine ext4 telling you to do acl's on
| your own. To me, it is a little more than bittorrent without acls
| and at-rest confidentiality built-in.
|
| [1] https://github.com/ipfs/notes/issues/376
| mayli wrote:
| ironically, few links on this 2015 post are dead, and most of
| them being ipfs releated.
|
| https://ipfs.io/ipns/QmTodvhq9CUS9hH8rirt4YmihxJKZ5tYez8PtDm...
| https://ipfs.io/ipns/ipfs.git.sexy/
| v_london wrote:
| Pretty interesting. A lot of people here are focusing on
| permanence, but for me the main difference on addressing by
| content vs by host name is the loss of authorship it opens up for
| the web. Since a research paper of essay is referred to by its
| hash, the owner effectively gives away all control of the work
| when it's first published. There will be no editing, no taking
| down unwanted work, and no real way to build an interactive
| website that allows dynamic linking to other materials by the
| author.
|
| It's interesting how the same people promoting the "creator
| economy" also tend to promote the cryptocurrency space and IPFS
| without an ounce of self-awareness. IPFS sounds awful for
| creators of all kinds in the same way as BitTorrent was awful for
| artists. I can definitely see a use case for IPFS as a file
| storage for trustless systems such as smart contracts, which are
| designed as immutable, trustless systems.
| Gigachad wrote:
| IPFS claims to solve this with their name service IPNS which
| can update to point to a new hash with a revised file. Where
| the original hash can be cached and used but users can refer to
| the NS version and get the latest version. But last I saw, the
| name on IPNS had to be frequently pushed by the original server
| or it would go away.
| jayd16 wrote:
| Seems like at that point it might be easier to just build a
| new http+ protocol that supports document signing and focuses
| on bringing caching back.
|
| You could use all the current web/http/DNS infrastructure,
| and add certified/cacheable GET results.
|
| Anyone could run their own proxy and cache what they see fit.
| Seems like an easier transition as it could be fully
| compatible with the current web.
| davidgerard wrote:
| IPNS doesn't work. Whenever you press them on this point,
| they'll admit it doesn't work.
|
| But IPFS has the crypto problem of conflating the stuff that
| works now with the stuff that's hypothetical in its
| marketing, and not admitting that the latter is janky
| nonsense that doesn't bloody work.
| Gigachad wrote:
| Yeah this is what I saw 4 years ago. Shame it still isn't
| working. Insane how crypto projects spend all this effort
| on flashy landing pages, marketing, hype. But if you
| actually try to use the product, you find out it just
| doesn't actually work.
| dpweb wrote:
| I like the concept of immutable content, but HTTP eliminated top
| down control of information?
|
| Well, we're all dependent on the Internet which can be shut down
| at any time by any government, and normally almost completely
| dependent on FAANG companies.
|
| I applaud the freedom activist spirit but the only exciting
| technologies in this regard must be P2P and not Internet carried.
| Zababa wrote:
| So IPFS is basically some kind of automatic behind-the-scene
| torrenting? I see how that solves the "dead server" problem, but
| how does that solves the "content longevity" problem?
| riobard wrote:
| That was supposed to be solved by FileCoin, i.e. financial
| incentives to keep content alive.
| xur17 wrote:
| Yeah, I've been pretty disappointed by what they actually
| shipped. The concept (decentralized, financially incentivized
| storage) is really neat, and there would be a demand for it,
| but every time I've tried to use it, it's been incredibly
| difficult. Ran into similar problems with Sia.
|
| Example: I'd love to use one of these projects as an
| additional backup layer for my NAS, but the technical
| complexity necessary to set it all up makes it.. feel very
| fragile. Definitely not set and forget.
|
| My hope is that in 10 years something cool comes out of one
| of these projects, but we're definitely not there yet.
| xwdv wrote:
| Incentives must be created for storing content. Imagine if each
| request was really more like a bounty where the requester would
| pay the host when the file is delivered.
| j_mo wrote:
| I think "you host mine, I'll host yours" works better here
| than a financial incentive.
|
| If you can specify "I've got 1gb spare to replicate other
| people's assets, as long as each of them replicates mine in
| return" then your incentive to replicate other people's sites
| is more redundancy and bandwidth for your own.
|
| If you also prioritise files that have the least replicas
| across the entire network, and allow servers to re-distribute
| the content they are replicating, it would surely become
| quite hard for a file to be lost forever.
|
| This makes more sense to me than having each site pay for
| their own data to be replicated, because those who don't pay
| don't get their content replicated, which results in missing
| content when the server eventually disappears. That is just
| as bad as HTTP.
| sergiotapia wrote:
| This is what I'm saying. If there's a financial incentive to
| store popular content, or a higher incentive to host "at-
| risk" content this would work out, no?
|
| I have no idea how hard this would be to implement. I'm new
| to ipfs and crypto.
| [deleted]
| sergiotapia wrote:
| Is there a way to install something on my local machine and host
| IPFS content to help "the swarm". If they combine this with some
| kind of crypto monetary incentive it would go a long way for
| people to help "the swarm".
|
| Odysee is looking into adding crypto to your balance when you
| serve content that helps viewers.
| Willamin wrote:
| Maybe FileCoin is what you're looking for? https://filecoin.io
| neilalexander wrote:
| Note that the system requirements are way out of the league
| of the average home user (32GB RAM, 8 cores, several TB disk
| space). Plus, if the chain is growing at 38GB/day (as the
| Filecoin website suggests), that's a traffic average of
| 3.8Mbit/s 24 hours a day.
| leesalminen wrote:
| You could always download the IPFS Desktop client and "pin"
| content that you find valuable to provide to the community,
| (say, a partial copy of Wikipedia in your language [0]. No
| crypto-based incentives associated with that though, at
| least yet.
|
| [0] https://github.com/ipfs/distributed-wikipedia-
| mirror#cohost-...
| acdha wrote:
| Wikipedia changes every second. That seems like a very
| expensive combination for a CAS system -- even with good
| deduplification you're storing a lot of metadata tracking
| every revision.
| sergiotapia wrote:
| Is this legitimate or just a shitcoin scheme? The website
| looks very sketchy.
| anchpop wrote:
| I think filecoin is legit but it's not working super well
| in its current state
| leesalminen wrote:
| I've been following Filecoin for a while and although I'm
| not invested in it, some of their YouTube videos do have
| technical substance to them, and they seem to have some
| brand-name investors like the Winklevoss' org.
| noen wrote:
| No. I tried. For weeks. Filecoin is the mechanism for this. And
| they do everything humanly possible to both technically keep
| the ecosystem open, while at the same time making it
| practically impossible for any non-data center vendor to take
| part.
|
| The min hardware specs are absurdly large. Most of the services
| required are not prepackaged alum any way, the exercise is left
| to the implementer for almost everything.
|
| If you don't have 100k+ to drop in hardware, there's no
| community help for you.
|
| It's a shame because ipfs is well structured from the other
| end, but it's not really decentralized in any way other than
| naming.
| Gigachad wrote:
| Yeah I looked in to filecoin as well and it's not nearly as
| simple as setting up a raspberry pi with a 1tb HDD attached.
| You have to have a latest gen array of GPUs sitting there
| constantly cryptographically proving the entire content of
| the HDD every minute.
|
| As with all crypto tech, its insanely inefficient and you may
| as well use google drive or s3.
| carapace wrote:
| (2015)
| ptaq wrote:
| Economy of scale is hard to combat with a technically
| decentralized protocol.
|
| Let's assume all goes well and in 2-5-20 years IPFS is the web. A
| random Joe has an IPFS server in his basement, because it's
| profitable or at least convenient for him. Most of the traffic
| never reaches AWS or CouldFlare. What do they do about it? They
| pretend to be random Joes and mirror the same setup.
|
| Obviously Amazon will manage their servers more efficiently than
| an army of Joes, so the nothing really changes: we end up with a
| decentralized protocol where 90% of traffic just happens to end
| up on AWS servers anyway.
___________________________________________________________________
(page generated 2021-10-17 23:00 UTC)