XSF Discussion - 2020-04-28

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.

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

The issue with race condition also applies to editing in MUCs, due to multi session nicks

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

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

Aren't edits by id too?

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.

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)

larma: yaxim is limiting editing to the last 10 messages from the same sender

larma: the XEP author said "editing other than the last message is out of scope of the XEP"

and don't even get me started on which ID to edit in multi-edits.

so yaxim allows incoming and outcoming edits that are not specified in any standard?

yes.

and it's even worse than that.

And then other clients don't support those edits incoming I guess? So UX is crap

yaxim allows edits in semi-anon MUCs originating from the same nickname, even if somebody stole the nickname

larma: 🤷

re nick stealing: 0421 to the rescue?

larma: 0421 has interesting issues of its own. But yes, it's on my long-term todo list

which is probably just an elaborate way of saying: I don't care

if you want to attach identity to nicknames in semi-anon MUCs, then register the nicknames or don't use semi-anon

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)?

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)

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

larma: indeed

So, how do we fix this mess?

larma: write a new XEP that extends 0308 to the last N messages.

larma: Daniel suggested YMC, "YOLO Message Correction", allowing to edit any messages regardless of age and sender.

I can't find any relevant mail from me to standards, so it probably was buried in a Council meeting

But when we do "any message correction", fallback body becomes pretty useless, no?

fallback body of what?

well fallback body of correction

why should there be a *fallback* body?

for clients not supporting it?

fallback body should be "I mean $message *"

larma: there is no fallback body in 0308

Ge0rG, well the body is the fallback

larma: the body is the newbody.

Well, it happens to have two usecases at the same time

because legacy clients will display it as a normal message

which is ok, if it really is the last message

which is ok, if it really is the last message, see?

larma: so your point is: correcting an older message will lead to confusion in non-0308 client users?

with 0308 we don't really have that problem due to its restriction to the last message.

if we allow edits of older messages though, we get into trouble

let me make a controversial proposal: editing of older messages should be restricted by their age, not by their amount.

still the same issue, no?

Why not both‽

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.

larma: actually it's a much worse issue: time is relative

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.

"sneak-edit"?

Snake edit?

Snape edit!

I mean an edit that you're unlikely to notice

Ie because it scrolled out of view.

I don't consider those an issue really

Zash: but how large is the view?

Either because time passed or because discussio

Ge0rG, three fiddy

in yaxim, a view is roughly ten messages. See, I found a reason for the arbitrary number

Dice roll

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

that's ok

larma: "But you said yes to my contract proposal, it's binding now!"

the older a message, the lower the probability that you actually *need* to edit it.

Ge0rG, "My client says 'Yes (edited)', and you changed it from 'No'" ✏

Also, this seems to be a social issue, not a protocol issue.

of course it is

I can also edit paper contracts after you signed them, even without you noticing.

I don't think we need to do better than reality here.

larma: what limits do you consider sensible?

No limit?

edit everything?

Yes, but I don't see the solution for the "not sure which message was edited" in the fallback case

except not showing edits to legacy clients at all.

larma: stop caring too much about legacy clients.

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

Ge0rG, legacy client = literally every client right now

0308 is part of Advanced IM 2020

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.

fwiw I was also considering with poezio taking into account more than the latest, in a proper way. poezio already does AMC in reading

(maybe unintentionally, dunno, it was the case when I joined)

and it's possible to send AMC with /rawxml (great UX!)

larma: 0308 was adopted in 2013, that was long before my activity started.

larma: I could theoretically imagine Council relaxing the "last message only" rule, but I wouldn't bet on it

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.

larma: I agree.

So just changing XEP-0308 to allow AMC doesn't solve the issue

larma: nothing will solve the issue right now.

not even creating a new XEP that defines AMC on top of 0308.

larma, maybe using <body> for this is just wrong :P

except maybe creating that new XEP and putting it into CS2021 and then waiting.

pep.: please no!

<replace @id>correction</replace>

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.

but that implies not using <body>

Or precisely not using <body> in <message>

And then people want you to take into consideration non-implementing clients and you're back to square one

pep.: easy: just add a legacy body into AMC!

could still be <message><edit xmlns="urn:xmpp:edit:0"><body xmlns="jabber:client">Correction</body></edit></message>

larma: that would make some sense indeed.

would allow differentiating the *edited* part from the edit metadata part.

larma, I'm not sure I understand the intent

non-implementing clients won't understand this

<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>

Yeah.

ugh

Fallback body *only* if I want legacy clients to display something of course

(not in the case of fixing that one type)

Seeing the wire format of /me hurts every single time

larma, still not sure I understand the point of <body/> in <edit/>

Also in your fallback you included localtime

Or UTC, or ?

Which one is it

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.

I did say the <body> in <edit>

yes, that's whay is used as a replacement for the body when the client supports <edit>

Why do you need an extra child

ah ok

because I might want to edit other elements than body ✏

That's the info I was missing

And it also seems consistent to have the displayed body in the <body> element

If you could only edit <body>, I don't think so

I think it's being frowned upon anyway to edit anything else than <body/>, iiuc

Well, if I upload a file, why not edit the description of the file (assuming a SIMS-alike file sending)

I'm personally fine with this

why not replace the file with another one?

or that

I accidentally a dickpic.

or if the file is a text file and has a typo in it

Ge0rG, the internet will have to live with it forever

OK, solution was found, now just need someone to write the XEP 😀

And then a council to accept it even if it's not making use of fastenings 😕

larma: but it should make use of fastenings! You fasten the correction to the original message!

Ge0rG, my message is end-to-end-encrypted with forward secrecy, I am not fastening anything because fastening is crap when having forward secrecy

newsflash: OMEMO uses forward secrecy and is literally what made XMPP popular again

but it's probably a sidecase we don't want to care about 😕

Can somebody smart explain me something about stanza id xep?

Blue: if you find somebody smart...

larma: everyone has a different opinion on what makes XMPP (not) popular :p

I'm pretty sure most of you here are smart on my terms =)

Blue: then maybe ask the question :)

pep., yeah, I just needed my daily criticism of the reactions decision, didn't want to actually make a point here 😉

hehe

What if we lock all stakeholders in a room until the whole reactions thing is resolved?

that is, everybody kills each other?

larma> Fallback body *only* if I want legacy clients to display something of course that's also the approach which I would be pursuing

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?

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

flow, then a client displays two "media" thing?

For ""the same"" file

pep., maybe, or it does only display the corrected SIMS, while still allowing data fetches of the old SIMS

Blue, id attribute and <origin-id> id attribute should be the same. <stanza-id> is important for MUCs and MAM.

Blue: old clients don't generate a unique id attribute.

Ah, fight on 0359, that's also something I was curious about

and <stanza-id> is added by somebody else than the sender, typically an archive

Blue, if something doesn't explicitly talk about xep359 IDs then use the RFC 6120 IDs

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.

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)

and origin-id is mostly a hack that we've discussed potentially removing in the past (though it has a couple of useful properties)

I'm interested in those useful properties, beyond virtue signaling of "proper" ID generation

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 =)

None of the ids are guaranteed to be sortable

So you can't use them for order

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

but that doesn't make sence... There is sorted by time stream of messages...

Sure, I'm not saying messages don't have an order. I'm saying that ids are not used to convey the order.

but... how to query the history then?

You can still query from the last incoming message

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?

Yes, don't use time

Time where?

Anywhere

I do have this "origin-time" draft...

Hello, when i try to start private convesation (otr) and to generate fingerprints app instant close

any help?

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

anyone to help me out?

Kev MattJ ralphm

am

intosi

admin

zzzed, you're asking the wrong people in the wrong channel

Stop highlighting people for no reason please

aha , where should i finde help then?

What app are you using?

you dont need to be rude at all , you can say on nice way

PSI

https://search.jabber.network/search?q=psi

thanks

have a nice day

You too

does anyone have a clue about those ref files we generate for XEPs?

https://github.com/xsf/xeps/pull/938

I’d love to get a review on that one before hiting the green button

jonas’, lgtm

flow, can you add a review on github please?

those are mostly used by https://xml2rfc.tools.ietf.org/

and as you can see, e.g. https://xmpp.org/extensions/refs/reference.XSF.XEP-0435.xml has no target

in the root node ✏

wheras https://xml2rfc.tools.ietf.org/public/rfc/bibxml2/reference.NIST.SP.800-185.xml has

flow, good, can you add that as a review on github?

thx

What are this?

Zash, "this"?

These refs things

those ref entries are consumed by xml2rfc and can be used as references in I-Ds and RFCs

think of biblatex entries for RFCs

Oh-kay