We all probably know what Hentai@Home is. Why can't we

just use IPFS for static content

>>56946943
Shit I forgot about that

>>56946920
the problem is bandwidth not storage
IPFS works but IPFS images cant be deleted. this may be a problem but not the problem. How does one embed the image on your browser, etc...

4chan could allow users,volunteers to host an IPFS node along with a script/app/etc to fetch an image from ipfs and return it to the client device.
you could point the hordes of volunteer nodes under a different domain and load balance from the dns itself.

>>56946995
The main question IPFS brought up for me was "How can 4chan maintain ownership of its content?", in other words, how can 4chan delete things?
One of these days we'll have an IPFS node filled with kiddie porn and nobody will know how to get rid of it.

>>56947055
If an IFPS node has gone rouge or has CP, simply disconnect that node from the main 4chan pool.

>>56947086
Theoretically, if we want a node pool that is frequently up to date, then all of them will have it.

>>56946995
for "deleting" content, 4chan's servers just needs to "unpin" them, aka, stop storing and hosting it, along with removing references to it

this won't stop others from hosting it on their nodes, but that's also true to existing 4chan mirrors/archives

once 4chan stops hosting it, it's not their problem

>>56947124
Right, but the idea isn't to protect 4chan, but it's nodes. Those are precious and limited resources (and a future reason 4chan that isn't going under)

I see from the docs that there is an "ipfs files rm" command, but I have no idea to what degree it actually works. I doubt that it sends a command to every node.

Is it possible to 'git fetch' in IPFS?

>>56947142
i'm talking about third party/non-4chan IPFS nodes

you can't instruct other nodes to remove content, persistence/permanence is a key feature of IPFS

>>56947142
the main thing that seperates IPFS from "traditional" mirrors/archives is the universal naming scheme

4chan would have an IPFS node, and a user would have their own local IPFS node
when a user goes to fetch a file, it uses a URL which is basically a hash of the file, and any IPFS node which has it can serve that request
when a file is removed from 4chan's IPFS node, it will no longer store or serve that file, but other nodes which have it can still serve it, seperate to 4chan, as the URL does not change, unlike traditional URLs, which contain which specific server to fetch the file from

>>56947217
sounds like a node that adheres to 4chan policy would have to run the 'ipfs repo gc' command fairly often.

>>56947217
It wouldn't seem terribly difficult to protect 4chan and it's users (but not its nodes).
Once you ``delete" something, you merely replace its reference with the 'file deleted' ref, and update the DB accordingly.
Users who already saw it will still be able to access it via the direct link (although through the magic of javascript this may not necessarily be a problem), but to anyone that isn't a third party node that has to actively get rid of that content, this isn't a big deal.

>>56947231
must existing archives remove content 4chan removes?
of course not, that makes no sense, it wouldn't be an archive if it didn't keep old files

while 4chan's removal of a file doesn't prevent someone from fetching the file from another node, this will no longer tie to 4chan at all, the URL's won't contain 4chan's address, 4chan could disappear entirely and the URL's will still continue to function

this is what they mean by persistence/permanence, IPFS URLs remove the tie between a file and its originating server

>>56947274
Again, the idea is to protect the limited resource that is a node.
I'm not sure if literally every visitor has their own node (that would be ridiculous and heavily taxing on some people, i.e. Australians), but if they don't (and they shouldn't), it should naturally be part of policy that nodes should delete files when 4chan deletes files, in order to protect them from litigation.

Those nodes that don't adhere, we don't care about.

>>56947302
is 4chan legally responsible for files it doesn't host?

an IPFS hash isn't even enough to prove who the originating node was, it contains only information about the /file/

if someone posts a file that has been on IPFS before to 4chan, the hash doesn't change (reposts become free! there's no such thing as duplication on IPFS)

>>56947355
4chan is not responsible for those files.
Even if the hash doesn't identify the originating uploader, the IP address of the node that hosts it is going to be known by the downloader, barring i2p or TOR fuckery.

So, since the node that hosts the file is known under normal conditons, it would be breaking the law for hosting an incriminating file.

While what we're doing doesn't perfectly match the use-case of IPFS, we should think of nodes as some sort of large storage cluster that takes care of entire board(s), instead of smaller entities that only host a handful of images and posts. When a node goes down, we should think of it as a fairly catastrophic event.

>>56947055
All 4chan has to do is to unpin the content from THEIR side and remove references to it. You cant stop people from still having said content hosted by themselves

>>56946995
>how does one embed the image
Once ipfsjs is ready you can just include am src to it in the html and the client will automagically retrieve it from ipfs

>>56947095
Include ipns that has list of removed hashes to sync aswell

>>56947496
Perfect, this is what I was looking for this whole time

>>56947302
Every visito would be having their own node in the form of ipfsjs once its finished, just src to it in html and you have a readytemporary node

>>56947514
I seriously hope that you can disable uploading by default

>>56947523
yep, the implementation is supposed the be the real thing, meaning you can disable seeding just like in a 'normal' node.

>>56947546
This would be as easy as to include ipfsjs.repo.gc every time ipfsjs.get is called

This would be aviable method imo with forementioned solutions, how about we suggest this somewhere where it will actually be read by the people making decisions?

>>56946920
You dont even have to use central authority to confirm content if you use IPFS and ipfsjs on the client side, the system does this by itself

>>56947609
My question is, "why hasn't someone suggested this already?"
ipfsjs does not sound like a critical system component

There was a p2pchan a few years back.

Wasn't completely decentralised.
Everyone had a copy of all the posts and images were hosted on imgur.

I posted the results of our discussion on /qa/.
Rate my thread and tell me how wrong I am.
>>>/qa/748078

>>56946920
So it will be a CP feast.
And yes there is CP on H@H.

>>56948029
Ha! Covered that already.
As long as volunteers are syncing the "DELET THIS" list, they will not have CP on their machines for any appreciable amount of time.

>>56948068
Irrelevant.
Once you have it on your machine it's done.
At least when browsing you could plead I didn't know, some one else posted it.

>>56948128
Actually the government is pretty lenient.
If you host a webservice filled with user-created content, then as long as you're putting forth reasonable effort to remove it, you're good.

How do you think companies like Google aren't getting raped to the stone age on CP claims?
Because they have a department of people (all dead inside, you know it) whose job it is to look up CP picked up by their detection system, and remove any hits

>>56948210
>remove
You mean archive.

>>56948230
technically the hashes are being archived, yes.
There is also the concept of edge-based similarity hashing to match slightly modified or scaled images.
Whether it is possible to reproduce the image based on that is highly suspect, but archival nonetheless.

>>56948128
It is indeed not. Like with every normal http-hosting, you only have to respond to it when you know you have some in an ok timeframe. With ipfs volunteer hosts would be indeed that, hosts. With hosts the forementioned rules apply. Regular users with only ipfsjs have nothing to worry about either since they dont spread it by default

>>56948254
People saving content by themselves is the same with HTTP too, not really anything specific to IPFS. If someone were to host content in the banned list they would be just in as much trouble as with http

Just use WebRTC/webtorrent faggots, most people are going to have it enabled, and the only images shared would be the ones you've actually opened, solving the CP problem.

>>56948447
This would make users spread thumbnails of saod content still, contributing to the factor. IPFS also provides permanence by default which would automatically make archiving possible aswell. Webtorrent is possible right now though.

because then you could replace every node with CP or something

I think everyone is getting to caught up in what content would be mirrored and ignoring the fact that a 4chan hosted in this way would be unbearably slow.

>>56948571
With IPFS this does not happen because of how the addressing works (its also a checksum), as long as 4chan gives right hashes there is no way to serve wrong content.

>>56948615
With IPFS this hasnt been the case at all (atleast for me) when there is atleast one node available, even right out of the bat when coldstarting a node ive been able to seek in sub 400ms. The feasibility of the cdn comes from the people donating bandwidth, just like with torrents.

Webtorrent is the only easily feasible option, only the built-in extensions needs to be modified to run webtorrent and a tracker added.

>>56948555
Except that thumbnails are 3 fucking kilobyte jpegs and the overhead is probably going to be greater than the savings.

The biggest problem with decentralized images is that you can't use HTTPS on a simple node, except if they have a hostname. So maybe every node should get a hostname like node123.4chan.org. With either a wildcard certificate or let's encrypt it could be done

>>56948667
IIRC both IPFS and webtorrent support transport encryption after client negotiation.

>>56948667
Who need HTTPS when you can do this https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity

>>56948683
This only confirms integrity, but transport securiy is also built-in to both IPFS and webtorrent

But when is ipfs-js going to be usable?

>>56948743
You can view the roadmaps progress on their github page at:
https://github.com/ipfs/js-ipfs/blob/master/ROADMAP.md

>>56948784
Everything in Milestone 1 is checked but I'm not seeing any working demo