jdev - 2026-02-19

> A space is a organisational unit that is usually managed by a single group or entity, they can choose a server where the host this space, and all MUCs should be on that server Maybe that deserves another concept/terminology, but it would be a shame for this effort not to result with the ability to collect rooms under one umbrella that's easily discoverable and subscribeable to. It's nice to have spaces as "cohesive silo under one the supervision of one admin team on a single server instance" It's also nice for people to be able to interact with "collections" of topically-related rooms (e.g. "electronics": Collection = Set("open hardware": muc, "embedded software dev": muc, "3D printing": muc, …) ↺

I agree, I think it would be feasible to have a "related rooms" feature

I did write up Related Enties a little while ago. I should clean it and submit it maybe.

https://github.com/swift/protoxeps/blob/master/related-entities.md

And who says what is related? The MUC owner?

Or is this like a blog kind publishing situation, I publish a list of related things somewhere, and somebody van download it and join it? Kind of like a bookmark group?

I feel like something like this could be achieved by defining some kind of bookmark group sharing mechanism

I would add a group element to bookmarks and define a group share xmpp uri

This way everyone can build related stuff and share it? There could be also a well defined node on a home server where an admin can publish the groups

But hard to call that a space .. its a collection of bookmarks

Hello. Has anyone come up against this error recently when trying to send a message to a user on quicksy.im? "Authentication failed: Peer responded with error: unsupported certificate purpose (not-authorized)"

The issue appears to be the latest Letsencrypt (i.e., Google) attempt at making the web a closed ecosystem where only oligopolists get to play while everyone else is relegated to being a mere consumer. Details explained here: https://blog.prosody.im/2026-letsencrypt-changes/

My own server is ejabberd 25.10 which I believe should be able to cope with this breakage by accepting "TLS Web Server Authentication" (OID 1.3.6.1.5.5.7.3.1) as sufficient for S2S purposes. Not sure what Quicksy is using at the moment.

quicksy seems to be using ejabberd 24.12-3

So that's probably expecting my server's certificates to have both "TLS Web Server Authentication" and "TLS Web Client Authentication" flags, right? Sadly, upon certificate renewal a day or two ago, the latter claim is no longer present in Letsencrypt certs.

LetsEncrypt announced phasing out a specific flags a while ago. I believe that comes into effect ... now-ish, so it tracks.

I've poked the quicksy.im admins

https://letsencrypt.org/2025/05/14/ending-tls-client-authentication

Is dialback still working for you? That may prove to be a workaround to get around s2s authentication issues.

I've managed to coerce a server+client certificate out of Letsencrypt with `getssl` for now (add `PROFILE="tlsclient"` in the configuration file) but that'll stop working by mid-May.

> Is dialback still working for you? No it did not seem to work, although I did not fully validate my server's configuration. But at first sight, it looks like quicksy.im does not do dialback.

> I've poked the quicksy.im admins Poking Daniel seems like a good move, in case he's not aware of the issue. Thanks @Guus!

I'm building my own xmpp client and I wanted to add support for server-side search. I ran some tests against a local ejabberd instance but apparently nothing in the wild supports it - I couldn't find a single alive MUC which would advertise it. The server I'm using, draugr.de, advertises support for it, but when I try to search one of the dead but not empty MUCs always returns zero results if you specify {urn:xmpp:fulltext:0}fulltext (that is, with a string that I can see in the chat history for that MUC). So essentially server side message search is non-existant.

Also, mongoose advertises support for it, but in reality ignores that field altogether.

maybe report the bug to ejabberd?

it's not an ejabberd bug - I tested it against a local ejabberd and it works fine. probably misconfigured.

seems like an ejabberd bug if it allows such a config to advertise the feature and return nothing when it's used?

yeah.it works for one on one chats though

and for mongoose it is indeed a bug - but I don't think anyone uses it anyway

and it's not like anyone uses server side search in general - so I don't think ejabberd devs would rush to fix this configuration, etc

so yeah I should've probably checked if this a generally supported feature before beginning to design support for it as a core part of the client

Report it anyways

it does work for private chats though, maybe I could poke around that... if only all my private chats weren't omemo'd lol

I bet it's not too hard to write a prosody module also if the right storage system is in use

that's not something I can undertake.

a little surprising that it doesn't work for MUC MAM on ejabberd. feels like the sort of feature that would be sought especially in closed office deployments

where there is a tendency to use the group chat as a knowledgebase

if only such deployments existed that were actually in use

I got the impression they say it does work on ejabberd but no volunteer run server has it enabled?

draugr.de has it enabled and it seems to work for private chats

but yes group chat search was the #1 thing that inspired me to try this. I think it would be very cool. Matrix has this feature.

yep just double checked it does work for private chats on draugr

But not for MUC. Does it work for MUC in an ejabberd you control?

didn't try

I wonder if this is a thing where both the regular MAM storage and the MUC MAM storage need to be configured a way for it to work

wait, actually it does work on draugr.de for mucs! it was just a particular muc which it didn't work for

so I guess good news is it tends to work, and the bad news is it only tends to

Well maybe that one MUC has it disabled

lol: maybe some aspect of MUC configuration would allow owners to opt out of it

yeah

is there a way this setting could possibly be visible to the user other than trying to search

still a bug to advertise the feature then return empty result instead of an error ?

right

it sounds like the whole component advertises the feature, not the one MUC. or idk

lol: any different disco#info returned for the MUC where it works vs doesn't?

by advertise I mean: when you send an iq type="get" to an MAM entity (your server or an MUC jid) it return an empty form with the fields it supposedly supports. I didn't try or even implement disco yet

> still a bug to advertise the feature then return empty result instead of an error ? Yes ↺

> by advertise I mean: when you send an iq type="get" to an MAM entity (your server or an MUC jid) it return an empty form with the fields it supposedly supports. I didn't try or even implement disco yet Right. If the field is there it should work. So some bug maybe still ↺

would anyone happen to know any alive group chats running on ejabberd that might support server-side search, which I could test again?

even for those group chats that server side search on draugr.de works - it doesn't work with chinese characters

That's possible. Worth reporting the bug

hm, india@conference.a3.pm has a field `withtext`

that server claims to run ejabberd 23.04 . I guess the field had a different name in older versions

I guess I'm gonna implement at least server side search by date for now. At least that is claimed to be supported by most.

and where exactly is fulltext support advertised?

<query xmlns='urn:xmpp:mam:2'> <x xmlns='jabber:x:data' type='form'> <field var='FORM_TYPE' type='hidden'> <value>urn:xmpp:mam:2</value> </field> <field var='with' type='jid-single' label='User JID'/> <field var='start' type='text-single' label='Search from the date'/> <field var='end' type='text-single' label='Search until the date'/> <field var='withtext' type='text-single' label='Search the text'/> </x> </query>

and in what XEP section is that described as "support advertised"?

badlop: what are you saying? You add fields to a form that then are not supported when filled out?

How would that make sense

the origin of my questions is this sentence: « I'm using, draugr.de, advertises support for it, but when I try to search one of the dead but not empty MUCs always returns zero results if you specify {urn:xmpp:fulltext:0}fulltext»

In order for the client find out about additional fields the server might support, it can send an iq stanza of type 'get' addressed to the archive

That's what the xep says

I request a form and of course it's expected that every field in this form serve a purpose

> But hard to call that a space .. its a collection of bookmarks implementation may end-up being vastly different, I'm not sure the UX should be, though ↺

i thought that the feature support is advertised as specified in the XEP, that is: https://xmpp.org/extensions/xep-0431.html#feature

That's a different xep

ok, then which one are you talking about, that describes the usage of "withtext"?

313

and where is "withtext" described?

It is not, but that's not relevant, ejabberd describes it I'm it's form that it submits to the client

So maybe enlighten us, what functionality is behind "with text"

that's exactly what i want to know

a client is implementing a feature, but the server doesn't work "as expected"... so I want to know where is described what is expected :) I'm asking for the corresponding XEP section, but apparently there is none, apparently neither 431 or 313 are relevant to describe the expected behaviour

the expected behavior should be in ejabberds MAM documentation

the XEP defines that any server can add any form field they want and can define it however they want

seems some developer on ejabberd made a choice to include such a field, from the label "withtext" a developer can assume its a text search, but we will never know if ejabberd has no documentation for it

ah, then this case falls in this sentence "Other fields may be used, but are not defined in this document" https://xmpp.org/extensions/xep-0313.html#filter

and https://xmpp.org/extensions/xep-0313.html#query-form

ok, and "withtext" is such a field: custom added in ejabberd... let's see if i find some clue

It has a different name in newer versions.

Ejabberd is painfully slow to start locally btw. Sometimes it takes like 20 seconds. Mongoose is faster but it's buggy, I wonder if it is even used anywhere.

what was the old name, and the new name, and in what version approx do you think it may changed?

{urn:xmpp:fulltext:0}fulltext is what draugr.de has

draugr.de is at 25.10.0

ok, btw, withtext was implemented in mod_mam since the very first commit in 22 June 2015, when XEP-0313 was v0.2

summary of what I found: ejabberd 15.06 added support for MAM, including withtext ejabberd 25.07 added support for fulltext (XEP-0431) You can fill fields withtext and/or fulltext. If you provide boths, then fulltext is used and withtext is discarded. The form shows those fields only when using mysql storage, otherwise fields are not provided and are not read. you must provide the exact text to search in the body, there are no wildcards or partial sentences.