jdev - 2026-03-01

is there a XEP for message expiration in a specific convo / channel like in signal/whatsapp? (not a client side setting that would only apply to me)

https://xmpp.org/extensions/xep-0466.html

thx

> https://xmpp.org/extensions/xep-0466.html I wonder, can anyone just do Service Discovery on someone else and see if they support ephemeral messages? ↺

so as far as i see there is no client implementing this XEP and no MUC support in the spec?

MUC support is harder to coordinate

Even if the popular clients supported it, someone could be in the MUC with a obscure client that doesn't support it.

i'm guessing it would be a new field alongside MAM retention time like « request clients delete history after XX days »

And really, I don't think people should be tricked into a false sense of security over that

> Even if the popular clients supported it, someone could be in the MUC with a obscure client that doesn't support it. sure that's a well-known limitation, it's not exactly a security feature but it's still appreciated by users for some reason ↺

just like message retractation doesn't imply nobody kept a copy, and is still appreciated

Sure

I think there should be a warning if the user in a 1:1 chat tries to use ephemeral messages with the other user that doesn't support it

i'm not sure? it's better if the UI lets the user know people may not honor this setting, whether or not their client technically supports it, because of screenshots and whatever :)

Won't stop someone from maliciously advertising support while not doing so, but better than nothing :P

what i'm saying is the warning should be there even if the remote party advertises support :)

(if that makes sense to you)

still i personally see little value in this feature, but since 3 different friends asked me in the past months i thought it was worth asking about :D

Yeah, the XEP exists but it always brings up these conversations

I understand that client developers aren't keen on it, because it could potentially give a false sense of security to users

Yeah

This XEP was written with that in mind, it's more of an agreement protocol than a "Your message will definitely be deleted with 100% certainty" protocol

But still, if you want it implemented then it's worth approaching your favourite client developers and asking for it

is anyone aware of development for MUC support for that XEP?

I'm not, and the author has retired themselves from the XSF so I don't expect they would be working on it

thanks

I have plans to implement it, but not for muc

great! just curious though why not for MUC?

Makes everything more complicated. What if 4 people all set different expiring time suggestions, what do I suggest to the user? Etc. Better to start with the easier and more useful case

makes sense, but what about setting it at the MUC level instead of letting clients define their own expiry settings?

That's just MAM retention ✏

But client-side deletion

not exactly because MAM retention has no semantics for how long the client should keep logs

(i'm not sure if there's a usecase where they would use different values, though)

also mam retention is not advertised to my knowledge ✏

but yeah would be usueful if we just would add a config field to the MUC where a admin can define some limit

but i wonder is this a good design to have it per message in single chat? ✏

is this really needed? or is 99% a chat setting that says delete everything after X days

whatsapp negotiates a value per chat as it seems

but this is a model that we dont really have in xmpp to negotiate something per chat

i think a value per chat is more useful and avoids the "keep sending the expiration value forever" for negociation, but not sure how that could be implemented

(though setting an expiration on 1 message precisely is also a feature on some networks)

my feeling is i want to ignore what a contact sends me, i just want to tell them what i will be doing

say i set my local setting to 30 days, i want to tell them, that this is my policy, i dont want to respect theirs. If i want to do this i could set my setting to the same thing

though whatsapp has this feature, to look at pictures once

well it would make the feature more complicated in client code, but it would make sense to support both, like « Foobar requested to set expiration for this chat to 1 day » -> Accept/Refuse and if you refuse let the other side know what your settings are

yes but we lack mechanisms for that

sending a message with this info is not the best, because on a new client, you maybe will not load history so long back that you receive this information

it could be an IQ to whatever device is online

so maybe polling for the information in some intervalls?

can it be stored in PEP so it works when the other party is offline too? then query it once every connection (or when starting a new chat) ?

> say i set my local setting to 30 days, i want to tell them, that this is my policy, i dont want to respect theirs. If i want to do this i could set my setting to the same thing There's no requirement to match policies. Though my idea was to present a button like "contact suggests expiry after 30 days. Match?" ↺

yeah but when do you do this

everytime they send a message with a new time?

this makes it necessary to send the time on every message

no? we would just not send the inband expiry as suggested by draft XEP

(or optionally set it on a single message for single-message expiration which doesn't affect the session)

> no? we would just not send the inband expiry as suggested by draft XEP i dont understand this sentence, if you dont send something, another client cannot "match" the policy ↺

i mean maybe im overthinking this, its just so inefficient, to add a information on every message, though you need it only once or when it changes

it would work though

yes you would send it just once when you set the policy, or resend after a while if you received no response but the remote client advertises support for the feature, just not on every message

.. there is not only one client on the other side, there could be any day any given amount of clients

sounds more complicated then we gain in value

we could store it in pep in a node thats named after the remote JID

yep

or we just send it with every message :) its indeed the easiest solution

just not the most efficient one

yeah, checking against local settings on *every* received messages doesn't sound very efficient ^^

(to see if the settings still match)

this is just a query to the settings code which is in memory, thats not what i would worry about

> we could store it in pep in a node thats named after the remote JID What if you wanted to only send dissapearing messages on certain occasions rather than all tthe time ↺

then you can do this by including the time in the message

> or we just send it with every message :) its indeed the easiest solution Or just once when it changes, which seems more in line with the XEP ↺

then you might receive it never

> then you can do this by including the time in the message yes but if that's also the signal for changing the setting, that makes things more ambiguous and complex than storing it at the "session" level ↺

> then you might receive it never Why? Are you missing messages? ↺

i actually missed one message in gaijm on a MUC yesterday, only caught it because our matterbridge instance relayed it on libera.chat and i'm also connected there via biboumi, not sure if that's something i should be investigating

by the way jdev@, we're working on message replies/reactions and files uploads for XMPP backend on matterbridge… also someone is slowly working on a component backend to allow puppetting… if reviving matterbridge for network interop (without user intervention, unlike gateways like slidge/biboumi) and making it more glorious is of interest to people our community fork is very welcoming: https://github.com/matterbridge-org/matterbridge <3

(i feel it's a shame the discord backend is much more featureful than the XMPP one :P)

> Why? Are you missing messages? > of course? do you load 2 years of history on a new device because you opened a chat? ↺

feel free to do that if thats what you want, but i would not create a spec that makes that a dependency for even working

>> we could store it in pep in a node thats named after the remote JID > > What if you wanted to only send dissapearing messages on certain occasions rather than all tthe time Actually you could just maybe include an element that explicitly says not to delete ↺

do all "maintained" MUC servers support stanza-id? or is that a wrong assumption in 2026 when implementing message replies?

yes, but why would that matter?

there is not other way to use stanza-id anyway, so if its not there, then dont allow to reply

i 100% agree, just wanted to make sure my understanding was correct that we should treat origin-id as a radioactive artifact and only ever care about stanza-id

(thanks)

you should follow the XEP, which says you must use stanza-id for groupchat messages ✏

yup, that was the plan all along, the question was more about how to map our own messages internally, and whether to use origin-id or stanza-id in our bridge->messageID mapping (i was indeed arguing for stanza-id but just wanted to make sure because someone suggested maybe not all servers implement it) ✏

selfhoster1312, ignore origin-id, use stanza-id (but also be aware that there may be multiple stanza-id elements with different 'by' attributes)

hmm you mean the MUC server and my bot's server could each add their own stanza-id and i should really filter by=muc.whatever ?

Yes

In most cases there is only one that you care about, and it will be the one with the archive that you will synchronize with

So if it's a MUC server, you will synchronize with the message archive for that MUC, so you want to pull the stanza-id with by='room@muc.server'

sensible :)

For direct messages, your archive is at your own account, so you would pull the stanza-id with by='you@yourserver'