jdev - 2022-09-01

is there ever a reason a groupchat sends me a type "chat" message from its bare jid?

It wants to talk to you!

captcha or stuff like that? :/

but this would not be type "chat"

Why not

Does it have to happen in the room (even if not broadcasted to the others)

a message not sent in a room is not automatically type chat

there is also type "normal" which is commonly used for everything by a groupchat which is not a broadcasted message

the rfc intends type=chat for human one to one chat sessions

Does the RFC define human? (/s)

so i go ahead and assume sending a type=chat message which didnt originate from a human interaction is a violation or at least very bad style

Normal will render differently on some apps though no?

Wasn't it gajim actually that had a different UI for them? ✏

in ancient times

currently it does not differentiate between them

Ok

one of the biggest problems in XMPP i try to deal with since years is the question when i receive something: What is this JID?

is it a groupchat, a account, a pm, a gateway

"disco it"?

yeah, keep a FIFO queue of disco-unknown stanzas per JID that will be processed once the disco has been responded to. Also good luck with timeouts.

I get that it's not exactly optimal to have to wait a network round-trip to choose the UI

But it'll be the most accurate answer you'll be able to get I guess

If you can't already deduce from the URI (if it's not just a JID)

With MUCs, the naive hope is that you won't receive traffic from a JID you didn't ask before.

Except with the super-weird corner case of MUC-PMs

"corner case" :P

Which is why, a few years ago, I insistet on everbody adding <x muc/> elements into each passed PM

pep.: you'll only get unsolicited MUC-PMs as carbons from your own server, which should know better

> - A private <message/> from a local user to a MUC participant (sent to a full JID) SHOULD be carbon-copied This is a bummer, of course

lovetox, did you receive such a stanza, or you just want assurance it would never happen?

I'd agree that it seems like something that shouldn't happen

type=chat from a MUC bare JID? I'm pretty sure there are captcha solutions doing that, maybe also room mode changes on irc bridges

oh no, mode changes from biboumi are type=groupchat from=bare

type=groupchat from=bare is something clients should support

("because I said so")

It used to be commonly supported in clients, before XEP-0045. We have better ways to convey the information it was previously used for, but it's still handy for announcements and things.

no i did not receive something like that

i just want to determine as early as possible that im not dealing with a groupchat

but seems this is doomed to fail

Ge0rG, your proposal seems not thought trough

seems to invite high complexity not worth it

i would be suprised if anyone implemented such a thing in reality

lovetox: surprise!

Actually many do

yeah please name the project

i want to look into it

It's kinda the only way to distinguish certain payloads

poezio for one

just to be sure pep. before i go look

lovetox: https://lab.louiz.org/poezio/poezio/-/blob/main/poezio/core/handlers.py#L162-174

im not talking about "disco a jid"

im talking about not processing stanzas, until a disco result is received

lovetox: yes, poezio

ah

it's waiting for the disco to resolve before processing

Ah yes

I think it will even queue all messages from that JID on the has_identity semaphore.

(Ge0rG knows better..)

well, that was what one of the developers claimed

lovetox: also regardless of what other implementations do, it's the only way to correctly handle the situation.

hm for this particular case, no

the correct way to handle this is, if its not marked as muc pm, drop the message

the particular use case is: you receive a message from a JID you don't know

lovetox: "drop the message" is almost never the correct solution

seems poezio does this only for carbons

sooo ... what does it do when it receives a muc pm over mam?

https://lab.louiz.org/poezio/poezio/-/blob/main/poezio/core/handlers.py#L264-275

I'd assume it takes this path

MAM messages should be replayed as normal messages I think, with some tweaks

in your link i dont see a disco

I don't know this codepath much. I guess there should be one, maybe it's just that we encounter this issue less often and we haven't added it yet?

If you want you can try to craft a payload and send to my jid I'll tell you what we do :P

i think we can conclude that there is no general architecture in poezio that says we handle stanzas only after a disco.

i think in xmpp it was never needed to disco a contact

you receive something from a jid, look at the type, and open a chat

you dont care if its a groupchat or normal chat, or a gateway

fwiw my comment above was because you asked how to know what the jid refers to

Sure there are cases you don't really care and you display a generic tab

yes, and that seem to be my fault, i thought, hey lets write code under the assumption we always know what a JID is

seems the smarter way is, write code that does not care what a JID is

you probably should always write at least 2 xmpp clients

one where you learn everything that does not work, and one where you do it right :D

they say the same things about building a house

maybe we should write such a "Falsehoods XMPP developers believe" article

lovetox: If that's meant serious I would support it :-)

we should also try to improve the situation when developing new protocols

did any one ever think about just droping private message altogether

is it such an essential feature?

like could we live without it

does any of the other big messengers has this? whatsapp, telegram, signal, matrix?

I'm not sure Gajim could live without it. But something like Snikket definitely could

The problem is that XMPP 1) has public channels and 2) tries to keep participant identitifiers hidden in such channels

Pretty much all other platforms either don't do public channels, or don't hide identifiers

But in this context only are MUC PMs useful. But it's not impossible to find a better alternative at the protocol level.

i guess its half ok now with everyone adding the identifier that its a muc pm

it was total insanity before

the problem is also that i nowhere care about resources anymore

like for a normal chat message, i cast it to bare, i dont save the resource or do anything with it

aynway other topic

corrections, if i correct a message, then it replaces the other one

how does this work with stuff like receipts and chat markers

say i send a message, and then i correct it

do i expect to get a receipt/chatmarker with the message id for the correction?

or with the message id from the original message?

is there some mechanism that allows MAM queries to be handled from some other entity? so far i only found xep-0442, but it doesn't seem to be implemented anywhere