Proposed XMPP Extension: Message Displayed Synchronization
The XMPP Extensions Editor has received a proposal for a new XEP. Title: Message Displayed Synchronization Abstract: This specification allows multiple clients of the same user to synchronize the displayed state of their chats. URL: https://xmpp.org/extensions/inbox/xep-mds.html The Council will decide in the next two weeks whether to accept this proposal as an official XEP.
Hello list, daniel, On Samstag, 9. März 2024 21:15:16 CET daniel@gultsch.de wrote:
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: Message Displayed Synchronization Abstract: This specification allows multiple clients of the same user to synchronize the displayed state of their chats.
URL: https://xmpp.org/extensions/inbox/xep-mds.html
The Council will decide in the next two weeks whether to accept this proposal as an official XEP.
I would like to point out two things in regards to this specification: - Server assist should specify exactly when the modification of the <message/> stanza happens. In particular, the interaction with MAM, Carbons and potentially IM-NG should be spelled out (i.e.: is the <displayed xmlns="..mds.."/> part of the archive and/or the carbons reflection?). - Server assist could be extended to make the server discard the message iff the <displayed xmlns="..mds.."/> element is the only content in that message. That way, server assist could also be used with non-contacts or similar situations. Thanks for the spec! kind regards, Jonas
On Mon, Mar 11, 2024 at 4:28 PM Jonas Schäfer <jonas@wielicki.name> wrote:
- Server assist should specify exactly when the modification of the <message/> stanza happens. In particular, the interaction with MAM, Carbons and potentially IM-NG should be spelled out (i.e.: is the <displayed xmlns="..mds.."/> part of the archive and/or the carbons reflection?).
You are right. I will prepare wording to be added after the XEP has been accepted.
- Server assist could be extended to make the server discard the message iff the <displayed xmlns="..mds.."/> element is the only content in that message. That way, server assist could also be used with non-contacts or similar situations.
I’m against this for the following reasons. * The server assist was added because of the feature request that the server parses <displayed xmlns="urn:xmpp:chat-markers:0"/>. However this puts unnecessary burden on the server because the server then has to look up the stanza-id from the message-id (which is used by Displayed Markers (Chat Markers)). So with that feature request / requirement in mind NOT allowing otherwise empty messages doesn’t take anything away. * It is not that hard to just do a regular PEP publish * Overloading the semantic of "sending a stanza to x" with "performing an operation on the account that involves x" is a slippery slope that I’m really trying to avoid. I don’t want to set precedence to for example to use "<message to="foo"><block/></message>" to block "foo". This has come up in the group chat before. Maybe I'll add something to the Design Considerations cheers Daniel
* The server assist was added because of the feature request that the server parses <displayed xmlns="urn:xmpp:chat-markers:0"/>. However this puts unnecessary burden on the server because the server then has to look up the stanza-id from the message-id (which is used by Displayed Markers (Chat Markers)). So with that feature request / requirement in mind NOT allowing otherwise empty messages doesn’t take anything away.
I would ideally prefer this burden on the server over the way it is specced now, but there would need to be some way for the server to know that eg in MUC the id is in fact the stanza id vs doing the lookup in MAM for non-MUC.
On Mon, Mar 11, 2024 at 6:43 PM Stephen Paul Weber <singpolyma@singpolyma.net> wrote:
* The server assist was added because of the feature request that the server parses <displayed xmlns="urn:xmpp:chat-markers:0"/>. However this puts unnecessary burden on the server because the server then has to look up the stanza-id from the message-id (which is used by Displayed Markers (Chat Markers)). So with that feature request / requirement in mind NOT allowing otherwise empty messages doesn’t take anything away.
I would ideally prefer this burden on the server over the way it is specced now, but there would need to be some way for the server to know that eg in MUC the id is in fact the stanza id vs doing the lookup in MAM for non-MUC.
What you are proposing depends on the message being archived. The specification as written notably does not. cheers Daniel
participants (4)
-
Daniel Gultsch -
daniel＠gultsch.de
-
Jonas Schäfer -
Stephen Paul Weber