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 <[email protected]> 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 -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ Standards mailing list -- [email protected] To unsubscribe send an email to [email protected]
