core icon indicating copy to clipboard operation
core copied to clipboard

Auto accept contact reqests for bots

Open Simon-Laux opened this issue 3 years ago • 1 comments

The problem

Currently bot code needs to check for and accept contact requests on incoming message, that adds unnecessary complexity to the examples and basic bots.

Example of the problem in the echo bot

C:

 } else if (event_type == DC_EVENT_INCOMING_MSG) {
      int chat_id = dc_event_get_data1_int(event);
      int message_id = dc_event_get_data2_int(event);

+    dc_chat_t *chat = dc_get_chat(context, chat_id);
+    if (dc_chat_is_contact_request(chat)) {
+      // check if contact is new / and accept its contact request
+      printf("[BOT] accepting new contact request\n");
+      dc_accept_chat(context, chat_id);
+    }
      dc_chat_unref(chat);

      printf("[incoming-msg] %d %d\n", chat_id, message_id);
      handle_message(context, chat_id, message_id);
    } else {

nodejs:

function handleDCMessage(chatid, msgId) {
  const chat = dc.getChat(chatid);
  const msg = dc.getMessage(msgId);

+ if (chat.isContactRequest()) {
+   dc.acceptChat(chatid);
+ }

  // only echo to DM
  if (chat.getType() === C.DC_CHAT_TYPE_SINGLE) {
    dc.sendMessage(chatid, msg.getText());
  }
}

rust:

async fn handle_message(
    ctx: &Context,
    chat_id: ChatId,
    msg_id: MsgId,
) -> Result<(), anyhow::Error> {
    let mut chat = Chat::load_from_db(ctx, chat_id).await?;
+   if chat.is_contact_request() {
+       chat_id.accept(ctx).await?;
+       chat = Chat::load_from_db(ctx, chat_id).await?;
+   }

    let msg = Message::load_from_db(ctx, msg_id).await?;
    if msg.get_from_id() == ContactId::SELF {
        // prevent loop (don't react to own messages)
        return Ok(());
    }

    if chat.get_type() == Chattype::Single {
        let mut message = Message::new(Viewtype::Text);
        message.set_text(msg.get_text());
        send_msg(ctx, chat_id, &mut message).await?;
    }

    Ok(())
}

Proposed solutions

  1. a config option that for auto accepting contact request
  2. the same as 1. but implicitly enabled by setting the bot config to true
  3. the same as 2. but only triggered by the bot config option without its own config option

Simon-Laux avatar May 06 '22 19:05 Simon-Laux

I'm in favor of option 3. 2.: We should avoid these "changing a setting changes something else" side-effects when we don't really need them, 1: such an option seems not useful for non-bots since for a user it means that if read receipts are enabled, they are sent automatically to strangers contacting you.

Hocuri avatar May 12 '22 13:05 Hocuri

they are sent automatically to strangers contacting you.

Isn't that what you actually want when you enable auto accepting contact request @Hocuri?

Septias avatar Aug 29 '22 14:08 Septias

But then you will send a read receipt to spam messages, too, allowing the spammer to see that the address is used actively, which usually they send you more spam.

BTW, thanks for bringing the attention back on this old issue, since it actually should be done rather easily - esp. @adbenitez what's your opinion here? Would this be useful for your bots?

Hocuri avatar Aug 29 '22 14:08 Hocuri

But if we go with option 3) we should still protect the user from spam, so probably only auto accept contact requests from bots. Is there any secure way to find out if a contact request is from a bot? Otherwise I imagine spam-bots which exploit the auto-accept feature

Septias avatar Aug 29 '22 15:08 Septias

@Septias i think, this is a misunderstanding. the issue is not about changing anything in the android/ios/desktop apps. it is about having sth. special for ppl coding bots, saving a few lines of code.

r10s avatar Aug 29 '22 15:08 r10s

Ahhhh, so if it is on the bot-side anyways we might also implement option 1 since a bot getting spammed is virtually no problem?

Septias avatar Aug 29 '22 15:08 Septias

question is, how helpful 1. actually is. either say auto_accept_chats() on bot startup accept_chat() when the bot gets a chat. both are straight-forward, and both are similar easy to forget :)

so, let's see what @adbenitez says, i mean, he has written lots of bots :)

r10s avatar Aug 29 '22 16:08 r10s

I'm for option 3, or 2. the contact request check if easily forget by new bot devs and then they think something else does not work searching the problem at the wrong place which makes for a frustrating first experience.

though that complexity is hidden away by simplebot, so simplebot-plugin devs don't need to worry about such things. So for the specific case of simplebot plugins, which abstract away complexity anyway its not needed. But that only covers highlevel python bots that expose a different api anyway.

Simon-Laux avatar Aug 29 '22 16:08 Simon-Laux

Okay, I will create a pr which implements 3) in the coming days since everyone semt pretty fine with it.

Septias avatar Aug 29 '22 16:08 Septias

yes, I think option 3 is the best, option 1 would only add extra work to port existing bots without any real benefit, since I use SimpleBot I only had to auto-accept in one single place in the base bot and then as plugin creator we don't have to worry about anything so it is not an issue for me but for new developers creating a bot from scratch and I think option 3 is the best UX for new devs, without needing to know about any other quirks but to enable the "bot" setting

adbenitez avatar Aug 29 '22 18:08 adbenitez

another question is why not auto-accept on reply? (sending a message in the chat auto-accept it) but that will not work well anyway if the bot only needs to read and then read receipts will not work since the bot will never send a reply auto-accepting the chat

adbenitez avatar Aug 29 '22 18:08 adbenitez

another question is why not auto-accept on reply?

Probably because can_send() returns false for requests so that the UIs hide the controls that don't make sense at this point (like adding/removing members from a group, or adding an attachment). And then when sending a message we check can_send() whether it's allowed to send this message.

Hocuri avatar Aug 29 '22 18:08 Hocuri

fixed by #3567

Septias avatar Sep 01 '22 13:09 Septias