Can clients have default whitelisting vs blacklisting setups, please?
Discussion
Blacklisting would be "Everyone can interact unless you actively mute or restrict them."
Whitelisting would be "Everyone you actively invite or allow can interact."
Most people probably want something in the middle, but it's easier to start of with whitelisting and loosen controls.
I was thinking about the same for phone calls. I wish there would be a way to filter calls. Is on whistlist (phone contact list) -> ring, is not on whistlist, ask for a PIN code (I could give togheter with my phone on a business card or in an email, it can be valid for single use, multiple use, valid for a period only,...), blacklist -> redirect to the local police station or a sex shop whatever 🤣
A whitelist model would be like:
DMs over inbox or limited to follows/WoT.
Replies from inbox or limited to follows/WoT.
Feed default set to "All Follows" not "Global".
Mark npub pics with NIP-05 validity.
Mutes and report functionality.
Thread muting.
Private mutes (quiet mode).
Full relay management.
Etc.
So, the default action would be "do not display", with the option to display.
This is a very interesting idea.
Now the reality would be, all these bots and bad actors would still be interacting with you, but you just wouldn't see it by default. Only if you actively add them to your whitelist.
It may be the most free-speech friendly way of dealing with the issue that I have seen presented so far.
As a father of three daughters, I would love to see this idea built.
Discovering who to follow would become even more important under this scheme, though. Maybe we need a recommended follows function that uses WoT to help discover people you might want to add to your whitelist.
It also helps make stalking and harrassing less interesting because you don't see it and react.
And we already have private groups and stuff, if you want more privacy.
Yes, the assholes are after the reaction, for sure. Deny them that and they crawl back into their sad and lonely corner they have made for themselves.
I think the way Coracle has implemented WoT can solve a large portion of the issue already and should be adopted by more clients, but your idea would further improve it, especially if WoT is not "show anyone above this score by default" but more of a recommendation engine, where the user still needs to make the decision about whether they want to add them to the whitelist.
Yes, they can still write, but you remain oblivious and your followers probably don't see them, either, or quickly mute them.
this discussion makes me think of something too... so, i already have a simple size-related caching strategy implemented, it runs on a timer and trims down the database when it gets to a certain size and trims it back to a second size (high and low water marks)
it might be an interesting addition to the cache prune heuristic to selectively prefer to remove entries that have few inbound references, ie, the less engagement, AND the more stale (last accessed timestamp) combined would be a good heuristic for pruning not just stale events but irrelevant events, which are going to largely be botfarms
it would require a second ticker for doing inbound reference counting and adding a new index that keeps track of this so when the GC runs it only has to check the inbound count index alongside the most recent access time
i am up to a stage of optimization with replicatr... this could well be very useful thoughts for future reference
made some notes about this and another optimization i have got in mind after this chatter
https://github.com/Hubmakerlabs/replicatr/issues/38
https://github.com/Hubmakerlabs/replicatr/issues/39
#nostr is so awesome for free-wheeling discussions about nostr engineering