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.
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