
IPFS Pics - andars
https://github.com/ipfspics/server
======
lenish
My concern with the IPFS claims of permanence, like "Where you can know for
sure your pictures will be available forever" is that, AFAICT, files are only
uploaded to the network once another party requests them.

An example:

    
    
      $ipfs init
      $echo 'agdkjagka' > test
      $ipfs add test
      added QmTtmsSSTH5fMQ9fn9NRXWtcZXnBBazxR8fidXcE5KB76h test
      $rm -R ~/.ipfs
      $ipfs init
      $ipfs cat QmTtmsSSTH5fMQ9fn9NRXWtcZXnBBazxR8fidXcE5KB76h
      Error: merkledag: not found
    
    

In English, `ipfs add` does not upload anything to the network. The only way a
hash becomes distributed on the network is for another party to request that
hash. Even then, I believe that the data only exists on that party's system.
That is, if both you and the requester leave the network, the data is gone.

~~~
diggan
IPFS is just piece of the puzzle. Filecoin, Bitcoin like technology (but about
files instead) is meant to combat this issue. Similar to how you pay Dropbox
or AWS to host your files, you'll have IPFS hosts that you'll pay to rehost
your content. Or, you'll have your own public daemon that you can "pin" your
own content. In the end, people are not willing to give out disk space for
free, therefore Filecoin will exist.

[http://filecoin.io/](http://filecoin.io/) < built by the same guys behind
IPFS and meant to be used together

~~~
astrobe_
> In the end, people are not willing to give out disk space for free,
> therefore Filecoin will exist.

Disk space is one parameter of the equation though. Bandwidth and uptime
should be considered too in order to estimate the effective amount of
resources a node adds to the network.

~~~
mstade
Given enough peers over time, neither bandwidth or uptime should be an issue.
If an incentive based system like Filecoin were to take off, and there's a
market to exchange that currency, then it may actually be a viable business
just to set up farms that host content. Kind of like a hosting service, but
with indirect customers.

------
mrmondo
Great idea and use case for IPFS. I'm not sure I want to run php just to host
images though. I always have this 'oh... It's in PHP...' moment with things
like this and I generally end up not wanting to play with or host them, either
because I don't find php attractive as a language or because of the various
security issues around hosting php applications.

~~~
Gigablah
It's worse than that, his PHP scripts make cURL calls to a local nodejs server
which then exec() the ipfs commmands.

~~~
toomuchtodo
Ipfs exposes a JSON API locally. Not sure why the author didn't just use a
JavaScript front end making calls to the local API.

[https://ipfs.io/docs/api/](https://ipfs.io/docs/api/)

EDIT: I'd encourage the HN community to look past the technical merits of the
code, and focus on the idea presented (and even perhaps fork and contribute
back an improved version).

~~~
eis
Hm what prevents some malicious website from pinning unwanted content on a
visitors machine?

~~~
Natanael_L
The visitor needs to chose to run IPFS and cache it

~~~
eis
He just needs to happen to have IPFS running. Any website can make a request
to localhost via Javascript or even without.

Scenario:

Attacker sends you harmless looking link to a page that contains some
invisible JS that sends a request to localhost and pins kiddypon on your IPFS
node. Attacker then sends the police to you.

~~~
mappum
The IPFS API isn't exposed like that, there is actually a whitelist for hashes
that can access the API (the IPFS webui is in the whitelist by default), and
hashes that are blocked will get a 403.

------
abricot
So, we would blindly host other people's pictures. Does noone see the danger
in that?

~~~
derefr
Also see: Freenet, Perfect Dark, etc.

The difference here is that the content you're opting in to rehosting is
sitting in cleartext on your machine. So it's not blind, per se; you can
delete (un-rehost) whatever you don't want to be there, or run a nudity
detection algorithm (yes, those exist) to automatically prevent re-hosting of
any porn, etc.

~~~
AndrewGaspar
Similar to this, you could suscribe to a good-faith censor that removes known
illegal images from your ipfs enlistment (using known hashes, for example).
Obviously wouldn't catch everything, but I suspect would remove any legal
obligation on your part (IANAL).

------
hitchhiker999
This may be somewhat immature as far as its development but IMHO it's the
beginning of the future. My guess is that we'll now be seeing almost complete
server/client decentralization of many of the most popular apps (social /
search / sharing). 5+ years from now.

~~~
steckerbrett
I bet strongly against that. "Decentralized" systems do not scale, and are
impossible to keep clear of spam.

~~~
chriscool
So Git for example doesn't scale and is impossible to keep clear of spam?

~~~
nickodell
Git's not that decentralized, though. You've got centralization at a technical
level (everybody contacts the same server to push code) and at an
organizational level (if you want to add code you need to be the repository
owner or someone authorized by them).

That brings up an important point, though: you can make your system partially
decentralized, and gain many of the benefits of a totally centralized system
with a fraction of the complexity.

~~~
eis
Git does not need any centralized server. Git is fully distributed. It is a
DVCS, D standing for Distributed.

That some/many organizations tend to centralize parts of Git, doesn't mean
that Git itself is inherently centralized.

~~~
nickodell
HTTP's not inherently centralized either. What's your point?

------
pervycreeper
>where you can know for sure your pictures will be available forever.

This is certainly untrue, but it would be interesting to know what reasonable
conditions would need to be true for an IPFS file to become unavailable.

------
PlzSnow
It seems to be a huge problem that random people can store crazy pictures on
your computer.

Maybe it would have been better if the images were stored encrypted in some
manner, and decrypted on the client.

However I applaud the initiative and newness of this!

~~~
hohenheim
This is not true. You only store pictures you have requested.

------
unclesaamm
I realize this may not be constructive, but it definitely qualifies as
"glorious": I clicked "Random" and this was what I got:
[http://ipfs.pics/QmPJddhYZb2kXtn2vzeGTAagPcPyfCb7fuoPxQ3mqpE...](http://ipfs.pics/QmPJddhYZb2kXtn2vzeGTAagPcPyfCb7fuoPxQ3mqpEL4G)

Excellent project.

~~~
xp3ll3d
While we are sharing, this is what random threw up for me
[http://ipfs.pics/Qmcim5DzJSW7xpmonxALaEw9oVbhYM9RjqUhAjSws4F...](http://ipfs.pics/Qmcim5DzJSW7xpmonxALaEw9oVbhYM9RjqUhAjSws4FEeF)

------
lewisl9029
Does IPFS have a client-side JS library for building apps that interact with
the IPFS DHT? Something similar to [https://github.com/feross/bittorrent-
dht](https://github.com/feross/bittorrent-dht).

I've been looking into developing distributed client-side apps for IPFS, and
it would be great if we could just tap into the native IPFS DHT rather than
having to depend on a separate IP-based DHT for peer discovery in our apps.

~~~
diggan
A fully client side implementation of IPFS is in the works. Right now, you'll
have to run the daemon on your server and interact with it, so not fully
distributed until either the client-side implementation of IPFS is done (node-
ipfs on Github/NPM) or the public gateway can accept calls from the JS api
client that works in the browser too (node-ipfs-api on Github/NPM).

------
Breefield
[edit] derp I am dumb, was not familiar with
[https://ipfs.io/](https://ipfs.io/) this explains my questions

~~~
steckerbrett
It's just POSTing the image to a web server running from something else.

I don't understand why they are doing dumb things like passing everything to a
shell when PHP has curl support of its own, and imagemagick.

~~~
Gigablah
Not to mention that index.php contains only HTML.

------
scrrr
Can a user delete a picture he or she has uploaded?

~~~
mtgx
I imagine no, just like you can't delete a picture after someone else has
downloaded on their PC.

------
reitanqild
It seems to be licensed under AGPL which means it is unusable for a whole lot
of stuff.

~~~
Kototama
It seems to be licensed under AGPL which means it is usable for a whole lot of
stuff.

~~~
mnx
But for less stuff then if it was licensed under MIT.

~~~
Kototama
Yes but the argument is unidirectional. AGPL answers different needs than more
permissive licenses.

Also it would be good to recognize the work done before shooting out
"wrooooong license (for me)", specially when it still is licensed under a free
software license.

~~~
reitanqild
> Yes but the argument is unidirectional.

I'd say yes. IMO there isn't a single thing you can do with a AGPL licensed
piece of SW that you cannot do with a MIT licensed one, -the other way around,
-quite a bit.

> Also it would be good to recognize the work done before shooting out
> "wrooooong license (for me)"

Sorry. Wasn't my intention but I can clearly see it being read that way. I
just wanted to point it out as I personally don't like AGPL and wanted others
to avoid the disappointment had.

~~~
jordigh
> IMO there isn't a single thing you can do with a AGPL licensed piece of SW
> that you cannot do with a MIT licensed one

Sure there is. You can prevent others from imposing restrictions. If someone
takes your non-copyleft software and uses it to build something that forbids
people from knowing what's in it, how it works, or what it does with their
data, then you are helpless to stop it.

~~~
reitanqild
And this is where our views differ:

IMO nobody can impose restrictions to your MIT licensed code unless they can
somehow threaten you and your users (think patents, law enforcement) in which
case you have lost anyway.

They can reuse your MIT code and impose restrictions on their modified code
but we still have the free MIT code that is way free-er that AGPL and we also
have an additional proprietary option.

Edit: And if your worry is that they will use the code to create a commercial
product with a slightly different file format etc this is a standards issue,
not a open source issue. Furthermore, if there isn't liberally licensed code
available they will just create their own broken/different version.

Summarized: I am fairly convinced that for many companies the option to using
BSD/GPL/LGPL/MIT code isn't using AGPL but rather using a commercial solution
or write their own. Both this more or less guarantees you get no patches back
to your open source project. AGPL is then just a way to make a statement.

~~~
jordigh
> IMO nobody can impose restrictions to your MIT licensed code

Not to you, but to your users. If you don't care about your users' well-being,
well...

> use the code to create a commercial product

I wish people who oppose the AGPL didn't see mistreating their customers as
the only way of being commercial. There are several examples of commercial
AGPL software.

Yes, hiding the source code and forbidding them from copying the source code
is mistreating them. If you are not doing anything wrong, then why are you
hiding the source code? When software is naturally copyable, why are you
denying them this natural right?

> Both this more or less guarantees you get no patches back to your open
> source project

There are also plenty of examples of copylefted projects getting even more
patches than corresponding non-copylefted projects. There's a popular kernel
called Linux that is copylefted and gets tons of industry-backed patches.
People have been using that bugbear for as long as copyleft has existed.
Mailpile got that threat when it switched to AGPL-only and so far its
contributions haven't slowed down.

~~~
reitanqild
> Not to you, but to your users. If you don't care about your users' well-
> being, well...

They can still use my MIT licensed code which gives my user more rights than
AGPL ever will.

> Yes, hiding the source code and forbidding them from copying the source code
> is mistreating them.

Now you are arguing against closed-source, not liberal open source licenses.

> There's a popular kernel called Linux that is copylefted and gets tons of
> industry-backed patches.

Note that you can use Linux on your server without announcing it to everyonce
who acesses it. Also another reason for why patches are submitted are because
industry hope their patches will be mainlined so there will be less
maintenance.

That said, _GPL_ has worked well for the Linux kernel, possibly better than
BSD. (I'm mostly arguin against AGPL.)

> Mailpile got that threat when it switched to AGPL-only and so far its
> contributions haven't slowed down.

Now that is interesting.

~~~
jordigh
> Now you are arguing against closed-source, not liberal open source licenses.

Non-copyleft licenses provide no protection against proprietary derivatives.
If you have no objection to proprietary derivatives, then I think that's a
weak stance to take. It means you don't care if your users can be given your
software but without the rights that you intended them to have, because
someone between you and your users can always take that right away.

While your users might come back to you to get the same software with the same
rights you intended them to have, they might not be aware of this, or they
might not want your software alone, but together with whatever else was built
on top of it, which they cannot get under your original permissive terms
anymore.

------
buster
Bonus points for that gif:

[http://ipfs.pics/QmYqA8GiZ4MCeyJkERReLwGRnjSdQBx5SzjvMgiNwQZ...](http://ipfs.pics/QmYqA8GiZ4MCeyJkERReLwGRnjSdQBx5SzjvMgiNwQZfx6)

------
cherioo
So, this is like eMule? What's the benefit of this over eMule?
Faster/better/hype?

~~~
jmnicolas
No this is Imageshack decentralized.

------
muyuu
Without an extension many forums won't let you embed these images.

