my notes about a way how we could realize it - protocol wise:
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?
Layout: Grid | List | table with x{2-3} columns
Buttons:
- Label (might contain emoji unicode)
- Message to be send in this channel
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)
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.
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:
I think gzipped html, through deflate implementations already in software such as Apache HTTP 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.
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.
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
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.
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.
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 
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
Probably that.
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.
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.
Inline webxdc is an often request feature:
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>.
Introducing non-standard data attributes on <button> would be less interoperable.