Thanks for your explanations. Now I understand.
And I’m with you for managing high number groups. But one remark: people outside of a bcc group can’t subscribe by themselves because they don’t see the group. This could be done only by recipients which are in.
For me the current simple bcc group is a big step forward in contrast to having nothing
of course, better something than nothing
btw, another reason I wanted channels, is because I need this bcc stuff in my bots, it is really slow to distribute messages one by one, but the use case is also channels, where bots distribute the messages and I need the messages to arrive as a group not as a 1:1 with the bot
@adbenitez keep in mind that channels are read-only, so they are not ideal for mega-groups, either.
BTW as soon as we have mailing lists, switching from broadcast lists to channels is going to be a 1-line-change (adding a List-Id header when sending the message). And I think that I like channels better, too.
The two solutions for the spam problem I see are:
let the bot create a 2-members-group with each person, as you did before. Then add a new FFI to the core that efficiently sends a message to many chats using BCC. Will be waaay easier to do once we have broadcasts/channels. This would also be an improvement for the Android app as you can forward messages to multiple chats, which is currently implemented by sending one message per receipient.
Don’t organize the mega-groups with Delta bots at all, but make them regular mailing lists. Will only be possible once we have read-and-write mailing list support.
to proceed with your last message: When you want to have a broadcast message where you still want to see a group, but read only for the recipients. How would that be possible with email? When the recipient sees a group he’s able to answer. Read only in that manner is not possible. We are not on a server which could handle that. If DC should handle that
a) from the recipients perspective DC could prevent to reply to such a group or
b) from the senders perspective DC could just not route incoming messages to the sending group or
c) what about a standard MUA? As recipient You can do what you want. Reply, Reply to all and do nothing (read only)
=> not so easy :-/
There are possibilities in how to send the mail and what a receipient sees:
a) when you put some addresses in To, Cc or Bcc recipient SEES a group OR NOT if you don’t do that. These informations are in mail header and even Bcc sometimes is not deleted by mail server.
b) this is independent to whom a mail is sent for the mail server. This is another list, which a recipient never can see! This is SMTP.
I think if we are speaking here from real mailing lists (@Hocuri) there is a server in between which can do some things. The broadcast group here is much simpler. It just uses a) and b).
i would like to see: option to show members/friends opted in
which spam problem? i’m not following the bot idea at all, still couldn’t see those bots in action…
but spam will always be a huge technical cat and mouse hurdle, sadly. even when we do get better ai… (fighting against useless stimulus is subjective and an individual, a constant battle we all have to endure in many different layers)…
that being said, it might be better to not worry too much with spam while delta doesn’t get tremendously big. even telegram have only started to show spam issues (from my user point of view) this year. obscurity is one of the best spam protections!
I know, I don’t want channels for mega groups but for channels just that I would like to use the bot to be the one handling the channel, so the channel admin can avoid getting replies from users, and also to avoid the high data usage of having to send a message to a ton of users.
this is exactly what I want, just that on the bot side there would be only one group with all users and users receive the messages as 2 member groups, but well what you say could also work for me, but not usable for users that want to handle the channel directly without having to trust a bot, so in the end it is better to implement it as channels.
not allowing to reply with delta chat will, in practical terms, solve the issue, users can reply from other MUA(if you have email interactions in only chat this is no issue), or reply in private to the channel admin, DC should show the reply in private, so they will get to contact requests chat not spamming the channel. That is good enough and in practice less problematic than sending broadcast messages in private, as a direct message people will tend to reply to your messages, with the user knowing it is a channel and they shouldn’t reply and that their replies have a high probability to be ignored, they usually wouldn’t bother to try hacks to reply.
that is without bots, now with a bot, the bot will administrate the channel for you so the channel admin is protected and the bot is the one that creates the channel and sends the messages so people effectively can’t reply to channel admins
Ok, I’m with you. In DC you can handle that but from the technical point of email “prevent reply” is not really possible. Ignoring replies is the only way to prevent replies when a recipient shouldn’t do it