XSF Discussion - 2024-08-24

. ✏

https://draugr.de/upload/00f530bb49b4e1685114d28f8bb6fb44b2fcbc2f/4TFpL1enGwNETx5UfcPJVQgvX2RHCQnartSIG4cd/1000157060.jpg

What bug leads to this? I got this on both dino and Conversations. Order of messages not matching their timestamps.

kurisu: not a bug, if someone sends a message without networking and connects later

The same person sent a message at 13:44 somehow, so even then 13:30 should be directly next to it'd seem?

Could be a different client

Could be a bug of their client

Client can attach a timestamp when a message was sent

Seems to be a weird choice by the client you are using

Showing the sent timestamp but order it at the received timestamp

Either way join the support channel of your client and ask the developers

> Showing the sent timestamp but order it at the received timestamp That's likely the correct thing to do no? ↺

Otherwise you'll never see the message and remote parties can basically edit your history

Ordering is correct but I would indicate to the user with a symbol or tooltip that it is a delayed message, otherwise it's confusing

personally I would put the sent timestamp also in the tooltip

Seems good

Because normally you always show received timestamp, why suddenly change that

the mam xep doesn't seem to clarify what the order should be beyond "not timestamps alone" if I were making a client, what order should I display messages in? whatever order the server sent them in?..

That's a client UX problem, not a protocol problem, no?

There are lies, damn lies, and delay timestamps

well as a user I always really hope my recepient sees the same thing as me..

in jabber conditions it's not rear that we end up "acking by hand", quoting a message and asking "did you get this?" or even just exchanging screenshots... at that point one might as well just do a screencast and write text there, more reliable..

Stop using Cisco jabber, use XMPP ;)

For real though that's true of all systems no? https://en.wikipedia.org/wiki/Two_Generals%27_Problem XMPP is as reliable as possible

Conversations does show the message on receiving it but shows the timestamp when it was send. After a while (?) it will be in the correct order. I don't know what exactly triggers that last part. But at least we see even old messages we didn't see before and in the history it will be ordered later

> That's a client UX problem, not a protocol problem, no? This seems like a surprisingly deep question. ↺

A Screencast under the same condition as the delayed message was send likely would have broken. There is a reason after all why the message was so late

Is there some kind of foundational document about the philosophy of what xmpp is intended to be? ✏

We already have read state notifications, send notifications etc. Acking is happening automatically.. Seems dam good for me. It is the most reliable system I have ever used for peers on the same server.

https://xmpp.org/extensions/xep-0134.html perhaps. But really it's whatever we, the XMPP community, wants to make of it.

> For real though that's true of all systems no? https://en.wikipedia.org/wiki/Two_Generals%27_Problem XMPP is as reliable as possible Except I never encounter this anywhere else, and also it's only xmpp people that I got references to two generals from as an excuse... ↺

Some people do a thing while others explain why that thing is actually not possible...

What exactly did happen kurisu? Someone send a message late? Or messages lost?

Sounds like you talka about message loss

A client not sending a message is unrelated to a protocol. Nothing a protocol can do if the first step isn't taken. Introduce the message to the system...

Everyone has this problem. How they solve it may be visible if you go into a tunnel with no coverage and send some messages.

Like, write "The time is now 12:34, what time does it say on this message?"

Stay in the tunnel a bit and then walk back into coverage.

Perhaps the problem here is simply that XMPP is honest about the delay.

also the way to solve this with centralized services is vastly different compared to xmpp. in xmpp you have at least 4 endpoints to consider with different requirments and capabilities each

> https://xmpp.org/extensions/xep-0134.html perhaps. But really it's whatever we, the XMPP community, wants to make of it. thanks ↺

Is anybody there？

👋

Is there anyone else now？

xiamen: No

> Everyone has this problem. How they solve it may be visible if you go into a tunnel with no coverage and send some messages. In the screenshot I sent it's clearly not that, as the person sent other messages at 13:44, and they appeared before 13:30. ↺

kurisu, you dont know that, people have multiple devices

he could have tried to send that message from another device, it lost connection before sending the message, then went to another device that was connected and started chatting

later that device came online and sent that message with a delay timestamp

I now think we can't know what happened from a screenshot.

this also has nothing to do with MAM, and also its pretty clear what order messages are received from MAM

the server must send the messages in the order it received them

hence when you receive the message you know the order in which the server received them

now as a client you can choose to honor another user added field "Timestamp when i tried to send that message"

this is a user added field, its not verified by any server or intermediate

you can trust it or not, and do stuff depending on it, every client does its own thing in this regard

>Stop using Cisco jabber, use XMPP 😉 problem is the name is acronym, already hated here (lot of acronyms in each process of that country) ; in a way, i can't recommand "this app", because it's not the same app on pc or on macos ; so i recommend xmpp, because "jabber" is both trademark plus commercial-closed offer of cisco ; so i say i use xmpp, even if it's opposite of glamour-sexy to mention like it, but it "kills" every sort of confusion related to jabber brand/offers.

"Xmpp" may work ok in English but no way I'm saying that to a Russian speaker, especially non-techie, and I think same goes for any other language. You cannot write it, you cannot decline it as a noun.

But these days we have Snikket and Quicksy as marginally cross-platform brands, for Android & iOS

Hey everyone, I would like to ask everyone's evaluation of China.

The above message is shown with a timestamp of 2:16pm GMT in Conversations (which was online the whole time) I just joined the room with Gajim and it shows the message as sent at 2:50pm GMT

If I'm writing a gateway, and the legacy service has read-only public channels (i.e. the messages have the name and the avatar of the channel), how should I translate that to XMPP / MUC? Should I send the messages from the room jid (from='room@component.org'), or should I create a channel participant that sends these messages?

lissine: it will probably look less confusing in clients if there is a channel participant

mathieui, thanks Indeed, it seems some clients don't even display messages from the room jid, as the only mention of that I found in XEP-0045 is: > Out of courtesy, a MUC service MAY send an out-of-room <message/> if a user's affiliation changes while the user is not in the room; the message SHOULD be sent from the room to the user's bare JID, MAY contain a <body/> element describing the affiliation change, and MUST contain a status code of 101.

Out of curiosity, are there other cases of such messages being used in the wild?

> If I'm writing a gateway, and the legacy service has read-only public channels (i.e. the messages have the name and the avatar of the channel), how should I translate that to XMPP / MUC? > Should I send the messages from the room jid (from='room@component.org'), or should I create a channel participant that sends these messages? Telegram? ↺

yes

but I'm under the impression that other legacy services have a type of channel similar to that. Also, the MUX draft mentions a similar concept (Announcement groups) https://pad.nixnet.services/s/7xKNOKxxE#Requirements

Do you see the other participants? I think in a lot of cases MUC is not the natural fit

I see this as more of a multicast / pubsub use case

No, you don't see the other participants

However then you'll quickly run into the problem that 'normal' xmpp apps don't have out of the box support for pubsub

lissine: not trying to discourage but do you know about https://slidge.im/slidgram/index.html / https://dev.narayana.im/narayana/telegabber/

moparisthebest, it was a rhetorical question. The gateway I'm talking about is slidgram

specifically https://todo.sr.ht/~nicoco/slidgram/18#event-381392

I ran into at least one client that doesn't display messages from the room jid. So I was wondering if clients should be improved in that regard, or if slidge should create a fake participant for message delivery. It seems the latter is the more sensible option, since it keeps complexity on the server

If it's just a stream of messages from 1 JID why is it modeled as a room instead of 1:1 ?

To have a way to subscribe/join and unsubscribe/leave?

Roster/presence subscription is that no?

> If it's just a stream of messages from 1 JID why is it modeled as a room instead of 1:1 ? Well that's a good idea. On the Telegram side, you can see the number of users joined to the channel, the number of views on messages, and the reactions and their numbers. But for a gateway, it may be sensible to use a 1:1 And they also have "pinned messgaes", the last of which is to be the MUC subject. I think that's the only thing that would be lost by moving to 1:1

> yes Telegram channels also have comments, reactions etc.. Xmpp clients don't even try to represent this model. Thus I don't think this can possibly work nicely no matter how you represent this at the protocol level. ↺

lissine: you could translate the topic to the user status

> lissine: you could translate the topic to the user status thanks ↺

> Telegram channels also have comments, reactions etc.. > Xmpp clients don't even try to represent this model. Thus I don't think this can possibly work nicely no matter how you represent this at the protocol level. XMPP channels have reactions too, and they already can be gateway'ed with slidge About comments, Telegram channels that have them have a "discussion group", where messages from the channel get posted, and replies to them count as a comment. It's not something special. ↺

(But I don't care about comments or reactions on Telegram channel messages) ✏

> If I'm writing a gateway, and the legacy service has read-only public channels (i.e. the messages have the name and the avatar of the channel), how should I translate that to XMPP / MUC? > Should I send the messages from the room jid (from='room@component.org'), or should I create a channel participant that sends these messages? If the message is not from a participant then a message from the MUC bare jid may be appropriate ↺

> I ran into at least one client that doesn't display messages from the room jid. So I was wondering if clients should be improved in that regard, or if slidge should create a fake participant for message delivery. > It seems the latter is the more sensible option, since it keeps complexity on the server If a client doesn't display messages with a body just because the jid is "a MUC" I would probably consider that a client bug (thought some clients may have some reason for this UX why knows) ↺

singpolyma: a client bug according to the RFC or the XEP? There's almost no mention of such messages in XEP-0045, that's why I thought it was normal if clients don't support them.

But I didn't consider what the RFC says on the matter.

A message is a message, unless the xep says *not* to show them then normal rules apply. But also show vs not is a UX question and so technically out of scope for xeps

hmm I just noticed that I've gotten 2 emails about some "post quantum omemo replacement xep" that this person said he has submitted, but I don't see it anywhere, he has CC'd ralphm and Ge0rG and Fishbowler too, did you all get them ?

Yep

I also got a LinkedIn invite

he also used my email alias that I've only ever used on github, seems a bit fishy

Steep stuff, will make for an interesting council review. Specifically mentions open sourcing a client implementation too, which, I assume, means no server implementation at the point of review.

Have not seen an actual spec. Also, without knowing the contents, I'd assume any reasonable way forward would build on MLS, and I think there's a proposal for PQ there.

Any spec requiring specific implementation limitation, including license requirements will be unacceptable.

This is also why we took issue with Signal

the email says "I have submitted a new XEP" though and I can't find that

I said so back then and I'll repeat now I have no qualms about a XEP who's only current implementation is GPL or AGPL, that's beside the point here though

They submitted it by sending it to the editor

Last night / my morning

that would explain it, I checked github PRs and all mailing lists but found nothing :)

I haven't gotten around to do something with it yet. I'll probably tell them to submit via github

iirc the process is github *or* mailing list, but if it's not, we should probably make that the process hehe

Idk I prefer github. We have the IPR bot and updates are handled over git anyway

I'm not gonna start merging diffs or patches or something

I agree but I really don't want that to be the only option, if someone opts for mailing list, anyone (not only editor) can make the github PR etc

You can obviously post a rendered version to the list if you'd like to discuss it first

> I'm not gonna start merging diffs or patches or something I am not okay with this if it forces editors choices on everyone writing XEPs. ↺

https://www.reuters.com/world/europe/telegram-messaging-app-ceo-pavel-durov-arrested-france-tf1-tv-says-2024-08-24/ i lovely prefer decentralized networks personally..