XSF Discussion - 2024-03-19

Anyone know Daakia? It's rare that you see job titles on linked in with 'XMPP' in the title: https://xmpp.work/job/xmpp-encryption-expert/

(or XEPs mentioned in the listing)

I was about to make fun of how they wanted someone with 10 years of OMEMO experience but actually it's 9 years old so they just want the creators I guess 💀

There appears to have been some confusion in opererators@ as to how/where to contact the Conduct Team. Things get a bit confusing by the Conduct Team defaulting to Board if no explicit Work Group is appointed. What would be good ways to reduce the confusion? Could a collection of email/xmpp contact addresses help (eg: `conductteam@xmpp.org`)?

Yeah, we should probably just make another alias

experimental is or should be the everything goes state

https://xmpp.org/extensions/xep-0166.html#concepts-session

which is in line with (my understanding) of xep0001

That was weird :)

https://matthewwild.co.uk/uploads/screenshot-20240319-1710855668-28262.png

(observe the timestamps)

https://burtrum.org/up/a8296312-7a22-4eb6-b634-63a88fd9307b/zb2rhcguqQqoNrktmmKGf59wwCBVQAYUjC9Kgv3rhnCkficHH.jpg

MattJ: your client is missing the dates ^

gajim also shows it as if they were now

huh

Distributed systems are such fun 😁

Dino is really annoying in unstable network conditions

I think the resend only happens when you restart Dino. Not upon sm resume

I've been putting my laptop to sleep a lot recently and Dino recovers fully upon wake-up maybe 5% of the time, and also crashes 95% of the time I try to only toggle account on and off, I've started just killing and restarting it

This "dino resends old messages that were sent successfully" issue is annoying yes, I've had a slidge user report that slidge resent a bunch of messages on launching dino, I looked for the bug in slidge for a while, but then figured it was probably a dino thing, as it has happened for me in non-bridged chats too. The user has given up on XMPP at this point. That's just one data point and dino is great anyway, but this was a bit of a sad moment for me :). I haven't figured out exactly when it happens or I would have opened an issue…

If the user can't put up with any bugs they shouldn't use computers... Or cars... Or anything built in the last few decades... The only solution is to live like the Amish, and then you have to deal with bugs of the 6-legged variety

nicoco: Maybe a stream management issue. Profanity/libstrophe had the same issue for a while.

moparisthebest, I have this vague impression that it takes a couple of centuries to perfect something. I'm basing this entierly on one video where someone drives a steam car. Steam technology got pretty good after 200 years :)

damn i was born too early to see xmpp be any good :/ i should have been born like 160 years from now

As for XEP-0198, anything we can do? Anyone good at networking who could build something like a test suite? I'm thinking Linux tc scripts to simulate poor connectivity and such

that could be useful yeah. at least android studio had something like that which was really nice

Zash, MSavoritias fae.ve: https://github.com/tylertreat/Comcast

amazing. thanks :D

Hm, can you simulate suspend-resume cycles like SIGSTOP, wait 11 minutes, SIGCONT ?

nicoco, note that in this example my message weren’t sent successfully before. they just got stuck at 'pending' even though i was sucessfully receiving (and even sending further) messages in this muc

When doing stream management, the resending client should add a <delayed/> (or was ist "delay"?) Containing the original timestamp into the stanza...the messages displayed as "sent now" probably did not have such an element...

Yesterday I had 3 messages in pending state in Dino and after turning the account off and on again, these messages got sent in random order which was a bit confusing on the receiver side...

It had a delay that's why mattj client displays different timestamps

The problem seems to be that messages are not sent on resume, not that the message has wrong data

Argh Daniel, then it might have my fault after all =) I have an unrelated question about ‘message displayed synchronisation’. If I understand publish-options and https://xmpp.org/extensions/xep-0060.html#owner-affiliations it would be possible for an entity other than the account to receive the pubsub ‘displayed’ events, because the whitelist is not defined in publish-options, right? I’m asking because I’d like gateways to be able to receive these events to ‘mark as read’ on the bridged network too.

I guess you can add the bridge to the white list

Yes the publish options only say white-list. Not who is on it

Cool, thanks