[TRACKING ISSUE] Channels

[Hocuri]

This is a tracking issue for broadcast channels, similar to the ones known from Telegram/WhatsApp. As oppsosed to Telegram/WhatsApp, channels will be end-to-end encrypted in Delta Chat. Some other features known from Telegram/WhatsApp will be missing.

Implementation

Show broadcast channels in their own chat

Core work:

• Add new chat type InBroadcastChannel and OutBroadcastChannel, where the former is similar to a Mailinglist and the latter is similar to a Broadcast (which will be removed)
  • Consideration for naming: InChannel/OutChannel (without "broadcast") would be shorter, but less greppable because we already have a lot of occurences of channel in the code. Consistently calling them BcChannel/bc_channel in the code would be both short and greppable, but a bit arcane when reading it at first. Opinions are welcome; if I hear none, I'll keep with BroadcastChannel.
• api: Add create_broadcast_channel(), deprecate create_broadcast_list() (or create_channel() / create_bc_channel() if we decide to switch)
  • Adjust code comments to match the new behavior.
• ASK Desktop developers what they use is_broadcast field for, and whether it should be true for both outgoing & incoming channels (or look it up myself)
• Make it possible to block InBroadcastChannel
• Make it possible to set the avatar of an OutgoingChannel, and apply it on the receiving (ReadonlyChannel) side
• DECIDE whether we still want to use the broadcast icon as the default icon or whether we want to use the letter-in-a-circle
• chat.rs: Return an error if the user tries to modify a ReadonlyChannel
• Add tests
• Grep for broadcast and see whether there is any other work I need to do

UI work:

• Rename "broadcast list" to "channel" or "broadcast channel" both in UI and code (depending on whether it's important to be concise in the particular place). There are new stock strings in which broadcast_list is replaced with channel
• Adapt to the new chat types

Symmetrically encrypt broadcast channels

Channels need to be symmetrically encrypted, because if we encrypted them asymetrically, like we do for all other messages:

• with some technical expertise, it would be possible to find out who the other recipients are
• when there are a lot of recipients, the messages would be very big.

This will need a lot of work (like new QR codes) which I'll write about later.