XSF Discussion - 2018-11-17

When doing multiple follow-up LMCs, do I reference the original message id or the follow-up message id?

> A single message may be corrected multiple times by subsequent edits. The XEP doesn't quite tackle that explicitly

Ge0rG, the original

Aslo should a client allow both?

IMO, no

I think yaxim will overwrite the stanza ID with the correction's ID.

I mean a _receiving_ client

poezio does the same.

so poezio will correct the last correction and not the original message?

So it means I need to support both?

The semantics are defined as replacing the message.

This includes the id.

Who promoted that shit to Draft?

Link Mauve, only payloads though

We have a linked list of older versions in the case the user wants to see a previous version, but we don’t recognise the old id as part of the discussion anymore.

> It is expected that the receiver SHOULD then treat the new stanza as complete replacement for all the payloads received in the original stanza.

> for all the payloads

the @id is arguably not payload

Ugh, I guess I missed that.

Would it be possible to get stuff, fliers/stickers/stuff to put on the table to say "Here is the XMPP assembly" (that I can maybe build with stickers myself)

for the CCC

pep.: SCAM team?

scam@ ?

https://signup.c3assemblies.de/assembly/982f5ea6-fcea-4c1e-965d-8ef478149ac0 ! (wondering if others can see that)

jonas’: how does JabberCat handle that correction-of-correction?

it doesn’t implement LMC yet

but in my mental model I was expecting to see the original ID

lovetox: which message ID does Gajim referene on a correction of a correction?

Conversations also corrects the last ID and not the original one

meh

then we’re doomed

Doooomed

or we could make a list of the pros and cons of the different approaches and after careful evaluation aggree on exactly one

flow, that sounds good

Ge0rG, would you care to take it to the list?

jonas’: you are lagging

sorry :)

I should keep a list somewhere of my questions to standards@ that never got answered

Ge0rG, you got an answer!

(but the list is probably still processing it)

he said blockchain!

:)

I'm surprised it got through the spam filters

hah

> he said blockchain! ITYM Smart Contracts

Gajim corrects the last message

i always thought its pretty clear what that means

protocol wise the last message that was sent out by the client

not what the user may think was the last message or what the UI shows him as last message

that’s also a nice rationale

this all does not change though that the XEP allows to correct every message

not only the last

its just a recommendation

requiring to correct the original @id and forgetting about the correction @id makes not-last message correction consistent though

otherwise you can make a tree of corrections :)

(well, you could also specify to forget the original @id and only keep the corrected one to fix that tree)

i always thought this works good, you basically make a linked list of messages, every message references the one before with a correction

I forget the old one

also, lovetox, daniel, to standards@ please

otherwise Ge0rG is sad that he doesn’t get on-list replies ;-)

lovetox: so just to be clear about. When you correct for the second time you correct the id of the previous connection not the original one?

yes

*Previous correction

the last message protocol wise

daniel: you are still listening, right?

the last message i sent out

Then four clients independently made the same decision

That seems pretty clear to me

I mean we can clear up the xep

yes please

BLOCKCHAIN!

I would’ve implemented it differently

but jonas’ is right, this implies a tree and not a list

Not if you forget the old one

Which lovetox and I are doing

but if we always reference the original, this is a star topology

flattened by timestamps

daniel: "forgetting" is an important point BTW, what if you only have the last N messages, and the original is N+1

and are you keeping the timestamp?

Not sure about timestamps

Ge0rG, then you already know which IDs you can ignore :)

I think I might use the new timestamp

But I can check later

in yaxim, the correction timestamp overrides the original one, moving the LMC to the bottom of the chat

Ge0rG, you cant know what message i want to correct

i send you a message with a reference to an id

and you correct that

you have to pre prepared to get a message referencing the last message you received

Can I propose YMC again

YMC?

Yolo message correction

Anyone can correct any message

oh dear

lovetox: I lost you.

i dont know why you care what message i correct

"the original" or some other message

when implementing that i didnt spend one thought about what messge another clients wants to correct and if its a original or not

lovetox, the question is then how you decide what is displayed, maybe?

I don’t konw, I can’t follow

message comes in -> has id ref -> look is that id the last message for that client -> yes -> overwrite that message in gui

which would break if your interpretation of what constitutes the "last message" diverged from everyone elses (which it doesn’t)

i.e. if everyone (except you) agreed that replacement does not create a new "last mesasge" and thus would be using @id of the original message, you wouldn’t be able to handle re-corrections at all (because your flow would discard it because it’s not hte "last message")

and this is why it’s sensible to think about this

correct

you just got lucky that your intuition matched that of others :)

(mine didn’t)

in my opinion this is a easy to follow rule that every client can check

the last message i received over the wire

every other definition depends on what you do with your UI

what you show the user

what you do in your db

not really

also

by that argument

do you allow corrections after you have seen Chat STate Notifications from a client?

or Chat Markers

which are also messages

thats not what i meant

but it’s the same thing :)

obviously we talking about stuff that has a body

not that obvious

my point is

you could treat corrections as meta-message just like CSN or Markers, apply its effect (replace previous messages payload) and not include it in the "messages" array.

it is not that obvious, is all I’m saying

how should i know that if i reference a id that is 3 messages back, is till the last message for your client?

dinner

because you don’t include the corrections in your list of "messages"

> A single message may be corrected multiple times by subsequent edits.

for me this is just stating that this is possible

lovetox: your ML message is as ambiguous as what you write in here. I can't follow you

what is ambiguous?

lovetox: in terms of the two examples you provided to Андрей, which one is Gajim sending out, and which one of those it understands when receiving?

that post was a question to the list

and not to answer your question

see my other ML reply to answer your question

lovetox: but your answer to my question also didn't answer my question

whats not clear about it?

how can the "last message that is sent over the wire" be ambiguous

?

lovetox: so you reference the id of the last correction?

or rather, previous correction

yes

i dont see the value in the other approach, instead of just checking the last message, you would have to check all messages between the original and the last correction

you must check that all these messages are corrections of the original, otherwise you would have to deny the correction

how will Gajim handle a received message correcting the original ID?

it denys all messages that dont reference the last message that was received

deny meaning its displayed not as correction

thanks

thats my idea of it, i never put it to a test in gajim though ^^

my idea how the code should work, and what it actually does are sometimes not the same thing

Hello. In XEP-0198 what happen if client specify a prefered maximum resumption time ("max" attribute) and server specify an other one? I don't see the point of having 2 different values (except if the server has a default value and overwritte it by client prefered value, but nothing like that is specified).

goffi: The client can specify a desired value, but the server decides.

Holger: OK thanks, in this case the formulation in the XEP is bad, it states "he <enabled/> element MAY include a 'max' attribute to specify the server's preferred maximum resumption time.", it's not preferred value, it's authority value: the one which will be used.

goffi: Revision 0.7 had this: > the <sm/> element MUST include a 'max' attribute that specifies the longest allowable time period for session resumption (in seconds). https://xmpp.org/extensions/attic/xep-0198-0.7.html

I guess in the end it's not really interesting for clients. I guess they'll usually just try to resume as fast as possible, and they must be prepared to handle a <failed/> resumption no matter whether they're within the 'max' time period or not.

yeah, i dont see how this is useful for the client

Holger: it's interesting for client to know when the session can be deleted.

I don't think it's really interesting to specify, as the server have authority anyway, but knowing when the session ends is useful, and it should be a "MUST" and not a "MAY" in my opinion (in <enabled/>).

goffi: At least with ejabberd, the timeout for a given session can change after <enabled/>, so I'm not sure ejabberd could adhere to such a MUST clause.

Holger: how does it changes ?

The server can be configured in a way that enabling of push notifications increases the timeout drastically. And then when an actual push notification is generated, the original timeout is restored. Stuff like that.