Are you working on your language and compiler recently?

>>21a957be been thinking about making a mini language for fun, although I haven't started.

I've never written a language before, what kind of features do you want it to have? Someone on soyjak.party's /t/ board was also working on their own language/compiler, but the board got nuked with all the administrative changes. I wonder how that's going.

>>60c321a4 i find low level stuff really fun, I haven't really thought about it much tbh, I just want to experiment with alternative syntax nothing too crazy. damn that sounds interesting I wish I knew about it before the purge, I dont get too invested in altchans because of that it's sad to say the least.

>>a18d52e5

>because of that it's sad to say the least.

Yea, that's one of the motivations for this project, to allow users to control the access to the data that they want to see, rather than letting outside forces and jannies and whoever else decide what you do or don't get to see. In fact a lot of posts detailing the early development of gladden itself got deleted from jakparty.soy because the admin mass deleted all my posts when banning me lol. Still it's a relaitvely chill site but that kind of stuff is annoying.

>>a18d52e5 I don't know much about low level stuff but compilation and compiler optimization is always really interesting from what I've learned so far.

malware

In russian internet, when smallboard matures to like 800 posts per hour, it gets mysteriously shut down. So I hope for p2p to be the final answer and ethernal schizoadmin-resistant destination. I (personally) think the most important thing is example of auto-moderation daemon\'new post received "event listener"' so people could build and finetune their own AI-moderation systems, releasing clientIDs before wipes happen and not after that. It would require to go to 3rd party resource and find moderation clientID there, if you're not ready before wipe. Which not everyone could do. I had to go to lambda to find repo address last time lol.

>>aaa2d7fc what kind?

>>953a5250 evilproxy\modlishka-like reverse proxy phish, MAAS ok I guess I lied, people don't see that as "malware" as it's not run in user's system but it also needs to avoid AV detects, bypass WAF, reverse-engineer frontend scripts, spoof TLS fingerprint and so on

tfw no blackhat board added expect all services to be a scam

>>f5a59dfe

>I (personally) think the most important thing is example of auto-moderation daemon\'new post received "event listener"' so people could build and finetune their own AI-moderation systems, releasing clientIDs before wipes happen and not after that.

Yeah that would be good. I was originally focusing more on handling spam detection at the post validation step, but then you don't really get the benefits of subscribing to another moderator as the deletion event wouldn't even occur or be broadcast, and each peer would have to perform the validation check locally, leading to redundant calculation. And using the event listener approach we can also hook that up to the "unread post" alert thing. But right now, the "new post" validation logic is gone through every time you reboot. https://github.com/dao-xyz/peerbit/pull/287 This update to peerbit allows saving the index state to disc, which might make the event listener concept work more nicely as posts won't be re-checked after rebooting. (I'm also hoping this will greatly improve speed on rebooting the client) Another thing to do is allow as many config settings as possible to be changed while the node is running rather than loading them once on boot, as booting is the most unstable and slow step right now.

>>f5a59dfe Another user also suggested pinning threads, which could make existing threads somewhat immune to wiping. It could even be automatic like if you open or a reply to a thread it gets given a "sticky level" of 1 (and you can assign multiple sticky priorities like jschan), so if someone is going to spam 1000 threads and wipe the catalog, only those new threads will be wiping themselves rather than threads you took an interest in. Wouldn't solve everything (new threads could be prevented from being seen) but could be one line of defense. And maybe instead of being sticky at the top they would just be given some type of immune to the pruning mechanism.

I think before doing pruning there should be more of an 'analytics dashboard' type thing on the homepage that shows all the boards you're watching and then various things about them like:

>replication factor (for each posts, file references, and file chunks) >whether the board is loaded properly (reload button if something went wrong) >something showing how many posts, files, etc. >'orphaned files' counter for files that no longer have a post referencing them

This kind of stuff would be useful before pruning so we can see what is actually happening more easily And probably we can just have manual pruning at first like "prune all but the most recently bumped N threads" button and "prune orphaned files" button, instead of having it automatic to start as thats the former is less exploitable by spam wiping Also looking into the event listener thing

>>f5a59dfe For the event listener, it should probably emit the event like (new post added with hash 484adcb33828.., by client 373737ddabc...,) into a socket.io type thing rather than just the node.js application itself right? That way the spam detection system can be a different program rather than having to be integrated into the node.js server itself. Or let me know if you have a different idea of how it should work.

>>a21bbfb1 Like what program? Everything has APIs and can be accessed from node script

>>f6b7509d For it to be fully modular like say you want to have an AI spamchecking program written in python. Instead of editing the main node.js code you can have your AI python daemon running on the same machine. When a new post is processed in the gladden client, it would emit an event on a given port eg. 8600. Then the AI python daemon would be listening to port 8600 and check the post contents, if it's spam it sends a delete command via the http API gladden express server has (/function/deletepost/..). Otherwise you have to edit the main gladden code itself and would be restricted to doing it in node.js.

>>77752af4 But we can also do both like using the internal node.js event handler and then also have it emit to a socket for optional use there.

>>e30e01f9 >>77752af4 I was thinking that we can have .js modules to modify gladden which will load on start and can listen to event(s) and maybe modify default behavior, preprocess content etc. This would allow to create "overlay" forums on top of boards and other cool stuff, like various encryption schemes where posts are publicly seen encrypted. Well maybe userscripts can do all that too, without gladden modules. But yes, AI things are in python so better have language-agnostic solution

>>c8508a15 That would be cool and fit into the plugins thing as well. I'm curious what you mean about the overlay forums. Like what?

>>a93c83a1 Basically using gladden codebase to build something on top of it with modified frontend and threads\messages used under the hood as communication channels. P2P videohosting (with real p2p this time, not federated), or p2p market with accounts and reputation system for vendors + search DMs etc. Both of those ideas could be executed even at current state of gladden, but imageboard frontend limits adoption significantly. Sure people could just use peerbit, but gladden looks like nice barebone for anything that involves p2p public communication, especially with ai-mod integrations

>>cfff7791 Very nice. Yeah that would be really cool. One early aspect of this could be a direct messenger type application where someone posts with their static clientId (instead of the random one used for posting), and then another user can send them a direct encrypted message. Also it would be cool if you could start a torrent easily from within the gladden client for very large files.

I should figure out how to set up a module/plugin system allowing for easy installation.

>>b36bd3ca

>One early aspect of this could be a direct messenger type application where someone posts with their static clientId (instead of the random one used for posting), and then another user can send them a direct encrypted message.

Well there's a lot of such projects already it seems