[Standards] Re: Proposed XMPP Extension: Message Displayed Synchronization
On Mon, Mar 11, 2024 at 6:43 PM Stephen Paul Weber wrote: > > >* The server assist was added because of the feature request that the > >server parses . 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 ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
[Standards] Re: Proposed XMPP Extension: Message Displayed Synchronization
* The server assist was added because of the feature request that the server parses . 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. signature.asc Description: PGP signature ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
[Standards] Re: Proposed XMPP Extension: Message Displayed Synchronization
On Mon, Mar 11, 2024 at 4:28 PM Jonas Schäfer wrote: > - Server assist should specify exactly when the modification of the > stanza happens. In particular, the interaction with MAM, Carbons and > potentially IM-NG should be spelled out (i.e.: is the 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 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 . 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 "" to block "foo". This has come up in the group chat before. Maybe I'll add something to the Design Considerations cheers Daniel ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
[Standards] Re: Proposed XMPP Extension: Message Displayed Synchronization
Hello list, daniel, On Samstag, 9. März 2024 21:15:16 CET dan...@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 stanza happens. In particular, the interaction with MAM, Carbons and potentially IM-NG should be spelled out (i.e.: is the part of the archive and/or the carbons reflection?). - Server assist could be extended to make the server discard the message iff the 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 signature.asc Description: This is a digitally signed message part. ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
