I built an experimental webxdc app called Confluence that adds Slack-like features to Delta Chat: public channels, user roles (admin/user/pending), and centralized message history. It works through a bot that acts as a central server, with users connecting via 1-on-1 chats.
Key caveat: This experiment deliberately breaks DeltaChat’s decentralization model - all messages flow through a single bot account that stores everything in a SQLite database. The bot manages access control, broadcasts messages to all participants, and provides the webxdc interface.
You should know that even chatmail servers have a sending limit (60 messages per minute i think), so if a lot of people start using this and the bot has to broadcast each message to more than 60 people then is going to get slow.
Oh thats interesting, thats an important thing to keep in mind with this design! If it’s used by many people it may become necessary to host a chatmail relay with an adjusted config.
The bot may be optimized to batch and bundle dozens of messages together and only send out an update every minute, grouped by broadcast subspaces.
According to the source, isn’t it using realtime channels at present? The app seems to be completely broken if you disable that switch and it seems odd.
Could you please add a slash command (such as /stop) to allow members to leave the conversation with your bot? It would also be beneficial if the introductory message itself listed all supported slash commands.
Allowing to set a custom nick would be highly desirable, but at least using the display name of the DC account would make more sense than showing the random localpart of the email address as now.
It greatly limits the scale of your project that you are the only approver and only moderator in general. The role of the software developer, relay bot operator and community moderator ought to be separated, each with their own strategy for progression. At a minimum, users should be able to create spaces or channels where they moderate themselves and are able to elevate their own moderation team also.
Yes it uses realtime for the webxdc to work. But at the moment every message is relayed also as a normal message to the 1-on-1 chat with the bot, mainly to get DeltaChat notifications. (In the future notifications could be made customizable)
Yes it would be nice to have a way for users to leave (and maybe also do some cleanup on messages you wrote, i.e. change the sender to “deleted member”). For now it might be enough that you can simply delete the 1-on-1 chat with the bot. For now there is only /con and for now it’s only documented in this forum post.
Yes that’d be a good improvement, I agree!
Yes the purpose of this post is to show my experiment. If anyone is interested I might invest in the extra work needed to add features and cleanup the bot code to open-source it. That way anyone could create their own server.
Basic roles are already implemented, in the admin view user roles can be adjusted. An admin can also add/remove channels and delete any message. This was the MVP to show that basic moderation is possible.
Let me elaborate a bit more. Each bot needs to support a /stop command, otherwise if you delete the chat, it will keep coming back every time the bot sends a new message. If the user blocks the bot, it will still waste precious resources on your side and it may have side effects on their part.
I would highly suggest making the realtime channel use optional then if you can handle it. Many disable it for unknown apps (such as this one) and only have it enabled on accounts reserved for friends & family whom they trust.
Until you do, it would be ideal if the app could display an error message if it catches such an exception upon initialization to the effect that the user needs to enable realtime under settings for the app to work, otherwise they won’t know why the page is blank.
Also, maybe this would be too much to ask, but it would be a deed on your part if your bot could support communication through both webxdc updates and DC messages. This would enable use without the webxdc via slash commands. Such CLI could preferably be condensed, such as providing separate commands to switch channels, so you wouldn’t need to prefix each reply with the destination channel name. It could also parse when the user pressed the reply button and place the respective message in the respective channel. You could implement soft-muting channels and then only messages coming from unmuted channels would show on the chat (others could be polled via list and status slash commands). For efficiency reasons, you may decide to operate the bot in these two modes at separate addresses (or provide a mode switching slash command if this is easier for you).
Did you know that “Confluence” is the name of a widely know enterprise software package (and probably a bunch of other things)? Could you think about renaming the project and this topic before it gets known widely?
Also, if you already have a registration flow, you could mind as well identify members by their generated or hashed UUID or nick instead of their email address similarly to how it is done on PixelSocial.
Thanks for elaborating this. You are right, I added a /leave command.
I definitely see your point. I started this webxdc approach because I thought it’d be cool to realize this by using the bot to provide a web api for the webapp. Loading long message histories on demand could be realized in an intuitive way. But it complicates things a lot and I don’t think there is so much benefit in having the webxdc app at all. Only in the last step of my development I decided: let’s actually just forward all the messages also in the normal chat to get notifications. Then I realized similarly to you that a cli like interfice might actually be much nicer and more DC-native. I think I should also remove the channels concept, i.e. make a single DC-chat is just a single channel. All these simplifications would make this public chat easier to use and more robust.
Yes I know. I couldn’t come up with a better name and liked the river metaphore, DC becomes a ricer delta, and confluence can mean “the place where two rivers flow together and become one larger river”.
Yes I think a chosen username/nickname would be my preferred option.
I’m glad our views are aligned about this. It also occurred to me that we could start small by creating a single channel. The less complicated the server-side bot, the more sustainable it becomes to maintain it on the long run.
One of the major drawbacks of DC groups is the lack of a chat log for new joiners. If your bot could provide a service to fetch some of the recent messages (even if assembled into a single message), it could also be useful without moderation activated (i.e., if adding the bot to a group instead of a direct message).
Did you know that such a bot has the ability to fake its display name each message, mimicing each sender? Matterdelta (Matterbridge) implements relays this way also.
And despite the fact that some dislike the foreign appearance of the separate chat window of Pixel Social, I wouldn’t discount enhancing the appearance of Confluence with a webxdc later on. Especially if it could be done in a way that a single server could interconnect clients of both interface, such that each user could then choose how they want to participate in the group and possibly change their mind later on.
Some further ideas for a name: Chatfluence, Deltafluence, Group Relay, Group Filter, Chat Firewall, Delta-hub, Mod-Relay.
Another thing that came to mind. After such a bot makes it possible to moderate groups, it would become safe again to publish a directory about them for anyone to ask admittance. I think implementing related features would be a strategy of great impact. For example, group moderators could opt-in (opt-out?) of the directory, add a group description and keywords, while users could query groups from the directory and ask to join some of them. Every message of a new joiner would need to be reviewed by one of the group moderators before being forwarded to others until reaching a given trust level. Members should also have an easy way to report abuse to the group moderator (or in case of lack of response, to the relay operator).
No I didn’t know, thank you! Will have to look at it! Thanks for all this input, I also didn’t know about PixelSocial, the corresponding bot seems to have a quite similar concept to what I tried to build.
Maybe I will give that new simplified version of a public group chat bot a try some day.
I did some cleanup and published the source of the bot to a gist. It includes instructions how to run it so anyone interested can play around with it / create own servers: dc_webxdc_chatbot1.ipynb · GitHub
I will keep my bot instance running for a while, so people can more easily have a look and try it out.
While experimenting with a new version of a chat bot for public groups I discovered another issue with this approach. Even when I use my own chatmail-relay and increase the 60 msgs/sec there is still rate limiting built into the deltachat jsonrpc server which is used by the bot to send messages. Messages are queued and are sent at a rate of ~1 msg/sec (even when sending to chatmail relays), which would be far too slow.
Not sure how to proceed now. I could try to disable the hard-coded rate limiting but there is a good reason why it exists for sure.
I took part in one of the experimental chats, with 92 members at one point, and it was surprisingly smooth. I know that the bot had some issues due to excessive load by some spammer, but the overall impression is very good. Thank you for sharing the annotated source!
