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: https://github.com/smugdev/smugboard

Working instance: http://localhost:8080/ipns/client.smugchan.org/#Qmf9QKURJVU53mzmysAFAR3mj48dLXqS2rNpq2o41EugcV/tech

(You need a running go-ipfs daemon set up as per https://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.

>>785171

>You need a running go-ipfs daemon set up as per https://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.

>>785173

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).

>>785173

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.

>>785171

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

>>785178

>Nice job OP. Not a faggot for once.

Rethink. He used NodeJS.

>>785178

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

>>785180

>nodejs

Oh well fuck you OP.

>>785178

>Is IPFS encryped for data going from one node to another?

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 https://github.com/ipfs/go-ipfs/issues/3994

>>785180

>>785183

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.

>>785187

Who cares if it is easy to use. Make it correctly for autists as that is what the target of image boards is. Which is to say don't be a pajeet using javascript and implement your own in goor rust.

>>785171

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.

https://github.com/hydrusnetwork/hydrus

>>>/hydrus/

The web and android front-end is being developed right now

>>785216

>coded in python

>target audience is 8ch/4chan

>hosted on cianigger code website

I am skeptical. But it is just a image sorter after all?

>>785171

>Working instance: http://localhost:8080/ipns/client.smugchan.org/#Qmf9QKURJVU53mzmysAFAR3mj48dLXqS2rNpq2o41EugcV/tech

Make https://gateway.ipfs.io/ipns/client.smugchan.org/#Qmf9QKURJVU53mzmysAFAR3mj48dLXqS2rNpq2o41EugcV/tech work

Awesome.

>>785171

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?

>>785216

the code is literally the worst i have ever seen. i can't imagine that this even works properly.

>>785219

It downloads images and texts from 4chan/8chan, *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!

>>785240

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.

>>785242

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.

>>785171

Why not just copy FMS but add provisions for sacrificing decentralization for anonymity? You could also use ring signatures and similar.

>>785251

rewrite it in rust

Doesn't nullchan already exist?

>>785268

>limit the pool of potential developers for an already niche product by writing it in a special snowflake language

I don't think that's a good idea.

>>785171

Doesn't IPFS expose my IP?

>>785341

no more than HTTP does.

>>785343

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?

>>785341

>>limit the pool of potential developers

you mean exactly one?

https://github.com/hydrusnetwork/hydrus/graphs/contributors

>Doesn't IPFS expose my IP?

yes

>>785343

wrong. http exposes your ip only to the server. ipfs exposes your ip to literally everyone in the swarm.

>>785347

>you mean exactly one?

That's a situation you'd want to rectify, no? Adopting Rust would make it even harder to find more devs.

>>Doesn't IPFS expose my IP?

>yes

Dealbreaker tbqh. Sorry, but I don't trust all you niggers. Good fences make good neighbors, you know what I'm saying?

>>785347

>http exposes your ip only to the server

wat

>>785353

What's my IP address?

>>785354

haha. Lets both post on OPs ipfs board and you can tell me my IP.

>>785353

literally copied from wikipedia:

>An HTTP session is a sequence of network request-response transactions. An HTTP client initiates a request by establishing a Transmission Control Protocol (TCP) connection to a particular port on a server (typically port 80, occasionally port 8080; see List of TCP and UDP port numbers).

>>785358

Ive posted. Im waiting. BTW you have the burden of proof, not me. But by all means continue to post.

>>785359

literally copied from ipfs.io:

>A peer-to-peer hypermedia protocol

>>785360

the CIA should cut your pay, youre terrible at this.

>>785353

>>785357

>>785359

>>785361

bait

>>785361

i don't have a clue what you want

>>785357

>>785353

>>785359

>>785361

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.

>>785364

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.

>>785366

>And also all the time as a general rule.

why?

>>785367

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.

>>785198

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 /tech/ 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

>>785415

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 8chan 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

>>785427

After some cursory investigation, vichan is the one with NNTP support. You could have a go-ipfs daemon running and use this wrapper.

https://github.com/cloutier/php-ipfs-api

Here's some examples from IPFS Pics.

https://github.com/ipfspics/ipfspics-server/blob/master/app/upload.php

https://github.com/ipfspics/ipfspics-server/blob/master/app/pages/preview.php

>>785471

You could also patch the upload function to run ipfs add <local image pathas an external command, save the resultant hash in the database, and upon pruning the post unpin the image.

>>785369

instead im showing my vpn provider everything im doing on the web. genius

>>785171

The hero we need, but not the one we deserve.

Nice effort OP.

>all these people praising op or bashing

>I have yet to see a single post on the live demo that isn't my own.

>>785599

nevermind, took me an ass long time to find peers for some reason.

how hard would it be to stick i2pd before ipfs and run a textboard?

>>785606

not even your computer is good at making friends

>>785595

Well the point is that you choose a paid VPN provider that doesn't keep logs or such. Or use a VPS to set up your own VPN, which is probably the best way to do it. What is your solution?

>>785610

Can't be done yet, but IPFS is planned to support TOR transports. Actually it's already working https://github.com/OpenBazaar/go-onion-transport but the devs are refusing to merge it upstream until they're done auditing it https://github.com/ipfs/notes/issues/37#issuecomment-322310422

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.

Remember the Gentleman's guide to forum spies:

http://cryptome.org/2012/07/gent-forum-spies.htm

Don't fall for in-fighting, focus

>>785173

This would probably be for people who don't just want to access normal-fag content.

Activism, speaking freely, etc.

Long as you make a step-by-step How To, like-minded people will join in.

>>785173

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

>nodejs

>>785364

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?

>>785825

>Also OP's site won't load for me

If you're using Pale Moon, see >>785426

I'd really like to contribute to this but i don't know enough js

>>785868

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.

>>785885

That means you've started the daemon in readonly mode. Run it with --writable.

>>785907

Thanks. That fixed it. Sorry for the incompetence. It's a nice place.

>>785885

Do you happen to be running Windows? Normally just configuring the daemon is enough. Did you restart the daemon after running those configuration options?

>>785930

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.

>>785171

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.

>>785415

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.

>>785364

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).

>"IPFS-based"

>it just loads javashit from ipfs then does ajax calls to a normal webserver

>>786324

Can't be arsed to check the code, is this true? Can you post file/line numbers?

>>786324

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.

>>786384

In any case, all I get now is a "loading..." page and that's it.

>>786389

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.

>>786389

>>786391

Try refreshing again; I just restarted the post auth server.

>>786395

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.

>>786443

but who would do it for free?

>>786443

Fuck off back to promisedchan

>>786446

Anon there's always someone who will do it for free.

Always

>>786443

That's pretty much what smugchan does, though. You can decide to ignore hotpocketeering and just load everything.

>>786455

Well then that's just perfect.

>>786389

>>786391

>>786395

Fixed it, I didn't do the CORS shit beforehand that's why it wasn't loading.

>>786443

>However we also can't let mods namefag since that would be a massive opportunity for [email protected]

I don't know what you said before it got eaten by Cuckflare but I can't see why names would be so harmful. What's the difference between a custom name and a random string?

>>786579

Named mods allow cliques to form about popular moderators that can easily cause infighting and drama.

>>786591

Where's the drama when they're optional? Who gives a shit? Just use a different moderator.

>>786595

Never underestimate the potential for the eternal namefag to fuck everything up.

Just do it to be safe.

I have added in webm and so on support. No in-page player yet, but you can now post them and it shows up as an attachment ( http://localhost:8080/ipns/client.smugchan.org/#Qmf9QKURJVU53mzmysAFAR3mj48dLXqS2rNpq2o41EugcV/gondolas/1 ).

On that note, a good many more formats are also now postable as per https://github.com/smugdev/smugboard/commit/1b9ab2c130aab8ad8144e6277a5e794c0d1982fc including ogg flac mp4, pdfs, various archive formats, and torrents.

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)?

>>786327

Press F12 ffs.

>>786707

> How do you deal with input sanitation?

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()).

>Do you really need ipfs-js-api? Why not hit localhost:5001 directly?

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.

>Would it be possible to support reduced/no js?

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).

>>786727

But you could write a local client in theory?

>>787072

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 http://localhost:8080/ipfs/QmPSuDKYSbj3rWkXdsaBXStcYX6zo29AX1zHLndaNhYidr and be able to grab them from the IPFS daemon.

>>787084

Seems reasonable. What about using something like FMS but with ring signatures to further decentralize moderation?

>>785265

>>787089

people keep saying FMS, what is that?

>>787122

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.

>>785216

>literally uses reddit spacing in the source files

https://github.com/hydrusnetwork/hydrus/blob/master/include/HydrusDB.py

wtf?

>>785330

That project appears to be dead. Also, Zeronet isn't really secure.

>>787122

richard matthew stallman's lesser known brother, francis matthew

We could get a mass migration to a IPFS based image board if handy features were implemented.

Features like archives that have a calendar, that way you could remember a range of days to search for content that you remember being posted, and then look up what was posted on those days.

There needs to be a better way to compile information on complex topics such as Pizza & gamer gate, other wise it's a quagmire especially for new people to the topic or those who're aren't up to date with the latest information.

----

Can we get an archive of flash games going?

------------

One of the top priorities of IPFS adoption is getting a IPFS based tracker up and running. People would flock over a tracker that has decent content that's impossible to take down. There have been many great trackers that are now dead.

>>786994

Looking into it more, that issue was reported in 2015 and has still not been solved to this day. ipfs is known to completely destroy bandwidth 4no raisin. Not sure how this happens to also affect unconnected clearnet sites but it's bound to be yet another bug.

Given how long ipfs has been developed and the fact such bugs still exist, maybe it's wise to evaluate alternatives like storj, sia, tahoe-lafs, retroshare, zeronet, etc.? Can someone write out some pros and cons of each?

>>785242

so make it better, or start your own project

at least he actually made something

Can you take a look at >>785426 ?

Digging through the code, I see that bundle.js is generated in the setup.sh script, by the "browserify" command

The issue is that that command generates a js file which uses the new "class" keyword to build, well, classes, which is not a supported feature in Pale Moon

The real question is wether or not you really need all that javascript (it's something like 30K lines) or if you can use a smaller script using features supported by every browser

>decentralization

>no spam

pick one and only one

>>787420

How about both, inbred?

>>787423

>decentralization with no spam

it's not decentralized enough if that's the case

>>787424

Bad actors can be culled in many ways. Nodes can request culled material, or not (default).

>>787404

That appears to happen within the included js-ipfs-api package. The two solutions are to either not include it any more, which is a problem since it forms the crux of the interface to IPFS, or else to get Palemoon to support the class structure. I want to support PM, but smugboard is a while away from being stable so my hope is that Moonchild gets his act together by then and I don't have to do anything. We'll see what happens.

>>787428

So the post culling is tracked globally? How will this work once it expands past one node? Will it just automatically cull posts if federated nodes request it? (Assuming of course that the feature is enabled.)

>>787122

Freenet Messaging System (and Web of Trust)

FMS:

http://freesocial.draketo.de/fms_en.html

https://d6.gnutella2.info/freenet/USK@0npnMrqZNKRCRoGojZV93UNHCMN-6UU3rRSAmP6jNLE,~BG-edFtdCC1cSH4O3BWdeIYa8Sw5DfyrSV-TKdO5ec,AQACAAE/fms/147/

https://d6.gnutella2.info/freenet//USK@xedmmitRTj9-PXJxoPbD7RY1gf9pKi0OcsRmjNPPIU4,AzFWTYV~9-I~eXis14tIkJ4XkF17gIgZrB294LjFXjc,AQACAAE/fmsguide/6/generalfaq.html

Web of trust:

http://freesocial.draketo.de/wot_en.html

https://d6.gnutella2.info/freenet//USK@0npnMrqZNKRCRoGojZV93UNHCMN-6UU3rRSAmP6jNLE,~BG-edFtdCC1cSH4O3BWdeIYa8Sw5DfyrSV-TKdO5ec,AQACAAE/fms/147/trust.htm

https://d6.gnutella2.info/freenet//USK@xedmmitRTj9-PXJxoPbD7RY1gf9pKi0OcsRmjNPPIU4,AzFWTYV~9-I~eXis14tIkJ4XkF17gIgZrB294LjFXjc,AQACAAE/fmsguide/6/trustfaq.html

>>785265

>>787089

What benefits do you think this would have over smugboard's current approach?

>>787543

More robust and decentralized.

>>787544

In what way? It's not possible to knock a mod offline, since their log structure exists as a distributed object that is mirrored by every visitor.

>>787560

It scales better. Spam needs to be actively removed, with FMS it's not even downloaded. Look at what WoT does, then remake it with ring signatures for anon.

>>787577

I think you're proposing that each poster gets and maintains their own public ID, and the users white/blacklist other users per recommendations from each other/specified mods. This approach would turn everyone into tripfags, which is something I am going out of my way to avoid. The current architecture is as decentralized as possible whilst still maintaining per-post public anonymity, something I don't think any other platform to date has pursued or implemented.

>>787597

You can solve that with ring signatures. How are the captchas generated?

>>787605

None of the things you're saying have anything to do with imageboards. OP doesn't want a mailing list.

>>785181

i would much rather circle jerk with 4 non-plebs than 4 non-plebs and 196 plebs

fucking normie lover

>>787469

All the data is present at all time, but the "main page" has variations, which may or may not include the request for the "moderated" data. A node that requests the spam data is said to vote against the "spam" vote, and vice versa. Consensus indicates the result.

This system can further be augmented by generating currency for all posts not marked as spam, and requiring payment for all posts. This prevents total censorship while making spam attacks expensive (the intent is that it is prohibitively expensive).

>>787863

>requiring payment

ishyddtg

>>787863

I think the payment system might be a bit far and easy to misrepresent as a "tenbux" model or something. Anything even RESEMBLING currency should probably be left out of the equation.

>>787863

>requiring payment for all posts

>generating currency

>Consensus

Sounds like a set of horrible ideas to me.

>>787953

>>787958

Other options like those employed by frost or fms (as mentioned before) are also possible. Currency is a simple sustainable way to prevent bad-actors while preventing the network from censoring nodes. Generating post deletion using asymmetric crypto to validate authorized mod actions is still a possibility but obviously runs into the centralization issue. Although it is possible to also use federation to elect moderators.

>>787976

Wouldn't switching IP address just solve the problem for the spammer. Also as >>787972 points out, the whole consensus thing is something that bothers me. Honestly I'm not opposed to a traditional moderation scheme as long as moderation is kept to a bare minimum.

>>787977

IP is irrelevant in the network, content is what matters and that's what the federation is based on.

If consensus is what bothers you then there's currently no good solution without also causing some amount of centralization. The only canonically proven way to remove bad actors is to increase the cost of bad actions to be larger than their resistance threshold.

>with moderation taking the form of a client-side filter. Users can choose to toggle specific mods on or off

OP I love you (no homo). I feel we've spoken before, but I'm still glad someone else understands the need for this.

>>788008

>Shitposting general

>>788008

Only faggots use filters.

>>788008

We probably have, I've mentioned it a few times across various boards here. I recall saying I intended to get this out before Christmas last year, but IPFS wasn't ready yet and I wasn't wanting to bring attention and heat on the devs from TPTB lest they bail. I figure the censorship push proper has already started now though so we're either screwed or we're not.

>>788030

Well at least if the hammer comes down we can retreat to the 8chan Onion and finish smugchan if it comes to that.

Holy fucking turbo autism. Look at the state of this shit.

>>788008

>That form of moderation was actually my idea

Honestly I think that one of the greatest feelings in this world is when your ideas can stand on their own and end up integrated into culture/important projects completely based entirely on merit.

>>788043

Yes. Here's the basic idea:

>generate identity with captchas

>generate new key for a thread with ring signatures (the kind where a member of the group can tell and prove they didn't sign it)

>if that key shitposts excessively all the keys used get bad reputation unless they publish the proof it wasn't them

>a new identity can also be generated with ring signatures from trusted identities instead of captchas, with bad trust affecting their parents like bad posts'

>this allows you to rotate identities weekly or so

It should be "good enough".

>>788079

I know why and you know why. But that UI is NOT acceptable.

I estimate there are literally 2 autists in this world that can be bothered with this, so they might as well just email each other.

>>785171

I know I'm probably going to get lynched for this post, but can someone explain what IPFS actually is?

Wikipedia says it's a protocol to replace HTTP but the rest of the article is useless. Looks like botnet to me. Say if I want to put a website on IPFS does that mean my computer will need to become a 24/7 server for hosting it?

>>788087

It's basically bittorrent, but you access it through your browser instead of a normal torrent client.

>>788081

Freedom ain't free.

>>788079

Sounds good.

>>788081

Its a one time thing unless you excessively shitpost, its a decent solution to preventing people spamming.

>>788043

That's why all three of the people who use Freenet just use Frost to shitpost. It has absolutely no spam protection though.

> not calling it distributchan

ishiggydiggy

>>788081

Freenet can't do dynamic content so they don't have much choice.

>>788109

As far as I know it has a form of moderation or spam prevention. They still receive the spam, but they don't display it. Apparently this has the caveat of somehow making it very hard to accept legitimate posts. Not sure about the details.

>>788043

This is a page you see only once in the whole lifetime of your identity. Moreover, it's actually the least technologically advanced part of FMS, as it is common knowledge that captchas are insecure, can be OCR'd or massively solved for a small price. The idea is that someone breaking current half-assed introduction process will be met with another half-assed level of indirection (introductory interviews? lol) that won't be as cheap to game.

You should probably temporarily increase your requests limits in FMS settings. Meanwhile, you can visit extra fat FMS archive.

>>788109

I am pretty sure no one has been using public Frost boards to shitpost for a couple of years because of some funny fellow(s) who finally managed to insert hundreds of junk data messages each day on every board, rendering Frost unusable for anyone who decides to update them.

Also, you are underestimating Freenet user base size. I think it has something to do with your ignorance and technical illiteracy.

>>788720

>claims no one's using frost then calls me ignorant

>>788733

> claims no one's using frost

That's anal smuggling of goalposts across the border.

Bumping because smugchan is great and needs more attention. This is excellent both as a bunker and somewhere to escape normalfags.

>>789082

It's more important as deterrence

>>789082

>ipfs destroys bandwidth like nothing else and gets you blocked from every clearnet site "somehow" just by running ipfs-go for more than a few hours

>smugchan never fucking loads right

>still stuck on the old architecture and forced js

"no"

>>789169

>and gets you blocked from every clearnet site "somehow" just by running ipfs-go for more than a few hours

I've never had this problem, or heard of anyone that did apart from you.

>>789266

Have you ever checked the issue tracker? There are hundreds of reports. It's been a well-known issue for years.

>>789437

>hundreds of reports

Proofs?

>>789474

https://github.com/ipfs/ipfs

>>789437

why ? (technically speaking, not le conspiracy meme)

>>789508

>laziest possible reply

I don't disbelieve you, but if you don't link to actual issues, or further specify what you mean by "blocked from every clearnet site" so I can look for them myself, I'm going to assume you're just a delusional paranoiac

>>789541

The reason they/people who noticed the issue give is that they haven't implemented bandwidth limitation yet and try to connect to every peer simultaneously no matter how many there are (so 1k peers at 10kb/s each is quite a lot, whereas e.g. for torrent you'd typically be limited to about 50 peers by most clients).

It's not clear what causes the clearnet site issues, most likely similar bugs/misfeatures (for example maybe the client checks for network access by pinging a domain repeatedly instead of only once in a while, or perhaps a nat traversal that connects to a site that is cloudflare protected, e.g. once per peer instead of only once, thus prompting cloudflare to globally blacklist the node).

>>789543

He refuses to link an issue because he's outright lying.

Is there an IRC channel for the project?

>>789858

Seconding this question. I think a #smugchan on Rizon or something would be a good idea.

>>785173

The ratio of need:effort is fairly low on the effort side right now. What with 4chan being EZ. Like OP mentioned though: If half and 8 suddenly get shoahed, many people would be willing to put in extra effort to get to autist israel.

>>789858

>>789900

Good point. There is now a channel up, #smugboard on Rizon.

>>790100

Thanks m8. I've been looking for more /comfy/ irc channels to join.

>>790100

Could you also make a >>>/smug/ board?

Discord would actually be okay

>>791443

>(((discord)))

Commit suicide at your earliest convenience.

>>791443

I'm not sure there's enough to say for a /smug/ board yet, this thread is probably enough for now.

I'm not making a Discord, there is the IRC channel if you want to get in touch.

>follow the instructions

>doesn't work

nice

>>791540

What browser are you using? Have you disabled Javascript?

>>791621

SeaMonkey and no.

>>791637

The problem doesn't seem to be Seamonkey. Try opening the inspector and seeing if anything obvious is going on. Are any errors showing up in the console? Is anything not loading in the network tab? Are you sure you ran the config lines as stated? Are you sure your local daemon is running correctly?

>>791637

If you aren't running the daemon with the --writable flag then it won't work.

>>791651

I believe that shouldn't be necessary if the daemon is configured as per the usage directions.

>https://github.com/smugdev/smugboard#usage

Can this be restricted any further? What are the security implications of this?

>>791652

It was when I did it. After the config the page would still not load unless I used the daemon with that flag. I'm not entirely sure why.

Can confirm all works with --writable flag. This is great work, Anon!

>>788049

You liar, it was my idea.

>>791443

>discord would be okay

NOPE.

>>792561

>>791454

Then use matrix/Riot instead

>>792670

Matrix yes, riot no. And only with encryption.

>>793351

whats wrong with riot? other than electron

>>793390

Read their privacy policy, jewgle is watching.

>>792561

>28 million in the hole

this /pol/yp doesn't know how VC works, does he?

forever "Loading"

>>793403

That kinda is how it works though, VC sends money with the expectation to make it back and then some. Though it is also true it's not a loan, i.e. there's no liability so long as the company can show they haven't deliberately tanked it.

>>793403

that's an investment that must be paid back retard

>>793687

VCs exchange money for equity, it's not a loan. And even if it was a loan, when an corporation goes bankrupt they only pay back with their current assets, which is basically nothing.

LARP boy

>>793689

until they pay off that debt or go under it is money owed

bump

Hey m8.

This is pretty cool. Be nice if webums had thumbnails.

>>786443

this is fucking retarded, it would just promote a bunch of circlejerk fags voting to get their leader into moderation and fucking everyone over.

moderation has been too abused and hijacked here, for example if you post something that someone else doesn't like they'll basically downvote you by calling a mod to do their dirty work and stop you from talking this happens a lot on /pol/ or /a/.

>>785171

i've been wanting to do this for over a year now but never knew where to start. atleast someone is doing it. good job.

>>795854

There is no voting in a subscription based system. Every individual user gets to decide for themselves who they want to mod for them. If you don't like a mod you don't subscribe to him and his actions will have no effect on your experience. Simply not subscribing to any mods would have the same effect as having no moderation at all.

>>795883

>SJWs flock to IPFS based imageboards for nerd points

>subscription filters fail to load

>so many people get triggered that they off themselves and no longer pollute our spaces

>mfw

I like this model actually. It solves the age old problem of moderation; little people with a piece of power controlling conversation.

>>789437

>hundreds of reports

there are exactly 107 open issues on the tracker.

feel free to point to all of the ones that are related to your problem.

Content-address subscription moderation is (should be) a hugely appealing idea for sjws, since it's the ultimate vehicle for custom trigger-warnings. You can have some categories you don't want to see at all, some categories you want to be warned about, and then the rest is just normal. (Content warnings aren't necessarily trigger warnings -- someone who's not a sjw but maybe browsing at work or in public can just turn on "nsfw" warnings.) Better to turn the whole world into a safe space than have them ignore the world because they can only browse in one particular safe space. Especially when it isn't apparent to other people browsing the same content.

>>795953

Feel free to stop being clinically retarded

>>795883

de-unified augmented reality probably has some consequences

>>795955

This is how Mastodon killed GNUSocial. Nobody had ever banned parts of the federation before tumblr imported their content policing values. The consequence is you have some imperative information or timely cultural events never reaching the critical mass they deserve to reach due to augmented content.

>>795883

isn't that like, Tyranny of the majority?

>>796231

oh no wait I misread it hard

>>795890

I wouldn't say it fixes everything; you still have to motivate people to moderate at all. With no incentive to be a power tripping mod, you remove the autistic dedication to moderate 24/7.

This is a respectable first step, however. Ideally you'd be able to combine them in a manner similar to adblock lists. You subscribe to people who promise a certain level or mode of moderation and combine them to reach comprehensive coverage of posts.

>>796201

Looks pretty alive to me, especially considering Jap Mastodon doesn't block the Fediverse. This is the exact opposite of what those Mastodon servers did; instead of letting users block content on a case-by-case basis, the admins blocked entire nodes of the network.

>>796238

>With no incentive to be a power tripping mod, you remove the autistic dedication to moderate 24/7.

That's always been my main problem with choosing people for this position. I was always on the administrator level and needed folks to moderate for me after a certain point so I could focus on other things. It has been the same issue since the BBS days: no matter who I picked they'd eventually let their ego get in the way of their job. It'd go to their head and the community would rightfully want them ousted. In 20 years I only found a few people, out of hundreds, that could handle it without becoming a major problem for me. Even those folks would often have minor slips of not remaining impartial. I never understood why my simple instructions could never be followed: don't let them post pizza or anything that will bring me legal trouble and if they fight let 'em.

I like this model for the reasons you states, any power tripping/stupidity can just simply be ignored by not subscribing to that list. However, I do agree that SJWs will hug box themselves as they always do and this type of set-up may prevent important information from reaching the masses via self-censorship. At least with this model I have a choice in what I read.

>>796343

god that is just the fucking problem isn't it

How are the mod filters implemented? Do users have to download the whole linked list of posts first and then the client filters them out of the UI or does it process the filter list first and prevent blocked posts from being downloaded? This is a pretty big deal as the second way will lead to filtered posts becoming less "seeded" and might eventually become lost forever. On the other hand I really don't want to download thousands of spam posts just to filter them every time I visit a new board.

>>796667

>Do users have to download the whole linked list of posts first and then the client filters them out of the UI or does it process the filter list first and prevent blocked posts from being downloaded?

The latter. You raise a good point, though I don't think it should be much of a problem in practice. I figure if people don't like a mod there'll be plenty of people not subscribing to it - and so contributing to the health of those filtered posts. Also, the mods themselves still see filtered posts (marked as hidden) so those posts are still active in their local daemons.

Can you add .opus support? Nobody puts opus audio in an ogg container.

>>798470

Added, though it won't be merged to the live site until after the rewrite is done.

>>793595

Yeah, this is still "loading" for me too.

>>793595

>>800213

Did you set the config parameters as per the github?

Would it be possible to federate this with NNTPchan? It doesn't seem to hard to me, just create one daemon that follows some filterlists and reposts to NNTPchan, and one daemon that reposts from NNTPchan. It would be good for the userbase and provides long-term retention.

>>800830

>create one daemon that follows some filterlists and reposts to NNTPchan, and one daemon that reposts from NNTPchan

Can you expand on this more?

>>800849

>one daemon is a smugchan client

>it follows an operator-defined list of moderators

>whenever it sees a new post, it reposts it to a pre-defined NNTP server (e.g. one specially dedicated for smugchan federation)

>one daemon is an nntpchan client

>it fetches messages from an operator-defined list of nntpchan servers

>whenever it sees a new message, it reposts it to smugchan

Simple as that, don't see what more there is to explain.

>>796200

The problem would crop up when you have one side of a conversation hidden but the other not. You'd probably need to have the mod automatically also delete all responses to a deleted post on that same filter.

>>801181

>filterlists will work

i mean maybe a little bit but youll get some shit still going through if people want it to...

Bump

>>791674

Still waiting on a response...

>>791674

Those settings permit the JS API control of your local daemon. So, any JS you run needs to be trustworthy, else someone else could use your daemon for their personal file host or something. I once asked the devs about this and they said they were going to have security such that you would whitelist specific scripts but that it wasn't done yet.

To avoid the class keyword, just transpile the JS with Babel.

>>785178

>I used the word "normies". Do I fit in yet guys? I'm cool, right?

I see the dev commited a bunch of smugboard next changes. Any updates on when it'll be ready?

How about an explanation on what you changed or improved?

If anyone is interested I've made one using Orbitdb (single discussion thread):

https://ipfs.io/ipfs/QmRG68mR9P6Z8RnHppJqizRpBMBYGNQ3AwwhUEp2DFrTJt/

Honestly distributed imageboards should not have any server-side code, just a configurable list of mods public keys on each client. It might also be a good idea to develop a separate base project for human PoW blockchain / database (https://grez911.github.io/captcha.html) in a way we can use it with different imageboard engines.

>>830621

doesn't seem to work on the new firefox, says that it's offline after waiting for many minutes. i used my local gateway by the way

waterfox handles it just fine though

>>831061

It works fine on the new Firefox. If you have an adblocker with "Prevent WebRTC from leaking local IP addresses" you need to disable it.

>>831226

no thanks friendo.

Dead IRC= dead project

>>831226

wasn't enabled in the first place, but i will try toggling it

>>832683

NEVER EVER

>>830621

Ignore the second part of my comment. The said distributed CAPTCHA is easy to abuse. You could tweak a post until its hash match a CAPTCHA you have previously generated yourself and repeat until the whole chain is full or yours. In order to make a proof of human-work blockchain, we need to find a way to generate puzzles easy for the human to solve but hard for the computer including the one who generates it.

>>832705

It must stay disabled. Though IPFS.js doesn't have DHT implemented yet.

Why is the IRC dead?

Another way to mitigate spam in a fully distributed imageboard is to use monero's proof of work algorithm (Cryptonight) which was designed to run well on consumer hardware. But if the board is slow and since there would be no incentive to mine other than to append a post, the chain would be easily forked by attackers who seek to delete the latest blocks.

If being censorship resistant isn't a concern it's also possible to let everyone seed their own chain head.

>>830228

There's a bunch of changes written up here https://github.com/smugdev/smugboard/issues/4#issuecomment-347211683

>>833241

Nobody has any questions and there's only one dev.

When I go to

http://127.0.0.1:8080/ipns/client.smugchan.org/

It just says "Loading..." forever

Going to

http://127.0.0.1:8080/ipns/client.smugchan.org/#Qmf9QKURJVU53mzmysAFAR3mj48dLXqS2rNpq2o41EugcV/tech

Works fine though and loads almost instantly.

Is something wrong on my end or does the root handler not do anything on its own?

>>834747

The first address is the client, the second is the actual site. You have to give the client a site to read.

>>833327

> the chain would be easily forked by attackers who seek to delete the latest blocks

FOR THE &%##@$&#% TIME! BLOCKCHAINS ARE NOT MAGIC PIXIE DUST YOU RETARDS!!!

Blockchains can only work if all parties have an interest in all new transactions getting into the chain. For cryptocurrency, this holds----a currency is worthless if you can't transfer it. For message boards, this doesn't hold----shills want to censor your posts.

Interestingly, Git uses a blockchain-like structure for a repository, but without proof-of-work because making a commit is supposed to be easy. A Git repo can fork a thousand ways, but every fork provably came from a common parent commit.

>>835012

Did you even read what you quote? This has nothing to do about transactions. The idea is to have each block hold a single post with a proof of work relatively easy to compute.

>>835027

Yes, I did. Are you familiar with the term "transaction" as it's used in SQL? Each post is a transaction, adding that post to the thread.

In a cryptocurrency, multiple transfers are grouped into each block. Each block is a transaction that commits when a miner solves the proof of work.

In an imageboard, each block carries one post. The transaction commits when the poster solves the proof of work.

Blockchain transactions are not durable when the chain forks and a hostile actor can fork the chain from any past block. Cryptocurrencies address this attack by assuming that legitimate miners have more processing power than attackers and that no attacker can fork from N blocks ago and "catch up". This only works because miners are constantly seeking to add blocks for the mining reward. There is no mining reward in an imageboard----blocks are only added when a new post is made. Attackers can thus "undo" posts by forking the chain from the past----and there is no "catching up" to stop the attacker because the chain is static on a thread.

>>835515

This is correct. Imageboards would not work well as their own blockchain.

That doesn't mean that PoW is a bad idea to implement into an Imageboard as a spam-preventative measure.

There was a proposal like this I found on BitMessage that mentioned using PoW as Identity. Copying below if anyone is interested.

# DecentraNet

## Abstract

In the current year, most Chans are isolated and are not intended to interoperate with each other. Thus, the content being posted on one chan is easily censored and is not mirrored on any other Chan. The closest thing to a Decentralized Chan that we have is BitMessage. This, however, requires the user to install software and is also subject to spam attacks where an attacker with sufficient resources can flood a channel with irrelevent or even illegal content.

DecentraNet would aim to mitigate a few problems:

1. User-friendliness (through web-facing nodes)

2. Spam Attacks (through Pow as Identity)

3. Censorship (through distributed storage)

## Proof-Of-Work As Identity

Currently, BitMessage uses PoW in order to lower spam levels on the network. This is done on a per-post basis which means that in the event of a spam attack, it is almost impossible to block or identify the spammer. Provided the PoW is sufficient, the message is deemed valid.

DecentraNet would not rely on a PoW per message as the basis for mitigating spam, but would rely on PoW per Identity. This means that for each Identity created, there would be a large PoW involved. Messages posted would then have to be tied to an Identity, making it easier to filter out identities that users deem to be posting non-informative content. The Proof Of Work here would be determined by each node relaying the content (but would probably be quit large).

Obviously, this PoW is too much for the average user. However, it is not intended that all, or even most, users will run a node. Instead, we will rely on some nodes providing a web front-end that submits posts from the node's identity on behalf of the user. From a user point of view, the frontend would operate the same as Chans do today.

## Frontend Node

As an example, imagine we had the site decentralchan.org. Decentralchan.org looks the same as most Chan sites today. It also features a Captcha to mitigate spamming.

DecentralChan.org has taken the time (and processing) to generate an identity that allows it to post on the DecentralChan Network. When a post is made, DecentralChan.org proxies it through their identity and posts it onto the DecentraNet. The message posted will be in JSON format to allow for extensibility (fields like Tripcode, Name, Email, etc).

All other identities that post on DecentraNet will also show on DecentralChan.org - provided DecentralChan has not Blacklisted their identities. This allows optional censorship for the Node Operator. If an Identity is frequently posting illegal or insensible content, then that node can choose not to store or propagate its content.

A Node can also specify a data threshold on a particular identity so that if that identity posts too much within a set time period, all further posts are ignored.

## Attachments

Because the propsed format is JSON, the client can choose how they wish to attach files or view files. To keep data usage low on the network, it is recommended that IPFS is used for file attachments and the IPFS hash of the file given instead. This would prevent duplication on the network.

If this approach is taken, it is recommended that the Front-End Nodes host an IPFS Gateway that allows uploading and downloading. Other Front-End Nodes can then mirror this content.

## Others That Wish To Run A Node

Anyone is free to run a node and collect all data posted to the Network. In this way, it is intended that this network would be incredibly difficult to censor in all cases.

However, to post on the Network, a user MUST generate a valid identity.

## Possible Use Cases

This framework could be extended to the following Use Cases:

• Chans

• Twitter-Like services (through Twitter-like nodes. Node could post on behalf of user or users with sensitive information could generate their own identity, mitigating the trust issue.)

• Leaks-Like service (each media agency could monitor and mirror a "leaks" channel.)

• Offline Instant Messaging (a message cache-type channel - useful for services like Tox to replace independent Master-Nodes implementation. A user could choose a Front-End node to interface with for Offline Messaging - or could again generate their own identity if trust is an issue)

This is all just a proposal. All thoughts and contributions welcome.

Message me on BitMessage if you have any suggestions/contributions: BM-2cVoCYnYy8k5xrpRNS97YJKG4NB554F8Bq

>>835515

>and there is no "catching up" to stop the attacker because the chain is static on a thread.

The blockchain must be at the scale of a board, or even larger.

>Attackers can thus "undo" posts by forking the chain from the past

This is the issue I mentioned in my original post. There are certainly ways to get around it. For example, the block difficulty could be adjusted such as legitimate users spend more time mining thus focusing on quality instead of quantity. Or we could simply ask them to mine empty blocks for the sole purpose of securing the chain. Saying that it can't work because people don't want it to work is a fallacy. Adding to that if some posts were to be censored by a fork they will likely be reposted even more widely and frenetically by the community.

Anyway not all imageboards need to store sensitive political discussions. I would love just to be able to talk about anime without having my opinion controlled by whatever centralization.

>>835620

I think using a Blockchain is complicating things. What would a blockchain offer over something more dynamic?

Basically, what you'd be after in a chan is:

>decentralization

>uncensorable

>efficient

Blockchain solves 1 and 2, but not 3. A permanent history of everything ever chan'd isn't needed. Why not just a DHT with "channels" that have concensus rules? Similar to how BitMessage functions.

For example, on channel "/tech/", in order to post, you must generate a PoW of X difficulty - and for every post after, PoW adjusts depending on how frequently that user is posting.

Or a "bidding" PoW if that channel aims to maintain size (think Difficulty Adjustment Algorithm). During times of high traffic (shilling), a higher PoW is needed to actually post.

>>835652

Is it even possible for the network to adjust PoW difficulty without a blockchain? Since there would be no way to approximate each block real time as Bitcoin does. At least I can't see any. But yeah even if I agree we don't need to store everything forever, unlike cryptocurrencies where history matters, 4chan is nothing compared to what a truly distributed imageboard can become and I want to believe we should not give up to any kind of centralization.

>>835723

If the nodes run NTP, the nodes know the current time.

different approach

How about using a web of trust to establish identity? I know this requires real world friends (ideally), but PoW makes it too easy for adversaries. You can rent much, much larger compute resources for cheap than any normal user base would provide. PoW is a massive waste of resources and you'll have to create incentives to provide these resources, but at the same time posting should remain free (as in free beer). An automated WoT at the same time could also solve one of the usability problems of PGP, and solve spam and captchas on the Internet in general.

>but then I can only post using my real identity!

No, there are plenty of people with multiple identities who somewhat trust each other. E.g. if someone credibly proved to me that he's @SwiftOnSecurity, I'd gladly sign his key, even if he's not called Taylor Swift on his government ID.

>>836245

>admins have persistent identities

>posters have persistent identities

nice ""anonymous"" imageboard you got there, agent Fud.

>>836323

1. What's FUD about this? You know what FUD is, right?

2. Is it really that bad if you build one or more identities just for posting on chink cartoon forums? Also possible would be services which sell signatures on identities in return for PoW, such as bitcoin.

>>836378

that is, under very specific rules because otherwise they'll become distrusted by others. Such a rule may be that the identity does not have any name attached to it

>>835538

>Identities

>On an imageboard.

>>836521

Congratulations, you didn't get the problem.

>>834772

Oh I see.

If you are the dev would you consider adding functionality to the client that either links or redirect to a "default site" if whoever is hosting the client has one configured. I think something like that would be useful instead of just displaying the "Loading..." text that isn't actually loading anything, even if you choose against this, it should still probably return an error message saying to provide the site imo.

I think that would make things easier for users, you can just point them to your instance of the client and it will auto direct them to the default ipfs hash that's configure for that instance, instead of forcing them to specify the whole thing every time.

>>835538

>majority of users post to limited number of host nodes

>host nodes have local control over user's content

>can blacklist external nodes or specific external users on a host node basis

It sounds like you're describing what GNU Social and Mastodon currently do. That's one way of approaching it, but there are still flaws. Data persistence reverts back to the centralized model. Because each node also hosts the user's content, if it gets taken down then all history goes with it.

I can't emphasize enough the significance of authority. Decentralized imageboards will be build around a single agreed upon authority model. Depending on which model is used, the design will be completely different. Before solving the technical problem we must ask what exactly we want to accomplish structurally? We already agreed on user subscribed mod/user blacklists and/or whitelists for post moderation. The next question is what to do about board creation and owners. Who should bear the resource burden of hosting a new board? The collective network or the board creator/owner? Should we create a complete all-in-one package or a federation of separate boards? Do we want a limited or low barrier decentralized system in terms of authority? How about a distributed system?

Here are my ideas for limited decentralized systems. Excuse my shitty image but visualizations always help. I also have other ideas but I think this would work better in practice.

Trusted Crypto Hydra

Each node hosts a copy of the entire Imageboard Collective. This consists of every board in the Collective. Only text posts/metadata are stored as attached files are stored/served in IPFS. Users visit nodes, which host the Collective and provide a website front end. The database of boards are append only link lists. Nodes synchronize new posts by adding to the linked list. Nodes also synchronize past additions with each other automatically. Anyone can freely make a read-only node and download a local copy of the Collective. Yes, the database is a blockchain but instead of PoW (Proof of Work) nodes use PoS (Proof of Stake) to post. This works by locking in and wagering cryptocoins instead of using computing power to mine. The more coins you stake the more "hash power" you have and the higher percent you have at mining a block. Nodes that try to take over the network get punished by having their staked coins taken from them.

This is where it gets interesting. I figured why not make a web of trust using cryptocoins? Initially there will be three nodes created to bootstrap the network. These original nodes would start off with a certain amounts of coins, say 100 each. There would be consensus rules saying a node can mine only when it has a certain amount of coins, say 60, as well as have had at least three deposits from unique addresses (the first three are an exception). A cap of 20 coins per transaction would ensure all new nodes have to have the approval of at least three other nodes. The block reward could be fixed or dynamic in order to control the amount of possible new nodes. Other constraints could also be included like not allowing any single node's coins to be more then 50% of the total supply or total staked. The nodes could even vote to make consensus changes like block reward changes, node blacklists, or block size changes (block size can help minimize spam floods by limiting the max posts/sec). The blockchain would only consist of text/metadata since attachments would be stored/served by IPFS. In this model there are no board owners, only board creators. It should be decided whether it can be either be done for free by users or at a small cost ,like 1 coin, to mining node operators. The coin would be burned aka taken out of circulation.

Mods are really just users that maintain blacklists/whitelists that other users subscribe that hides/enables posts in threads/boards. Node operators can take advantage of this by creating a node-wide blacklist of sketchy IPFS hashes (the blacklist shows the blocked hashes, it just doesn't serve them). Spam prevention is done on the node level via captchas and such. Haven't thought of a way to do it better yet. As a general idea for the storage size, assuming an average of 1KB of text per post, 8chan would be using about 60GB for all posts (excluding attachments) on all 16,519 boards if no thread were ever deleted. Not too bad for 4 years of shitposting. Note that not all nodes have to be "archive" nodes, though they help a lot. Full nodes can implement block pruning to save storage space.

Liberated Crypto Federation

This model is very similar to the first. The difference is that instead of the Imageboard Collective being one huge monolithic blob, each board is broken up into its own blockchain. Board creators and also the primary node operators. They can decide for themselves how they want to run their board's nodes. They can follow the best practices I explained in the first model or throw it all out and implement their own consensus rules. Blacklists/whitelists could still work across boards. Website front ends would have one node per supported board in their back end.

I like my first one better. What about you?

>>836690

>Liberated Crypto Federation

My preference is this one. There'd be certain boards that some nodes do not (reasonably) wish to host.

I still don't know about the cryptocoin aspect. I sympathize with the problems you've cited with PoW - it's still very easy for a malicious party to overwhelm this. This is actually one aspect of:

>>835538

... that I like, in that it is expensive to generate an identity (let's say, several hours on standard PC) and then if a single identity is shitposting excessively, other nodes can choose to blacklist them (either temporarily - until spam attack is over - or permanently if it's a CIANigz identity). It also allows for other spam-mitigation controls whereby a per-post PoW can be initiated depending upon how many posts that identity is making per hour.

(Note that proposal states that most users will not generate an identity, but have a third-party identity - a web-facing chan - post on their behalf).

There was actually a bit more to this that I saved somewhere regarding a "DISAVOW" message:

>This is why identities are expensive to generate. Basically, if an identity becomes notorious for posting illegal content, nodes can choose to blacklist and/or stop propagating content from that identity. This makes moderation far easier and makes it very expensive for an attacker to spam the network.

If a Web Fronted Node (e.g. a www.chan.com) happens to have a user that posts illegal content through their Frontend, they should be able to post a "disavow" message to the network signifying that this message should be deleted. It is, however, the decision of the other Nodes as to whether they abide by this.

The advantage this would have over BitMessage is that, once an identity is generated, sending messages to the Network are basically instantaneous. Hardcore privacy people can generate their own identity to post, while normies can just use a Web Front-Ended Node that posts on their behalf (using that Node's identity - for services like a Twitter clone, the username, etc, can be stored in a JSON field in the message content itself).

And anyone is free to "listen" with their own Node (Identity is only needed for posting), so they can still receive any content from an Identity that another Node might have blacklisted (PoW required is also tweakable, so they can lower this if desired).

>>836709

>There'd be certain boards that some nodes do not (reasonably) wish to host

I suppose, but they could be only hosting text-only boards since node operators can blacklist hosting IPFS content for entire boards.

>I still don't know about the cryptocoin aspect

The coins represent a scarce form of trust in the node's web of trust. The more coins a node has, the more trustworthy it is. You are required to obtain a minimum amount of trust from at least three other nodes in order to join the network (have your node be able to post). By trusting someone else's node into the network you decrease your own node's coins, enacting a short term penalty and limiting the amount of nodes you can add. This encourages adding trustworthy new nodes by penalizing those who trust. In the beginning there would be a handful of nodes but as time goes on it will become increasingly easier to join since the web of trust grows with each new node.

It's also easy to block bad nodes using the blockchain. Good nodes just have to reject adding transactions coming from bad nodes. Assuming the vast majority of nodes are good, there should be little impact bad nodes can cause. Nodes could even vote to revoke the coins of a bad node, removing it from the network. A lot of trust issues can be solved using cryptocoins as a token of social value.

>it is expensive to generate an identity (let's say, several hours on standard PC) and then if a single identity is shitposting excessively, other nodes can choose to blacklist them

That's assuming people don't abuse the PoW penalty of creating a new node. In reality PoW will never work as a form of deterrent or cost. An Amazon EC2 P2 instance has has 16 GPUs, 64 CPU cores, and 732GB of RAM and costs $14.40/hour. What's stopping me from renting it for an hour or two and creating hundreds if not thousands of new PoW identities that will be trusted on first contact? The solution you're describing will just lead to a whack-a-mole situation.

Instead of using PoW on the node level it might be somewhat useful on the user level. Maybe a minimum of one PoW public key identity per thread? That way node operators and mods can more easily blacklist spammers (I'm assuming this is in a post-IP-address world aka i2p or tor). I don't think normal users would mind that much and would increase the barrier of entry a bit, which in my mind is a good thing.

>>836972

>I suppose, but they could be only hosting text-only boards since node operators can blacklist hosting IPFS content for entire boards.

It's still not all that safe. Base64 encoded images as can be done on BitMessage, etc.

>The coins represent a scarce form of trust in the node's web of trust.

I'm still not sold on the coin angle. It's too easy to monopolize.

>What's stopping me from renting it for an hour or two and creating hundreds if not thousands of new PoW identities that will be trusted on first contact?

This is why PoW as Identity might work. Set the PoW VERY high (I would actually advocate it being set on a "per channel" basis) and it becomes quite expensive and is easy for others to spam-filter - just block that identity. The problem that I do foresee with this approach is that Identities could be generated in advance - leading to sit-and-hit attacks whereby as soon as someone posts something sensitive, spam-attacks go into full effect.

BitMessage blocks against this by having the PoW hash on the current timestamp and offers a window for that PoW to be valid.

Was messaging the guy about this a while ago, but only have bits and pieces left. Here's one on his description of how the channels might be defined (comments are mine)

Channel { name: '/tech/', powAlgorithm: 'sha256', powInitialAllow: 1000000, // PoW for valid identity? powPerPost: 0, powPerExcessivePost: 3, // This would have to obviously be scoped out better, but basically a rate-limiter per identity? keyspaceType: 'fixed', // I'm assuming this is for DHT storage of the chan's contents? keyspaceSegments: 32, // I'm assuming this is the number of segments the DHT is split into for "fixed" mode? Why not use dynamic?}

>The channel identifier could be a hash of the object above.

>>838277

>It's too easy to monopolize

The people running nodes want the network to grow, otherwise they wouldn't be donating their resources towards it.

Needless to say, my model is pretty complex and would take quite a bit of time to make (I sure as hell don't have the time to make it). Your model is much easier to achieve in the real world (just fork BitMessage) so I've changed my mind and would like to offer a few thoughts.

>Set the PoW VERY high

I agree the node-level PoW needs to be high, but it can't be too high as to price out random users who want to join the network themselves. I'm thinking something like having a target PoW cost of $30 (two hours of an Amazon EC2 P2 instance).

>I would actually advocate it being set on a "per channel" basis

From what I understand a BitMessage "channel" is analogous to an imageboard thread. Users would have to spend money to join each new thread then. How would you sub-partition the channel (/tech/) into threads (IPFS, Libbie, ThinkPad, Linux, etc.)? We need two tiers of message signing, board level and thread (channel) level.

According to their wiki a BitMessage channel is just a shared deterministic address. Individual users can sign shared messages with their own unique address so users blacklist messages from the bare shared address to reduce spam. Why not also require the messages be signed by a board node? The board node would be required to have the one-time large PoW address while users would have to generate cheap (2 minute PoW good for 3 posts within 1 hour) temporary addresses. It would discourage low effort spammers.

Node operators could choose to blacklist signing unwanted threads. Bad nodes could also be blocked. Ideally one node's PoW identity would be good for one board, though there would be no way of enforcing that. This would be to completely segregate one board from another. Each board would be like its own blockchain. This is because all message history is permanent in BitMessage. They would list all supported threads in their web interface.

Would this be possible?

Wikipedia says every network participant attempts decryption of every message passing through the network even if the message was not originally intended for that network participant. Can you explain the data structure of BitMessage? It it a blockchain or a DHT or something else? Do users have to download the whole network's history to catch up?

>>839023

> data structure of BitMessage

BitMessage is essentially Bitcoin's transaction pool adapted for transferring messages.

There is no permanent storage and messages "age out" of the network after two days.

>>839023

>From what I understand a BitMessage "channel" is analogous to an imageboard thread

I downloaded BitMessage for myself and it looks like it's the opposite of what I thought. Channels are equal to imageboard boards. They have message threads which are equal to regular threads. Also my user-level PoW would only work on the node level if the current BitMessage client was used. It might still be useful since the vast majority of users are going to use third party nodes. I don't know how people feel about this, but how about having users mine Monero in their browsers for 30-60 seconds to post? The small profit would go to the node operator to help compensate for the hosting bill.

>>838277

Now that I understand BitMessage more I think I get what you're saying. With some community standards this could be achieved with upstream BitMessage and a web node/client. First have a node add a channel (board), then create a whitelist with a regular expression that accepts addresses only with the agreed upon PoW difficulty in the form of address customization. Each channel could have a different address requirement, like 10 leading zeros, a repeating pattern for 10 characters, or having the address include a phrase of 10 characters. The web front end would look like a regular imageboard. The new thread and reply form would have the standard Name, Email, Subject, Comment, and Files fields. The web back end would upload the files into IPFS and return the hashes. An additional Number field with a global channel post number incrementer would be added along with a small salted hash of the user's IP address (these would help moderation. Tor/i2p posters would show an IP of all zeros just like here). All fields would convert to a JSON object. This would be the actual message that would be broadcast to channel threads. Other nodes would parse new messages and update their front ends to reflect new posts. Anybody can made a read-only node to help contribute back to the network.

All that needs to be made is a GPU accelerated BitMessage address generator and the web front/back end.

>>839041

When I added the channel "general" BitMessage downloaded over 600 threads. Does it keep all previous threads or just active ones?

>>839596

>I don't know how people feel about this, but how about having users mine Monero in their browsers for 30-60 seconds to post? The small profit would go to the node operator to help compensate for the hosting bill.

Personally, I think this is a good idea. It could even be on a "rolling" basis - by that I mean, the miner runs when a user has less than X number of PoW's generated (e.g. "You have generated a PoW for 3 posts"... make one post and the miner runs again to get back to 3). Spam-preventative and hosting bill - as you mentioned.

>Now that I understand BitMessage more I think I get what you're saying.

I agree with pretty much everything you've written there.

>All that needs to be made is a GPU accelerated BitMessage address generator and the web front/back end.

I haven't looked into how addresses are generated yet. Still need to do this.

>When I added the channel "general" BitMessage downloaded over 600 threads. Does it keep all previous threads or just active ones?

BitMessage operates on PoW per post. The degree of PoW determines how long a post "lives" for, I believe.

In general though, PoW per post does not work well. It's easy/cheap to launch a spam-attack and this is exactly what happened last year during DAK. Hence why I'm suggesting PoW per-identity (and then possibly an additional PoW per post if the channel desires it).

I know Peter Surda was aiming to make newer versions of BM more modular. I might take a look into the code later this week and see how hard it would be to implement something like this.

>>831061

>>831226

finally figured it out, decentraleyes was causing the problem

>>835538

>>836690

You're overthinking it. Blockchain imageboard can work and the reason is: altruism. I think people are more willing to mine for their community rather than mine Monero for some random stranger. Especially if the miner isn't a resource hog and uses a limited amount of CPU (~50%).

I like the idea of using a single blockchain better because it fits the spirit of imageboard where every post is treated equally and there is an intrinsic sense of unity. Using Proof of Stake instead of PoW would be a huge benefit but if it means tradeable cryptocoins it's too easy to abuse for corporates.

Also someone already made the cryptonight hash function working in asm.js:

https://github.com/noahdesu/xmonarch

>>785359

>muh you have the burden of proof

You fucking fedora faggot. It doesn't matter who claims first as long as you are talking shit out of your ass. If you are talking bullshit, you prove your claims. Faggot.

>>840342

>You're overthinking it. Blockchain imageboard can work and the reason is: altruism.

IMO, this is a bad model to work on. Economic incentivization (e.g. Monero Captcha) mitigates the risk of corruption later.

There's also the other problem mentioned earlier: Blockchain immutability which means if (((they))) want to shut it down, they only have to spam the chain with illegal content (they did this in the DAK bunkers and I've seen it in other threads where there was very damaging research being done).

There's no need for a Blockchain. The perks of a Blockchain are not needed for this kind of project.

Also, the accumulation of capital (coins) presents a risk whereby they can accumulate coin and then spam heavily when a sensitive subject comes up. What's needed is a method of moderation, hence the proposal for a EXPENSIVE PoW per Identity. This allows blacklisting.

That said, I'm not dismissing the possibility of a Blockchain-type solution, I just don't think it's needed in this case. If you have rebuttals to the above, I am open to it.

On a side note, anyone want to actually start working on something of this sort? I should have some time over the Christmas period to delve into the working of BItMessage and might be able to whip up a POC for PoW as Identity.

>>842123

I'd like to add something else here actually.

>>835538

If you read this, we could turn this into a decentralized store of sorts which could implement Masternode-like functionality for other services (e.g. Tox).

Other services (e.g. DMS triggering) could also be implemented. I believe this is why this proposal gave JSON as the format - so this service is not limited to just chans. It's generic.

>>785171

It took me a long time to get it set up, now I can access the site and go to different boards, but cannot see any threads or make any new threads, what is the problem?

>>845928

I was messing with the server and forgot to restart smugchan. The only reason you were able to load anything at all was some parts of the site apparently happened to still be active in some anon's local IPFS daemon. Go ahead and try that again.

>>840342

DAGs don't inherently have the problem you describe, the only issue that can happen is if you have a sharded DAG where a shard isn't well-connected to yours so you have a chunk of missing posts. But then, none of the posts you see will refer to any of the missing posts, by definition. Also not all DAG solutions need/use sharding. Check out hashgraph for example, but it's the case even with iota (there is one "true" DAG, people can shard off it but the authoritative nodes maintain the entire network, thus you have one consistent DAG at all time even though non-authoritative nodes only know about a fraction of the network).

>>842123

PoW as a spam fighter is a great idea and one of the only things I could think of that would serve an anonymous imageboard effectively. Wouldn't long-term PoW-generated identities allow the mods/admin to link posts made over something like tor together though? How can it be improved while still allowing for "banning"?

Further, how would this stand up (or not) to a dedicated and well-funded adversary? Once we have our Promised Chan I bet (((they))) will be quite willing to throw a couple hundred thousand at an AWS cluster generating identities for them to shit our discussions up with.

>>851483

>Wouldn't long-term PoW-generated identities allow the mods/admin to link posts made over something like tor together though? How can it be improved while still allowing for "banning"?

Well, I think the idea there was that the PoW-generated Identities weren't necessarily used by a single user. More likely than not, there'd be web-facing chans that generate the necessary "Identity PoW" and then post on behalf of the users. But the option of a user generating their own PoW-Identity is there for those that want it.

>Further, how would this stand up (or not) to a dedicated and well-funded adversary?

I don't think it could be done perfectly. However, if we took a board like /pol/ that's incredibly popular and set the PoW for that particular channel very high (let's say something like 12hrs to generate the PoW on standard PC), it would, at least be very expensive for them. It would only take one overt shill-post for fellow nodes to blacklist that PoW-Identity, wasting X amount of hours of computing time.

Probably want to have a "comment" or something when a new PoW-Identity announces itself though so that web-fronting nodes can identify themselves. This would be needed so that other nodes are more forgiving when these identities shitpost.

I imagine other channels would also get established that require a weaker PoW, and unless (((they))) were explicitly invited (given the address, etc) they wouldn't be able to shit those up easily.

At the very least all of this would give us far more censor-resistant chans.

>>851488

> the very least all of this would give us far more censor-resistant chans.

Baby steps I guess. We do need to solve this spam/Sybil problem though, it's messing with our ability to have discourse.

>>851491

I don't know if there's a solution to it tbh fam.

The future of chan research might be fairly splintered - small anon groups forming their own channels with partial membership spanning between these channels. Information gathered then consolidates back to main channels like /pol/.

I think we are at the point where partial compartmentalisation might be necessary. Chans are getting gamed hard now and, given the effect we've had the past few years, I imagine (((they've))) been stepping up their shill engines to combat it.

>>851483

>Once we have our Promised Chan I bet (((they))) will be quite willing to throw a couple hundred thousand at an AWS cluster generating identities for them to shit our discussions up with.

At least they'd be easily filterable. Just blacklist that identity. As a BitMessage user, PoW per post doesn't work because spamming is easy and you have to delete every post one-by-one.

>>851483

How about using AI moderation to form threads, not by user declaration, but by actual topical relevance? Going off-topic spawns a new thread. Can't shill.

>>852006

I imagine this would be too easy to game - particularly if it's open source.

Also, it might detract from actual quality shitposting.

I honestly think that the best we can do is make shilling expensive and easy to filter. Any kind of AI moderation should be on the client-side. Like a scoring system or something.

>>852080

Correction: distributed AI moderation. All nodes see all posts, but posts are sorted into threads client-side. Don't want shitposting? Shitposts branch the thread. Shills branch the thread. Just adjust the relevance threshold until you see the productive conversation. Spam is filtered by its sheer bulk.

forgive me for this shitpost, but when will this be rewritten for WebAssembly-capable browsers?

>>852080

>make shilling expensive

10bux?

Is progress being made?

>>863616

Progress on this is directly proportional to the chance that 8chan goes down in the next couple days. The dev is busy watching anime the rest of the time.

bump

>>863649

This is accurate. Incidentally, my favorite show this season is Sora Yori, it's something special. Progress isn't at a complete standstill though, I actually got the in-browser server system totally working recently. The only thing left there is the UI, which is currently stalled because I hate writing UIs. It'll get done eventually, though psychologically the main killer right now is that js-ipfs isn't ready yet and I don't feel a major desire to push ahead when the project is still fundamentally uncompletable. If 8ch was about to go down I'd go all-out on it again though, so probably your best bet for immediate, substantial progress is to try taking down 8ch.

Keeping this thread alive

>>785366

>>I imagine we all use VPNs when torrenting, right? And also all the time as a general rule.

No, and no. Giving your data to some VPN provider doesn't help much, except in some cases, and then I would rather use TOR or JAP.

>>840342

>Blockchain imageboard can work

hahaha

>>787525

>freenet

What if you don't want your computer to be used to serve CP?

>Distributed imageboard

>When someone posts CP, suddenly everyone is hosting it

>Everyone on the board exposes their IP to everyone else

Sounds like an idea cooked up by a cianigger to pad his performance statistics.

>>882576

Its controlled opposition, ignore it

What's the progress on this?

>>887480

We're making the logo.

>>887480

See >>863779

bump

Don't let one of the few good threads die.

>>785350

>he doesn't know that a fence is a firewall

>security through hiding your ip

retard