9 Mar
2024
9 Mar
'24
1:15 p.m.
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.
11 Mar
11 Mar
9:28 a.m.
Hello list, daniel,
On Samstag, 9. März 2024 21:15:16 CET daniel(a)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
11:39 a.m.
On Mon, Mar 11, 2024 at 4:28 PM Jonas Schäfer <jonas(a)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
11:43 a.m.
* 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.
11:52 a.m.
On Mon, Mar 11, 2024 at 6:43 PM Stephen Paul Weber
<singpolyma(a)singpolyma.net> wrote:
What you are proposing depends on the message being archived. The
specification as written notably does not.
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.
69
days inactive
71
days old
4 comments
4 participants
participants (4)
-
Daniel Gultsch -
daniel＠gultsch.de
-
Jonas Schäfer -
Stephen Paul Weber