jdev - 2023-01-23

I'm willing to die on this hill, though, that a client that "shows you something but sends something else to the rest of the world, and gives no indication of it" isn't one that most people would want to trust with their messages

Completely agree

Well, welcome to XMPP. It sounds like a network with a diverse ecosystem of software isn't what you're looking for 🙂

I only ever see links in my (terminal-based) client

MattJ, "shows you something and sends something else" is different from "sends something which other clients may intrepret less fancily"

Yep

(the first sounds like a violation of intent, while the second is, indeed, what you'd expect in a federated network)

> (the first sounds like a violation of intent, while the second is, indeed, what you'd expect in a federated network) 👆

With message retraction, the retracting client shows, "it has been deleted", but my client will show the original and a message about the attempt ¯\_ (ツ) _/¯

And?

jonas’ [08:48]: > MattJ, "shows you something and sends something else" is different from "sends something which other clients may intrepret less fancily" Sorry, I don't see a distinction in practice. Either way you can't guarantee what someone is going to see on the other side.

MattJ, the first one at least tries

the first case sounds like the order of magnitude of a client adding a "not" before every verb.

(but only on the wire)

That's not what is happening in the issue that sparked this discussion though

What Dino sends on the wire matches what it displays to the user

scrollback, how does it work

But it is seen as a "bug" which is what was discussed here

Yeah, and I think it's a stretch to call it a bug

it's a bug if it violates user expectations, isn't it?

To be clear the two cases are mod_pastebin changing long text to a link, and mod_restrict_media stripping oob tags

i never understood the word bug as violating user expactations

a bug is when the software does not what the *developer* intended

Every user has different expectations

not what the user wished it would do

so we're talking about the <oob/> removal?

right

They're both the same category I believe

I would wish for dino to show what the server did, because that also helps with servers which *have* to change even the text (looking at you, biboumi)

are there words in modernxmpp on this topic?

seems like there should be, i.e. "what to do if the MUC reflection differs from what we sent"

It's not covered there, no

I doubt it would sway larma if it was 🙂

may or may not, but "we" should form a consensus on what clients should do nontheless, IMO

but the biboumi stuff is weird

so it splits my message in 3

does one of the 3 messages actually have the message id i added?

What the server sends is the definitive form. I think it's fine for clients to show the sent form until the definitive form is received, as long as they mark it as transient and replace it when received.

biboumi is kind of special case, its not mere rewriting a body or message

it adds a inifinite amount of new messages instead

lovetox, yes, all have message IDs, and the first one will be clearly associated to your original message

Kev, except that's not written anywhere

Sure. It was a response to Jonas asking for what we should do.

(via origin-id passing or @id passing)

that would actually be a good use of origin id?

if all 3 new message have the origin-id set to the original message-id?

Hah, making origin-id not unique? That would be great :P

dear lord

:D

but eh

I'm on board with that

but how would you know the splitting of your message had completed....

but yeah .. this is problematic i think gajim also expects only one message in the database with a unique origin id

why not add an element to the reflected parts: <split-from origin-id="foo" part="1"/>?

would wfm

Only for bimboumi? Does it change anything for anyone?

maybe some can put this information to good use, maybe not. but it appears trivial to add, so it seems worth a try, err experiment