XSF Discussion - 2024-08-20

Guus, Do we think all clients handle multiple status codes now? They certainly used not to.

No idea dwd. The XEP is full of examples of having more than one status code though, so client support (or maybe: bug?) shouldn't be a factor there, I think.

We're talking about 15 years ago that we knew there were clients in the wild that didn't play nicely with multiple status codes (despite being required to), am I being overly optimistic to think that bug might have been fixed by now? :)

I'd not put money to that. :)

Kev, Gosh, was it that long ago? But yes, your optimism is legendary...

honestly? catering for clients which were already broken 15 years ago ...

... not a great way to move a protocol forward.

jonas’, I wasn't suggesting that we should only send a single status code. I was wondering which to send first.

Shuffle them each time!

Chaos engineering or something

I'm wondering if in this particular case we should send two at all

Send one, but add the two codes together?

Author: Dave Cridland <dave.cridland@isode.com> Date: Thu Aug 21 14:57:07 2008 +0100

For room-removals due to a service malfunction (code 333, section 11.1), the spec writes this: > Note: Some server implementations additionally include a 307 status code (signifying a 'kick', i.e. a forced ejection from the room). This is generally not advisable, as these types of disconnects may be frequent in the presence of poor network conditions and they are not linked to any user (e.g. moderator) action that the 307 code usually indicates. It is therefore recommended for the client to ignore the 307 code if a 333 status code is present.

16 years, almost to the day :)

Kev, I know that guy. I'd do another code review, just to be safe.

Guus, but 322 is a moderator action to some extent

jonas’ yes, I'm on the fence. I think this can be rationalized either way

Which is why I asked. :)

Unrelated, in 5.1.3, this note is given: > A moderator SHOULD NOT be allowed to revoke moderation privileges from someone with a higher affiliation than themselves (i.e., an unaffiliated moderator SHOULD NOT be allowed to revoke moderation privileges from an admin or an owner, and an admin SHOULD NOT be allowed to revoke moderation privileges from an owner). Is this text OK / can it be improved? I read this as if it may be possible for an admin to remove moderation privileges from another admin (as they're not 'higher') - but that's explicitly forbidden elsewhere in the document.

Agenda for todays meeting just went out. council members please read some backlog so we can come to an agreement on #1365 in todays meeting

wrong channel. sorry

hello, have two questions regarding xmpp : 1. is there an existing voip-compatible xmpp client for old macos, eg 10.5, intel or even powerpc? 2. on a public chan (like this one), if two persons wants to communicate in PM, how could they exchange addresses without publishing them in the tchat? thank you

lm2lm2: I do not know about the client. The XMPP specifications for multi-user chat allow people to send private messages to each-other in a groupchat, by using their occupant addresses. This does not require users to exchange their 'real' address. See https://xmpp.org/extensions/xep-0045.html#privatemessage for details.

Guus: if the groupchat allows it, though, it can be forbidden (and iirc it is the case here)

mathieui, i was speaking in the case here, where it's not a "private chan" but a "semi-public" one, where meta data are not accessible. if i understand well, here it's just impossible to exchange in PM with a specific person, without asking to go on another channel briefly?

lm2lm2: yes you can, but private exchanges "in the channel context" can be prevented by the administrator of they wish it so

In most cases it is authorized (obviously the client has to implement it)

You then exchange with identifiers tied to the room, and the room server does the message passing stuff between you two

mathieui, thank you

i dont know for other people, i tried astrachat on android, it's a disaster : only unsecured messaging (works), but only ringing, impossible to establish a voice/video communication

On Android you want Conversations (or a fork)

moparisthebest, yep, i know it well... but the idea was to "have a look" at astrachat software, in a way the macos i tried is too old enough to install their latest dmg, and i was thinking their android app would be a first nice overview ; but even on their site, android's part brings only to google play (where it has been removed) and amazon store (where i dont want to deal with neither) ; so im wondering if it happens that astrachat was "well working" before, in secured messaging and voice/video, plus file transfer, on at least one or two platforms (computer/phone), in an idea of : could i recommend it to somebody? I was looking for an enthousiasti conclusion..

There are likely no modern a/v supporting clients that will run on such an old OSX, honestly such an old OS probably shouldn't be connected to the internet at all considering all the security flaws it has. An option would be installing a modern Linux on the machine instead, then it'll be secure to connect to the internet and you can run Dino or any other client

That is an enthusiast conclusion for sure :)

moparisthebest, with linphone, it works well for sip audio/video

moparisthebest, id like to manage multiboot on it but im macos neeb

but it was also to "check" about health of astrachat company, as i see them lot of time in xmpp software, but im unsure about their quality of product (the idea of why i asked)

Linphone isn't an XMPP client though

i know, but they let their old client available at download, and i tested : it works to connect/communicate (i previously tried adium for xmpp, but ssl errors...)

i thought it would perhaps be some macos xmpp users here 🙂

Personally I vaguely know of astrachat's existence, never heard anything about them or ever known anyone to use them

I think the only times I've seen astrachat mentioned is on old "top 10 best xmpp clients" website.

Monal and BeagleIM are probably what most use on MacOS now, though I don't have numbers to back up that claim. And they might not install on an old version

There are some macOS XMPP users, but a/v is a fairly modern feature for XMPP clients and macOS doesn't make it easy (or possible at all? Unsure) to compile new code for old machines. So it's unlikely an old XMPP client that will run there will have a/v support, and it's unlikely a new client with a/v support will run there. That's what I meant. :/

Movim might run in the browser

Yeah I would defintely not be running a system that old connected to the internet

Menel, the idea was to not depend of a browser (use a dedicated client) but i will test it too 😉

mike, i still see old win7 and xp connected to the internet

but it's not the subject =)

You could run modern Linux in a VM 😂💀

> mike, i still see old win7 and xp connected to the internet *gets dad out* oh yea if you saw someone jump off a bridge would you do it too? ↺

The answer is yes, https://xkcd.com/1170/

>> mike, i still see old win7 and xp connected to the internet > *gets dad out* oh yea if you saw someone jump off a bridge would you do it too? 🤣🤣🤣

>> mike, i still see old win7 and xp connected to the internet *gets dad out* oh yea if you saw someone jump off a bridge would you do it too? already tried.. but was a 2meters window 😀

was it windows 2000 (mm) ?

Zash, im afraid so.. william henry was trying to catch me at jump

Is my server not supposed to store messages in MUCs on other servers? Is it forbidden from?

Not forbidden per se but no one puts groupchat messages in local mam that I'm aware of

Not forbidden, but yeah AFAIK nobody does that (in MIX though...)

You totally could though

And cache remote mam queries locally once to serve to all clients 😈

moparisthebest: oh no

What could possibly go wrong

(but it's a very complicated and nearly needless optimization which is why no one does it)

Permissions, retractions, it's a deep deep rabbit hole

> And cache remote mam queries locally once to serve to all clients 😈 XMPP bouncer =}