One feature of some Reddit subs that I've seen to be very valuable is programmable automoderation. Are there any plans, or existing ideas for SN to add this kind of feature for territory owners?
Example use case:
  • add customizable territory-specific post types/labels replacing "link" or "discussion" such as News/Meme/Social Media/Shitpost
  • require a citation link in the post for particular labels such as News, or have your post auto-removed
  • check for a previously posted meme with an identical image or repeated links to the same social media post
One way to achieve this is to add a sandboxed scripting language like Lua with hooks that are called when events occur, like a new post being created. Assuming code executes server-side, there would need to be hard limits on script memory usage, allowable CPU time and, access.
The other option would be to create a REST API for automod code running elsewhere for SN hooks to call when events occur. This has the advantage of allowing any language and relaxing concerns of server load, but has some security implications to consider.
check for a previously posted meme with an identical image or repeated links to the same social media post
I like this one. If there are duplicates, there could be a possibility of reposting them with shared rewards.
reply
147 sats \ 1 reply \ @k00b 6 Mar
Rather than copying the way reddit does everything (which is useful to study), I prefer looking at all the problem cases that exist in SN's context and finding a solution that fits SN best. I don't like moderation in reddit's sense of the word but I do understand the problem it's trying to solve. tldr I want us to have better solutions.
reply
I will admit that coupling the sorting order partly to zap quantity already takes care of most of the purpose of moderation. A sea of bots up-zapping posts is going to spend a significant amount for questionable reward.
reply
5 sats \ 2 replies \ @ek 6 Mar
The other option would be to create a REST API for automod code running elsewhere for SN hooks to call when events occur.
@jeff mentioned webhooks in the past, too and I never mentioned that I am not a fan of webhooks. The place I worked before did exactly this (allow customers to configure the product to their needs). It worked but it was definitely not great. A lot of support tickets where the customer complained about something not working and in most cases, it's because the endpoint they configured did not respond fast enough, in the wrong format or not at all. We basically had to debug their webhooks.
I know that only 20% will make 80% of the problems so it would probably work fine for the majority of cases but I would like to avoid the 80% of problems, too. I think just giving better API access is the better way. No webhooks or any code we run for you (huge security nightmare) but you just query the data whenever you want and then do API calls whenever you want.
reply
105 sats \ 1 reply \ @hodlme OP 6 Mar
Yes, having an API on the SN side may be a less of a reach. As a compromise between hooks and a server API, there could be an empty-payload "something changed, do stuff if you want" style of notification like Signal uses. Without a change notification, the remote side needs to poll.
reply
15 sats \ 0 replies \ @ek 6 Mar
there could be an empty-payload "something changed, do stuff if you want" style of notification like Signal uses. Without a change notification, the remote side needs to poll.
That makes sense, very good point! We will consider it. Maybe we will do something like long polling just because I liked working with it when I used the TG API.
I'm definitely a fan of not having to poll for stuff (even though it's more complex and can be more demanding of resources) and want things to be as real time as possible and reasonable.
reply
stackers have outlawed this. turn on wild west mode in your /settings to see outlawed content.