okdistribute
commented
5 years ago I like the simplicity of publishing a chat/join message. To kick/ban people, could do the "walkaway" approach which is also sort of publishing a new type of message key, just with not the person that you're kick banning.
I also think it would be small overhead and a lot of security gain to do something similar to group email encryption, which is encrypting the message with X number of keys, all the people who have been invited to the channel, and then when someone gets kicked you encrypt to X-1, so they wont see future messages.
ghost
Right now, if you post a message to a channel, everyone on the cabal swarm receives the plaintext of that message, whether or not they are in that channel. I think that is a bad default in terms of privacy and is not what somebody unfamiliar with cabal might expect. The privacy aspects are compounded by the historical append-only nature of hypercore data: all somebody needs to do to eavesdrop on an entire cabal is to connect once, download all the history, and disconnect, without ever showing up as having even joined a channel.
At the very least, each channel could be encrypted with a randomly-generated box key. A client could publish a
type: 'chat/join'message and a user (selected deterministicly on some schedule if no key has been sent in time) in one of those channels could send the box key for that channel encrypted to the client's public key. For invite-only channels, thesetype: 'chat/join'messages could go into a queue to be manually verified or else the channel box keys could be sent encrypted directly. Private 1:1 conversations could use client public keys and wouldn't need the extra step of having a channel key.Another way to do this could be to generate a unique random key per message and send the message decryption key to each user in the channel in an attachment on each message. I think deltachat might do something like that using autocrypt for group chat, but I'm not sure.