-
larma
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.
-
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?
-
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.
-
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?
-
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.
-
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
-
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.
-
Ge0rG
larma: I could theoretically imagine Council relaxing the "last message only" rule, but I wouldn't bet on it
-
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>
-
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>
-
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
-
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 😕
-
Blue
Can somebody smart explain me something about stanza id xep?
-
Ge0rG
Blue: if you find somebody smart...
-
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 =)
-
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
-
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.
-
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...
-
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?
-
MattJ
You can still query from the last incoming message
-
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
-
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?
-
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
-
zzzed
anyone to help me out?
-
zzzed
Kev MattJ ralphm
-
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
-
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/
-
flow
and as you can see, e.g. https://xmpp.org/extensions/refs/reference.XSF.XEP-0435.xml has no target
-
flow
int the root note✎ -
flow
in the root node ✏
-
flow
wheras https://xml2rfc.tools.ietf.org/public/rfc/bibxml2/reference.NIST.SP.800-185.xml has
-
jonas’
flow, good, can you add that as a review on github?
-
jonas’
thx
-
Zash
What are this?
-
flow
Zash, "this"?
-
Zash
These refs things
-
flow
those ref entries are consumed by xml2rfc and can be used as references in I-Ds and RFCs
-
flow
think of biblatex entries for RFCs
-
Zash
Oh-kay