jdev - 2025-07-01

what insight can i gain about https://xmpp.org/extensions/xep-0018.html being rejected?\

It says "Note well: The functionality described herein can and should be implemented by means of the Privacy Rules namespace defined in XMPP IM [1]. This document is provided for historical purposes only."

Which expands to, Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence (https://datatracker.ietf.org/doc/html/rfc6121)

hm i suppose, kinda just saw it, and pattern recognizing brain thought about invisible mode on discord and the like

kinda would be nice to build in functionality to effectively be seen offline by all people, dont know that its possible with mucs though

What you want is, effectively, XEP-0016

> Server-side privacy lists enable a user to block incoming messages from other entities based on the entity's JID, roster group, or subscription status (or globally). perhaps im reading through it wrong but this seems to be blocking other users, the opposite of what i want to achieve?

what im looking for is the ability to appear offline but still receive messages as per usual, and be able to send them the same

also 0016 is depricated by XEP-0191: Blocking Command ✏

Nope. Where did you get this text from? Read the XEP, it's about blocking in/outcoming _stanzas_, not _messages_

that text was from somewhere in the text, i think taken out of context

Ugh, damn connection

It isn't even out of context, it's just wrong

https://xmpp.org/extensions/xep-0016.html#protocol-message

also i dont think blocking all stanzas is what i would want either, as you would still want <message> stanzas to go throuigh, literally just the presence stuff. though like i said it might just not be able to work that way given how connection based xmpp is, but i think it could make sense for clients in the background or whatever else to mark themselves as offline as well

unless you should use extended away for that purpose?

If you don't want to send outgoing presence - block it in privacy lists then

ohhh privacy lists for each item you select what you want to block i see

Anyways, it would make sense if and only if XMPP sent presence to everyone, which isn't how it works

i am concerned by it being depricated though

> Anyways, it would make sense if and only if XMPP sent presence to everyone, which isn't how it works yeah still wrapping my head around the idea that you could in theory send a different presence payload to every connection ↺

So if you wanna stay invisible then just don't confirm any presence subscriptions

oh is the client responsible for doing that?

Did you think that server is responsible for you being online?

for letting others know im online, yeah 😅

(matrix trauma probably)

also how does that interact with muc? do you also handle a presence subscription for each user?

MUC doesn't require presence subscriptions

is there any way to invisibly connect to a muc?

> what im looking for is the ability to appear offline but still receive messages as per usual, and be able to send them the same jjj333_p (any pronouns): what you want is https://xmpp.org/extensions/xep-0186.html

> is there any way to invisibly connect to a muc? How would clients handle receiving messages from a full JID which hasn't sent presence in the MUC before?

there's servers which only send presence for "active" participants

but it's typically not something you can control from the client side for an individual join ✏

but it's typically not something you can control for yourself from the client side for an individual join ✏

> > what im looking for is the ability to appear offline but still receive messages as per usual, and be able to send them the same > jjj333_p (any pronouns): what you want is https://xmpp.org/extensions/xep-0186.html hm that does look to be exactly it ↺

should i be concerned by the status being deferred?

> but it's typically not something you can control for yourself from the client side for an individual join thats unfortunate, is there realistically any way that muc or future groupchat iterations make this possible? ↺

The only concern is if your server and client softwares support it

sorry if this is a bit of a novice question, but is there any good resource to check if servers (such as prosody and ejabberd) support various xeps?

On https://xmpp.org/extensions/ if you look on the right of the table there's a column for number of known implementations

oh perfect thank you!

186 doesn't have widespread support at the moment

it seems prosody removed support yeah

or no i clicked the wrong one

Prosody doesn't currently support it

i would assume this to be something that could be implemented via a custom/community module?

Potentially

Probably wouldn't be too difficult if you already know a bit about how Prosody does it

i dont, but ill consider it at which point im actually realistically implementing presence settings

That's on Goot's todo list actually

implementing presence settings in a client or figuring out how prosody does presence things?

Invisible presence on the serverside

ahhh nice

This client will make use of it to send each contact a different presence according to user preference

Appear busy to some contacts, free to chat with others, etc

i wonder if muc support could be done in a similar fashion, i.e. you send this iq to the muc host and it only delivers your presence to admins, it shows up as a "hallucination" to everyone else

Unfortunately as it stands right now the initial presence gets sent to everyone first

> This client will make use of it to send each contact a different presence according to user preference ah yeah im planning to do that in my client, im just far from actually implementing presence lol ↺

> Unfortunately as it stands right now the initial presence gets sent to everyone first yeahh ↺

The invisible command will help that

> The invisible command will help that would you be able to send it before you send an initial presence? ↺

>> This client will make use of it to send each contact a different presence according to user preference > ah yeah im planning to do that in my client, im just far from actually implementing presence lol See Goot is going for implementing all the features in the RFC's first before even implementing XEP-0004

get them fully implemented before moving on

It's going to be a while before it's ready for a proper release

>> The invisible command will help that > would you be able to send it before you send an initial presence? It seemed like the spec supported that at least on last read

i should probably look at the core rfcs, im relying partly on my underlying library (mellium), and just kinda lookiing at the ux feature i want and going up from there and accomplishing the prereqs

Unfortunately the platform for which Goot is writing has no XMPP ibrary currently ✏

> i wonder if muc support could be done in a similar fashion, i.e. you send this iq to the muc host and it only delivers your presence to admins, it shows up as a "hallucination" to everyone else i think it would be worth looking into this, as otherwise your muc presence would effectively leak it, and most people just autojoin all their mucs ↺

Unfortunately the platform for which Goot is writing has no XMPP library currently ✏

Nothing's really _stopping_ this, but there's no spec for it and could cause interoperability issues

would there be any way to propose it as an extension of 0186?

What would clients who don't understand XEP-0186 or another XEP that does similar see?

see, i thought there was president for recieving messages from resources you dont see as joined (i.e. from either mam or legacy history) ✏

It's complicated

Is it allowed to send service messages from the MUC itself somehow? For a message of type "groupchat" from a MUC JID, Gajim replies with a message error.

yes should be fine, lots of stuff does that

grouchat from bare jid

Ah, I confused with a jabber:component:accept message, sorry.

singpolyma: yeah, I see them in Tkabber as pink messages, and they're even logged… But not in Gajim, it seems to ignore them, even though I made broadcasting them to full client JIDs with resources, so it's not priority issues or something.

sounds like a bug

> is there any way to invisibly connect to a muc? jjj333_p (any pronouns): some servers had and might still have a bug where you could query muc mam without joining the channel which sounds like what you want ↺

Not all mucs use mam. Or at least one public muc doesn't.

That's only a bug if the client isn't authorized to join/know the history otherwise

You'd also have to constantly query for new messages

It's a bug if you only want people joined to read history, which is how it was considered iirc

> In the case of open MUC rooms, the MUC archives can generally be accessed by any users (including those who have never entered the room) who do not have an affiliation of 'outcast', but a MUC archive MAY further limit access based on other criteria as part of the deployment policy. From XEP-0313 section 6.1.2

If a client's user doesn't want to join and participate but still wants to keep their local archive relatively synced so that there's no big flood when the user next joins

Likewise, if a user isn't sure they want to join a public room just yet, they can check out the vibes before joining

Considering mucs with a few real "participants" and 1k, 10k, or more "viewers", it seems like something useful.

>> is there any way to invisibly connect to a muc? > jjj333_p (any pronouns): some servers had and might still have a bug where you could query muc mam without joining the channel which sounds like what you want definitely not a bug ↺

"joined" is just about presence broadcast. For historical reasons most MUC won't let you send unless "joined" but otherwise there's no reason to limit actions

I swear I saw that but maybe I was confusing it with https://prosody.im/security/advisory_20210722/

Not sure why listing members would be a remote disclosure CVE but listing all messages with members wouldn't be...

> 2025-07-01T15:57:03Z - singpolyma: > sounds like a bug Yeah, I tried it on another system with a newer Gajim revision and it's displayed there. ↺

BTW, how crucial is it to send a presence about a certain occupant before sending a message by it? I'm going to implement a LRU list of a limited length to map huge groups with tens of thousands and more members, and I wonder how strict the management of this members LRU cache and keeping it up in sync with clients should be.

bodqhrohro: clients don't seem to care about occupants when receiving messages, which I guess is good news for you

This was tested recently in the open hardware muc when # of participants passed 1000 and ejabberd's behavior of "ok show 0 participants ever now" kicked in

Messages worked fine, only problem was the messages from new people every few minutes asking why no one else was in the room yet people kept talking 💀

Could instead send the X most recently active users (who have sent a message of type="groupchat" oslt)

it makes sense for clients not to care if they've seen the user's presence before handling a message in a MUC; that means less special case code for dealing with MUC history (either legacy or MAM)

I think with GC3 we could easily allow sending messages without "joining" even

And let presence just be about what it is about, that is, presence

that ancient concept that no one has wanted or used for 20 years :P

Except for every user on every major that platform, sure

Which ones? Not SMS or email

i think you all forget something

Real JID is only communicated via presence

if a muc does not send presence, this means a moderator cant ban anyone anymore

easily fixed though right?

in a new GC spec yes? but you said, it is no problem in current MUCs that presence is not sent

Oh further up, bodqhrohro 's issue, that's a great point you'll need to send everything to mods

Then moderators get hit with the thousands of presence stanzas

Perhaps drip-feed presence in some way to them?

If someone's not actively chatting then they probably don't need moderator action

Unless it's like an hours-old message or incident and the only mod available just now logged in

you get the real jid on MAM messages

but not on live

the idea still works, send a presence only right before someone sends a message

one could argue that nobody cares if someone is joined if they dont interact with the MUC, at least for the thousands of users scenario

but this is still problematic, i guess, you need to send a presence to almost everybody ..

Would that be every message or just if the recipient hadn't been sent a <presence/> of that user?

so one message triggers 10.000 stanzas sent out for the server

Either case has issues

current MUC spec is simply not great for this use case

Either bandwidth or complexity

it would be easier to disable presence sent out except for some roles - this config exists already

and then one would need to implement a addition to 0045, Ban by occupant-id

occupant-id is transmitted on messages

or basically add all the moderation stuff that now needs real jid, and add occupant-id instead

Is there an equivalent to Matrix Spaces for XMPP and if so, how does one use this feature? Using Gajim for example

idk what Matrix spaces are but Cheogram has spaces

I'm not sure if Spaces is the correct name to be honest, but what I mean is like having channels within a group chat, like in Discord you can have different channels within a group, so something like that

You could use <thread/>s

You know for the clients that support them anyway

There are XEP-0503, which is literally m***ix spaces ✏

I think cheogram spaces are limited to one muc component iirc, I think matrix allows to add rooms from different servers to spaces.

I'm kind of confused to be honest, so there are groups, rooms and spaces?

And the XEP-0503 is for spaces, but it's experimental and not really implemented anywhere?

A MUC component is just the easiest way to make a space right now, because it's already well supported by servers

You could do other things with some server side coding, but if you just want it to work right now with no fuss, make a component

I see. Excuse my noobness, but what do you mean by 'make a component'? Does this require coding custom stuff? Or can I create a MUC component on Gajim for instance

nope, no coding. just server configuration

"component" is the name some give to the domainpart after the @ in a MUC jabber id

in prosody for example you would add one line Component "myspace.example.org" "muc"

then you make the MUCs in this "container", "component", "space" as you wish to call it

> I think cheogram spaces are limited to one muc component iirc, I think matrix allows to add rooms from different servers to spaces. As far as i understand the XEP-0503, nothing prevents you from hosting chatrooms somewhere outside of the spaces service

I see, so I would need to host my own server for this? And could I, after having enabled the MUC Component, then create new spaces on the fly as admin via the client?

Host own server or else have a server where the admin is happy to make a space for you

I don't think any server has on-the-fly creation without editing a config file yet, but it's on my list to build that

I see. Yeah that would be really cool and convenient

To allow people to be able to create them on the fly via a client, like in Discord. I'm certain this feature would also increase adoption of XMPP

> I see. Yeah that would be really cool and convenient XEP-0503 also specifies that, so it should be there sooner or later

sort of. XEP-0503 is more about specifying the listing protocol and also some advanced use cases

but yeah, we don't really have any hosts focused on muc / community chat stuff today everyone just sort of rolls their own. having one click to get a muc service is the bare minimum we need I think

> sort of. XEP-0503 is more about specifying the listing protocol and also some advanced use cases It is (in theory, sadly) usable enough though

hi

> but yeah, we don't really have any hosts focused on muc / community chat stuff today everyone just sort of rolls their own. having one click to get a muc service is the bare minimum we need I think If Kaidan ever implements it maybe we can get KDE people to move :)

> "joined" is just about presence broadcast. For historical reasons most MUC won't let you send unless "joined" but otherwise there's no reason to limit actions oh good to know ↺

tbh being able to send messages without "coming online" is preferred, however unimportant

> bodqhrohro: clients don't seem to care about occupants when receiving messages, which I guess is good news for you this is good to know re the idea of asking the muc server to not disclose our presence ↺

still prob more work than is necessary if theres other ways around it, but being able to ask the muc to be invisible might be the cleanest

> if a muc does not send presence, this means a moderator cant ban anyone anymore this is why my thought was to cloak it to only non-admins ↺

Yeah, and this Gajim version from Debian Stable has another annoying bug regarding messages by bare MUC JID: they are not displayed in the history area, only _temporarily_ as the last message in the chats list, until I switch to other chat. I recalled why did I leave Debian Stable on my primary system :P And now I'm sure I shouldn't switch back. Messing with backports, all sorts of portable executables, and self-built executables from Git (which nowadays typically require the bleeding edge build toolchain anyway) is _a.n.n.o.y.i.n.g_.

I find backports quite easy to use for the few packages where I want newer versions.

> Yeah, and this Gajim version from Debian Stable has another annoying bug regarding messages by bare MUC JID: they are not displayed in the history area, only _temporarily_ as the last message in the chats list, until I switch to other chat. > > I recalled why did I leave Debian Stable on my primary system :P And now I'm sure I shouldn't switch back. Messing with backports, all sorts of portable executables, and self-built executables from Git (which nowadays typically require the bleeding edge build toolchain anyway) is _a.n.n.o.y.i.n.g_. i would assume still attach the resource name to the jid, unless youre not discussing presence ↺

jjj333_p (any pronouns): yeah, but which one lol, some dummy bot user for "announcements", perharps. That's not even supposed to cause naming conflicts, as all members have strict nickname formats.

> jjj333_p (any pronouns): yeah, but which one lol, some dummy bot user for "announcements", perharps. That's not even supposed to cause naming conflicts, as all members have strict nickname formats. The one you use as a displayname, no? ↺

(and they're all dummy, in fact, hehe, but the "my" user which also has an enforced nickname)

its not a full cloaking, just a cloaking of the online/offline switching

> > jjj333_p (any pronouns): yeah, but which one lol, some dummy bot user for "announcements", perharps. That's not even supposed to cause naming conflicts, as all members have strict nickname formats. > The one you use as a displayname, no? Makes sense. Newer Gajim displays the JID's local part for messages from the bare MUC JID, which is also not quite nice.

And I could actually format it the same way member names are formatted, but just the current group, huh.

i think we're discussing different issues ✏

but yeah just make it look like a member name tbh

jjj333_p (any pronouns): so without me testing it sounds like you can get what you want (messages from a muc without joining) by polling it's mam, I was mistaken about it being fixed

> jjj333_p (any pronouns): so without me testing it sounds like you can get what you want (messages from a muc without joining) by polling it's mam, I was mistaken about it being fixed moparisthebest, yes, which primarily solves it, however muc support for 0186 would be better if unlikely to happen ✏ ↺

but overall good to know, also good to know that you can poll mam without joining just as a general ability for other reasons

I find it kind of creepy but I can see use cases nonetheless

Like, the all seeing eye of sauron or something 👁️‍🗨️

i think it would be very useful, such as in the case of notifications you could just go ahead and fetch the entire history, but not actually go through the whole process of joining and leaving

(useful in case of loosing connection between receiving notification and the user reading it, ive lived through that kinda connection where you just wait 30 minutes for a send and then response eventually) ✏

(though ig now that i think about it how you gonna get the push notification... except maybe periodic fetching?)

which kind of push notification?

like through whatever apples push is, unified push, google play notifications, etc

like client is offline but you get notifications from relevant messages

ik thats not a super solved issue in xmpp, but still

(even in the case of remaining online in background as conversations variants apparently do, fetching mam at opportune times could be smart though)

Well if you have that kind of push set up you're not really offline IMO

> Well if you have that kind of push set up you're not really offline IMO true, however most platforms communicate this as offline ↺

though Extended Away might be more appropriate for such a state

yeah, communicating it as offline is just wrong IMO. I don't do that

does it make sense for the user's server to have a notification component that stays "joined" to mucs to serve push notifications? is that what existing push notification modules do?

i almost feel like extended away should kinda become offline but less ™

What I do is leave my client resource online and joined when using push. this is my module https://modules.prosody.im/mod_push2.html

> What I do is leave my client resource online and joined when using push. this is my module https://modules.prosody.im/mod_push2.html that could work for my use case (still far from worrying too much about push), though i might want to change the status to indicate the user is at least _away from the app_ ↺

(imo minimizing a desktop client should also be considered away after a while

I don't understand why many people claim that online/away/busy/unavailable statuses make no sense for slatephones anymore. Online = device is unlocked, away = device is in pocket, busy = I'm on a call or playing Genshin, nye ruini mne katku!, unavailable = device has discharged, pushes won't come.

Privacy concerns? sure, but statuses have always had them.

you could even (with user opt in ofc) use busy to communicate when the user has do not disturb on their system (ios has an api to find this, i assume android does too)

if you wanted you could come for imessage's "deliver anyways" and allow trusted contacts to send a "time sensitive" (bypasses focus mode) notification

Thanks for a suggestion for a new feature (and new article).

glad my rambling was of use

> you could even (with user opt in ofc) use busy to communicate when the user has do not disturb on their system (ios has an api to find this, i assume android does too) Conversations has this ↺

Hehe, okay.

cheogram too

the deliver anyways feature might be nice, if more complicated

would probably require some sort of spec of "deliver this immediately"