
Paper review: IPFS – Content addressed, versioned, P2P file system - mad44
https://muratbuffalo.blogspot.com/2018/02/paper-review-ipfs-content-addressed.html
======
mmjaa
IPFS should be enabled and treated as a first-class service by my distro. I
install said distro, it comes with a folder - and a basic service - upon which
I can replace Dropbox, Facebook, and Instagram - for my target peer group,
i.e. any of my friends and family who will also run the very same distro, for
this purpose.

Like, plug and play OS support, and its a go.

~~~
braderhart
I agree. I am working on an Arch distro (may roll my own for containers) that
includes secure decentralized storage and configuration by default, and a
federated marketplace for sharing your own local and server resources.

~~~
diggan
That sounds really interesting, do you have a link to a work in progress or
something like that?

~~~
braderhart
Haha... right now I have my desktop that I can show, which isn't perfect but I
have an idea of where I want to go and how to get there (mostly). I am still
running i3 for compatibility, but definitely moving towards Sway.

I've seen some great looking desktops that I still need to mimic, and the make
them more fluid/responsive for multiple devices. I would like to review and
look at what George Singer is up to:

[https://github.com/SimulaVR/Simula](https://github.com/SimulaVR/Simula)

Seems like he may be offering VR devices for developers that are able to
demonstrate some requirements. How cool is that? I would like to take
something like Sway, and add or combine it with a project similar to
SimularVR, with a Vulkan backend. That is the end goal.

I will likely just start with Sway and build a kick ass plugin and application
manager that uses containers. I will re-explore the current application
isolation solutions, such as AppImage vs FLatpak vs Snap, but likely try my
hand at building my own.

Part of that process is repeatable builds. I would like to build the OS
compilation into the decentralization process, and make distributed (and
localized) compilation a core component of the crypto solution, as it will
later be used for rendering all types of resources on top of something like
IPFS and Git.

Ideally, package maintainers will be solely focused on automated builds
directly from source repos, so that everything is compiled and versioned
automatically, so that you can switch software versions at anytime, with some
compatibility-script support for DB and data changes.

Anyway, that is a lot of talk, so I will have to share more when I make more
progress. It is a longer term goal, but feel free to help me get started:

[https://discord.gg/R6NQ7aj](https://discord.gg/R6NQ7aj)

For example, you can see a UI kit here that I would like to utilize initially,
although I am still inclined to try to implement my own idea here, which
involves combining a

------
hoschicz
I've been following the development of IPFS for the last few years and I'm
getting the impression that it's fizzling out. Maybe Protocol Labs are working
on Filecoin now (that's what's bringing them money), but they never really
finished the pubsub implementation and js-ipfs still can't run in the browser
because there is no IPFS network that communicates using WebSockets and not
TCP/UDP.

~~~
brodo
I find that unlikely. They got 250 MUSD quite recently and they need IPFS
working if they want filecoin to work.

~~~
pavlov
They already got 250M USD. Why do they need to get Filecoin to work?

The easiest and least stressful outcome is to drag it along forever while
paying themselves giant executive salaries from that stash. As long as there’s
some minimal progress, it’s not fraud.

~~~
zapita
I understand that it's fashionable to be cynical about ICOs. However the IPFS
people have clearly been working their asses off writing solid software and
giving it to us for free, for several years now. All along they've been
talking about their plan for filecoin.

With that track record, the burden is on you to explain why you think they
will suddenly throw all that away, and stop working on a project they're so
clearly passionate about, ruining their reputation in the process.

~~~
pavlov
With a track record of major ICO success, they could easily start a fund or
raise money for the next venture — regardless of what happens to Filecoin.

Convincing people to give up $250 million is the part that built their
reputation and ensures lucrative deals will be coming their way. Whether
they’re passionate about some storage-sharing token is neither here nor there.

~~~
woodandsteel
You're absolutely right. All human beings are selfish monsters and are
motivated by money more than anything good. And that of course includes you
yourself.

~~~
pavlov
What’s good about Filecoin? It’s not like it would benefit humanity somehow.
You make it sound like I’m criticizing Doctors Without Borders here, rather
than a clunky S3 alternative.

~~~
ghthor
Please take your cynicism somewhere else.

~~~
pavlov
Cynicism about overhyped technology projects isn't welcome on HN anymore? Now
that's quite a change.

------
woah
Brings up a lot of good points, but his question at the end “Does IPFS mean I
may be storing some illegal content originated by other users?” is so off-
base, it casts doubt on the whole rest of the post. I only have a passing
familiarity with IPFS, but I know that you only store files that you have
explicitly chosen to store, or “pinned”. How did the author miss this?

~~~
aw3c2
I thought content was shared even if not pinned until it is garbage collected?

~~~
cypherpunks01
Content that is _viewed_ is stored temporarily, yes, not random unvisited
content.

------
HugThem
The web already is decentralized. Most HTTP requests are fulfilled by a
computer that is part of a CDN, not by the publishers computer.

IPFS is like Wikipedia, Uber, AirBnB. There have been encyclopedias, taxis and
hotels before. But now it's easier to participate.

My computer has this article cached right now. So if my neighbor want to read
it, he could get it from me. The infrastructure is just not there yet. IPFS
will add it.

~~~
nodja
I disagree, the internet is very much centralized.

In your example, this very post on HN points to an https url. An url that for
now, means this article, but years from now might land in a 404 page, or a dns
not found. Sure I can use the internet archive or find your post here on HN
and ask you for it. But those are alternative services, they're not part of
http.

IPFS ensures that a url means one thing and one thing only, if changes, the
url changes. No censorship, no ninja edits, as long as someone in world is
willing to host that specific url, the ipfs protocol will serve it.

~~~
skybrian
Immutable data has its place, but you wouldn't want to use that for Hacker
News because reloading the page wouldn't show new comments.

Also, when someone edits a comment here, usually that's either harmless or
beneficial.

~~~
notheguyouthink
Fwiw, IPNS is mutable - you wouldn't use applications directly over IPFS,
you'd view them over IPNS.

So it has mutability in the sense that a single address can change content
over time. It's nice though, in that if it's important that content stays the
same, it always will.

~~~
cocktailpeanuts
IPNS is virtually unusable at this stage. It's super slow that most people who
use IPFS just use IPFS directly and try to come up with their own solution for
this.

I do hope they figure out how to solve this problem but looking at the
discussions around the issue, it doesn't sound like something that can be
easily solved, maybe never.

~~~
diggan
I left you a comment addressing the IPNS slowness here:
[https://news.ycombinator.com/item?id=16434057](https://news.ycombinator.com/item?id=16434057)

Short version: we know, it sucks and we have a couple of ways of making it
better, fear not

I also want to add that we have many other ways of doing mutable data over
IPFS, not just IPNS. While IPNS is a naming system, having services on
protocols with streams or using pubsub can also give you the ability to do
mutable state in your application.

------
thinkcontext
I thought software distribution would be a no brainer. There are plenty of
projects that still have lists of mirror sites, using IPFS would be much
better from a bandwidth and security perspective.

~~~
hoschicz
There already is Bittorrent.

The distros are getting distributed over Bittorrent and since more people have
it and know how to use it than IPFS, there is no point in distributing it over
IPFS.

~~~
detaro
IPFS has some benefits if I understand it correctly, e.g. I think it can share
duplicate data between multiple trees, while Bittorrent can't share blocks
between multiple torrents. Still understandable that distros with working
infrastructure won't jump on every new thing.

~~~
zaarn
I doubt there is much efficiency gain when most distro's compress the packages
and ISO's anyway, the few bits you could spare would most likely fall towards
the installer ISOs, which are always mostly the same. But since nobody cares
about the old ones, there isn't much win other than getting a tiny bit more
bandwidth from people who don't offer the newest version yet.

There would also have to be a very high uptime guarantee, which means either
every user of the distro operates a IPFS node by default, which nobody wants
because IPFS is extremely chatty and there is such a thing as "servers in
private subnets with limited internet access" that people don't want to send
out arbitrary data to the internet. The next option would be opt-in, which
means nobody will do it because everyone is lazy. Last option; simply maintain
status quo.

------
ldiracdelta
All IPFS needs is less install friction. The local IPFS server packaged as a
chrome extension is what is keeping it back:

[https://github.com/ipfs-shipyard/ipfs-
companion/issues/248](https://github.com/ipfs-shipyard/ipfs-
companion/issues/248)

~~~
hoschicz
TLDR: What's keeping it back is Web standards. Extensions cannot initiate TCP
connections and there is no IPFS network made of (possibly hybrid -- both
protocols) nodes that are able to use WebSockets instead of TCP.

The js-ipfs daemon can only fully run on Node.js where it has access to real
UDP/TCP sockets. (I don't see this as a clear proclamation in their readme, so
don't take this for granted)

~~~
diggan
> The js-ipfs daemon can only fully run on Node.js

Not sure what "fully" refers to here, but js-ipfs in the browser can fetch/add
content like a normal IPFS node via either websockets or webrtc. Although, TCP
connections would make a lot of things, a lot more efficient and nicer.

------
ttul
I think the author is overly critical of the limitations of a distributed file
system. With a decent incentive system (FileCoin for instance) there is no
reason that distributed file storage won’t scale really well.

I for one have a stack of SSDs waiting for FileCoin to arrive. I am keen to
leverage the 10Gbps fiber in my office to start ghetto hosting for some $$.

------
woodandsteel
>IPFS may be a way of sticking it to the man. But the invisible hand of the
free market forces also help here; when one big corporation starts playing
foul and upsets the users, new companies and startups quickly move in to
disrupt the space and fill in the void.

No, once someone like Facebook gets a monopoly, it becomes impossible for a
startup to get anywhere. It is hard for me to believe the author doesn't know
this.

He also doesn't address the problem of web companies going out of business,
like Geocities, so you lose all your data forever. Likewise the if-you're-not-
the-customer-you-are-the-product problem that is behind so many ills today. As
far as defeating governmental censorship goes, IPFS is being combined with
Tor.

In general, he seems to be looking at things from the perspective of someone
who works for a company based on the present centralization model, rather than
the perspective of those who are suffering under it and could solve a lot of
problems with IPFS.

------
amelius
I don't understand his argument surrounding scalability. Isn't IPFS naturally
scalable?

~~~
burkemw3
I understand part of the scalability concern being about the physical network
capabilities ("Today's networking ecosystem evolved for the client-server
model, what kind of problems could this create for switching to peer-to-peer
model...") as opposed to the scalability of the IPFS protocol and node
implementations.

------
book_mentioned
Why does IPFS get all the HN attention?

In my ignorance I'm not really aware of the landscape for these types of
technologies; does anyone have time to share a brief summary or link to
further info?

~~~
woodandsteel
The short answer is that a great many techy's are working on decentralization
because the present centralized model has a lot of serious problems, like
Facebook et al making their money selling ads that may have malware, and also
selling your data to who-knows-who.

There are many projects to decentralize the web. IPFS gets so much attention
because it is such a broad platform that other technologies (like Ethereum)
can operate on top of, and because in some important ways it is farther along
than anybody else.

------
diggan
First off, I'm a developer working on IPFS for Protocol Labs. Let me try to
answer some inaccuraties and questions from this blogpost, to clear any
confusion.

> There is even the Beaker browser to help you surf IPFS

Beaker does not currently support IPFS, even though it used to in the
beginning. We're hopeful Beaker might support IPFS once again in the future,
but for now, Beaker just supports Dat.

> How common are petabyte or even gigabyte files on the Internet? There is
> definitely an increase in size trend due to the popularity of the multimedia
> files. But when will this become a pressing issue? It is not a pressing
> issue right now because CDNs help a lot for reducing traffic for the
> Internet. Also bandwidth is relatively easy to add compared to latency
> improvements

Bypassing the fact that centralized vs decentralized are fundamentally
different models with different reliability, argueing that CDNs help with
reducing traffic is just wrong. CDNs just moves the traffic from "your server
-> your client" to "your server -> someones CDN -> your client", it doesn't
actually reduce traffic. However, using a decentralized protocol like IPFS
would actually reduce traffic, as closests nodes can help serve content and
maybe clients would not need to contact your own IPFS node at all, if the data
already exists in a closer node (at your ISP or even neighbor)

> For scalability, shard it, georeplicate it, and provide CDNs for reading.
> For fault-tolerance, slap Paxos on it, or use chain replication systems
> (where Paxos guards the chain configuration), or use the globe-spanning
> distributed datastores available today.

IPFS is actually a globe-spanning distributed datastore, so IPFS would be
excellent choice if you're building a CDN. IPFS gives you the benefits you
want for a CDN, scalable, content-addressed and used to passing around a lot
of data.

> Case in point, Dropbox is logically-centralized but is very highly available
> and fault-tolerant, while serving to millions of users. Facebook is able to
> serve billions of users.

For now. In the future, who knows? The argument for using IPFS is that we
don't know if a central server will be around in the future, but to make sure,
let's add content-addressing to data so we can serve this data from anywhere.
Then it doesn't matter if Dropbox is around in the future, I can just pull
down the data from anywhere and verify it's correct locally.

> If you want to make the natural disaster tolerance argument to motivate the
> use of IPFS, good luck trying to use IPFS over landlines when power and ISPs
> are down, and good luck trying to form a multihop wireless ad hoc network
> over laptops using IPFS. Our only hope in a big natural disaster is cell
> towers and satellite communication.

Here the author is comparing a physical network with a software stack. Of
course IPFS is not a antenna, so it'll be hard to use it as such. But, IPFS
works excellent over radio and ad-hoc networks, because it's content-
addressed. The current web? Not so well, as we have bunch of assumptions that
the endpoints we're using are all serving us "good" content and that you have
a server-client model. Ad-hoc networks are bandwidth-constrained, and
everything we can do to reduce that bandwidth is worth doing. IPFS helps a lot
with that since everything is content-addressed.

> Does IPFS mean I may be storing some illegal content originated by other
> users?

No, IPFS only shares what you already accessed (until GC) or when you
explicitly "pin" something (basically tell IPFS you want to help share this
content with others)

> How does IPFS deal with the volatility? Just closing laptops at night may
> cause unavailability under an unfortunate sequence of events. What is the
> appropriate number of replicas for a data to avoid this fate? Would we have
> to over-replicate to be conservative and provide availability?

This questions lead me to the belief that the author hasn't really understood
IPFS before writing this post. Yes, shutting down your server will make
content stored on that server unavailable. IPFS does not automatically
distributed data. Just as your local HTTP server does not automatically
distribute data to other servers.

> But can the Byzantine nodes somehow collude to cause data loss in the
> system, making the originator think the data is replicated, but then
> deleting this data? What other things can go wrong?

Again, other nodes can't control your data. If you add data to your IPFS node,
it's there until you remove it. No other nodes can control your data. Also,
data is fetched based on hashes and when the content is downloaded, it's
verified again to make sure it's correct. No way of screwing around with that.

Happy to answer any more questions people have about IPFS.

~~~
cocktailpeanuts
> Beaker does not currently support IPFS, even though it used to in the
> beginning. We're hopeful Beaker might support IPFS once again in the future,
> but for now, Beaker just supports Dat.

Since you're a developer at protocol labs, I will assume you remember why
beaker dropped IPFS in favor of DAT. I think IPFS is cool but the biggest
hurdle for adoption is the naming scheme. More specifically what happens when
a file content changes. You have IPNS to handle this but as far as I know it's
virtually unusable because it's extremely slow. And I got the impression that
you guys have no real solution for this, and maybe IPNS is not even one of
your top priorities because you're focused on other important things.

But as a user this matters a lot because without a name resolution system,
we're left with static files only, and while this may be a good alternative to
S3, this means that's about it and people can't build apps on top of it. I
wonder what your plans are and if you have any solution to building an actual
functional IPNS, or if you're focused on building an S3 alternative at the
moment.

~~~
diggan
Indeed, I do remember why Beaker dropped IPFS support. Basically, it comes
down to the URL structure and how we structure them in the IPFS ecosystem,
which is not super easy to integrate with browsers today. There is some logs
about the discussion over at Github:
[https://github.com/beakerbrowser/beaker/issues/2](https://github.com/beakerbrowser/beaker/issues/2)

There is a open feature request for (re)adding IPFS support to Beaker as well,
if someone feels a bit experimental with adding IPFS support to a Electron
application:
[https://github.com/beakerbrowser/beaker/issues/480](https://github.com/beakerbrowser/beaker/issues/480)
Reach out to me if you feel interested in helping out and I can point you in
the right direction. Email is in my profile.

Re: IPNS is currently slow: Yes, it is. Apologies for that, it definitely has
to get faster to be really useful. The network has grown a lot and we are
working on improving the performance of IPNS, both for adding the records and
reading them. Currently the adding of records is slower than reading, as
reading now uses pubsub to push updates and making it a lot faster than
before.

We do have more solutions in mind for IPNS performance and still doing
research on the best way of implementing them.

If you haven't seen IPFS pubsub before, I urge you to take a look, as it gives
you the ability of doing communication with a large number of nodes cheaply.

So while IPFS started out as a distributed file system with naming on top, we
now have more functionality for handling dynamic data and working on making it
even easier to build applications with just IPFS.

------
Klasiaster
Paired with an anonymity layer and TOR hidden services for direct
communication it is really solving a lot of the problems present todays Web,
where DPIs can mess with the unencrypted HTTP contents, DNS responses faked,
web servers and CAs hacked and centeralized services decide on content
availability.

------
hiccuphippo
Is there any project like Wikipedia or Linux package repositories making use
of IPFS already? Where can I find out who and how to help?

~~~
hex12648430
There's a repo dedicated to the coordination of archival efforts.

[https://github.com/ipfs/archives](https://github.com/ipfs/archives)

IPFS is also used for the experimental gx package manager, which IPFS uses.

[https://github.com/whyrusleeping/gx](https://github.com/whyrusleeping/gx)

------
toomuchtodo
Globally distributing the Internet Archive.

------
brownbat
Those are great questions.

Especially provocative point about how mobile devices would most likely be
leeches in a p2p world. The world wants easy to use mobiles. A system like
this may need to constrain leeches. There will be some tension serving both
goals.

------
jadedhacker
It's a wonderful concept to decentralize the internet. However, I am a little
skeptical of this concept. Won't IPFS be subject to the same problem as the
global blockchain for BitCoin? That is, it can't process the kind of
transaction throughput the global economy requires. Wouldn't that technical
limitation be present for IPFS?

~~~
diggan
No, IPFS is not subject to the same problem as IPFS doesn't use or is a
blockchain. There is no transactions.

There is data, and data is referred via their content hash. People can request
that data via the content hash and then it's downloaded. There is no mining or
similar things in IPFS itself.

------
jacksmith21006
What is not?

------
bra-ket
Filecoin

------
stefpr
Indexation of content on IPFS thru Atmos (cryptocurrency). Watch this one....
might really be the "killer app" you are all looking for. link : Novusphere.io

