XSF Discussion - 2024-08-14

I didn't mean ignore I meant ban (and the client could send the unban after a time)

It would work pretty ok since the error bars of you being offline for a bit probably barely matter. So long as you don't drop your phone in a lake before the unban

The client needs to be online for the unban, which seems to be a shaky prerequisite to me.

A bot would be the easiest choice, wouldn't it?

Sure, but that also is an external process that needs to be online. I'd add it to the XEP, also to prevent fragmentation of specifications.

> The client needs to be online for the unban, which seems to be a shaky prerequisite to me. The whole muc thing in xmpp is shaky to say the absolute least. ✏ ↺

+1

It won't get better by spreading out various bits of very related functionality elsewhere.

XEP-0045 explicitly states that modifying the Owner List (section 10.5) is 'forbidden' to any non-owner, but does not explicitly state that error in 10.3 (Granting Owner Status) and 10.4 (Revoking Owner Status). The same issue is there in the sections 10.6, 10.7 and 10.8 (granting/revoking Admin Status). I think this is an oversight, and I suggest to copy the text that's used throughout the specification ("If the <user@host> of the 'from' address does not match the bare JID of a room owner, the service MUST return a <forbidden/> error to the sender.") to the sections where it's missing. Is that right?

https://github.com/xsf/xeps/pull/1370

In my frequent "I wonder if the server could do this better" moments, I do wonder if having a server identify and intercept all traffic to/from a MUC, and host a virtual MUC (for its user) and a single virtual user (for the MUC) might solve a lot of problems. For one thing, the virtual user need never actually leave the MUC when the real clients it was proxying for dropped offline. It feels like a way to vastly improve MUC without actually having to change every MUC and client - albeit some client changes would be needed to take full advantage.

So, an xmpp bouncer?

AFAIK, movim might be already doing this (the staying always joined) as it runs on a server

Does XEP-0045 intentionally allow for the owner- and admin list to contain full JIDs, rather than bare JIDs? Section 10 doesn't explicitly make mention of this, unlike section 9, which does.

>> The client needs to be online for the unban, which seems to be a shaky prerequisite to me. > The whole muc thing in xmpp is shaky to say the absolute least. Strongly disagree 🙂 MUC is one of the most solid and well tested and designed parts ↺

singpolyma: solid and well tested but also full of weird and non user friendly corner cases ✏

mathieui: like what?

i mean there is multiple times in this room every week where a new "feature" is discovered in he MUC xep or something is unclear and needs a fix. there is a person that has been going around point all this stuff out. one of the instances being just above :)

>> The whole muc thing in xmpp is shaky to say the absolute least. > Strongly disagree 🙂 MUC is one of the most solid and well tested and designed parts How is the nickname and join-leave per device instead of per user a good design (with other problems ensuing like message edits being screwed up)? I wouldn't even call it a *sane* design, let alone a remotely good one. ↺

MSavoritias fae.ve, if you're referring to me: most, if not all of the changes that I've been suggesting in the last few weeks are a result of me going with a fine comb though the specifications, and _mostly_ improve just wording. I believe that all of my changes are editorial, with very limited functional changes - and even where I suggest changes that would be functional, then I suspect that most implementations already have that, and the specification simply omitted it in the wording.

kurisu: join-leave per device is a UI choice in the client, spec allows either way. Message edits being screwed up is a bug in the message edits spec which came after MUC, which is fixed now by bolting on occupant id

Guus: and we appreciate you for it 🤗

Guus, i wasnt saying its broken. just that the spec needs rewording in some places. which as you said you have been fixing lately. thank you for your work

Would we do it differently nowadays? Sure. But this XEP has served us pretty well for two decades+

kurisu, A lot of that is because MUC was designed with IRC as a template, and in addition the multi-device design was based around people switching devices - having multiple devices meant desktop and laptop when XMPP started, not laptop/phone/tablet/watch. People would rarely be online with both, and certainly wouldn't be "active" on both, and if they were active the network was probably stable for the duration of that activity. Obviously times change - hence carbons etc - and MUC does need an overhaul of some form to handle this. But the design was very much sane (and state of the art) when it was made.

kurisu, But - while I readily accept that it needs work now, the biggest problem with getting that work done is actually that MUC is so successful it's really painful to move off, which suggests that even though there's lots not to love about it, it comfortably falls into the category of "good enough". There have been several attempts to replace it, none have got traction (examples include MIX, which some of us put a *lot* of effort into).

to answer my own question related to full/bare JIDs: section 5.2 says: "Affiliations are granted, revoked, and maintained based on the user's bare JID"

>kurisu: join-leave per device is a UI choice in the client, spec allows either way. If it's a UI choice than it's a terrible UI choice that shouldn't be allowed at the protocol level. Also, my understanding so far is that it's not exactly a ui choice and it takes a separate xep (bookmarks) to emulate per-user join-leave, wherein clients just listen for bookmarks updates. Is my understanding wrong here?

It is just that you weren't around at the time this was designed. At that time it was what people wanted and expected

> kurisu, But - while I readily accept that it needs work now, the biggest problem with getting that work done is actually that MUC is so successful it's really painful to move off, which suggests that even though there's lots not to love about it, it comfortably falls into the category of "good enough". There have been several attempts to replace it, none have got traction (examples include MIX, which some of us put a *lot* of effort into). It's not like xmpp has that much traction to spread it on different implementations of the same thing, so what stuck on the very limited resources isn't really any measure of success. ↺

Guus, There were - back in the day - a lot of cases where we thought full-jid operations were useful and even sensible. ISTR they crept into blocking ('16, not '191 I think), amongst other places. They're a bad idea, and should be removed.

Actually, things being popular when the popularity depends on network success, is rarely a measure of their quality at all. The most popular platforms are also the most terrible (like Facebook)

dwd: I'm purely talking about 45 now

> dwd: I'm purely talking about 45 now Yes, but I suspect someone thought it was sensible in some places to have full-jid affiliations, but they've only been partially added or removed. Clean it up, I say. ↺

> >kurisu: join-leave per device is a UI choice in the client, spec allows either way. > If it's a UI choice than it's a terrible UI choice that shouldn't be allowed at the protocol level. > Also, my understanding so far is that it's not exactly a ui choice and it takes a separate xep (bookmarks) to emulate per-user join-leave, wherein clients just listen for bookmarks updates. Is my understanding wrong here? I guess it depends what you mean by join-leave. I usually would think that means register/deregister, but you're right someone might think of bookmarks that way as well ↺

> It's not like xmpp has that much traction to spread it on different implementations of the same thing, so what stuck on the very limited resources isn't really any measure of success. Being able to do wildly different implementations that are still vaguely compatible is basically the whole point of having a standard :) ↺

> It's not like xmpp has that much traction to spread it on different implementations of the same thing, so what stuck on the very limited resources isn't really any measure of success. Well, irrespective of how much traction you think XMPP itself has, the traction of MUC within the XMPP world is very high indeed. ↺

> It is just that you weren't around at the time this was designed. At that time it was what people wanted and expected When did anyone want to set one nickname for his laptop and a different one for his phone? When did anyone ever want to join a group from his laptop but not his phone? ↺

> When did anyone want to set one nickname for his laptop and a different one for his phone? When did anyone ever want to join a group from his laptop but not his phone? Well, people literally couldn't join from their phone, because phones didn't have IP back then. But that aside, the answer (later) was literally all the time - people expressly wanted not to join chatrooms from their phone, either because the badnwidth was slow/expensive/etc or they didn't want to be bothered by chatrooms when on the move. User behaviours do change, have changed, and will change some more. ↺

>> If it's a UI choice than it's a terrible UI choice that shouldn't be allowed at the protocol level. >> Also, my understanding so far is that it's not exactly a ui choice and it takes a separate xep (bookmarks) to emulate per-user join-leave, wherein clients just listen for bookmarks updates. Is my understanding wrong here? > I guess it depends what you mean by join-leave. I usually would think that means register/deregister, but you're right someone might think of bookmarks that way as well Okay I don't know that much about muc, what does register-unregister mean in the context? Anyway what I meant by join-leave and what most people will mean: when I join a group, it shows up in my clients interface, I receive messages from the group and other people see me in the list of participants. When I leave, all these stop being true. ↺

>> When did anyone want to set one nickname for his laptop and a different one for his phone? When did anyone ever want to join a group from his laptop but not his phone? > Well, people literally couldn't join from their phone, because phones didn't have IP back then. But that aside, the answer (later) was literally all the time - people expressly wanted not to join chatrooms from their phone, either because the badnwidth was slow/expensive/etc or they didn't want to be bothered by chatrooms when on the move. User behaviours do change, have changed, and will change some more. I am pretty sure telegram for example wastes virtually no bandwidth on groups you're part of but don't open on this specific device. It only updates the last message to show in the preview. But then I also don't think it blows up each message's size tenfold+ with verbose xml either. ↺

> Okay I don't know that much about muc, what does register-unregister mean in the context? > Anyway what I meant by join-leave and what most people will mean: when I join a group, it shows up in my clients interface, I receive messages from the group and other people see me in the list of participants. When I leave, all these stop being true. FWIW, I agree with your definition, and no, MUC doesn't do this properly (hence my floated suggestion of a MUC-bouncer in the home server). ↺

> I am pretty sure telegram for example wastes virtually no bandwidth on groups you're part of but don't open on this specific device. It only updates the last message to show in the preview. > But then I also don't think it blows up each message's size tenfold+ with verbose xml either. You realise there's not as much overhead as you think with XML? The bulk of the redundancy within a stanza is in close tags. Across stanzas there's a bit more, but nothing unique to XML at that point - you'd need an ASN.1/Protobuf kind of payload to avoid it. ↺

Certainly "tenfold+" is a wild exaggeration. Unless you're sending astonishingly short messages.

> FWIW, I agree with your definition, and no, MUC doesn't do this properly (hence my floated suggestion of a MUC-bouncer in the home server). In what way does MUC + bookmarks not do this properly? ↺

kurisu, So for your last message, which quotes mine in entirety, then your actual text as rendered is 293 characters, and on the wire the full stanza (including all my text, entity expansion, framing, etc) comes to 1518. Quoting is responsible for the bulk of that, too.

> In what way does MUC + bookmarks not do this properly? Well, if your device is offline then (assuming it is the only device of yours in the chatroom) other users do not see you as a room occupant, and messages sent to the chatroom will not get delivered to you. ↺

> other users do not see you as a room occupant that's a UI choice by the client to only show online participants. a client can easily show the full list of members instead (and indeed some clients do this already)

Messages aren't "delivered to you" I suppose while offline, but that's true of 1:1 as well as is the purpose of history API and/or MAM

1:1 messages do get as far as your server, though, and could then cause a push to your device. No, this is not a "UI choice", this is a technical issue, and I don't think it's useful to pretend otherwise.

I'm not yet sure where the technical issue is?

I don't know how to explain it better.

> Clean it up, I say. dwd, what about adding this in various subsections of section 10 of XEP-0045 to clean it up: > As affiliations are granted, revoked, and maintained based on the user's bare JID, the requesting entity SHOULD use the bare JID of the user in the request. When processing the request that identifies a user by its full JID, a service SHOULD use the bare JID representation.

is that second half a functionality change?

Do we need "various subsections", or is there somewhere to put blanket statements about affiliation operations? DRY would seem to apply.

>> It is just that you weren't around at the time this was designed. At that time it was what people wanted and expected > When did anyone want to set one nickname for his laptop and a different one for his phone? When did anyone ever want to join a group from his laptop but not his phone? Yes, we did name our nicknames with -PC-Home at the end etc. It was a different time. And somehow it seemed normal to explicitly send a message to only one specific device and intentionally not to the other. It was cool ↺

Well, we had to originally. Nick sharing wasn't a thing, to begin with. Nobody even thought of it, as far as I recall.

dwd, there's section 5.2 that already states that affiliations are bare-JID based, but doesn't suggest the down-cast, I thnk.

> You realise there's not as much overhead as you think with XML? The bulk of the redundancy within a stanza is in close tags. Across stanzas there's a bit more, but nothing unique to XML at that point - you'd need an ASN.1/Protobuf kind of payload to avoid it. The endless repeated needlessly long namespaces add quite a chunk.Pretty sure even json or bencode wouldn't blow it up that much. But then a gain, a person sane enough to choose one of those would also be sane enough to not plaster long namespaces all over the place.. And there probably wouldn't be a need for multiple, self-repeating message ids either, or even a single one because with e.g. bencode you could actually hash the messages... Aand there wouldn't be a need for e.g. the extra occupant id if muc was sane from the get go. Madness is like gravity. ↺

section 10 defines both room creation as well as various affiliation changes - I do not see an easy way to add it to just one place that's also not easily overlooked.

kurisu: yes no other formats use... Oh no https://www.moparisthebest.com/images/jsonschema.jpg

kurisu: Seriously though, read https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/

> > other users do not see you as a room occupant > that's a UI choice by the client to only show online participants. a client can easily show the full list of members instead (and indeed some clients do this already) Conversations has repeatedly failed to indicate a person leaving a group chat, and I'm not sure which of the two options you listed it is even supposed to do, in either case it failed consistently. ↺

> kurisu: yes no other formats use... Oh no https://www.moparisthebest.com/images/jsonschema.jpg One can be an idiot with json too, so? ↺

Except even then it's not as bloated lol

> Aand there wouldn't be a need for e.g. the extra occupant id if muc was sane from the get go. Madness is like gravity. kurisu: That's the point of having an extensible protocol. Requirements / user expectations change over time.

XMPP is useless without namespaces, it's just MPP, no longer extensible

> > Aand there wouldn't be a need for e.g. the extra occupant id if muc was sane from the get go. Madness is like gravity. > kurisu: That's the point of having an extensible protocol. > Requirements / user expectations change over time. Again, I highly doubt anyone ever expected their nickname to be device specific. So I don't think occupant-id is adapting to a new expectation, rather I see it as a patch on a rotten foundation. ↺

kurisu, There is certainly redundancy between stanzas. Some of that is element names and namespaces. But if you want an extensible protocol, you're basically tied into needing something very very similar to XML namespaces.

We had that before, it was called IRC

> Conversations has repeatedly failed to indicate a person leaving a group chat kurisu: in Conversations, when somebody leaves a group chat, their avatar is no longer shown. Sure, the UI could be improved to have a small dot in the avatar's corner for presence, but that has nothing to do with the spec

>> kurisu: That's the point of having an extensible protocol. >> Requirements / user expectations change over time. > Again, I highly doubt anyone ever expected their nickname to be device specific. So I don't think occupant-id is adapting to a new expectation, rather I see it as a patch on a rotten foundation. kurisu: They literally did and they still do today, try joining any older IRC channel. ↺

In either way, it isn't constructive to say it is bad now. It is what is there (because it is there for a log time) And from here it is improved. Many in this room already said it some time ago : if they would design it from scratch it would look different now. (unsurprisingly) But everything you design now would look "stupid" after two decades

lissine, Unless we mandated registration, how could Conversations possibly know the occupant was ever going to come back?

> kurisu, There is certainly redundancy between stanzas. Some of that is element names and namespaces. But if you want an extensible protocol, you're basically tied into needing something very very similar to XML namespaces. no you're not. In any sane format `<occupant-id xmlns='urn:xmpp:occupant-id:0' id='dK6UCwz5HhoIwFvVkvbrh9JU6iuy2HZvJx3VGZ1PdT0=' />` would look roughly like `occupant-id=dK6UCwz5HhoIwFvVkvbrh9JU6iuy2HZvJx3VGZ1PdT0` and do just fine. ↺

##atari on Libera is an example, people will be joined with various nicks from various old ataris, but also nick-phone etc

> > Conversations has repeatedly failed to indicate a person leaving a group chat > kurisu: in Conversations, when somebody leaves a group chat, their avatar is no longer shown. > Sure, the UI could be improved to have a small dot in the avatar's corner for presence, but that has nothing to do with the spec that's not the kind of leave they mean. Conversations indeed doesn't have an easy way for someone to actually leave a room (remove themselves permanently from the room). it's a ui hiccup I'd like to work on soon ↺

> Again, I highly doubt anyone ever expected their nickname to be device specific. kurisu: The MUC spec already allows you to use the same nick for all your devices: > However, if the bare JID <localpart@domain.tld> of the present occupant matches the bare JID of the user seeking to enter the room, then the service SHOULD allow entry to the user, so that the user has two (or more) in-room "sessions" with the same roomnick, one for each resource https://xmpp.org/extensions/xep-0045.html#enter-conflict

>SHOULD >two (or more) in-room "sessions" with the same roomnick

lol

Laugh all you want. It works™

except it's all broken all the time

I even think the nick is stored in the bookmark so other devices use it

kurisu, By the way, you know that XMPP has been used - MUC is used, actually - over HF radio links that are such astoundingly low bandwidth that you can literally watch the bytes come in?

> except it's all broken all the time Sorry, what? Your message didn't reach me. ↺

Again these are all patches to a rotten foundation. If you ask me the MUC owner shouldn't even know how many devices I have. Because I always expect service operators to be complete idiots, which they often turn out to be, so some groupchats I can't join from two devices at once, and what the hell is even going on with irc bridges and multidevice is beyond my mortal comprehenion completely. ✏

> except it's all broken all the time When it's broken, report the issue to the relevant client / server. I don't face any such problems with prosody and Conversations / Gajim / Monal / Movim ✏

yeah, I don't think we can blame specs for misbehaving implementations. unless it's actually unclear, which Guus is working on but isn't a foundational issue

> I even think the nick is stored in the bookmark so other devices use it Yes it is, it's a patch to make the absurd reality somewhat match expectation. ↺

> some groupchats I can't join from two devices at once Wait what? I've literally never seen that

lissine, kurisu is incapable of doing anything other than aimlessly roping about literally everything

> yeah, I don't think we can blame specs for misbehaving implementations. unless it's actually unclear, which Guus is working on but isn't a foundational issue The greater the complexity of the spec, the greater probability of a misbehaving implementation. ↺

> > some groupchats I can't join from two devices at once > Wait what? I've literally never seen that Used to be commonplace, but I think every server follows the SHOULD now, and has for many years. ↺

the MUC can force users to always have only their registered nick, it's just not commonly done that way currently, but the spec explicitly allows for it if that's the UX a service wants

kurisu, Out of curiosity, what do you think "SHOULD" means in a spec?

>, Out of curiosity, what do you think "SHOULD" means in a spec? Something like >Used to be commonplace, but I think every server follows the SHOULD now, and has for many years.

kurisu, I get the impression you think it means something closer to MAY than to MUST, whereas actually it means the same as MUST (unless you actually know why it had to be SHOULD). So a server (or client) not following a SHOULD is a bug that needs reporting (and almost certainly fixing).

kurisu: so you want a new standard with a MUST there even though 100% of implementations in the wild for the last 15+ years do this anyway? How does that help?

> the MUC can force users to always have only their registered nick, it's just not commonly done that way currently, but the spec explicitly allows for it if that's the UX a service wants The thing is, as a user the last thing I care about is what "the service wants". It's like on the web: I often encounter websites the owners of which want to block everyone outside their country. As a user, I don't care about what they want. As a user I want to have such admins focre-hospitalized, but the next best thing I want is to have software that isolates me from their choices as much as possible or better yet doesn't give them such choices in the first place. ↺

> Yes it is, it's a patch to make the absurd reality somewhat match expectation. > The greater the complexity of the spec, the greater probability of a misbehaving implementation. kurisu: So how would you design a group chat spec for XMPP?

kurisu: And most importantly, what benefits will end-users get with the new replacement?

kurisu, Well, the MUC can force a nickname on you, that's absolutely within the spec and also absolutely fine (and needed, too, in all kinds of cases where MUCs are used for critical stuff like healthcare). I'd expect all clients would support it just fine.

kurisu, The way it works is that a client says "Hey, I'd like to join with this nickname", and the server replies with "Sure, here's your nickname". The nicknames can differ in the two messages. So actually, getting the nickname you requested is a special-case of the exact same flow.

> The thing is, as a user the last thing I care about is what "the service wants". It's like on the web: I often encounter websites the owners of which want to block everyone outside their country. As a user, I don't care about what they want. As a user I want to have such admins focre-hospitalized, but the next best thing I want is to have software that isolates me from their choices as much as possible or better yet doesn't give them such choices in the first place. So, as a user, choose a service that does what you want? changing the spec won't acheive this ↺

> kurisu: And most importantly, what benefits will end-users get with the new replacement? End users don't benefit from specs, only from implementations :) Implementors benefit from specs ↺

I'm making this suggesting in relation to affiliation management in 0045: https://github.com/xsf/xeps/pull/1371

> In my frequent "I wonder if the server could do this better" moments, I do wonder if having a server identify and intercept all traffic to/from a MUC, and host a virtual MUC (for its user) and a single virtual user (for the MUC) might solve a lot of problems. For one thing, the virtual user need never actually leave the MUC when the real clients it was proxying for dropped offline. It feels like a way to vastly improve MUC without actually having to change every MUC and client - albeit some client changes would be needed to take full advantage. Did someone say https://modules.prosody.im/mod_minimix.html ? ↺

My goodness... If only the spec was sane to begin with

Zash, Like that, yeah. Few tweaks to allow explicit join/leave and stuff, and I think you're golden.

kurisu, I note you've not explained your new design that will account for all your concerns.

> > You realise there's not as much overhead as you think with XML? The bulk of the redundancy within a stanza is in close tags. Across stanzas there's a bit more, but nothing unique to XML at that point - you'd need an ASN.1/Protobuf kind of payload to avoid it. > The endless repeated needlessly long namespaces add quite a chunk.Pretty sure even json or bencode wouldn't blow it up that much. But then a gain, a person sane enough to choose one of those would also be sane enough to not plaster long namespaces all over the place.. And there probably wouldn't be a need for multiple, self-repeating message ids either, or even a single one because with e.g. bencode you could actually hash the messages... Aand there wouldn't be a need for e.g. the extra occupant id if muc was sane from the get go. Madness is like gravity. If you think JSON helps then go look at the JSON(-LD) in ActivityPub as used by Mastodon, it's just as full of namespaces and redundant noice. Today I feel like most overhead in XMPP is additional IDs, timestamps and whatnot added by things. And don't forget the OMEMO base64 layer! ↺

>if you think $thing is better, look at people doing a stupid thing with $thing

I know several instances where software authors just invented their own serialisation plain text format on the spot and it was an order of magnitude better than xml and could even do more things, like embedding binary and being readable. And of course used much less bandwidth.

> > some groupchats I can't join from two devices at once > Wait what? I've literally never seen that Someone needs to update their 10 year old ejabberd :) ↺

“Any damn fool could produce a better data format than XML”

kurisu: why don't you use matrix then?

I guess it time to stop feeding

kurisu, Sure, but, and here's the thing, nobody cares. I'm telling you, people use MUC in really low bandwidth cases, and rely on it for life-or-death situations, and it works just fine.

Who relies on it in life or death situations? I couldn't rely on xmpp in life or death situations. Xmpp had my friend believing I killed myself, and me believing a girl ghosted me because messages randomly stopped being delivered for a while while reporting no error.

I maintain clients for both a fairly complex XML and a fairly complex JSON protocol and the amount of time I spent working on low level xml or JSON goes towards zero

Both use namespace btw 😂

I do quite a bit with low-level XML, but then, I maintain an XML parser. :-)

FWIW, XML is still faster to parse than JSON, as far as I can tell.

> I know several instances where software authors just invented their own serialisation plain text format on the spot and it was an order of magnitude better than xml and could even do more things, like embedding binary and being readable. > And of course used much less bandwidth. kurisu: lol no ↺

I believe that this discussion is well past its peak constructiveness level...

This is a mistake programmers make often, I could do this better myself, I should rewrite it. It's even got a name, NIH Syndrome (Not Invented Here) , that's why I suggested https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ as a good read as it has real life lessons that are best learned through reading rather than experience if you can choose

> FWIW, XML is still faster to parse than JSON, as far as I can tell. I've been always curious about that but never really looked into it... How would you check that? Do you pick a set of data in both formats (the best way possible in both) to start comparing, for example or..? ↺

Seve, I think you can demonstrate by first principles. XML you can parse in a single pass through the data. Entity decoding aside, at least, and we don't do user-defined entities in XMPP so that's fine. JSON you have to in some cases check the previous character, so you'd have to copy state. Moreover, you need to do string unescaping in many more cases - rapidxml does it on demand (now), but attribute names and element names never need decoding, they're always sequences as on the wire. JSON, on the other hand, allows escape sequences in object keys, and since there are multiple encoding options for strings, you more or less have to decode.

In a world where we have gigabytes of ram to power some web desktop client, and every website is MB of traffic for 1000 ad partners, there we seriously discus some text format. This protocol didn't blow up exponentially the last decades, but storage and bandwidth did. So.. By comparison it became much more efficient then 10y ago This is nothing but bikeshedding. Why is there this obsession with xml or whatever plain text.i think everything one could use is ~the same, because it is basically nothing. ✏

> This is a mistake programmers make often, I could do this better myself, I should rewrite it. It's even got a name, NIH Syndrome (Not Invented Here) , that's why I suggested https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ as a good read as it has real life lessons that are best learned through reading rather than experience if you can choose Should xmpp have been an extension to irc by that logic? ↺

kurisu: maybe, but IRC isn't very extensible and XMPP adds a *lot* of stuff

That just sounds like NIH

/s

And have you seen how awesome steam cars were before gasoline cars took over? :D

Yeah XMPP is basically a different product. the whole idea of NIH is that you're looking to reimplement the same product essentially

All of human history is full of things being replaced by other things and then when it's too late we realize it was a bad idea

You think you can do one minor thing better so you create a whole new product

Consider that XMPP to some extent came about in order to create a unified interface to things like the Open System for CommunicAtion in Realtime protocol and the Mobile Status Notification Protocol. Not as a replacement for IRC, hence why MUC is an additional XEP and it's like the 5th attempt at group chat or something.

Zash, I think MUC is only the second attempt, actually. The other 3 came after.

dwd, I could have sworn there was a thing before Groupchat 1.0 tho?

>> This is a mistake programmers make often, I could do this better myself, I should rewrite it. It's even got a name, NIH Syndrome (Not Invented Here) , that's why I suggested https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ as a good read as it has real life lessons that are best learned through reading rather than experience if you can choose > Should xmpp have been an extension to irc by that logic? kurisu: IRC isn't eXtensible, if it was, we likely wouldn't have XMPP ↺

OTOH I weren't around in those times so I don't know

Zash, Before even my time, but I believe that before groupchat, the XMPP community used IRC.

The historical records are a bit unclear on the 1999-2002 period

See all the systems that came after XMPP for example, where all just do a poor job of reimplementing half of XMPP

Zash, Maybe Kev knows? stpeter would of course.

We really should download PSA's consciousness one of these days...

Guus, I think Klensin is the more pressing problem, TBH.

Zash, Got any specs/docs for minimix beyond what you shared above? I'm pretty sure a customer of mine would find this useful.

dwd, no, what you see is what there is.

Also haven't gotten much actionable feedback, or not enough to find motivation to work on that again.

XEP-0045 section 10.5 defines that an owner list can be retrieved only by owners of the room. Shouldn't other participants also be able to see who's an owner?

(modifications to be restricted, sure, but a simple get?)

oh, JIDs

which is a privacy concern

We allow it (get) if JIDs are visible ('whois')

I'm pretty sure that behaviour is somewhere in XEP-0045, though it may have been one of the more recent additions

> If the <user@host> of the 'from' address does not match the bare JID of a room owner, the service MUST return a <forbidden/> error to the sender.

I can't find it in 0045 (searched for `whois` and `non-anonymous`). It does make for a sensible addition, I think.

That MUST makes a lot of sense in non-anonymous rooms where the JID is broadcast along with the affiliation to every participant anyway /s

'makes a lot of sense' ?

Sarcasm

my client doesn't support that.

Put all that MUC stuff on hold and draft XEP-xxxx: Sarcasm indicator /s (for Serious) ✏

What, you're not already working on that?

No I was waiting for someone to discover that XEP-0045 or XEP-0060 already had a section about it :P

I'm preparing a PR with this change - should it be applied elsewhere than in 10.5 and 10.8?

Is this about fixing/improving the XEP? Because yeah, such a change can go further :)

I thought we'd done it already, around the time we updated Prosody, but this section is related and "wrong": https://xmpp.org/extensions/xep-0045.html#modifymember

It says that if the room is members-only, you should allow any member to fetch the member list

Which leaks JIDs in a semi-anonymous room

Granted, semi-anon + members-only is not a common configuration, but it would be somewhat surprising for someone to find that JIDs are exposed to members when the configuration form says they are not

Although related, it's slightly different. To have to-the-point discussions, lets add that in a different proposal.

So in Prosody the logic (for all affiliation lists) follows the whois setting

Well, it's strongly linked - you're proposing changing the rules for fetching affiliation lists, and here is where it is already defined (for members, anyway)

yes, but I've already been called for dinner, and that other PR is ready as-is :)

Well, submit it, we can continue the discussion :)

https://github.com/xsf/xeps/pull/1372

Thanks :)

MattJ: do you think that the distinction that I added between semi- and non-anonymous rooms is sufficient here?

> When did anyone ever want to join a group from his laptop but not his phone? Well, I do want that for most of my public groups, so much that I use a patched gajim to do just that 😊

nicoco, why not set autojoin to false in your bookmarks, and leave the channels from your phone?

Or just use a separate account for personal vs MUCs. That's what I do

If you set autojoin to false, all your clients automagically leave! Ain't it grand!

Or simply leave the channels from your phone, Gajim does not yet implement leaving when other clients leave from xep-402 https://dev.gajim.org/gajim/gajim/-/issues/11288

> If you set autojoin to false, all your clients automagically leave! Ain't it grand! Is this sarcasm or the reality? 🤔 XEP-0402 doesn't tell clients to do anything if they receive a notification with autojoin=false

It's the reality with Conversations + Dino at least :)

And if you leave a channel while autojoin is already set to false, will that send a bookmark retraction notification?

> It's the reality with Conversations + Dino at least :) Why not update the spec then?

How can you be joined if autojoin=false ?

Joining flips it to true, other client follows.

Leaving flips it to false, other client follows.

When is a bookmark retraction notification sent? https://xmpp.org/extensions/xep-0402.html#example-13 From my understanding, that is when a bookmark is deleted.

> Leaving flips it to false, other client follows. In which spec is this documented?

I is just what clients comsider modern now. And just do

To mimic other chat platform behaviors

> I is just what clients comsider modern now. And just do Not having it documented results in different clients doing different things

We have standards for a reason :)

From XEP-0402: > autojoin attribute: Whether the client should automatically join the conference room on login. So, my understanding is, if you update the bookmark to have autojoin=false, the clients won't leave immediately, but they will leave on the next login. If they stay logged in forever (movim?), they never leave ✏

>> It's the reality with Conversations + Dino at least :) > > Why not update the spec then? Because spec does not spec UX ↺

>> I is just what clients comsider modern now. And just do > > Not having it documented results in different clients doing different things Which is good 🙂 ↺

singpolyma: The spec says: - if autojoin=true, join the channel - if the bookmark is deleted, leave the channel But it doesn't say anything about autojoin=false. These are similar and related things. It's not good that some of them are docuemnted

while others aren't

Does it really say if bookmark is deleted leave the channel? That seems like an odd thing to be in a spec

Interesting given that retraction is not in the required pubsub subset spec'd by PEP, why a bunch of early PEP XEPs has a "publish an empty thing to delete"

> Does it really say if bookmark is deleted leave the channel? That seems like an odd thing to be in a spec I'm not sure. What does this mean? > if the event is a retract notification, the client SHOULD leave the room immediately. https://xmpp.org/extensions/xep-0402.html#example-13 ↺

singpolyma

Huh. It's even SHOULD that seems quite strong to me

It makes the join/leave consistent across clients

(a few hours ago somebody was complaining that xmpp doesn't do this ^^ ) ✏

Depending on what "join", "leave", and "consistent" mean it may do that. Doesn't mean it belongs in a xep. Different clients may legitimately want to do different things, and what "most" clients want even changes over time

What "join", " leave", and "consistent" mean: If you have multiple online resources, either they're all joined to the room or they're all not joined.

That's a fine default but makes sense some don't want it

https://xkcd.com/1172/ 😅️

But as said above, using different accounts is a solution for those who don't want it

Or possibly using the new XEP https://xmpp.org/extensions/xep-0492.html

Or clients could optionally let you mark specific rooms not to join manually, doesn't need to be overcomplicated

Don't you mean "not to join automatically"?

You mark them manually, so they aren't joined, but sure