XEP-0308 allows to edit the last message of each full jid by the bare jid in direct messages. Which means I could technically edit another resources message. But when I do, I run into a race condition as that other resource could send another message shortly before my correction thus effectively making my correction "out of scope" of XEP-0308.
andrey.ghas left
larma
Also, when I send each message with a new resource, I could technically use XEP-0308 standards compliant to correct any message, not only the latest
larma
The issue with race condition also applies to editing in MUCs, due to multi session nicks
Ge0rG
larma: the scoping doesn't make much sense. I'd suggest you roll a D20 to determine how many recent messages you accept edits for, and only count those based on the sender's bare JID / identity
Ge0rG
larma: also you could hope that a user won't send a message from device A and *at the same time* edit an old message from device B
Zash
Aren't edits by id too?
larma
Ge0rG, question is not only for incoming but also outgoing. And "at the same time" could be caused by a mobile device coming back online and having that message still in its offline queue.
larma
Zash, yes, we do have the ID, but 0308 has some obscure rules beside ID (which seems to be so that legacy fallback can easier spot that it's a correction)
Ge0rG
larma: yaxim is limiting editing to the last 10 messages from the same sender
Ge0rG
larma: the XEP author said "editing other than the last message is out of scope of the XEP"
Ge0rG
and don't even get me started on which ID to edit in multi-edits.
larma
so yaxim allows incoming and outcoming edits that are not specified in any standard?
Ge0rG
yes.
Ge0rG
and it's even worse than that.
larma
And then other clients don't support those edits incoming I guess? So UX is crap
Ge0rG
yaxim allows edits in semi-anon MUCs originating from the same nickname, even if somebody stole the nickname
Ge0rG
larma: 🤷
larma
re nick stealing: 0421 to the rescue?
Bluehas left
Ge0rG
larma: 0421 has interesting issues of its own. But yes, it's on my long-term todo list
Ge0rG
which is probably just an elaborate way of saying: I don't care
Ge0rG
if you want to attach identity to nicknames in semi-anon MUCs, then register the nicknames or don't use semi-anon
larma
also, which clients will allow this correction-10-messages-ago incoming? And why 10? And is that the last 10 by bare jid, so if I write 1 message X with resource A and then >10 message with resource B, you don't allow correction of message X anymore (even though you should under XEP-0308)?
Ge0rG
larma: 1. yaxim, I don't care about the others. 2. It seemed like a good trade-off, given nobody else cared about it. 3. Yes, by bare JID (or by nickname in MUCs)
larma
Great, so we probably have a mix of incompatible rules for last message correction in various clients and even the spec is broken by design
Ge0rG
larma: indeed
larma
So, how do we fix this mess?
Ge0rG
larma: write a new XEP that extends 0308 to the last N messages.
pdurbinhas joined
lovetoxhas left
Ge0rG
larma: Daniel suggested YMC, "YOLO Message Correction", allowing to edit any messages regardless of age and sender.
Ge0rG
I can't find any relevant mail from me to standards, so it probably was buried in a Council meeting
larma
But when we do "any message correction", fallback body becomes pretty useless, no?
Ge0rG
fallback body of what?
larma
well fallback body of correction
Ge0rG
why should there be a *fallback* body?
larma
for clients not supporting it?
Zash
fallback body should be "I mean $message *"
Ge0rG
larma: there is no fallback body in 0308
larma
Ge0rG, well the body is the fallback
Ge0rG
larma: the body is the newbody.
larma
Well, it happens to have two usecases at the same time
larma
because legacy clients will display it as a normal message
larma
which is ok, if it really is the last message
larma
which is ok, if it really is the last message, see?
pdurbinhas left
Ge0rG
larma: so your point is: correcting an older message will lead to confusion in non-0308 client users?
larma
with 0308 we don't really have that problem due to its restriction to the last message.
larma
if we allow edits of older messages though, we get into trouble
Ge0rG
let me make a controversial proposal: editing of older messages should be restricted by their age, not by their amount.
larma
still the same issue, no?
Zash
Why not both‽
Ge0rG
it's happened to me many times that I sent a message, then another one, then realized I had a typo in the first one.
Ge0rG
larma: actually it's a much worse issue: time is relative
Zash
Sneak-edit of a message that has scrolled out of view seems about as bad as a sneak-edit of a 7 hour old message.
gavhas joined
larma
"sneak-edit"?
Zash
Snake edit?
Zash
Snape edit!
Zash
I mean an edit that you're unlikely to notice
Zash
Ie because it scrolled out of view.
larma
I don't consider those an issue really
Ge0rG
Zash: but how large is the view?
Zash
Either because time passed or because discussio
Zash
Ge0rG, three fiddy
Ge0rG
in yaxim, a view is roughly ten messages. See, I found a reason for the arbitrary number
Zash
Dice roll
larma
If I edit an old message that is probably scrolled out of view at the recipient, I must expect the edit not to be recognized by them
larma
that's ok
Ge0rG
larma: "But you said yes to my contract proposal, it's binding now!"
Ge0rG
the older a message, the lower the probability that you actually *need* to edit it.
larma
Ge0rG, "My client says 'Yes (edited)', and you changed to from 'No'"✎
larma
Ge0rG, "My client says 'Yes (edited)', and you changed it from 'No'" ✏
larma
Also, this seems to be a social issue, not a protocol issue.
Ge0rG
of course it is
larma
I can also edit paper contracts after you signed them, even without you noticing.
larma
I don't think we need to do better than reality here.
Ge0rG
larma: what limits do you consider sensible?
larma
No limit?
Ge0rG
edit everything?
larma
Yes, but I don't see the solution for the "not sure which message was edited" in the fallback case
gavhas left
larma
except not showing edits to legacy clients at all.
Ge0rG
larma: stop caring too much about legacy clients.
Ge0rG
if you edit the 11th-last message, yaxim will not merge the edit into the original, but will display this as a new message with an "edited" tag
larma
Ge0rG, legacy client = literally every client right now
Ge0rG
0308 is part of Advanced IM 2020
larma
Yes, but only the "version" accepting an edit of the last message of each full jid by the corresponding bare jid, which I bet nobody implements.
pep.
fwiw I was also considering with poezio taking into account more than the latest, in a proper way. poezio already does AMC in reading
pep.
(maybe unintentionally, dunno, it was the case when I joined)
pep.
and it's possible to send AMC with /rawxml (great UX!)
Ge0rG
larma: 0308 was adopted in 2013, that was long before my activity started.
andrey.ghas joined
Ge0rG
larma: I could theoretically imagine Council relaxing the "last message only" rule, but I wouldn't bet on it
debaclehas left
larma
Ge0rG, well my point is: If I fix a typo 10 messages ago, I don't want any client to display that typo-fixing as a new message, as it would just cause confusion. But I still want to be able to do those fixes.
Ge0rG
larma: I agree.
larma
So just changing XEP-0308 to allow AMC doesn't solve the issue
Ge0rG
larma: nothing will solve the issue right now.
Ge0rG
not even creating a new XEP that defines AMC on top of 0308.
pep.
larma, maybe using <body> for this is just wrong :P
Ge0rG
except maybe creating that new XEP and putting it into CS2021 and then waiting.
Ge0rG
pep.: please no!
pep.
<replace @id>correction</replace>
Dele Olajidehas joined
larma
creating a new XEP that defines AMC *outside* of 0308 so that legacy clients / 0308-clients do not display the correction at all would solve the issue.
larma
but that implies not using <body>
mukt2has joined
larma
Or precisely not using <body> in <message>
pep.
And then people want you to take into consideration non-implementing clients and you're back to square one
Ge0rG
pep.: easy: just add a legacy body into AMC!
larma
could still be <message><edit xmlns="urn:xmpp:edit:0"><body xmlns="jabber:client">Correction</body></edit></message>
Ge0rG
larma: that would make some sense indeed.
Ge0rG
would allow differentiating the *edited* part from the edit metadata part.
pep.
larma, I'm not sure I understand the intent
pep.
non-implementing clients won't understand this
larma
<message><body>/me edits "Corection" in message from 01:02:03 to "Correction"</body><edit xmlns="urn:xmpp:edit:0"><body xmlns="jabber:client">Correction</body></edit></message>
Ge0rG
Yeah.
pep.
ugh
larma
Fallback body *only* if I want legacy clients to display something of course
larma
(not in the case of fixing that one type)
pep.
Seeing the wire format of /me hurts every single time
lovetoxhas joined
pep.
larma, still not sure I understand the point of <body/> in <edit/>
pep.
Also in your fallback you included localtime
pep.
Or UTC, or ?
pep.
Which one is it
larma
Well the <body> in <message> is only for those clients that don't understand the <edit>. The client supporting <edit> will just edit the old message and not display the fallback at all.
pep.
I did say the <body> in <edit>
larma
yes, that's whay is used as a replacement for the body when the client supports <edit>
larma
because I might want to edit other elements than edit✎
pep.
Why do you need an extra child
pep.
ah ok
larma
because I might want to edit other elements than body ✏
pep.
That's the info I was missing
larma
And it also seems consistent to have the displayed body in the <body> element
pep.
If you could only edit <body>, I don't think so
pep.
I think it's being frowned upon anyway to edit anything else than <body/>, iiuc
larma
Well, if I upload a file, why not edit the description of the file (assuming a SIMS-alike file sending)
pep.
I'm personally fine with this
Ge0rG
why not replace the file with another one?
larma
or that
Ge0rG
I accidentally a dickpic.
larma
or if the file is a text file and has a typo in it
pep.
Ge0rG, the internet will have to live with it forever
larma
OK, solution was found, now just need someone to write the XEP 😀
larma
And then a council to accept it even if it's not making use of fastenings 😕
Ge0rG
larma: but it should make use of fastenings! You fasten the correction to the original message!
larma
Ge0rG, my message is end-to-end-encrypted with forward secrecy, I am not fastening anything because fastening is crap when having forward secrecy
larma
newsflash: OMEMO uses forward secrecy and is literally what made XMPP popular again
larma
but it's probably a sidecase we don't want to care about 😕
Bluehas joined
Blue
Can somebody smart explain me something about stanza id xep?
Ge0rG
Blue: if you find somebody smart...
mukt2has left
pep.
larma: everyone has a different opinion on what makes XMPP (not) popular :p
Blue
I'm pretty sure most of you here are smart on my terms =)
archas left
archas joined
Ge0rG
Blue: then maybe ask the question :)
larma
pep., yeah, I just needed my daily criticism of the reactions decision, didn't want to actually make a point here 😉
pep.
hehe
Zash
What if we lock all stakeholders in a room until the whole reactions thing is resolved?
pep.
that is, everybody kills each other?
flow
larma> Fallback body *only* if I want legacy clients to display something of course
that's also the approach which I would be pursuing
Blue
So, there is nice and cool "id" attribute for the message. You can edit retract confirm delivery with that and so much more. Basically - da heck is stansa id? How to behave with it?
flow
larma> Well, if I upload a file, why not edit the description of the file (assuming a SIMS-alike file sending)
that a nice idea, but I fear it is far easier to implement just re-issuing the SIMS
pep.
flow, then a client displays two "media" thing?
pep.
For ""the same"" file
flow
pep., maybe, or it does only display the corrected SIMS, while still allowing data fetches of the old SIMS
larma
Blue, id attribute and <origin-id> id attribute should be the same. <stanza-id> is important for MUCs and MAM.
Ge0rG
Blue: old clients don't generate a unique id attribute.
pep.
Ah, fight on 0359, that's also something I was curious about
LNJhas left
Ge0rG
and <stanza-id> is added by somebody else than the sender, typically an archive
flow
Blue, if something doesn't explicitly talk about xep359 IDs then use the RFC 6120 IDs
MattJ
Blue, the 'id' attribute is optional, and set by the first entity to generate the stanza. It may not be present, and it may not be unique. The stanza-id element allows other entities (such as a client's server) to inject their own ids.
LNJhas joined
MattJ
The id attribute is useful for short-term error tracking, stanza-id is useful for an entity to assign a more permanent unique id to a stanza (and it's not limited to just one)
MattJ
and origin-id is mostly a hack that we've discussed potentially removing in the past (though it has a couple of useful properties)
Ge0rG
I'm interested in those useful properties, beyond virtue signaling of "proper" ID generation
Blue
I just don't get how to treat them. You see, I have sort of message order in my lil app. I ordered them using ID attribute. Do i need the same order of stansaIds pointing to the same messages? Or do I just replace my pointing to the message id with newly discovered stansa id? Then how do I discover the stansa id server assigned to my outgoing message? There are attachements to the messages described in some xep, they go to stansa id, but i just checked message corrections - they go only to origin ids.... I'm a bit lost and confused =)
MattJ
None of the ids are guaranteed to be sortable
MattJ
So you can't use them for order
MattJ
There is currently no (sensible) way to discover the stanza-id assigned by the server to an outgoing stanza, that's something that will hopefully be fixed at some point
Blue
but that doesn't make sence... There is sorted by time stream of messages...
contrapunctushas joined
MattJ
Sure, I'm not saying messages don't have an order. I'm saying that ids are not used to convey the order.
Blue
but... how to query the history then?
LNJhas left
MattJ
You can still query from the last incoming message
LNJhas joined
Blue
but I cant relay on time either - it's also optional (stamp if I'm not mistaken) and a little to approximate, isn't it?
MattJ
Yes, don't use time
zzzedhas joined
Zash
Time where?
MattJ
Anywhere
Zash
I do have this "origin-time" draft...
zzzed
Hello, when i try to start private convesation (otr) and to generate fingerprints app instant close
zzzed
any help?
archas left
archas joined
archas left
archas joined
Blue
so... for that reason I build an order of messages, but seems like I have miscalculated about the id's I use in that order
zzzedhas left
zzzedhas joined
zzzed
anyone to help me out?
archas left
archas joined
zzzed
Kev MattJ ralphm
Nekithas left
archas left
archas joined
Zashhas left
Zashhas joined
zzzed
am
zzzed
intosi
zzzed
admin
MattJ
zzzed, you're asking the wrong people in the wrong channel
MattJ
Stop highlighting people for no reason please
zzzed
aha , where should i finde help then?
MattJ
What app are you using?
zzzed
you dont need to be rude at all , you can say on nice way
zzzed
PSI
MattJ
https://search.jabber.network/search?q=psi
zzzed
thanks
zzzed
have a nice day
MattJ
You too
zzzedhas left
adiaholic_has left
adiaholic_has joined
alexishas left
Wojtekhas joined
debaclehas joined
Jeybehas left
Jeybehas joined
Jeybehas left
Jeybehas joined
Jeybehas left
Jeybehas joined
lovetoxhas left
pdurbinhas joined
Jeybehas left
Jeybehas joined
lorddavidiiihas left
lorddavidiiihas joined
Jeybehas left
Jeybehas joined
archas left
archas joined
pdurbinhas left
jonas’
does anyone have a clue about those ref files we generate for XEPs?
jonas’
https://github.com/xsf/xeps/pull/938
jonas’
I’d love to get a review on that one before hiting the green button
flow
jonas’, lgtm
jonas’
flow, can you add a review on github please?
flow
those are mostly used by https://xml2rfc.tools.ietf.org/
mukt2has joined
flow
and as you can see, e.g. https://xmpp.org/extensions/refs/reference.XSF.XEP-0435.xml has no target