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(a)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(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org