free listening roadmap

This is my map for the moderation features that I think we can successfully implement in the rough order of complexity (in addition to currently implemently unfollow and block)

• client side mute (mute someone in the UI, without advertising)
• blocklist follow (treat as blocked, anyone who is blocked by this feed - also note: this is feature twitter users created, but not officially brought into twitter (users have been the source of all the best twitter features))
• auditable user invites (invites with some info trail about who invited them to where - for example, who the invite was created for - this would also allow us to de-emphasise public pubs)
• per message/blob tags/flags (wether a particular message needs a content warning, to be filtered in the UI)

• private groups/friend only posts (messages encrypted to a restricted audience)

@cinnamon that script wouldn't be that complicated for someone who knows a bit of flume. It might take a minute to run, but in a way I feel that is appropiate for a relatively heavy action!

@substack yes, and blobs GC should come into that. I definitely thing it's important but the thing that worries me is that tagging messages/blobs feels a lot like curation/bookmarks, it's just negative curation. We've talked about curation for ages...

• blocks (or any social action) should be able to be private. (encrypted to yourself, also to a recipient, or public)

It should be possible to block or follow or like without advertising that. You may want to let someone know that you followed them, but not let someone know that you blocked them. when following a block list, you may not want everyone (potential trolls) to know you did that, but you may want the maintainer of that list to know

I think @Josiah was talking about something along the lines of allowing any message type to be private. All we need to do is include unboxing in the ssb indexes (like ssb-friends and ssb-about). The ssb-backlinks index already does unboxing, so that means you can reply, like and hashtag privately already! (and this is why it works in private messages).

We could just hack it onto the indexes, but then that would require unboxing a message multiple times just to index it. Really this should be part flume. It should unbox messages before they get to the indexes.

Scuttle link: %9onFHV6...

cc @Dominic

Oh, that reminds me.

In patchwork we could add a warning on the confirm box saying: The action you are about to perform will be publicly visible.

I was wondering about adding a second button on the confirm dialog: Publish Privately. It could even be a drop down (kind of like facebook where you choose "Public", just my friends, etc). Then any action that has a confirm box could be done privately. If we had private groups, you could select from the dropdown who you wanted to be able to see the action.

@matt yeah that is basically what I was thinking. the confirm box would also be a good place be able to post as a different account.