# Bots Buttons & Command auto-completion

**URL:** <https://forum.delta.chat/t/bots-buttons-command-auto-completion/469>\
**Category:** Bots\
**Tags:** user-interface\
**Created:** [June 28, 2019, 3:27pm UTC](https://forum.delta.chat/t/bots-buttons-command-auto-completion/469 "2019-06-28T15:27:42Z")\
**Posts on this page:** 15\
**Page:** 1

<div class="post-metadata">

**Author:** ![Simon](https://forum.delta.chat/user_avatar/forum.delta.chat/simon/32/287_2.png) [@Simon](https://forum.delta.chat/u/Simon)\
**Post date:** [June 28, 2019, 3:27pm UTC](https://forum.delta.chat/t/bots-buttons-command-auto-completion/469/1 "2019-06-28T15:27:42Z")

</div>

## Message Reply Suggestion Buttons

Like in Telegram - show buttons beneath a message that act as a shortcut for typing in the next command.  
On click it sends the command.

## Command Auto completion

As you type you get auto complete suggestions for commands that the bot with whom you’re chatting has.

---

<div class="post-metadata">

**Author:** ![Simon](https://forum.delta.chat/user_avatar/forum.delta.chat/simon/32/287_2.png) [@Simon](https://forum.delta.chat/u/Simon)\
**Post date:** [June 28, 2019, 3:29pm UTC](https://forum.delta.chat/t/bots-buttons-command-auto-completion/469/2 "2019-06-28T15:29:19Z")

</div>

my notes about a way how we could realize it - protocol wise:

### Reply Suggestion Buttons

Could look like in telegram. On click it sends the command.  
It gets delivered in an Header (or in an attached file and the header just notifies dc that there is this file).  
(also there might be a maximum of like 8 or 10 button and then a show more button in the ui that shows all buttons in a new dialogue)

Only show on Latest message / or only as special keyboard to avoid clutter?

#### Information:

```auto
Layout: Grid | List | table with x{2-3} columns
Buttons:
- Label (might contain emoji unicode)
- Message to be send in this channel

```

### index/ ?Manifest? / Presets

one file that has lists all comands for autocompletion and presets for Reply Suggestion Buttons that can be refered by the Reply Suggestion Buttons headers to safe trafic.

DC always use the last one it got from a particular bot and the bot is responsible for sending the client a new one when the hash canged (automatic handling for updating clients could be integrated in dc core)

#### Information

```auto
Hash of data // for integrity chacks and to compare versions
Commands List:
 Array of Commands:
 - command (special syntax to enable typed placeholders that there can be suggestions for enums and the keyboard can switch to a numeric one on number input and so on.)
 - (optional) scope: only Group | only Direct Chat with the bot
Reply Suggestion Buttons presets List:
[id]: Reply Suggestion Buttons Data

```

When an Message references an preset id that isn’t defined in there, the dc ui will instead show a button to send an system message to the bot to resend its “index/Manifest”. When the bot doesn’t have it it’ll log the incident it somewhere for the bot admin to check.

---

<div class="post-metadata">

**Author:** ![anon93826752](https://forum.delta.chat/letter_avatar_proxy/v4/letter/a/eb9ed0/32.png) [@anon93826752](https://forum.delta.chat/u/anon93826752)\
**Post date:** [June 28, 2019, 4:52pm UTC](https://forum.delta.chat/t/bots-buttons-command-auto-completion/469/3 "2019-06-28T16:52:10Z")

</div>

@adbenitez

---

<div class="post-metadata">

**Author:** ![Simon](https://forum.delta.chat/user_avatar/forum.delta.chat/simon/32/287_2.png) [@Simon](https://forum.delta.chat/u/Simon)\
**Post date:** [June 28, 2019, 5:45pm UTC](https://forum.delta.chat/t/bots-buttons-command-auto-completion/469/4 "2019-06-28T17:45:44Z")

</div>

Ah also note worthy is that @adbenitez uses HTML files with mailto links as a way to provide a GUI for his simplebot.  
And I threw together a small companion app that opens zipped html files, because unziped ones are a waste of mobile data(html compresses super well). Though Custom GUI / DeltaChat-webapps are a topic for a dedicated Feature Proposal.

Mentioned Projects:

- [https://github.com/adbenitez/simplebot](https://github.com/adbenitez/simplebot)
- [https://github.com/Simon-Laux/ZHV](https://github.com/Simon-Laux/ZHV)

---

<div class="post-metadata">

**Author:** ![anon93826752](https://forum.delta.chat/letter_avatar_proxy/v4/letter/a/eb9ed0/32.png) [@anon93826752](https://forum.delta.chat/u/anon93826752)\
**Post date:** [June 28, 2019, 7:22pm UTC](https://forum.delta.chat/t/bots-buttons-command-auto-completion/469/5 "2019-06-28T19:22:39Z")

</div>

I think gzipped html, through deflate implementations already in software such as Apache HTTP [https://httpd.apache.org/docs/current/mod/mod\_deflate.html](https://httpd.apache.org/docs/current/mod/mod_deflate.html) (and supported by most of web browsers), it would be better. Anyways @adbenitez told me about that, I only think you had the intention to implement it on another way and @adbenitez did not know about that.

---

<div class="post-metadata">

**Author:** ![Simon](https://forum.delta.chat/user_avatar/forum.delta.chat/simon/32/287_2.png) [@Simon](https://forum.delta.chat/u/Simon)\
**Post date:** [June 28, 2019, 7:52pm UTC](https://forum.delta.chat/t/bots-buttons-command-auto-completion/469/6 "2019-06-28T19:52:11Z")

</div>

We can add gzip and gzipped tarball support to zhv.  
I used plain zip because I think it’s easier for a user to understand. (also - does it make a big difference? 👀)  
Can you elaborate more on your point on how browser support helps? The ZHV app is only a wrapper for the system installed webview (thats why it is so small) - It extracts the zipfile and then loads it into the webview.

Also this discussion is a bit offtopic for the bot buttons, so lets rather keep it short.

---

<div class="post-metadata">

**Author:** ![adbenitez](https://forum.delta.chat/user_avatar/forum.delta.chat/adbenitez/32/2323_2.png) [@adbenitez](https://forum.delta.chat/u/adbenitez)\
**Post date:** [June 28, 2019, 8:23pm UTC](https://forum.delta.chat/t/bots-buttons-command-auto-completion/469/8 "2019-06-28T20:23:01Z")

</div>

I think you are confused, this kind of compression is supported with the http protocol, when the server and the client are communicating, the client advertises it supports some kind of compression and the server send a reply with a header set to the type of compressed data, but I don’t think it is possible to have a local .html file compressed and open it with a browser, if it is possible please elaborate and provide steps to reproduce

---

<div class="post-metadata">

**Author:** ![Simon](https://forum.delta.chat/user_avatar/forum.delta.chat/simon/32/287_2.png) [@Simon](https://forum.delta.chat/u/Simon)\
**Post date:** [August 12, 2019, 4:46pm UTC](https://forum.delta.chat/t/bots-buttons-command-auto-completion/469/14 "2019-08-12T16:46:00Z")

</div>

from @adbenitez 's simplebot readme feature proposal for DC section:

> On a private chat(1x1) with the bot, the bot may send an especial message to send a “buttons” list, each button has a label, a command string and a “has\_args” flag, with this data, **DC clients** should display a board with the buttons in the bot’s chat, when a button is clicked, if “has\_args” is false, a message with the button’s command should be sent, otherwise the DC client should show the input field in an especial way with some visual effects to reflect that what you type here will be sent as part of the command, the user type what should be passed to the command and then press the sent button.

---

<div class="post-metadata">

**Author:** ![Simon](https://forum.delta.chat/user_avatar/forum.delta.chat/simon/32/287_2.png) [@Simon](https://forum.delta.chat/u/Simon)\
**Post date:** [August 12, 2019, 4:50pm UTC](https://forum.delta.chat/t/bots-buttons-command-auto-completion/469/15 "2019-08-12T16:50:13Z")

</div>

> [@Simon](#):
>
> On a private chat(1x1) with the bot

I wouldn’t restrict this to only Direct Messages by design. We can maybe say that it has a lower max button count per message before the buttons are collapsed.  
Also we should think about hiding the buttons of old messages by default, if a newer message has buttons.

---

<div class="post-metadata">

**Author:** ![adbenitez](https://forum.delta.chat/user_avatar/forum.delta.chat/adbenitez/32/2323_2.png) [@adbenitez](https://forum.delta.chat/u/adbenitez)\
**Post date:** [August 12, 2019, 5:01pm UTC](https://forum.delta.chat/t/bots-buttons-command-auto-completion/469/16 "2019-08-12T17:01:33Z")

</div>

> [@Simon](#):
>
> I wouldn’t restrict this to only Direct Messages by design

the problem with groups is that you can have several bots in a group each one with its own set of buttons, and it is possible to handle this but it will be complex so for a first proposal I wanted to keep it simple 😉

---

<div class="post-metadata">

**Author:** ![Joshua](https://forum.delta.chat/letter_avatar_proxy/v4/letter/j/48db29/32.png) [@Joshua](https://forum.delta.chat/u/Joshua)\
**Post date:** [August 12, 2026, 5:45am UTC](https://forum.delta.chat/t/bots-buttons-command-auto-completion/469/17 "2026-08-12T05:45:20Z")

</div>

Sorry for digging up a 7 year old thread, but did something happen here? Are bots able to send any kind of buttons now? If not, what is blocking it? Did the discussion just end, are there any blockers, is this a capacity problem? I think that a feature like that could be a real benefit

---

<div class="post-metadata">

**Author:** ![WofWca](https://forum.delta.chat/user_avatar/forum.delta.chat/wofwca/32/1702_2.png) [@WofWca](https://forum.delta.chat/u/WofWca)\
**Post date:** [August 12, 2026, 8:35am UTC](https://forum.delta.chat/t/bots-buttons-command-auto-completion/469/18 "2026-08-12T08:35:33Z")

</div>

> [@Joshua](#):
>
> is this a capacity problem?

Probably that.

---

<div class="post-metadata">

**Author:** ![ian](https://forum.delta.chat/user_avatar/forum.delta.chat/ian/32/3164_2.png) [@ian](https://forum.delta.chat/u/ian)\
**Post date:** [August 12, 2026, 11:24am UTC](https://forum.delta.chat/t/bots-buttons-command-auto-completion/469/19 "2026-08-12T11:24:27Z")

</div>

The Delta Chat client now automatically turns text fragments that resemble local paths into clickable links, essentially making access to slash-commands easier. If you click such a link, it pastes it into the message composer box so it requires pressing the send button separately.

Later on, webxdc was also introduced in 2022 that seems to have solved most of the requested use cases for providing a user interface for bot backends.

---

<div class="post-metadata">

**Author:** ![Joshua](https://forum.delta.chat/letter_avatar_proxy/v4/letter/j/48db29/32.png) [@Joshua](https://forum.delta.chat/u/Joshua)\
**Post date:** [August 12, 2026, 7:32pm UTC](https://forum.delta.chat/t/bots-buttons-command-auto-completion/469/20 "2026-08-12T19:32:50Z")

</div>

I see! But as far as I see the only thing that is available in-chat is the /commands that you have described where the user still has to press enter, right? On the other hand when using the webxdc apps (which are definitely super cool) as you described the user would first have to press on “start” and only then would be able to see the available commands, right? In that case I think the apps would not really fill that usecase - but they could if there was an “inline mode” for the webxdc apps where they render directly in the chat and not just after being opened. But I can imagine this having performance implications because it would mean potentially having multiple apps loaded at any time and loading/unloading many of them when scrolling through the chat.

---

<div class="post-metadata">

**Author:** ![ian](https://forum.delta.chat/user_avatar/forum.delta.chat/ian/32/3164_2.png) [@ian](https://forum.delta.chat/u/ian)\
**Post date:** [August 13, 2026, 1:04pm UTC](https://forum.delta.chat/t/bots-buttons-command-auto-completion/469/21 "2026-08-13T13:04:08Z")

</div>

Inline webxdc is an often request feature:

> [@Feature suggestion - view apps inline](https://support.delta.chat/t/feature-suggestion-view-apps-inline/4468/11):
>
> A use case for allowing to show webxdc of static HTML + CSS in the chat with JS disabled is to provide an alternative for space-efficient and accessible stickers, animations and lightweight interactive CSS-only galleries and combinatoric logic. You can already achieve this with SVG+SMIL, but competence for creating such from scratch is high and it can’t be usually reused elsewhere. Whereas, existing png & jpg thumbnails of a game or the current snippet from the doc or calendar app could be repr…

> [@'Inline' realtime polls](https://support.delta.chat/t/inline-realtime-polls/3882/11):
>
> Related:

If we supported rendering HTML email (optionally inline) and chat URL references with parameter passing, such buttons could be implemented using `<a href="openpgp4pfr:...">RSVP yes</a>`.

> [@Deep links: make it possible to pre-fill the first message \[i.delta.chat parameters similar to mailto:?body\]](https://support.delta.chat/t/deep-links-make-it-possible-to-pre-fill-the-first-message-i-delta-chat-parameters-similar-to-mailto-body/4801/3):
>
> We can’t initiate encrypted communication via mailto as it is missing the public key. This means it won’t work on chatmail.

> [@Dumb proposal for group-local user nick to allow tag](https://support.delta.chat/t/dumb-proposal-for-group-local-user-nick-to-allow-tag/5179/2):
>
> You could possibly already @-mention other members within the group based on their key fingerprint or any unique prefix of it, just like it is done in git. No further data would need to be maintained and synchronized then. However, I still believe that user ping mentions would be more durable if it was serialized as an openpgp4fpr or i.delta.chat URI (only with the fingerprint and address included) in the sent message. The Delta Chat interface would render such links as a clickable user pill wi…

> [@Direct mention on groups](https://support.delta.chat/t/direct-mention-on-groups/185/25):
>
> No, it’s the other way around. The fingerprint of a profile won’t change, while the display name and the email address can be changed back and forth any time. Hence, embedding the fingerprint according to my suggestion would be a stable reference to the given person.

Introducing non-standard data attributes on `<button>` would be less interoperable.
