jdev - 2025-06-18

I'd assume it's a name that the server sets aside so no-one can actually create it, but that's obviously not something a client should be expected to create?

hey, I'm building a bot slinging presence around. I have trouble finding if contacts are available

when I join with the initial presence, I get an unknown number of presence stanzas from my contacts taking an unknown time, but I only get them from available ones

how do I distinguish between an available message taking a long time to arrive and a contact being unavailable?

I did try sending probes but I never got a reply if the contact was unavailable (older ejabberd)

In a MUC?

If you talk not about the MUC case I think there is no way to discovering that.

But it's not clear what you mean by message arriving

Presence has nothing to do with messages arriving

Or do you mean by message the presence message

I mean the presence message

there's "if the contact has no available resources, then the server SHOULD reply to the presence probe by sending to the user a presence stanza of type "unavailable"" in https://datatracker.ietf.org/doc/html/rfc6121#section-4.3.2 but it's only SHOULD, not MUST

does anyone know how to convince ejabberd to always send the reply?

testxxxi: There's no way without patching the code.

can a mod do that?

Yes it could.

You can't force other entities to reply if they aren't programmed to do that

the other entity is the server, so I guess it's fine

it only has to return the cached last presence

testxxxi: The bot is trying to do a one-time thing?

testxxxi: Because for a regular IM client that copes with presence state changes anyway I wouldn't quite see the point.

Assume the contact is offline until you receive available-presence.

Holger, no, it's a kind of a bridge and I want the bridge to know if the account is online as soon as it connects

Why that "as soon as it connects" requirement?

because the bot has an account in my contact list and I want that account to be online or offline depending on the other side of the bridge. Initially I wanted the bot to be connected permanently and go invisible to indicate "the other side is offline" but invisible presence has never been standardized and is gone

so I must drop the connection entirely instead

I'm not doing a great job explaining but it's basically a mutant doorbell. I want it to tell the other side if I'm online or not, and I want to know if there's anyone on the other side

> because the bot has an account in my contact list and I want that account to be online or offline depending on the other side of the bridge. Initially I wanted the bot to be connected permanently and go invisible to indicate "the other side is offline" but invisible presence has never been standardized and is gone There is an XEP for invisible presence (several even but only one that hasn't been deprecated/obsoleted?) but you'd have to implement it yourself

it got kicked from ejabberd back in 2010 based on a quick search :P

I think expanding the SHOULD would be a more productive use of my time. I remember being disappointed I could not see offline statuses of friends back when I moved away from GG where offline statuses were a super important part of the chat culture

GadoGado?

GaduGadu, yes

Ah yes. I remember having the transports. We're showing our age, I suppose :)

the transport one day stopped working and took my password :P but those were not important friends anyway

testxxxi: Well the RFC explains why it's only a SHOULD right after your quote, and I think that reasoning applies even more so with today's mobile use cases (they generally don't like presence floods, even more so given they're generally not too interested in presence info).

("kicked from ejabberd"?)

I think what currently saves us is that mobile XMPP users "generally" don't have to huge of a contact list. For world domination, we'd have to think about how to get rid of probe responses, not how to add more on top.

I think it's basically impossible without breaking backwards compatibility

And if you wanna break compat then you could as well start from scratch

Feature negotiation does allow such things.

But I was really just explaining why I have no personal interest in teaching ejabberd to send even more presence spam :-)

Roster versioning except presence state versioning

That would probably be a lot more complex tho

I get it that people use things different now, but there are also people who use things different to how most people use things now. I'm not the one to solve the problem of what pigeonhole XMPP should force itself into, but I'm interested in making it more fitting to my use case which is similar to what we used to have

I'm team "everything is PubSub". If we had too much time & energy, we should find a general solution to this for PubSub. And once we have that, allow for opting out of traditional presence and opting in to PubSub presence.

I'm down for PubSub, whatever that means exactly, if it gets my doorbell to work :P

testxxxi: Yes, wasn't trying to argue against that viewpoint at all. I'm all for making more presence spam _possible_! I'd just be against making more spam the default.

I'm afraid that with "everything is PubSub" you are reinventing the worse ActivityPub or something like it ✏

I don't think so :-)

meanwhile, I think I'll pass with the ejabberd mod until I get more frustrated because modding seems less documented than I need right now

> I'm team "everything is PubSub". If we had too much time & energy, we should find a general solution to this for PubSub. And once we have that, allow for opting out of traditional presence and opting in to PubSub presence. And - viola - now you basically have another IM protocol on top of XMPP Core

testxxxi: If you return to that task and need help feel free to ask.

right now my ejabberd instance is crashing when I try to dump the database. If you're interested in a quick look: https://paste.debian.net/1380705/ , otherwise I think I should upgrade it

testxxxi: Looks like "something very broken" :D It's failing to parse your ejabberdctl command line. (And guessing from the line numbers it's a pretty old ejabberd version?)

testxxxi: But let's maybe move that to the ejabberd channel.

speaking about presence spam again, I don't know which XEP defines the initial roster presences, but I'm surprised a "roster presence complete" event doesn't follow so that the client knows all online contacts have been updated and the rest are offline

it's the responsibility of the client's server to track those anyway (even if they ar not cached)

If you follow up your initial <presence/> with a ping, would that be sufficient?

Since those have to be handled in the order received

that would, thank you! I was searching for a "barrier" but couldn't find anything

let's see what kind of a reordering that prevents exactly

is this what you mean? https://xmpp.org/extensions/xep-0199.html I can't find anything about ordering

The order is mandated by the RFC

this one? https://datatracker.ietf.org/doc/html/rfc6121#section-3.1.1 I can't find anything about ping vs presence ordering there, either

https://datatracker.ietf.org/doc/html/rfc6120#section-10.1

you just saved me heaps of work <3

Presence comes back from all manner of other servers though. Getting a ping response means your server has finished processing your presence but not that you have "all" the presence you will get

Especially since it can take some time for remote domains realising that they should send you the presence information of your contacts on their domain.

Presence information from your contacts will arrive piecemeal. It is possible that between those 'first' presence statuses, you'll receive 'live' updates (from a contact that you already had received presence).

Also note that contacts may become available/unavailable at any time, so you still need to deal with those changes, i.e. there is no stable point because it's constantly changing

You should start with the assumption that all contacts are unavailable, and then update as you receive available presences; also, cache status text if you want that for unavailable contacts (which is not necessarily their last update, but it's the best you can do)

that assumption of being offline doesn't work when I connect in order to answer the question: is X available at this moment? because it leads to assuming the answer and no need to connect at all (which is nonsense). and yeah, server-side caching seems to be a workable solution

hm, so the processing of the presence messages is *not* serialized via pings after all. I doubt there's an exception for the same server, so that's a no-go

If you want to know if an entity is online at a particular time, it may be best to simply send it a query and wait for the response. Doesn't need to be presence-based?

You will receive most presence updates within the first few seconds of connecting, so you will have largely up-to-date information, but others could be delayed for any number of reasons (or they could suddenly come online seconds after you did.) If you're intending to connect for a second, get presence, and then disconnect, then you can't guarantee a full up-to-date set of presences.

if you're interested in some 'last' state, then having that published through some server-sided pubsub node would probably work best.

what query would best be used for that?

https://xmpp.org/extensions/xep-0199.html may be the simplest.

although you _need_ to know/use a full JID for that to work

(assuming client-to-client functionality)

But you can trivially write something custom that mimics a "are you there?" -"yup" kind of query/response

yeah the full JID is a problem. If I don't know if the contact is online and under what resource, how do I get one?

Your clients can request a preconfigured resource

Or use a message stanza instead of an IQ stanza.

that would be the right solution if the client was a constant, but I prefer to have as few constraints on clients on the sides of the bridge as possible

Hello all. I have an ejabberd server that has been running for a few years. Works great and I use it daily.

..lately I have one particular contact that loves to chat in a stream-of-conscience kind of way.

..it is a bit annoying, but I do not want to block them entirely

use a client that has a mute functionality

Does anyone know if there is a way to prevent that persons messages being sent until once a day?

sort of like a digest that some forums can do...a daily digest

the digest is that you mute the contact, and read his messages whenever you feel reading a digest

Can the mute be done on the server rather than each client?

no, why ?

every user of your server can make this decision on his own or?

or are they complaining to you?

I ask because I float between several devices throughout the day. I have an XMPP client on each device

but would be a funny feature, hey man you talk too much everyone will from now on only receive a digest once a week :D

hmm, so to answer your question, i never heard of such a server feature

usually people solve this problem by muting

Ok. thanks. Anyone else aware of such a thing? Or can point me in the right direction?

sounds like something a client could have, but in the world of multiple devices that would probably need server synchronization too