jdev - 2026-04-14

test

> test ie ↺

D:

are muc_open and muc_membersonly mutually exclusive?

I expect so

considering XEP-0045 explicitly defines the terms open and members-only as antonyms of each other, i assume so too, but i haven't yet properly read through the XEP yet so don't quote me on that lole

Sunglocto: yes

are they? 2 different booleans implies they are not mutually exclusive and nothing mentions this in the XEP so I'd say no they are not mutually exclusive

> Open Room > A room that non-banned entities are allowed to enter without being on the member list; antonym: Members-Only Room. > Members-Only Room > A room that a user cannot enter without being on the member list; antonym: Open Room. what does it even mean if a non-member can simultaneously both join and not join a room??

Where do you read that

I think the text is pretty clear

> Where do you read that https://xmpp.org/extensions/xep-0045.html#terms-rooms ↺

> are they? 2 different booleans implies they are not mutually exclusive and nothing mentions this in the XEP so I'd say no they are not mutually exclusive muc_open is not a setting with a boolean, it's a feature that can be in disco ↺

basically config muc#roomconfig_membersonly=true -> feature muc_membersonly config muc#roomconfig_membersonly=false -> feature muc_open

>> are they? 2 different booleans implies they are not mutually exclusive and nothing mentions this in the XEP so I'd say no they are not mutually exclusive > muc_open is not a setting with a boolean, it's a feature that can be in disco 2 different features, meaning they can both (or neither) be returned ↺

I agree a MUC returning both or neither would be silly, but when it's possible (especially when not called out in the spec) your code still needs to handle silly

it is called out in the spec

it says its an antonym

I mean, it's always good to be lax, but they're mutually exclusive, so the server would be misbehaving if they sent both. Reasonably behavior includes making it impossible to join a MUC that has both in its disco result (because if you can't know if it's open or not, better not join at all). However it may be that a room is in a state that's neither of the two

antonym: a word of opposite meaning

"antonym" is not normative language

A room can be in the creating state (between joining a non-created room and sending the room config form), in which case it is neither muc_open nor muc_membersonly. But also it's impossible to join at this state.

moparisthebest, 🙄

moparisthebest, there is no such thing as "normative language"

if you're referring to BCP14 keywords, RFC8174 is explict that "Specifically, normative text does not require the use of these key words."

all I'm saying is the payload supports both, the spec doesn't make them mutually exclusive via https://www.rfc-editor.org/rfc/rfc2119 or explicitly in any other way, so the answer to "does my code need to be aware of this possibility" is "yes"

I would argue the payload shape supporting both alone requires that answer to be "yes" but don't feel like dying on that hill :P

r.i.p. dying on a hill

definitely dont go up that hill

we can always just

make it explicit in the spec

yes ! lets solve more problems nobody has

> yes ! lets solve more problems nobody has agree

when in doubt do this

> make it explicit in the spec that's the way, aggressively remove any and all ambiguity ↺

for the win, no contest

> yes ! lets solve more problems nobody has it sure seems like a problem if the semantics of a formal specification can be questioned at all, let alone promptly debated on ↺

if we're arguing against making specifications clear why even have specifications at all

For fun!

so you argument is, a specification is not clear until you cannot find anyone anymore on the internet who can debate and question it?

i guess the easier way is to declare all specifications unclear and do something else :D

epic genius idea!

explicit or no plicit

> i guess the easier way is to declare all specifications unclear and do something else :D what an odd conclusion to come to. at that point why even try to improve anything when we all know it'll never be completely perfect? ↺

Let's make XMPP our own way

For me, I'll be using YAML instead of JSON or XML

expecting perfection, while hardly realistic, has already been achieved

xmpp is amazing, you should try it

¿How do I make a MUC read-only during the night and read-write during the day?

With a module!

Yup

modules for the win

i have yet to figure out custom modules for ejabberd. that could be a good amount of fun, so long as I can use not erlang o_o

How big are XMPP stanzas on average

seems impossible to answer generally

generally accepted max on the public federated network is 256kb if that helps

The vast majority of stanzas are `<presence/>` so the average will tend towards the average size of those (less than 1kb)

> How big are XMPP stanzas on average smallest of the standard limits of prosody and ejabberd ↺

ley posted a limit for prosody that secures you against a dos attack

Is it possible to make a XMPP client for the Sega Genesis with stanzas as big as 256kb?

Maybe that's a dumb question, but someone managed to make a IRC client for it

there are xeps for using xmpp's models in constrained environments

some millitary contractor said to support it i think

I wonder if that could be useful

Imagine having an entire client in 64KB of RAM

do you want to do TLS on it too or are you ok offloading that?

xmpp over wireguard when

would wireguard even fit

maybe mqtt or some shit?

I wrote https://github.com/moparisthebest/kiss-xmpp to use from my 1983 atari ... one day I'll play with writing a native one :)

holy shit

xamn