Private messages

[hackergrrl]

This issue is to track the implementation of private messages in cabal.

The idea is to add private messages that enable two individual users (feeds) to communicate with each other such that other participants in the cabal will sync their messages, but not be able to read them. The messages will be encrypted using private-box, which uses chloride.

There are a few pieces involved across the cabal stack:

cabal-core (https://github.com/cabal-club/cabal-core/pull/69)

• [x] Core API for publishing messages to a recipient
• [x] Kappa View for indexing sent and received private messages
• [x] Core API for reading private message conversations (via ^ kappa view)

cabal-client

• [ ] API for publishing messages
• [ ] API for reading messages & bubbling up events when they are received, exposed as virtual channels
• [ ] Logic to hide PM channels with folx that are hidden or blocked
• [ ] /pm//w commands (+ a command to close a PM window)
• [ ] move the whisperlink command /whisper to /share (and /share to /cabalkey? or just output cabal key as well on /key)
• [ ] Unit tests

Clients

Expose interface for

• [ ] cabal-cli
• [ ] cabal-desktop

[hackergrrl]

A major consideration for this feature is preventing abuse & harassment. Blocked & hidden users should NOT be able to have their messages to you be displayed.

Q: where is the best place to handle this logic? I think it makes sense to still index these messages (in case you un{block,hide} someone), but would this be easier to manage in -core or -client?

[cblgh]

@noffle good points!

I have been thinking of experimenting with abuse mitigation in the following way:

• introduce some sense of a "small enough" cabal into e.g. cabal-client. when we're small enough, actions can be implicitly assumed to be very high trust (e.g. # identities < 10)
• for small enough cabals, it is okay to show private messages from anyone in the cabal by default
• make a branch that uses trustnet
• for larger cabals (# identities >= 10), private messages will not be shown from people who aren't trusted (e.g. trusted directly, or indirectly as determined by trustnet)
• when bob private messages alice, perform a small check to see if alice trusts bob directly. if not, display a notice in bob's message to the extent of alice does not appear to have you in their trusted group, so this message might not appear for alice until trust has been issued for you

I haven't thought about the details of where to index what, but these are the brush strokes with which I have been considering abuse-laden features such as PMs, images & avatars :)

edit: lol i totally missed that you had finished PMs?!?! :D!

(originally i didn't have the small enough concept, but felt maybe that would be important to introduce for small groups & making things more intuitive + less annoying when getting started :)

[okdistribute]

A major consideration for this feature is preventing abuse & harassment. Blocked & hidden users should NOT be able to have their messages to you be displayed.

Q: where is the best place to handle this logic? I think it makes sense to still index these messages (in case you un{block,hide} someone), but would this be easier to manage in -core or -client?

In which repository is the filtering done for removing messages from users that have been blocked/hidden in the channels? Probably best to keep that consistent?

[hackergrrl]

For the cabal-client work, a proposal:

• map PMs from privateMessages.list() on cabal-core to virtual channels
• use /join @cblgh and /leave @cblgh syntax for opening/closing these channels
• ^ use the @ sigil to decide if it's a PM channel. also requires us to disallow @ from regular channel names
• someone messaging you auto-opens a virtual channel
• logic happens here to prevent a hidden/blocked person who PMs you from opening a virtual channel

[cblgh]

command-wise i was thinkin

• /w kira && /pm kira, the former giving me cosy mmo vibes :)
• cabal-client can take care of the virtual channel stuff for the /w command under the hood
• we can use the same disambiguation logic that we have for the moderation views, e.g. if multiple kiras we prompt with "hey there are multiple kiras! which one do you wanna pm?"
  • maybe, if we already have a kira pm going, when we do /w non-disambiguated-style we just do a check to see "do i have a convo with someone called kira already?"
• i was thinking of having pm messages also show up for you in the channel window you are currently viewing as well (albeit in a different colour, like maybe all purple); it opens up for abuse potential, but i think it would be interesting to experiment with? there's something about it that i like (again, mmo vibes :)

[hackergrrl]

@cblgh I agree on points 1-3. I'm personally -1 on point 4. I already really dislike the status messages we show in regular channels. >__<

[cblgh]

@noffle ahh oh no, well we can skip pushing point 4 then. i just wanna experiment with it on my own branch, maybe making it an opt-in for cabal-cli in its config for people who want it, if the experiment ends up working okay ^^