28 May
2024
28 May
'24
1:06 a.m.
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.
28 May
28 May
3:33 a.m.
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
4:16 p.m.
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.
29 May
29 May
12:29 p.m.
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
1:36 p.m.
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? 
1:40 p.m.
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
645
days inactive
647
days old
5 comments
4 participants
participants (4)
-
Andrew Nenakhov -
avidseeker7＠protonmail.com -
Nicolas Cedilnik -
Stephen Paul Weber