XSF Discussion - 2024-02-22

> as per summit discussion: https://gultsch.de/files/xep-mds.html I filled in some of the missing sections and incorporated the early feedback I received yesterday.

Daniel: > To update the the displayed item

Hmm so it's not possible to use the server help when not doing chat markers? :/

It'd have to keep wasting cycles sending pep stuff itself?

That's the current idea yes

:/

Also.. > Receiving an outgoing message (for example via Message Carbons (XEP-0280) [1] or Message Archive Management (XEP-0313) [4]) SHOULD mark the chat as displayed up to the point of that message. This I mentioned yesterday, i'd rather have this implementation defined

Because my client is fetching mam doesn't mean I scrolled down

But a different client likely has or there wouldn't be a message, no?

I can be reading the backlog and sending messages at the same time

In fact I do this pretty often

Marking as read should be an explicit step, I agree with (what I think) pep says.

That's a valid argument. But if there is consensus around this I'd rather change the xep to say the opposite rather than make this implementation dependent

I just checked and Slack also doesn't mark your messages as read just because you send one in the same channel

Daniel, I would argue that it depends on the situation

but then it's implementation dependent anyway what is considered "displayed"

If I reply from within the Android notification in Conversations, I would certainly expect the message I'm replying to to be marked as displayed

Why, though? Given that read is a sequence state, rather than just that message.

larma: I wouldn't. What if I haven't read all in between

It seems quite reasonable to reply to a message in a notification without having read the rest of the chat.

Sure, but you certainly read the message you are replying to, no?

The one message yes

Yes, but marking that read would mark the rest of the chat read, and that's not true.

This is a read-up-to marker, essentially, right?

Yeah that's what it is

True, but that's an inherent issue with read-up-to markers

Read-up-to markers inherently have some issues, certainly, but I don't think marking things as read because the server saw an outgoing message is inherent.

I agree to that, because the server lacks context that the client has

What's the issue here? Don't mark it as displayed, done :p

that's why I said that the client might consider the sending of a message as a reason to mark a message as displayed

which makes it implementation dependent if the client does it or not

the server should not

> that's why I said that the client might consider the sending of a message as a reason to mark a message as displayed I misunderstood - I thought you were saying it was reasonable for the server to mark as read once the client had sent a message. I was arguing the wrong point.

Well in the case you mentioned, I would argue C shouldn't.

Oh

So I think 'server marks as read because client sends message' should not be implementation dependent - it should be 'MUST NOT'. While 'when a client chooses to mark as read', I would agree as being implementation dependent - as it heavily depends on the UI properties of the client.

pep., well it depends on how many messages are unread for example. If there is a single message unread and that's what you got the notification for, a reply to this message can reasonably be assumed to mean that the message was read

Kev, agreed.

larma: sure

Also why isn't it possible to allow that optimisation for one's own devices too? (my first comment). It's it something technical?

I mean the server optimisation thing

Without using markers

Huh, you don't need to send chat markers, no?

Is it*

Currently it is worded that you have to

> This specification provides a convenient process to synchronize a user’s own devices and informing the third party in one, single message. However letting the third party know is not always desirable, for example when the user has generally opted out of transmitting the displayed status or when a non-contact initiated a chat. In those cases the client MUST use the Publish-Subscribe (XEP-0060) [8] method instead of server-assist.

Daniel, you mean https://gultsch.de/files/xep-mds.html#sect-id12 ?

Because the server removes the mds displayed and then would have to either route an empty stanza or drop the stanza ✏

But you can still send a message with other content (like a reply) and within that include a mds <displayed /> that is stripped by the server, no? ✏

Yes I think that would technically be allowed

But weird timing

What about a headline to your bare JID containing only an MDS? :)

What's the advantage over the pubsub thing? It's still one stanza to be sent with approximately same size

Advantage to the headline? Not much at all.

My reasoning was that doing the regular pubsub publish is 'fine'

I think that's likely true. Or at least, I don't see why it isn't.

Yeah, that's why I wouldn't consider it an "optimization" (which is what the <displayed /> thing is for) (this was a reply to Kev's previous message) ✏

How so? Isn't that still one more step than not doing this optimisation? In one it's included in the one message sent, in the other the client has to send an additional pubsub query ✏

(which is also broadcasted back to the sender, not so useful. But I guess that's pubsub..)

(though that can be configured maybe?)

If you are counting stanzas both approaches currently in the xep have the same number of stanzas

One is just a bit smaller

Wait you mean for this "optimisation" that's an additional message?

Not included in the original?

If you are doing the server assist you put both displayed in one message (and thus let your contact know) If you are doing pubsub publish you do one pubsub publish

And no message

Ok I've never actually read 333 (I dont use it), I didn't think it had to be a seperate step ✏

(does it?)

Separate to what?

Why not send mds in example 7, what's the case against it?

That's the incoming message

The one Juliet is going to read

Ah pff ok. But juliet could have included it too right?

Whether or not Romeo did mds on his end is irrelevant

Fail, Romeo* could have included it too

Well that's my question

But usually Romeo likely wouldn't do either displayed in the same message that he puts a body in

Why not

Because the read would have happened earlier

Then typing the response

Hmm

There should be a markable in example 7 though...

Ok I see

(note to self)