larmaXEP-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
larmaAlso, 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
larmaThe issue with race condition also applies to editing in MUCs, due to multi session nicks
Ge0rGlarma: 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
Ge0rGlarma: 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
ZashAren't edits by id too?
larmaGe0rG, 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.
larmaZash, 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)
Ge0rGlarma: yaxim is limiting editing to the last 10 messages from the same sender
Ge0rGlarma: the XEP author said "editing other than the last message is out of scope of the XEP"
Ge0rGand don't even get me started on which ID to edit in multi-edits.
larmaso yaxim allows incoming and outcoming edits that are not specified in any standard?
Ge0rGyes.
Ge0rGand it's even worse than that.
larmaAnd then other clients don't support those edits incoming I guess? So UX is crap
Ge0rGyaxim allows edits in semi-anon MUCs originating from the same nickname, even if somebody stole the nickname
Ge0rGlarma: 🤷
larmare nick stealing: 0421 to the rescue?
Bluehas left
Ge0rGlarma: 0421 has interesting issues of its own. But yes, it's on my long-term todo list
Ge0rGwhich is probably just an elaborate way of saying: I don't care
Ge0rGif you want to attach identity to nicknames in semi-anon MUCs, then register the nicknames or don't use semi-anon
larmaalso, 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)?
Ge0rGlarma: 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)
larmaGreat, so we probably have a mix of incompatible rules for last message correction in various clients and even the spec is broken by design
Ge0rGlarma: indeed
larmaSo, how do we fix this mess?
Ge0rGlarma: write a new XEP that extends 0308 to the last N messages.
pdurbinhas joined
lovetoxhas left
Ge0rGlarma: Daniel suggested YMC, "YOLO Message Correction", allowing to edit any messages regardless of age and sender.
Ge0rGI can't find any relevant mail from me to standards, so it probably was buried in a Council meeting
larmaBut when we do "any message correction", fallback body becomes pretty useless, no?
Ge0rGfallback body of what?
larmawell fallback body of correction
Ge0rGwhy should there be a *fallback* body?
larmafor clients not supporting it?
Zashfallback body should be "I mean $message *"
Ge0rGlarma: there is no fallback body in 0308
larmaGe0rG, well the body is the fallback
Ge0rGlarma: the body is the newbody.
larmaWell, it happens to have two usecases at the same time
larmabecause legacy clients will display it as a normal message
larmawhich is ok, if it really is the last message
larmawhich is ok, if it really is the last message, see?
pdurbinhas left
Ge0rGlarma: so your point is: correcting an older message will lead to confusion in non-0308 client users?
larmawith 0308 we don't really have that problem due to its restriction to the last message.
larmaif we allow edits of older messages though, we get into trouble
Ge0rGlet me make a controversial proposal: editing of older messages should be restricted by their age, not by their amount.
larmastill the same issue, no?
ZashWhy not both‽
Ge0rGit's happened to me many times that I sent a message, then another one, then realized I had a typo in the first one.
Ge0rGlarma: actually it's a much worse issue: time is relative
ZashSneak-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"?
ZashSnake edit?
ZashSnape edit!
ZashI mean an edit that you're unlikely to notice
ZashIe because it scrolled out of view.
larmaI don't consider those an issue really
Ge0rGZash: but how large is the view?
ZashEither because time passed or because discussio
ZashGe0rG, three fiddy
Ge0rGin yaxim, a view is roughly ten messages. See, I found a reason for the arbitrary number
ZashDice roll
larmaIf 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
larmathat's ok
Ge0rGlarma: "But you said yes to my contract proposal, it's binding now!"
Ge0rGthe older a message, the lower the probability that you actually *need* to edit it.
larmaGe0rG, "My client says 'Yes (edited)', and you changed to from 'No'"
larmaGe0rG, "My client says 'Yes (edited)', and you changed it from 'No'"
larmaAlso, this seems to be a social issue, not a protocol issue.
Ge0rGof course it is
larmaI can also edit paper contracts after you signed them, even without you noticing.
larmaI don't think we need to do better than reality here.
Ge0rGlarma: what limits do you consider sensible?
larmaNo limit?
Ge0rGedit everything?
larmaYes, but I don't see the solution for the "not sure which message was edited" in the fallback case
gavhas left
larmaexcept not showing edits to legacy clients at all.
Ge0rGlarma: stop caring too much about legacy clients.
Ge0rGif 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
larmaGe0rG, legacy client = literally every client right now
Ge0rG0308 is part of Advanced IM 2020
larmaYes, 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!)
Ge0rGlarma: 0308 was adopted in 2013, that was long before my activity started.
andrey.ghas joined
Ge0rGlarma: I could theoretically imagine Council relaxing the "last message only" rule, but I wouldn't bet on it
debaclehas left
larmaGe0rG, 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.
Ge0rGlarma: I agree.
larmaSo just changing XEP-0308 to allow AMC doesn't solve the issue
Ge0rGlarma: nothing will solve the issue right now.
Ge0rGnot even creating a new XEP that defines AMC on top of 0308.
pep.larma, maybe using <body> for this is just wrong :P
Ge0rGexcept maybe creating that new XEP and putting it into CS2021 and then waiting.
Ge0rGpep.: please no!
pep.<replace @id>correction</replace>
Dele Olajidehas joined
larmacreating 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.
larmabut that implies not using <body>
mukt2has joined
larmaOr 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
Ge0rGpep.: easy: just add a legacy body into AMC!
larmacould still be <message><edit xmlns="urn:xmpp:edit:0"><body xmlns="jabber:client">Correction</body></edit></message>
Ge0rGlarma: that would make some sense indeed.
Ge0rGwould 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>
Ge0rGYeah.
pep.ugh
larmaFallback 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
larmaWell 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>
larmayes, that's whay is used as a replacement for the body when the client supports <edit>
larmabecause I might want to edit other elements than edit
pep.Why do you need an extra child
pep.ah ok
larmabecause I might want to edit other elements than body
pep.That's the info I was missing
larmaAnd 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
larmaWell, 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
Ge0rGwhy not replace the file with another one?
larmaor that
Ge0rGI accidentally a dickpic.
larmaor if the file is a text file and has a typo in it
pep.Ge0rG, the internet will have to live with it forever
larmaOK, solution was found, now just need someone to write the XEP 😀
larmaAnd then a council to accept it even if it's not making use of fastenings 😕
Ge0rGlarma: but it should make use of fastenings! You fasten the correction to the original message!
larmaGe0rG, my message is end-to-end-encrypted with forward secrecy, I am not fastening anything because fastening is crap when having forward secrecy
larmanewsflash: OMEMO uses forward secrecy and is literally what made XMPP popular again
larmabut it's probably a sidecase we don't want to care about 😕
Bluehas joined
BlueCan somebody smart explain me something about stanza id xep?
Ge0rGBlue: if you find somebody smart...
mukt2has left
pep.larma: everyone has a different opinion on what makes XMPP (not) popular :p
BlueI'm pretty sure most of you here are smart on my terms =)
archas left
archas joined
Ge0rGBlue: then maybe ask the question :)
larmapep., yeah, I just needed my daily criticism of the reactions decision, didn't want to actually make a point here 😉
pep.hehe
ZashWhat if we lock all stakeholders in a room until the whole reactions thing is resolved?
pep.that is, everybody kills each other?
flowlarma> Fallback body *only* if I want legacy clients to display something of course
that's also the approach which I would be pursuing
BlueSo, 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?
flowlarma> 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
flowpep., maybe, or it does only display the corrected SIMS, while still allowing data fetches of the old SIMS
larmaBlue, id attribute and <origin-id> id attribute should be the same. <stanza-id> is important for MUCs and MAM.
Ge0rGBlue: old clients don't generate a unique id attribute.
pep.Ah, fight on 0359, that's also something I was curious about
LNJhas left
Ge0rGand <stanza-id> is added by somebody else than the sender, typically an archive
flowBlue, if something doesn't explicitly talk about xep359 IDs then use the RFC 6120 IDs
MattJBlue, 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
MattJThe 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)
MattJand origin-id is mostly a hack that we've discussed potentially removing in the past (though it has a couple of useful properties)
Ge0rGI'm interested in those useful properties, beyond virtue signaling of "proper" ID generation
BlueI 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 =)
MattJNone of the ids are guaranteed to be sortable
MattJSo you can't use them for order
MattJThere 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
Bluebut that doesn't make sence... There is sorted by time stream of messages...
contrapunctushas joined
MattJSure, I'm not saying messages don't have an order. I'm saying that ids are not used to convey the order.
Bluebut... how to query the history then?
LNJhas left
MattJYou can still query from the last incoming message
LNJhas joined
Bluebut I cant relay on time either - it's also optional (stamp if I'm not mistaken) and a little to approximate, isn't it?
MattJYes, don't use time
zzzedhas joined
ZashTime where?
MattJAnywhere
ZashI do have this "origin-time" draft...
zzzedHello, when i try to start private convesation (otr) and to generate fingerprints app instant close
zzzedany help?
archas left
archas joined
archas left
archas joined
Blueso... 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
zzzedanyone to help me out?
archas left
archas joined
zzzedKev MattJ ralphm
Nekithas left
archas left
archas joined
Zashhas left
Zashhas joined
zzzedam
zzzedintosi
zzzedadmin
MattJzzzed, you're asking the wrong people in the wrong channel
MattJStop highlighting people for no reason please
zzzedaha , where should i finde help then?
MattJWhat app are you using?
zzzedyou dont need to be rude at all , you can say on nice way
zzzedPSI
MattJhttps://search.jabber.network/search?q=psi
zzzedthanks
zzzedhave a nice day
MattJYou 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
flowjonas’, lgtm
jonas’flow, can you add a review on github please?
flowthose are mostly used by https://xml2rfc.tools.ietf.org/
mukt2has joined
flowand as you can see, e.g. https://xmpp.org/extensions/refs/reference.XSF.XEP-0435.xml has no target
flowint the root note
flowin the root node
flowwheras 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
Maxhas left
Marandahas joined
j.rhas left
Maxhas joined
ZashWhat are this?
flowZash, "this"?
ZashThese refs things
archas left
archas joined
flowthose ref entries are consumed by xml2rfc and can be used as references in I-Ds and RFCs