Ge0rGWhen doing multiple follow-up LMCs, do I reference the original message id or the follow-up message id?
Ge0rG> A single message may be corrected multiple times by subsequent edits.
The XEP doesn't quite tackle that explicitly
jonas’Ge0rG, the original
Ge0rGAslo should a client allow both?
Ge0rGI think yaxim will overwrite the stanza ID with the correction's ID.
Ge0rGI mean a _receiving_ client
Link Mauvepoezio does the same.
Ge0rGso poezio will correct the last correction and not the original message?
Ge0rGSo it means I need to support both?
Link MauveThe semantics are defined as replacing the message.
Link MauveThis includes the id.
Ge0rGWho promoted that shit to Draft?
jonas’Link Mauve, only payloads though
Link MauveWe 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.
jonas’> It is expected that the receiver SHOULD then treat the new stanza as complete replacement for all the payloads received in the original stanza.
jonas’> for all the payloads
jonas’the @id is arguably not payload
Link MauveUgh, I guess I missed that.
pep.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)
pep.for the CCC
Ge0rGpep.: SCAM team?
pep.https://signup.c3assemblies.de/assembly/982f5ea6-fcea-4c1e-965d-8ef478149ac0 ! (wondering if others can see that)
Ge0rGjonas’: how does JabberCat handle that correction-of-correction?
jonas’it doesn’t implement LMC yet
jonas’but in my mental model I was expecting to see the original ID
Ge0rGlovetox: which message ID does Gajim referene on a correction of a correction?
Ge0rGConversations also corrects the last ID and not the original one
jonas’then we’re doomed
flowor we could make a list of the pros and cons of the different approaches and after careful evaluation aggree on exactly one
jonas’flow, that sounds good
jonas’Ge0rG, would you care to take it to the list?
Ge0rGjonas’: you are lagging
Ge0rGI should keep a list somewhere of my questions to standards@ that never got answered
jonas’Ge0rG, you got an answer!
jonas’(but the list is probably still processing it)
flowhe said blockchain!
MattJI'm surprised it got through the spam filters
Ge0rG> he said blockchain!
ITYM Smart Contracts
lovetoxGajim corrects the last message
lovetoxi always thought its pretty clear what that means
lovetoxprotocol wise the last message that was sent out by the client
lovetoxnot what the user may think was the last message or what the UI shows him as last message
jonas’that’s also a nice rationale
lovetoxthis all does not change though that the XEP allows to correct every message
lovetoxnot only the last
lovetoxits just a recommendation
jonas’requiring to correct the original @id and forgetting about the correction @id makes not-last message correction consistent though
jonas’otherwise you can make a tree of corrections :)
jonas’(well, you could also specify to forget the original @id and only keep the corrected one to fix that tree)
lovetoxi always thought this works good, you basically make a linked list of messages, every message references the one before with a correction
danielI forget the old one
jonas’also, lovetox, daniel, to standards@ please
jonas’otherwise Ge0rG is sad that he doesn’t get on-list replies ;-)
daniellovetox: 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?
lovetoxthe last message protocol wise
Ge0rGdaniel: you are still listening, right?
lovetoxthe last message i sent out
danielThen four clients independently made the same decision
danielThat seems pretty clear to me
danielI mean we can clear up the xep
jonas’I would’ve implemented it differently
Ge0rGbut jonas’ is right, this implies a tree and not a list
danielNot if you forget the old one
danielWhich lovetox and I are doing
Ge0rGbut if we always reference the original, this is a star topology
jonas’flattened by timestamps
Ge0rGdaniel: "forgetting" is an important point BTW, what if you only have the last N messages, and the original is N+1
Ge0rGand are you keeping the timestamp?
danielNot sure about timestamps
jonas’Ge0rG, then you already know which IDs you can ignore :)
danielI think I might use the new timestamp
danielBut I can check later
Ge0rGin yaxim, the correction timestamp overrides the original one, moving the LMC to the bottom of the chat
lovetoxGe0rG, you cant know what message i want to correct
lovetoxi send you a message with a reference to an id
lovetoxand you correct that
lovetoxyou have to pre prepared to get a message referencing the last message you received
danielCan I propose YMC again
danielYolo message correction
danielAnyone can correct any message
Ge0rGlovetox: I lost you.
lovetoxi dont know why you care what message i correct
lovetox"the original" or some other message
lovetoxwhen implementing that i didnt spend one thought about what messge another clients wants to correct and if its a original or not
jonas’lovetox, the question is then how you decide what is displayed, maybe?
jonas’I don’t konw, I can’t follow
lovetoxmessage comes in -> has id ref -> look is that id the last message for that client -> yes -> overwrite that message in gui
jonas’which would break if your interpretation of what constitutes the "last message" diverged from everyone elses (which it doesn’t)
jonas’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")
jonas’and this is why it’s sensible to think about this
jonas’you just got lucky that your intuition matched that of others :)
lovetoxin my opinion this is a easy to follow rule that every client can check
lovetoxthe last message i received over the wire
lovetoxevery other definition depends on what you do with your UI
lovetoxwhat you show the user
lovetoxwhat you do in your db
jonas’by that argument
jonas’do you allow corrections after you have seen Chat STate Notifications from a client?
jonas’or Chat Markers
jonas’which are also messages
lovetoxthats not what i meant
jonas’but it’s the same thing :)
lovetoxobviously we talking about stuff that has a body
jonas’not that obvious
lovetoxmy point is
jonas’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.
jonas’it is not that obvious, is all I’m saying
lovetoxhow should i know that if i reference a id that is 3 messages back, is till the last message for your client?
jonas’because you don’t include the corrections in your list of "messages"
lovetox> A single message may be corrected multiple times by subsequent edits.
lovetoxfor me this is just stating that this is possible
Ge0rGlovetox: your ML message is as ambiguous as what you write in here. I can't follow you
lovetoxwhat is ambiguous?
Ge0rGlovetox: in terms of the two examples you provided to Андрей, which one is Gajim sending out, and which one of those it understands when receiving?
lovetoxthat post was a question to the list
lovetoxand not to answer your question
lovetoxsee my other ML reply to answer your question
Ge0rGlovetox: but your answer to my question also didn't answer my question
lovetoxwhats not clear about it?
lovetoxhow can the "last message that is sent over the wire" be ambiguous
Ge0rGlovetox: so you reference the id of the last correction?
Ge0rGor rather, previous correction
lovetoxi 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
lovetoxyou must check that all these messages are corrections of the original, otherwise you would have to deny the correction
Ge0rGhow will Gajim handle a received message correcting the original ID?
lovetoxit denys all messages that dont reference the last message that was received
lovetoxdeny meaning its displayed not as correction
lovetoxthats my idea of it, i never put it to a test in gajim though ^^
lovetoxmy idea how the code should work, and what it actually does are sometimes not the same thing
goffiHello. 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).
Holgergoffi: The client can specify a desired value, but the server decides.
goffiHolger: 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.
Andrew Nenakhovhas joined
Holgergoffi: 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).
HolgerI 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.
lovetoxyeah, i dont see how this is useful for the client
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
Link Mauvehas left
Link Mauvehas joined
Andrew Nenakhovhas left
goffiHolger: it's interesting for client to know when the session can be deleted.
goffiI 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/>).
Andrew Nenakhovhas joined
Holgergoffi: 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.
goffiHolger: how does it changes ?
HolgerThe 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.