Using bots through non-Delta Chat email clients?

Bots
1

I was thinking of using the Delta Chat library (deltachat-rpc-client I believe it is) to write an email bot primarily for the non-Delta Chat email audience, because the examples look pretty simple and I don’t know any other “email chatbot” libraries.
(I know the gettor@torproject.org email (DOWNLOADING | Tor Project | Tor Browser Manual), and I have found no indication of any chatbot libs being used in its source).

But bots.delta.chat seems to mostly talk about Delta Chat specifically and not email (SMPT, IMAP, etc) in general.

I tried to send a message to one bot using another email client. I got a response, but the interaction is not ideal because apparently the bot read the message as (No Subject) – /help, whereas it should have been /help — the email’s subject got appended to the message.

So

  1. How well does the current Delta Chat bot infrastructure support non-Delta Chat clients, if at all?
  2. If not at all
    2.1 Is it even feasible?
    2.2 Are there plans to support it?
    2.3 What are the recommended alternatives? For Python? For Go?
2

I think this should be filed as a bug into the core repo (EDIT: I filed an issue Do not put subject into message text if `bot` config is set · Issue #5499 · deltachat/deltachat-core-rust · GitHub). Simple solution would be to stop appending the subject to the message in case bot config is set.

2 Likes
3
  1. How well does the current Delta Chat bot infrastructure support non-Delta Chat clients, if at all?

we have eg. dc_msg_set_subject() - it is not exposed in UI and iirc was added to make bots look better when using Non-Delta-Chat-Clients, as one of the bigger issues. so, afaik, bots work with Non-Dc-Clients in general, @adbenitez will know more

for the other way round, how a bot sees the subject there is dc_msg_get_subject(), it is used for the title in HTML-views, but iirc also for bots

getting rid of prepending subject to the text, however, would be a more complicated and need adaption of APIs and UIs, so, we should not go for that now, if at all. but maybe we can stop doing prepending subject when is_bot is set - or, as a solution for today, a bot could just hack around that and skip to the first space-endash-space – or substract subject from text :wink:

in general, i think, bots should be quite tolerant wrt text input anyways - if i would write a bot, i would not take care about whether text is entered to subject or body (and i assume, this is what most bots are doing) - so a get_text() just returning both is maybe not that bad.

but the (No Subject) looks as a bug, indeed, that would be visible in UI as well, right?

4

yes, a bot could be tolerant and support commands in subject and in body, the problem is the way core returns the body, for a non-delta user even the signature will cause issues, for stripping the subject from the msg text the bot could use the new available subject property and strip it from the msg text body, because a — could be part of the actual message

5

why? core should strip signature accordingly - and if core fails there, and it is fixable for the bot, it should be fixed in core (so signature is not visible in UI as well)

6

it is stripped but […] is inserted IIRC

7

yip, […] is inserted for stripped signatures, non-simple-quotes, too long texts

8

Long texts are not truncated if receiver is a bot:

1 Like
9

that site needs reworking, so take it with a grain of salt. (I started a new version, but It is not complete enough yet to be uploaded.)

resources I’d recommend right now:

1 Like