Modern XMPP project discussion - 2019-09-13

is there a best practices on which of the 3+ delays to show? I muc message might have 1) a delay tag from the user who sent it (because they were out of wifi for a second) 2) a delay from the muc history 3) a delay from your local stream management

just show all of them?

Daniel, in MUC, I’d use the one from the MUC history if available

otherwise, show the one from the user, but order by the one from your local stream management ✏

yes i was thinking of storing different values for ordering and showing (which i don’t currently)

isn’t that slightly irritating to the user though?

if messages show 'out of order'

my clients have been doing that since forevers

(my = the ones I use)

I'm extracting one timestamp from the message and use that for ordering as well as display

I may not be the norm, but I think why this makes sense is because the ordering reflects the actual way things happened and the original timestamp reflects how they were intended to happen

yes that's what i'm doing. but i get the argument for doing what jonas’ said

jonas’: it will do horrible things on MAM backsync

Ge0rG, only if you sync by timestamps

if you do that, you’re doing weird things anyways

i could argue that what jonas is seeing is mostly an accident caused by append only txt files as storage rather than a conscious by the developer

that said it might be a good accident

Daniel, that’s certainly true

and I think, yes, it’s a good accident

at the very least, showing a "this message was delayed" thing may be sensible.

jonas’: no, if you sync by received-order

makes it less confusing when stuff arrives late

/* Obtain a timestamp from a message, in the following priority order: https://prosody.im/modernxmpp-paste/db89ed61-677e-42e2-8319-6982f2375956

ah, thanks mod_pastebin for stripping my XHTML-IM

You're most welcome

pastebin mod is way to aggressive in my opinion

noticed that as well now that i'm lurking in prosody chat

Daniel: luckily, it's a server-setting thing

Also advertised in disco

i currently just use the oldest timestamp (which is weird i admit that)

4 lines or 500 characters is the default, which seems fine to someone like me whos used to IRC

Haha I was just going to write: IRC emulation. Plain MUC doesn't support IRC's 512 char limit.

XMPP clients should just adjust by splitting up messages like IRC clients do.

People tend to do that manually 😞

Holger: biboumi will do that for you

Holger: also https://github.com/yaxim-org/yaxim/blob/master/src/org/yaxim/androidclient/service/SmackableImp.java#L1987-L1998

Figure out how to handle pastes of large config files, logs, etc in a nice way.

Zash, run `file(1)` against the message, if it looks like a config file, pastebin! ;)

And find the precise point where it the chat turns into a forum.

mod_muc_firewall!

25 lines, 2000 characters. That way a message won't exceed a VT100 display.

Also, limits on size in a broadcast medium is sane.

I'm not arguing against limits, just that those limits seem too restrictive to me, as they seem to catch 'legitimate' message quite regularly. I'm usually not motivated to follow an HTTP URL just to read a 5-line message. (But I don't do Prosody support anyway so whatever.)

To me it looks like if you increase it, people will increase their message sizes.

And then it turns into a forum

Zash: how did you arrive at that conclusion?

Observation of the Converse.js room where it's been increased a bit

Really? I would not have expected people to even be aware of those limits, let alone restricting themselves regarding message size.

Yeah, there is no way people take these limits into account. I'm not, and I know about them. Most of the time

Well ok, I have no learnt not to split up citations/comments into several lines to increase readability.

*now

Hi Zash, https://prosody.im/modernxmpp-paste/4e1f102a-d9b1-462d-a885-81b6fb60c15b

Messages in the ejabberd room are too short most of the time :-)

"hey it doesn't work"

Did you know that you can easily split multi-line messages into individual messages?

rocket

science

.

which is a different kind of annoying

*beep* *beep* *beep*

Which kind of annoying do you want?

Zash: I want to be annoyed by long messages in the chat log, not by having to open the browser. kthx

Maybe it makes less sense here, less likely to be long config files and logs paste.

I don't have access atm tho

I can see how pasting long things is bad on IRC, but here, really, with XHTML-IM syntax highlighting, it's very much usable

no, because your coloring is unreadable on my black background

Can we compromise on loading a module that wipes styles from your XHTML-IM?

MUC presence is the annoying stuff

jonas’: I'm using a dark blue background and it works rather well

MattJ, refiddle mod_pastebin?

Zash: limit colors to a value from the 0392 palette

https://issues.prosody.im/1411 because I also don't like the default limits (I don't load it on my mucs and generally it's fine) :x

it's less bad than muc_limits though

If I wanted to annoy this MUC and its occupants, I'd make use of something like /dice or /progress in poezio, to create a long trace of LMCs

Especially with poezio not doing LMC properly (as per some newish revision)

sigh i need to 'fix' this as well

Ge0rG, did you know that initial implementation of such useless plugins made poezio crash when enabling debug logs in the beginning due to the python recursion hard limit?

we better not tell Link Mauve about the possibility to combine XHTML-LM, libaa and LMC for ASCII art video streaming.

moohahahaha

hahaha

the 4 different clients that allegedly are doing LMC need to have a switch day

Daniel, switch day?

mathieui: this is a sign of the insufficiencies in the plugin architecture

Ge0rG, what plugin architecture?

mathieui: yes

it was crashing when *receiving* the corrections and priting the message objets to the debug log

inside the display code

mathieui: oh, so it was not about the plugins but about messages with too many corrections?

yeah

mathieui: that's a security issue.

also 'fixing' lmc will fuck with MAM

Daniel: what are you speaking about?

Daniel, I guess that's more or less fine tbh. As long as you can still see messages

well if i don’t make the old message id the new message id on the next catchup the last message id will still be the old

Daniel: I think you need to make a drawing. With message trees

Yeah I get what you mean, and I think that's fine..

Can we LMC an LMC?

In the current XEP view

you can correct a message multiple times yes

pep.: no, it's not allowed.

Not what I meant

Ge0rG, ok

pep.: there was a very heated debate about that, because I think that we need to LMC the last LMC and not the original, but it was decided otherwise

I remember the heated debate but not the content

pep.: by the XEP, you always send LMCs referencing the original message. Therefore, if multiple corrections get reordered, you don't know which came first.

"get reordered"?

pep.: if you see them in a different order than they were sent

I get wha tyou mean anyway

e.g. because you load parts of the conversation from MAM

yeah, you now need some external information to know the order

also do i need to bump Conversations to 3.0.0 when i 'fix' LMC?

hmm why?

breaking changes

Daniel: I'm still not getting your context

I think that's a very not-so-much-annoying breaking change

What will happen is that you will potentially not recognize old LMCs as LMC, and display them as normal messages, that's it

fwiw, it's already like that in the wild. Converse has been doing it as the LMC says all this time

well you don’t have to deal with the fallout on my issue tracker

as the XEP says*

It works for the first message

Which is 99% of the use-cases I guess

So sure you'll break all the rest, but a few clients are already incompatible anyway.. if I use converse and then login with conversations, I don't see the same

also i need to rethink all my deduplication logic

what are you talking about?

That makes me think, I'm not sure we're handling anything coming from MAM, LMCs, etc. :x

Ge0rG, which part?

pep.: the last 13 minutes

Changing how LMC is handled in a client?

Changing in which way?

Reading / writing. I guess Daniel was also referencing the last ID

and not the original

Sorry, I can't follow

I'm not sure what part of the context you're missing

(in this infinity of contexts, please give me one I need to specify better)

All of it, apparently. The last thing that I understood was a recursion problem in poezio

hah, yeah that's not related I guess

The LMC XEP has been changed right

You mentioned the heated debate

yaxim will store the original ID and the last-correction ID in its database, and match an incoming LMC against either; so it will technically be able to use both formats

pep.: the XEP wasn't changed, it was clarified to underline the original design

Yeah ok

Sure

"clarified"

#clarified should be the new label we put on things which are disguised breaking changes :)

no looking at my code this completly breaks my MAM catchup and dedup behaviour

> If the same message is to be corrected several times, the id of the original message is used in each case (e.g. If a message of id 1 is corrected by a message of id 2, a subsequent correction should correct 1, not 2).

Daniel, you can technically allow both behaviours if you want

To not have to change the world

with the existing implementations being inconsistent in that regard, accepting both is a sane approach

Unless you are a proponent of https://tools.ietf.org/id/draft-thomson-postel-was-wrong-03.html

In which case, you probably should show the user a popup if an incoming LMC is referencing a previous LMC

hmm

mhhh maybe i should indeed support both. and build read support

and then ship write support in a year

or so

what's "read support" and what's "write support"?

I thought Conversations already does LMC?

sending corrections out in the new format

would be write

pep., and converse does the new format you say? so i can use that to test

yeah it does

that's also how I noticed poezio wasn't

But Ge0rG had noticed before! Always first!!

https://lab.louiz.org/poezio/poezio/issues/3462

I'll keep sending the latest-correction-ID as a matter of principle

oh also LMC will probably start doing funny things once we start using stanza-ids in mucs for that

which again I'm sure will just be a clarification

i mean hasn’t it always been obvious that we should use the stanza-id

stanza ids or stanza-ids?

how do you LMC a message that wasn't yet reflected to you?

how do you attach-to a message that wasn't yet reflected to you?

If we start using MAM IDs in 1:1 communications, we'll have to wait until the next re-connect to obtain the MAM IDs of our sent messages.

"please reconnect to the server so you can append an emoji to your witty remark"

i mean my code is slowly moving toward yolo message correction

you can now put any id of any of the previous versions in and it will probably do something

so what ever message arrived last will win

now we just need to relax our rules on what 'last' means and what resources are

and anyone can correct anything at any time

that reminds me that i wanted to write a channel bot that; if soon as someone leaves will rename itself to that user and send a LMC for the last message that user has written

Daniel, only from their barejid right

And that bot wouldn't work with occupant-id (or similar)

wouldn’t…

only that we don’t have occupant-ids

and people will still mess that up

There's a prosody module \o/ (and one known bug I need to fix).

(And a XEP)

Though..

MattJ reminded me of jid-proxy, that would probably fit better in the whole picture

So I guess we can have something similar to occupant-id but used as "realjids". Maybe? Clients would know they're not real anyway since the MUC declares itself as semi-anon

We can reuse the same IDs as occupant-ids for the localpart, but then we need a namespace we can use (another (sub)domain)

Would these have to be routable?

Clients will try to PM them, query them for vcards and other nonsense

so pretty much what they do with in-room occupant JIDs

right

We can just tell them "nope"? As in, have the MUC reply that

Sure, though then PMs and vcards break

and I deem that unacceptable, since we are for some reason discussing this in a MUC primarily dedicated to UX :)

I wonder if there's anything in MUC that says you should not expect/use item@jid in a semi-anon MUC

Since it's not defined for the server to send it, I highly doubt it

it?

(the second one of the three)

it == the "real JID"

hmm

Daniel, i plan to it like that 1. record the timestamp the message arrived at your client 2. look for a trustworthy timestamp (MAM, MUC History, SM) -> this overrides 1 3. look for a user set timestamp -> record it separately

Without using 'it': The spec does not instruct the server to send a real JID in a semi-anonymous room, so I highly doubt you will find text instructing the client not to use one that is present

MattJ, tbh I already "break" vcard in non-anon MUCs, with private PEP

(and I'm fine with it)

pep., in practice Prosody has been sending real JIDs in semi-anon since... forever, and clients seem fine with it

on display, if the diff of user timestamp to server timestamp is < X, order the messages accordingly

MattJ, ??

sending realjids in semi-anon?

pep., it always reveals your own JID to yourself, and has done that forever

ah

also we send multiple <item> I think?

Right but this one is routable, and not of a MUC's occupant-id handling code

So many sneaky protocol violations in this code (which are nice things, but not standard). I never had much to do with MUC :)

Why would a client use this @jid btw

You know you are you

Ah, other resources ?

MSN is already not specified anyway, is it

Yes, other resources

MSN was added in brief, at some point

s/added/hacked/

A good hack, nevertheless

clarified

Exactly

Daniel [15:10]: > clarified 🤣🤣🤣

Can you have a triple Emoji in Reactions?