>>992
I want to get away from MongoDB due to its licensing change to be a non-free project (The SSPL puts limit on paid distribution of source code along with requiring that everyone gets source code, not just who you're distributing to), so I wouldn't mind if there was a way to convert.
I do wonder how accounts will work with this, will this go to a public-private key-based system? How will permissions really work?
>I'm curious about how the CP solution is going to be.
currently, content uploaded to the server will be submitted to a local-network only, server-side HTTP daemon that checks if the content is CP or not. It then returns JSON to the requester detailing its findings, that the server will then use for whatever it needs to (such as making NCMEC reports, blocking posts, etc.)
I think that something akin to this could be set up client side too for receiving posts. Check if each post constitutes CP or not locally, if it does, do not host it, do not download it, do not view it. Just block the post locally, so the only person hosting CP is the actual CP spammer. Perhaps even make a NCMEC report if the user opts-into allowing that to happen.
CSAM-Buster is going to be decentralized for hash distribution, so anyone can get their hands on a hash dataset by subscribing to another user's hash postings. However, this system is going to have a web-of-trust system built into it, where a trusted authority will deem certain hash databases as valid or invalid. On a web-server level, this isn't that bad, webmasters just subscribe to trusted hash providers. However, once this is decentralized, Subscribing to hash providers will get more difficult as people will have too many options, and the information will be much more fragmented.
I guess there is a hacky solution in just having the peerchans developers outright deem certain people trusted (i.e, automatically subscribing the user to kiwifarms, jakparty.soy, and soyjak.parts hashes for instance), but even that may be a bit fucky long-term as it gives way too much trust for content viewing and blocking to those individuals.
>As jschan itself is designed to be noscript compatible and some people might not want to run an in-browser node as they browse and turn it off, it should have fallback behavior to allow you to get the file normally over http.
Perhaps you could split the server and client up a bit more? Jakparty.soy could simply be a HTTP wrapper around this decentralized system when a user is not using JS. That way, we only operate as a mediator.
Either that, or outright abandon non-JS users and instruct them to either use the stand-alone client or enable JS to use the site.