XSF Discussion - 2026-06-29

> No, just an over-enthusiastic human Admittedly he did motivate me to get an old project over to new maintainers ↺

Tacky looks fun. Is there a DOAP file for it somewhere?

dwd: it is actually the latest of the aforementioned opened issues

Is there a way for a client to know that the MAM archive has fundamentally changed? As an example, if the underlying server implementation has changed so that the ids have all been reissued?

In other words, something like UIDVALIDITY in IMAP, but I imagine that may not be as helpful for most people as I intend.

No, but what would you do if you get this?

Wipe the local cache, and refetch messages.

It's not the only thing you could do, mind. You could keep the local cache, but you'd need to know not to use ids from it against the new archive.

You know once you receive that the id does not exist. Whatever you do then would be the same I would guess

dwd, currently the contract is that the IDs of existing messages must not change. If we want to relax that, we would indeed need something like UIDVALIDITY, but.... who really wants that? :)

dwd, does not mean that IDs of existing messages change, I think he meant if you wipe the database, switch to another server. And all IDs are now meaningless

I read it as renumbering, not as wiping.

well, not just meaningless. if you move to another server you may end up with a new message with the same id as an existing message. which would break everything

I think the switching server impl does not matter. If the database is wiped all IDs are unknown, it does not matter if the id would be theoretically valid

MattJ, What lovetox says. Hard to require that ids are stable if you switch from Prosody to Openfire (or the other way).

in a worldview where MAM is more like a temporary spool to get clients up-to-date instead of an eternal archive, that's not too much of a problem.

well but the IDs are eternal locally in the app

even if the server doesn't keep them

> in a worldview where MAM is more like a temporary spool to get clients up-to-date instead of an eternal archive, that's not too much of a problem. Which certainly isn’t universally the case. :)

And ids are used as the common concept of when to spool from/to.

Most MAM implementations have ordered IDs based on time, UUIDs, or both so it's probably not an issue in practise. But if someone did it it would be very bad for sure

and if the server doesn't have the id (anymore), in a spool worldview, you're like "ah, tough luck, I fill the gap from the point the server has to offer and inform the user that there's probably something missing there" ✏

Yes that's fine. The issue is if the server now has a message with id X and I already locally have a message with id X that is a different message

singpolyma, An id clash? Yes, that'd cause some wildly odd behaviour.

very wildly odd, yes

FWIW, I'm actually looking at a case where I need to actually rewrite messages in the archive, and want a client to ditch its archive and refresh. It's a closed system, I can do anything. But I was curious as to whether the more general case had been considered.

> and if the server doesn't have the id (anymore), in a spool worldview, you're like "ah, tough luck, I fill the gap from the point the server has to offer and inform the user that there's probably something missing there” Even in the spool model, that doesn’t work in the face of a server migration that re-IDs everything, as you’d end up with the full imported history duplicated in the client store, no?

yes, you'd get dupes for sure if you keep the messages but change the ids

Obviously server implementors could cheerfully subvert things by changing the id validity signal on every session, making the mam ids ephemeral. We had that problem in IMAP many moons past. But you can't stop people being people.

Does anyone from XSF have access to the EU (OSPO, JoinUp, Commission, Parliament, DC EDIC …)?

Because I’m looking at a EU Commission / DC EDIC presentation on the EU Open Source Strategy and instant messaging is one of the priorities.

ralphm MattJ maybe?

I thought EU solved instant messaging sovereignty already by making facebook add an API orgs can get access to via signing an NDA ?

nah that was interop not sovereignty

do legislators know there is a difference

seems that way

Might be good if XSF (or XMPP projects/companies) were involved: https://digital-commons-edic.eu/

Probably the easiest through the EU Sovereign Tech Fund, where Germany’s [Sovereign Tech Agency](https://www.sovereign.tech/) is heavily involved with.

Getting some projects funded through that might be a great way to put XMPP on the map of the EU and its member states, by showing XMPP is a standard protocol that is very much alive, robust and capable, but may just need some investment in polishing out some shiny bits here and there.

https://digital-strategy.ec.europa.eu/en/factpages/eu-open-source-strategy

everything I read there looks like they are investing in products not protocols, so interested products should indeed look into it

I agree that the first step should be for XMPP projects and/or companies to make. But the DC EDIC (and the EU FOSS strategy) is also about collaborating with the communities, so XSF has a strong position here to, once the question of standards and protocols (hopefully) inevitably pops up.

Here XMPP’s community (incl. businesses) has an upper hand IMHO, because 1) the protocol is open, standard and openly developed (IETF, XSF); 2) due to different projects and businesses offering interoparble servers/clients/extensions/… vendor lock-in is the lowest in all messaging solutions; 3) it has a not-too-loud, but well proven, track record.

you are preaching to the choir here, I'll only note that the XSF is not the "XMPP Community", it's just a standards organization comprised of volunteers

normally people interested in pushing govts usually have a financial interest in selling something, XSF does not, some XSF members might

I skimmed through the EDIC and the EU Open Source Strategy. Before this gets written off as "products only" a couple of things worth noting:

1. The EU Open Source Strategy has four pillars, and one of them is explicitly standards: "reinforced standards and international outreach," including better integration of open source into standardisation processes. So the protocol/standards angle isn't outside scope: it is a named objective. 2. The EDIC does currently have two concrete, component-shaped projects (the 100-Day Challenges and the EU Sovereign Tech Fund pilot), so yes, a funding application needs a real entity and a deliverable. But, it also says these are "the starting point, not the full scope. The first challenge is about making national suites interoperable. That's a standards problem by nature, and I think it's exactly the shape of thing XMPP exists for.

As the scope is literally still being written to me is the argument for engaging now rather than deciding in advance that there's no room for us.

Guus, sounds reasonable to me.

I’m one of the representatives for Slovenia (observer country) in DC EDIC, so I need to keep it clean, but I think this is a great opportunity for XMPP.

hook: can I interest you in putting this to the mailing list?

Guus: Sure. Which one? Standards?

I'd go for members, as I suspect that reaches a more appropriate audience