Broadcast group (distribution list)

Feature Proposal
1

Some weeks ago I saw a discussion where a teacher intended to use Deltachat for communication with his pupils. With this discussion he asked how to use a broadcast group with DC.
Especially now in “Corona” times, where many pupils are at home and are forced to do “home schooling” a broadcast function as requested would make sense.

Unfortunately I don’t find the discussion any more for reference. I know, it was here at forum or at delta’s github issues.

To focus on that requested function I opened now this new FR.

Expected behavior

Having a group where - outgoing - mails are sent individually to each group member.
No one should see the whole group list.
All addresses into BCC header!

Actual behavior

Standard group sends a message to all group members.
All addresses are included in the “To:” header field.
Every group member can see the whole address list.

Approach (first idea):

Extend existing group with a flag, to be a “Broadcast group”.
This flag could be set in group settings.
When a message to group is send, all addresses are placed in “bcc:” header instead of “To:” header.
“To:” header could include only sender address?

Possible answers to this group could

  • end in 1:1 chats or
  • mapped by “In-Reply-To:” header to group
2 Likes
2

I think you mean this discussion.

https://support.delta.chat/t/broadcast-messages-for-later-version-after-1-0-release/208

I also would like this feature.

2 Likes
3

@webratte

Yes, You are describing exactly the same than me :slight_smile:
Thanks for that hint :slight_smile:

But there was another discussion I mentioned. I thought to this one!

We should help teachers and pupils with DC as I see now in daily business how they struggle with one other messenger!

2 Likes
4

The key idea to come to a broadcast group is so easy that it should not be a big effort to do it in short term?

@r10s @link2xt
What’s Your opinion?

1 Like
5

I’m just working at an experimental Broadcast Group with following specification:

  1. all changes are based at the core
  2. use group name to identify Broadcast Group. When name ends with “#BCC” this is the flag
  3. introduce Mimefactory::bcc_group flag. it is set when 2) is triggered while rendering the a message
  4. set “Bcc:” header for all recipients instead of “To:” header
    use receipients list for smtp. Don’t set “Bcc:” header!
  5. set “To:” header to a default “Hidden recipients: ;” (Thunderbird does the same in that case)
  6. don’t set Chat group headers in that case.

Implementation is done, now I’m testing …

2 Likes
6

It works as expected :slight_smile:

Will push the code to github and do a PR

Tests shows that replies will end in 1:1 chat now.
In-Reply-To is set by a reply but DC is not mapping it to group.

This is the link to a binary (see version info):

7

I would rather have it as an entirely new chat type, not as a modifier to existing groups, I guess this could make problems.

Also we should keep in mind that this feature should work nicely with multi device setups. (also for the sender)
I haven’t looked closely at you code yet so I can only ask if it already considers multiple devices for the sender.

2 Likes
8

The flag/Broadcast setting:
It would be more professional to set a flag in group settings, but then you need an extension of user interface. For this first step I want to prevent this (as I don’t know how to realize that in short term now).

Problems?
Basic operation of this approach shows no problems now. The approach is simple.
All receipients will get a message like from a 1:1 chat. They don’t see the group. This is the nature of broadcast :slight_smile:

The biggest effort while implementing was, learning that BCC header must NOT be used and that MTA (e.g. sendmail) does not delete a BCC header in outgoing message!

Multi device usage:
Yes, this is not in focus here! You’re right.
The outgoing message is sent to yourself anyway, but to see it in group at other devices more efforts are necessary: It needs to be sent to yourself as full group message with all adresses. This is not done here and is not in focus, yet :wink:

9

agree.

to the general “broadcast approach” - i’d like to get one step back and have a look at the broader picuture:

  • “broadcast” as suggested here are used in whatsapp and in threema (“distribution list” there) - somewhere else?
  • telegram has “channels” instead, whatsapp has “restricted groups” which are similar to telegram’s channels (but have no invite-link, are still private)
  • signal has nothing
  • with some discipline of the group members, a normal group could do the job as well, just creating a group “homework” might do the job in the initially described scenario. maybe not perfectly, but still.
  • there is forward-to-multiple-recipients. for a birthday-invitation, that would be fine, but for everyday use, this is not a good solution, sure.

if we put away the fact that channels in telegram can also be used for huge groups, have invite-links etc., channels are similar in some aspects:

  • they also try to hide the complete recipient list
  • recipients cannot answer to the channel

otoh, of course there are differences:

  • channels do no hide the fact, that they are channels. recipients of “broadcast” are not aware that they are in some list.
  • the reply chain is clearer as you just cannot reply in a “channel” - for “broadcasts” replies go to the one to one chat which might be confusing.
  • channels might raise more expectations (invite-links, huge channels etc.), this is probably not true for “broadcasts” that we can implement more or less exactly the same as known by whatsapp.

implementation wise, there are probably no huge differences, there will be lots of tiny changes needed in both approaches, it will be some work.

i just came over all that that because the mentioned “read only groups” suggested at

are closer to “channels” as to “broadcasts” :slight_smile:

finally, i am not saying that the one or the other is better, currently i do not have a clear preference, ±0

3 Likes
10

@r10s I don’t think we have to decide this now because we can just do nothing (only implement the sender’s side, no change when receiving) and it will be broadcasts (call them experimental so users don’t complain when they change afterwards)

Then when we implemented mailing lists (i.e. showing already-existing mailing lists with a List-Id header in DC), we can just add a List-Id header and an extra chat will pop up (channel) .

Off-Topic

(actually we might want to add an Chat-List-Id header and make DC treat it as List-Id because current DC hides everything that has a List-Id header)

Or just leave it as is.

I personally find channels more useful but

  • channels might raise more expectations (invite-links, huge channels etc.)

that’s a point. Maybe call it “mailing list”? Disadvantage: users don’t know this word in instant messengers (but they do for emails so it’s not even that bad; we just have to make sure it’s translated correctly e.g. “E-Mail-Verteiler” not “Adressenliste”). Advantage: They don’t have any expectations.

3 Likes
11

I called it “broadcast” group explicitly because I intended to do only the job “distribute a message to the receipients of a group, but hide addresses!”
Hide the addresses is the important function. Receipients must not see to whom the message is sent too.
That’s all :slight_smile:

1 Like
12

the term you’re looking for is blind

this feature should be called simply “blind group” if it’s along side or “blind copies” if it’s a toggle option within groups.

both could be offered, redundant settings is perfectly fine.

but before you proceed with this, please keep reading…

no to broadcast!

broadcast is not intrinsically related to hiding anything. imho it’s rather a terrible name for this feature.

the nature of broadcasting is in its name: casting over a broad area. there’s nothing intrinsically related with hiding recipients or privacy. and, as pointed out, doing it digitally even means there’s no issue in broadcasting the recipients list in the broadcast itself (there’s technically no digital way to broadcast like a radio).

on a side note…

about telegram

personally, i love telegram idea of channels versus groups in general… and the points made were all great, @r10s and @Hocuri …

but there are many issues even with it. for instance, they added an option to hide the owners and admins by default. so now new channels are created, people get invited, but there’s nobody to blame. i’m in no way a personal target of abusers in general, still i already got abused by this once and i can see how easy it is to abuse it. the option was to protect admins of big channels (namely themselves) from flooding, and it works for them while they can hide their identity.

i don’t want to hide mine. i rather have a public identity and a private one. much easier.

getting a new email is easy, a new phone is also easy but much harder than an email. almost nobody have 2 phone numbers… telegram is based on phone numbers for this very reason. it’s a great layer o protection against a huge amount of abuse on itself… perhaps that’s a big reason why they get lost in their hiding feature…

i have zero idea on how delta chat does it, but i do know there are many features in place to prevent abuse as well, more than any email client. and it’s happily not based on freaking phone numbers!

delta can do much better than telegram and the rest, thanks to this smart choice.

yes to broadcast!

how about a libre friendly broadcast version?

the “broadcast group” would:

  • use bcc to hide the recipients only to prevent misuse of reply all.
  • have an opt-in option to send along the whole list on a file or something. including who’s managing the broadcast so that “viewers” can get in touch (in case there’s more than 1 admin).
  • there’s a huge warning explaining why this isn’t on by default and a confirmation box before turning it on for a new group.
  • of course the ux would show the list nicely, for every group member.
  • send an easy “unsubscribe” link at the bottom that will quickly and magically remove the user from the group, as soon as it hits the inbox.
  • make an extra option for users to get removed only from the recipients list.
  • perhaps even a global setting “hide me from all lists”, which might be better to be left of by default.
  • the first email (or perhaps the first few emails within an hour or so) will not send the list by default.
  • add an option to easily comment on each broadcasted item over on a linked group.
  • certainly need a few more features, but…

… in this direction we can get the best of all worlds, don’t you think?

most people who do broadcast are really just trying to organize data and make it interesting.

if i’m in a broadcast group, i want to know which of my friends are there. that makes it much more interesting. so i can even create a group with my friends only to talk about broadcasted items.

hiding email identities, in the other hand, is only really useful as prevention abuse and should be handled by who’s getting abused, and nobody else.

make sense? :blush:

1 Like
13

@cregox
The idea of this “broadcast group” is the same as using bcc in email. I want to send the same message to some recipients, but every recipient should see only his own and my address as the sender (I think it’s even possible to hide the sender’s address).

What I really want to hide is, that recipients in that “bcc list” should not know to whom else a certain message has been sent. The bcc list hides the relation between the recipients, not the relation to me as a sender.

Regarding wording: Someone called it broadcast group longer time ago and therefore I’m using this wording. Maybe you’re right and “blind group” or “distribution list” would be a better wording. Could be …

From the point of “how it works” it is more a distribution list, than a group.
For the sender it is more a group. For the receiver it is only a 1:1 message.

14

I admit the bcc part can be useful, I am only afraid that if this added, dc devs would not like then to add “channels” (like in telegram) channels would work the same as your “broadcast group” but will be also shown as a group on the receiver side(group of 2 members) so you can have context(for example if it I will send messages on the same topic this way regularly) that is missing if it arrives in 1:1 and also provide ways to “unsubscribe” from the list.

thinking more about it:
as I see it “broadcast groups” are only useful for ephemeral situations, otherwise a channel would be better than a “broadcast group”, if you just want to send unrelated messages to a bunch of people from time to time, improving the “forwarding to many” UX would be better than having to create a group to send a message then delete de group, and in the case you want this group permanently because you will send messages in this chat frequently, then a channel is a better approach

1 Like
15

in telegram, the users of the channel doesn’t see other members, actually it is unexpected I could see all members of a channel that is a privacy concern

16

I actually think channels are less confusing than this broadcast group that is seen as 1:1 on the receiver side,

  • invite-links: we have QR invite codes (that hopefully in the future could be shared as a link(just let users send the QR data)
  • huge channels: we already avoid issues related to provider receipts limit.

I strongly think channels are more useful yet not that different or more complicated (at least for an initial implementation, of course it could have more features, but the basics are the same as for “broadcast group”)

To resume (reply to this post if something is missing):

broadcast channels
hides members with BCC yes yes
transparent for the receiver yes no
mute messages from group no yes
can opt-out no yes
can invite no yes (ex. QR invites)
receiver can reply directly yes no

the main point of a channel is to hide the member list to improve privacy of the subscribers, so a normal group as channel will not work and adds a lot of annoyances for the subscribers and the admins (I tried this approach before)

1 Like
17

@adbenitez
Don’t know if PR is included in current DC yet. But did You ever tried the current implementation?
If current PR is still not merged into core You can try simply by using a standard mail client, put all receipients in bcc and keep to field empty :slight_smile:

This can give you an impression what we have in the moment.
For me it’s sufficient. Don’t need more :wink:

18

By the way: When you sent a message to any recipient he will always see where it comes from and is able to answer to that.
Therefore I don’t understand the options in table above “transparent for the receiver” and “mute messages from group”.
Even the “can invite” is not intended by this approach here. Any group relation is hidden for recipients.
The only indication regarding more recipients for a recipient is the text “Hidden recipients” in To field.

19

so you are not hiding the fact this is a broadcast email, just limiting functionality :wink:

I was thinking in “broadcast groups” the fact it is a broadcast group is transparent for the receiver.

this is the fact that channels are displayed as groups in the receiver side, the receiver can mute the group chat of this channel, being able to ignore this kind of content but still wanting private messages in the 1:1 chat with that friend to pop up, with bradcast groups all is sent in the 1:1 chat so all content is mixed.

it could be optional, like: the channel admin decides to share the invite QR with people or add to add them manually like in broadcast groups, this is: subscribers can’t invite others to the channel unless the admin shares the QR publicly

20

you will realize quickly that this is quite useful even for your broadcast groups if you don’t want just forward some message to 4 friends, managing the list manually can get messy, people asking you to stop sending, other wanting to get in, in my case I have a channel with +1000 it is a pain to manage that manually I want people in/out by themselves, that is why I would like your broadcast groups to be more channel-like :pray:

1 Like