IPFS-based Imageboard

There's been some talk for a while now about the idea of putting together a properly distributed imageboard, and there have been some efforts made towards that end. However, in my view the current efforts still have a number of weak points that leave them vulnerable to targeted attacks knocking them offline. NNTPchan for instance is cool, but the way it's put together DDoSing a (relatively) small number of nodes is still sufficient to take the federation down.

For the past year now I have been slowly working on an IPFS-based federated imageboard software package. It's still in a very early state, and I was hoping to let it sit until IPFS developed a little more, but recent events have made it clear that the noose is already starting to tighten now so out the door it goes.

Github: github.com/smugdev/smugboard
Working instance: localhost:8080/ipns/client.smugchan.org/#Qmf9QKURJVU53mzmysAFAR3mj48dLXqS2rNpq2o41EugcV/tech

(You need a running go-ipfs daemon set up as per github.com/smugdev/smugboard#usage to actually access it)

This is Smugboard, an imageboard package with a fully distributed content layer and a maximally decentralized control layer. It is composed of 5 separate server packages handling different aspects of posting and moderation, and a client-side renderer. Each thread and board takes the form of an append-only log hosted via IPFS, with moderation taking the form of a client-side filter. Users can choose to toggle specific mods on or off (soon - UI not yet complete).

As noted the federation is composed of a series of append-only logs, and these are published directly within IPFS. A proper UI for this isn't done yet, but it will be possible to fork any board or thread from its current state, or from any previous state, at any time. In the event of a board going offline, the board's state still exists within the IPFS network and as long as a copy still exists in any user's cache the board will still be retrievable (in a read-only state), and can be forked and restarted from that state or any of its previous states by any other user. As the content layer works like a bittorrent swarm, the board will paradoxically load faster the more people use it.

Again, this software is still very much a prototype so expect bugs and fun, there's still plenty that needs implementing and contributions are welcome.

Attached: smugchan.png (944x903, 177.28K)

Other urls found in this thread:

github.com/smugdev/smugboard#usage
github.com/ipfs/go-ipfs/issues/3994
github.com/hydrusnetwork/hydrus
localhost:8080/ipns/client.smugchan.org/#Qmf9QKURJVU53mzmysAFAR3mj48dLXqS2rNpq2o41EugcV/tech
gateway.ipfs.io/ipns/client.smugchan.org/#Qmf9QKURJVU53mzmysAFAR3mj48dLXqS2rNpq2o41EugcV/tech
github.com/hydrusnetwork/hydrus/graphs/contributors
github.com/cloutier/php-ipfs-api
github.com/ipfspics/ipfspics-server/blob/master/app/upload.php
github.com/ipfspics/ipfspics-server/blob/master/app/pages/preview.php
github.com/OpenBazaar/go-onion-transport
github.com/ipfs/notes/issues/37#issuecomment-322310422
cryptome.org/2012/07/gent-forum-spies.htm
localhost:8080/ipns/client.smugchan.org/#Qmf9QKURJVU53mzmysAFAR3mj48dLXqS2rNpq2o41EugcV/gondolas/1
github.com/smugdev/smugboard/commit/1b9ab2c130aab8ad8144e6277a5e794c0d1982fc
localhost:8080/ipfs/QmPSuDKYSbj3rWkXdsaBXStcYX6zo29AX1zHLndaNhYidr
github.com/hydrusnetwork/hydrus/blob/master/include/HydrusDB.py
twitter.com/NSFWRedditImage

>You need a running go-ipfs daemon set up as per github.com/smugdev/smugboard#usage to actually access it
And that's why distributed websites haven't taken off yet. If you can't just navigate there with the normal web browser and start using it, nobody cares.

That's right. Something like this can't properly take off until you can just visit a link that someone posts. In other words, we're waiting on ipfs.js to get done, but that's taking a while. The two components left that are needed for 'just werks' type of operation are DHT cross-compatibility with go-ipfs, and for js-ipfs to support IPNS. At this point I'm operating according to the assumption that those two things get done sooner rather than later, but that's up to the js-ipfs dev team.

The one situation where people would bother to install the go-ipfs (or any) client is where all the clearnet sites get completely rekt, which no longer looks as unimaginable to me as it once did.

Nice job OP. Not a faggot for once.
Is IPFS encryped for data going from one node to another? Or will it be eventually? This is my only quip with something like this for the target audience(autists).

These are image boards we are talking about. Literally who gives a shit about normies for this stuff. Make it correctly and build a solid foundation instead of basing it on all the failed librariesjavascript web browsers depend on.

Bless you my good sir. You are accomplishing a great deed.

Attached: ahegao.jpg (298x300, 20.4K)

Rethink. He used NodeJS.

98% of imageboard users are "normies and stuff" in that case. Have fun with your circlejerk of 4 people.

Oh well fuck you OP.

Attached: even-kebab-thinks-op-a-fag.webm (640x360, 2.95M)

Yes, it is. However, right now posts themselves when first being uploaded are currently sent in the clear because I'm waiting on direct links being supported via js-ipfs-api as mentioned per github.com/ipfs/go-ipfs/issues/3994

In my defense this is one of the few cases where it actually makes sense. If it is to be usable without installation then js-ipfs is pretty much the only valid approach as of now. Also the federation scales laterally - you can have each thread on a board running on a separate physical machine if you want. Inability to do multi-threading within Node isn't really a problem here.