This is something I've been trying to get a decentralized social media site to implement since the original idea for Hivemind. Presumably you will implement these in custom_json?
I encourage you to add operations for both adding and removing either usernames or specific permlinks.
Distributed, opt-in moderation without gatekeeping is the goal. Nobody wants censorship, and nobody wants an unmoderated site. This allows individual end users to choose how much moderation, and by whom, they want.
Yes, they will be implemented in custom json. Likely it will just be a minor tweak to the existing call for following/unfollowing and muting/unmuting.
Initially we're just replacing existing centralized lists of account names since we take a performance hit from the current implementation and the change is relatively easy, but we'll certainly look at adding more features later for opt-in moderation.
This isn't really related to this proposal, but do you have plans for an overhaul of the witness structure so we don't see similar things happen again? For example, could we move from 20 consensus witnesses to something larger, like say 100? Or if not, could we change witnesses votes from 30 to say 5 (or even 1 but with a slider to adjust voting power in order to vote for more witnesses). These changes seemed to be on every's tongue during the height of the hf, but have since seemed to have been forgotten about, at least publicly. I'd love to hear your plans/thoughts on improvements there. Thanks.
I don't think they've been forgotten, just people are busy with a lot of things.
My personal view is that the best way to stop a voting attack like the one that happened prior to Hive is the new voting delay feature. Most of the other suggested changes probably couldn't have stopped it, which is why I came up with the voting delay idea to begin with.
I'm not saying the voting delay defense mechanism is perfect either: it wouldn't stop a truly careful and patient attacker, but I think it will stop future attacks from likely real world scenarios.
But beyond voting attacks, there's other potential arguments for increasing the numbers of witnesses, assuming that witnesses are distinct individuals and not sockpuppets. But there's also arguments against that same idea. Both sides of the argument boil down to more witnesses means harder to get consensus on any action to change the blockchain's functioning. So more witnesses will generally mean more likelihood of status quo (for good or ill). There's also additional costs associated with running more witnesses, but this may well be a lesser concern.
Most of the other suggested changes probably couldn't have stopped it
Changing from 30 votes down to 5 votes (or 1 vote with a slider) wouldn't have stopped it? My napkin math looks like it would have, but I haven't double checked it yet.
And harder to get consensus is probably a good thing at this point as most people are fearful of investing in projects like this one due to the possibility of funds being frozen. The harder to reach consensus on something like that, the safer those funds become.
And sure there are pros and cons to everything, but I do think we need more changes than just a voting delay and we need to make them sooner rather than later.