I am an end-user, and having used Telegram for some time, it offers a more fine-grained control over members of a group. One of those controls is to prevent group members (usually bots) from reading group messages, and only allow them to send messages, following the principle of least privilege. A more complex set up would be partially allow them to read messages directed to them and exclude the rest of messages. E.g: by specifying a command like /bot, the bot can read the content of that message to process it then reply back.
Here are more restrictions Telegram provides for controlling users in groups: https://i.imgur.com/w1mYzZ2.png Transcription: --- What can this member do? * Send messages * Send media * Add members * Pin messages * Change group info Restricted until: * Forever * For 1 day * For 1 week * Custom
What can this member do? * Send messages * Send media * Add members * Pin messages * Change group info
Restricted until: * Forever * For 1 day * For 1 week * Custom
These all seem like things an XMPP server could choose to support. I don't think there's any standards work blocking such an implementation.
I also think that having "publicly available bots" that non-technical users could invite to their private room while maintaining decent privacy would be good. Hosting a bot may be trivial to readers here, but I think we can't reasonably expect all users to be able to set it up.
These all seem like things an XMPP server could choose to support. I don't think there's any standards work blocking such an implementation.
It could be implemented, but wouldn't it require breaking compliance with XEP-0045 by introducing a new send-only role, cf <https://xmpp.org/extensions/xep-0045.html#table-3>?
A more complex set up would be partially allow them to read messages directed to them and exclude the rest of messages.
MUC PMs would work for this, wouldn't they?
E.g: by specifying a command like /bot, the bot can read the content of that message to process it then reply back.
This sounds a bit too complex to me, especially when using E2EE. -- Nicolas
These all seem like things an XMPP server could choose to support. I don't think there's any standards work blocking such an implementation.
It could be implemented, but wouldn't it require breaking compliance with XEP-0045 by introducing a new send-only role, cf <https://xmpp.org/extensions/xep-0045.html#table-3>?
You don't need a new role in order for the server to treat a member differently. Role is just outward facing metadata vaguely sunmarizing *part* of the internal state.
A more complex set up would be partially allow them to read messages directed to them and exclude the rest of messages.
MUC PMs would work for this, wouldn't they?
Yes. Or could do as I do in muc_adhoc_bots module and "install on the room" so there is no participant at all but eg adhoc commands can be added to the room. This is probably a good fit for most send-only sttle bots and works already today.
Early on in our implementation of our group chat protocol, we had a separate 'send messages' and 'receive messages' rights, but then decided that no chat entity would be necessary that would not have a capability to receive all messages and we opted out of it in implementation. The case presented by avidseeker7 actually makes me thinking to bring this right back in our implementation. It is actually quite easy to do. On Wed, 29 May 2024 at 15:30, Nicolas Cedilnik <nicoco@nicoco.fr> wrote:
I also think that having "publicly available bots" that non-technical users could invite to their private room while maintaining decent privacy would be good. Hosting a bot may be trivial to readers here, but I think we can't reasonably expect all users to be able to set it up.
These all seem like things an XMPP server could choose to support. I don't think there's any standards work blocking such an implementation.
It could be implemented, but wouldn't it require breaking compliance with XEP-0045 by introducing a new send-only role, cf <https://xmpp.org/extensions/xep-0045.html#table-3>?
A more complex set up would be partially allow them to read messages directed to them and exclude the rest of messages.
MUC PMs would work for this, wouldn't they?
E.g: by specifying a command like /bot, the bot can read the content of that message to process it then reply back.
This sounds a bit too complex to me, especially when using E2EE.
-- Nicolas
_______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
participants (4)
-
Andrew Nenakhov -
avidseeker7＠protonmail.com -
Nicolas Cedilnik -
Stephen Paul Weber