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.
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.
>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).
Bless you my good sir. You are accomplishing a great deed.
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.
Sweet, will have to take a look at this after my uni classes today. Been looking for that final push to experiment with ipfs for a while now, and this will do it, I think.
If moderation is a client side filter, does that mean that I download stuff, ever if I don't see it? If someone posts CP and it gets "removed", it's not on my computer if I visit the page, right?
the code is literally the worst i have ever seen. i can't imagine that this even works properly.
It downloads images and texts from 4chan/Zig Forums, *booru, tumblr, deviantArt, Pixiv, HentaiFoundry and many more. Youtube, Vimeo, dailyMotion and Vid.me support is currently in the works (yes it can archive videos and pdfs as well). It also sorts images and send them to IPFS, so if you wan to, you can share stuff using that.
If these two projects are connected together, that would be great!
No, I thought about that. When loading a page, it waits for the mods deletion logs to be loaded, then only downloads posts that haven't been deleted by any mod. It slows down page loads a little, but I felt the tradeoff was worth it.
What do you expect from one singular dev who worked on it for 4+ years? At least he tried to put it into action and made something good.
Why not just copy FMS but add provisions for sacrificing decentralization for anonymity? You could also use ring signatures and similar.
rewrite it in rust
Doesn't nullchan already exist?
I don't think that's a good idea.
Doesn't IPFS expose my IP?
no more than HTTP does.
I expose my IP to 8ch.net, but not to other users of 8ch.net. Wouldn't an IPFS imageboard expose my IP to all other users of the IPFS imageboard?
wrong. http exposes your ip only to the server. ipfs exposes your ip to literally everyone in the swarm.
That's a situation you'd want to rectify, no? Adopting Rust would make it even harder to find more devs.
Dealbreaker tbqh. Sorry, but I don't trust all you niggers. Good fences make good neighbors, you know what I'm saying?
What's my IP address?
haha. Lets both post on OPs ipfs board and you can tell me my IP.
literally copied from wikipedia:
Ive posted. Im waiting. BTW you have the burden of proof, not me. But by all means continue to post.
literally copied from ipfs.io:
the CIA should cut your pay, youre terrible at this.
i don't have a clue what you want
Users of IPFS know each other's IP addresses in much the same way that users of a torrent know each other's IP addresses.
Prove me wrong.
You're right though, I don't think anyone is disputing that. I imagine we all use VPNs when torrenting, right? And also all the time as a general rule.
To keep from showing your ISP everything you're doing on the web. As a general privacy measure.
I think that it would've been a better use of your time to patch IPFS support into vichan or OpenIB rather than make an imageboard from scratch with it. Just having users help host the media would be a huge step in alleviating strain. I appreciate the autism either way, though.
If you knew anything about IPFS, you'd know that the only feasible method for integrating it into a website, now or in the near future, is to use js-ipfs in Node.js. Nobody but the same five memers on Zig Forums gives a flying fuck about the server stack, and even if they did, they'd prefer the distributed hosting more than what is running under the hood.
I tried it, but it doesn't work on Pale Moon bundle.js is received, but the script uses the "class" keyword, which is not yet supported
The media is probably the most sane thing to integrate. Then anyone can set up a textboard on their home computer for next to nothing but still use images. The one Zig Forums uses (one of the ones in the footer at least, don't remember which one) has NNTP support, you could probably patch it in there
After some cursory investigation, vichan is the one with NNTP support. You could have a go-ipfs daemon running and use this wrapper. github.com/cloutier/php-ipfs-api
When it's done smugboard will automatically pick up TOR support `for free`. It's just a matter of waiting at this point. I imagine after TOR support is in it won't be that much of a leap to I2P, since the security model shouldn't change.
Next best thing is something which can be downloaded, Next > clicked a few times with sane defaults, and then the magic address accessed. This would of course require marketing an element of secrecy/exclusivity as part of the allure of the destination (to make it worthwhile).
It's not bad to have *some* difficulty or barrier to entry. Make this bar fairly low, but with proper marketing: this barrier representing the cost of gaining something in status being someone who can be well connected regardless of situation/environment, allure of secrecy/exclusivity/"I want it because I can't have it." could actually work as "normie-nip," and bring interest. It would also fuck the Feds' day up as suddenly more people are harder to collect evidence from.
good effort, but the code is painful to look at. i doubt this'll live long enough to see the first wave of normies ruin it, like everything else on the Internet
Actually it might be worse. After setting up IPFS, the web interface lists my location as my actual location, not the location of my VPN. At least when I torrent, they just see my VPN location. Could just be something weird and peers only see my VPN IP, who knows. I hope so.
Also OP's site won't load for me and I don't know why because I went ahead and did all of the little config tweaks. Do i actually have to install what's on the github page to view a website?
If you're using Pale Moon, see
I'd really like to contribute to this but i don't know enough js
Well damn I switched over literally yesterday. Thanks for pointing that out. I just threw it in firefox and now it's stuck on a screen that says "loading" for the past ten minutes or so.
That means you've started the daemon in readonly mode. Run it with --writable.
Thanks. That fixed it. Sorry for the incompetence. It's a nice place.
Do you happen to be running Windows? Normally just configuring the daemon is enough. Did you restart the daemon after running those configuration options?
No, I'm on gahnooo/looonix. I didn't restart the daemon after doing the config and didn't start it in writeable. I got it all figured out now.
Huh, is something odd going on? I was able to post fine yesterday, and now suddenly I'm unable to post at all. As in, hitting "new reply" does not create a new post.
You can easily use y.js with y-ipfs-connector while providing the usual ipfs.js fallback of manual reload instead of auto-syncing. Node has nothing to do with this and you're a faggot.
Have you looked at orbitdb? Maybe it can help. Was there a reason you wrote ib software from scratch? I think you can pick one off-the-shelf and integrate everything except moderation and captcha with a couple require's. There are simple consistent protocols for distributed captcha that you can use (and probably even off-the-shelf libraries for it) too.
Yes, that's correct. I think tor and/or i2p compatibility is now active (not sure though) so you can use that for anonymity, but the base system does not have it by default (which I think is a good thing since it allows it to be blazing-fast for operations that don't need anonymity, which is most of them).
Can't be arsed to check the code, is this true? Can you post file/line numbers?
Currently IPNS names are slow to resolve, so there's a basic resolver there to speed things up for now. It's not necessary, the server can be switched off and the client would automatically failover to IPNS proper, but page load times would be around a minute. It'll be deprecated once either IPFS' pubsub or p2p systems pick up js-ipfs-api support.
In any case, all I get now is a "loading..." page and that's it.
that's what I got when I didn't launch with the daemon with the --writable flag. Did you do this? I've been having more problems just with not being able to post anything. Like anything at all.
Try refreshing again; I just restarted the post auth server.
No scrap that, I think my latest client update broke the federation. It's because I thought adding webm support to the running site would be a good idea, I'll fix it later today.
if we're going to develop new imageboard software I think that it's absolutely critical that we create a new system for moderation. The current one is extremely out of date and extremely susceptible to infiltration and subversion. If we move to 0chan, or smugchan, or some other imageboard we have absolutely no idea who the admin is or if they're trustworthy.
I would propose a subscription based moderation system where anons can decide who gets to moderate for them. However we also can't let mods namefag since that would be a massive opportunity for [email protected], thus when you sign up to be a mod you should be assigned something like a random string of 10 letters and numbers, it's a bit difficult to namefag as 235j4ns3e3. We regrettably need mods because of spam and CP but we should disempower them as much as possible to prevent co-option and subversion.
Unfortunately there was a bug that broke the federation, and it looked like it'd be a pain to reconstruct everything manually so I restarted it again from scratch. I may try remerging the threads manually later, but it's a bit tedious since the framework for attaching threads to boards on the fly isn't done yet. It shouldn't happen again though.
1- How do you deal with input sanitation? Can a user send a crafted document to inject arbitrary html and/or js? 2- Do you really need ipfs-js-api? Why not hit localhost:5001 directly? 3- Would it be possible to support reduced/no js? Simply pinning the latest documents to a version of the page and loading directly from ipfs (even auto-reload might work through ipns, though posting probably wouldn't work that way)?
Press F12 ffs.
I'm confident the servers are fine, in terms of sanitation there is no DB; data just gets dumped into IPFS as a blob. I'm a little less sure about the client, ideally someone else will have a look at page.js and tell me if it's as secure as I think it is (specifically decoratePostBody()).
Could do, but it'd be messy and I'd ultimately end up reimplementing the api anyway. The deeper reason is that js-ipfs-api and js-ipfs share the same interface; once js-ipfs is ready (still needs the DHT and name resolution) I will be able to change all of 3 lines and the daemon will be runnable in the browser, meaning no more needing to run go-ipfs or screw about with CORS. I'll still provide an option to use the go daemon though, it's likely to be more performant and stable.
No. I spent a long time trying to avoid requiring JS in the early days but it's just not feasible. The site doesn't work as a series of static pages that even could be pinned, it works as a series of linked lists (or blockchains if you prefer) published by servers that never know the current state of the complete system, it's up to the client to stitch things together. The other option was producing a custom program that needed to be installed locally to access the site, and then nobody would ever use it (might as well use Twister if we're going down that route).
Is there something wrong with the ipfs go client? Even when not connecting to anything, clearnet sites complain of unusual connections coming from me if it's running, and my network connection gets nuked every so often (as if through bandwidth starvation).
But you could write a local client in theory?
Yes. It's outside the scope of this current project, but the content stored in and pulled from IPFS is a series of raw objects that constitute a series of append-only logs, with no hint of HTML or anything. With enough motivation you could write some other renderer that either acted as a local server that rendered pages for a browser, or else you could go in the other direction and reimagine the federation with a CLI interface. The only requirement is that your platform has to be able to parse JSON objects that look like localhost:8080/ipfs/QmPSuDKYSbj3rWkXdsaBXStcYX6zo29AX1zHLndaNhYidr and be able to grab them from the IPFS daemon.
Seems reasonable. What about using something like FMS but with ring signatures to further decentralize moderation?
Something that has been working for more than a decade while you were reading walls of texts from various DevMarketing teams and shitposting about new ideas, a rare project that has been conceived to operate in real hostile anonymous systems.