jdev - 2026-02-17

> Is this going to be the vcard-temp of Spaces? I'll bite. If we don't do it via pubsub how do we: - have regular users create spaces? xep-0225 that still isn't implemented anywhere since its last update in 2008? and come up with a protocol to create a new "conference service" from clients? - broadcast space metadata update? - broadcast space content update? - have other entities than MUCs in a space? "We have disco#items that list MUCs already", but then we need to define how to do all of the above, and we end up with a different way of doing pubsub. I don't get how that's better and it reads like "I've already started working on spaces-like functionality in my product without documenting it so I'm disapointed" I wasn't around back then, but from <https://xmpp.org/extensions/xep-0054.html>: > This specification documents the vCard-XML format currently in use within the Jabber community. It looks like the exact reverse of what edhelas and I are doing. There was plenty of time to come up with other proposals, and there was none. ↺

When I set a name from conversations, your name field in settings. What is that? Apparently not v-card as that seems empty for my account?

Probably nickname in pubsub?

in PEP

but yeah

I see that V-card does contain something related to avatars as well and it is set in my V-card. So when my client sets an avatar should it also publish it to vcard as well as pubsub?

And do I understand correctly that MUC avatars only go through V-cards?

muc avatars use vcard-temp

vcard4 is another spec

it is messy

vcard-temp is avatar hash in presence + dedicated fetch mecanism. it is used for participant avatars and room avatar. pep avatar is the way to go for "accounts" but does not work in MUC because stuff. in practice servers handle the pep avatar->vcard temp conversion (there is a xep for that), so a client should only care about publishing the avatar via pep avatar (but should handle incoming vcard-temp in presence for room and participant avatar)

vcard4 is where you can store other metadata, (full name, phone number, pronouns, ...) but you should not store avatar in there

But in practice you store your nickname in PubSub right?

Btw like where? Is there spec for pubsub name storing?

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

yes

ZOV: you should publish your avatar with 0084

The rest does the server

Don't put a avatar in you vcard

Hm so in my client I shouldn't need to interact with vcard whatsoever? I can just forget about it other than fetching muc avatars?

for the room avatar there is no other way

for the room participants in semi-anon mucs when you are not an admin there is also no other way than vcard-temp ✏

you need to set vcard4 <https://xmpp.org/extensions/xep-0292.html> if you want something else than nick/avatar ✏

everything is optional and vcard4 content is less "visible" than avatar and nicknames. gajim, cheogram and movim have UI for it, in the "details" of someone.

ZOV: reading you can do in MUCs, writing only if you need to set the avatar for the MUC itself

Wait, didn't you say that the server will set the v-card avatar based on the pubsub one

for the room itself that is not a thing, no

see https://xmpp.org/extensions/xep-0486.html

> NOTICE: This Historical document

how would you set a PEP avatar for the room anyway?

PEP is meant for stuff related to your own account

Omg

I did say it was messy

So, like, to implement the right behavior, I shall follow what this historical document says?

> > NOTICE: This Historical document attempts to provide canonical documentation of a protocol that is in use within the Jabber/XMPP community. ↺

> So, like, to implement the right behavior, I shall follow what this historical document says? if you want avatars for the room that work with current implementations of servers and clients, yes ↺

if that makes it a bit better for you, be aware that when I implemented room avatars in slidge, the "reference document" was some paragraph buried in the ejabberd docs, so it got better since xD

and that explains why I took the piss earlier when I read "xep-0503: spaces" is going to be "a new vcard-temp", because we actually tried to document what we wanted to do about spaces and incorporate feedback about our proposal, which is actually the absolute inverse of what I got through when implementing (part of) a MUC service in slidge. (remember: finding stuff in the ejabberd docs about how room avatars work)

With the Space feature in Movim I'll also write a document that explains all the little things that you should do to add Space on your own client, what could be done server side to make thing easier and what will have to be XEPified on top to clarify things.

So far Spaces are only relying on things you can find in 0060, 0045 and Bookmark-PEP

nicoco_, edhelas, If I'm a space admin, I want to be admin of all MUCs in that space, right? Kicking someone out of a space, should kick them out from all MUCs, agreed? I guess, that's not possible without server support? Or do I ask for way too much?

AIUI there’s basically two camps of ‘spaces’ people - there’s the camp that just wants to be able to advertise relatedness of things, and there’s the camp that wants the Discord/Slack/Guilded/etc.-ish experience of a coherent entity with common admin.

The current XEP defines a usable basis for both camps IMHO. Some server support would be nice for what you want debacle, yes. This is also what edhelas wants, and TTBOMK he's starting by implementing it fully on the client-side, which will be a starting point. On my side I will implement "read-only" spaces as a starting point, and add anything "space administration" later. Server support is what the bridged chat network does.

> nicoco_, edhelas, If I'm a space admin, I want to be admin of all MUCs in that space, right? Kicking someone out of a space, should kick them out from all MUCs, agreed? I guess, that's not possible without server support? Or do I ask for way too much? foreach (mucs as muc) muc->setAffiliation(jid, 'banned') ↺

Movim is basically taking the Space Pubsub node affiliation as THE reference and always apply them to all the Space mucs

This is easy in a "restricted" space, with a fixed list of member

- 1: Accept a member invitation/add a new member => set it in all the mucs of the space and in the pubsub space node - 2: Add a new muc: take all the pubsub space node affiliations and inject them in the new muc

This behavior could be done tomorrow server side, a simple XEP explaining this flow and saying "if the pubsub server advertize feature:space:affiliation_mapping" then the client doesn't have to do it anymore

And this is based on the idea that the pubsub service and the muc service are both on the same XMPP server. If you want to start to do exploded Spaces (accross the network) its a totally different topic and its out of scope regarding what we want to do there. ✏

This behavior will be part of an upcoming XEP in any cases.

(as well as a few others, mostly around Bookmark extensions that could also benefit all the XMPP clients in general)

> Movim is basically taking the Space Pubsub node affiliation as THE reference and always apply them to all the Space mucs Sounds a bit hacky, but also very pragmatic 👍 ↺

> And this is based on the idea that the pubsub service and the muc service are both on the same XMPP server. If you want to start to do exploded Spaces (accross the network) its a totally different topic and its out of scope regarding what we want to do there. I wonder, for which use case the added complexity of federated spaces were worth the trouble? ↺

Matrix did it, and its one of the main complain about it "its a mess"

It's both difficult server side and very complex UX/UI wise in the clients

aren't spaces basically just rooms with painted on wings

on matrix i mean

>> Is this going to be the vcard-temp of Spaces? > I'll bite. If we don't do it via pubsub how do we: > - have regular users create spaces? xep-0225 that still isn't implemented anywhere since its last update in 2008? and come up with a protocol to create a new "conference service" from clients? > - broadcast space metadata update? > - broadcast space content update? > - have other entities than MUCs in a space? > "We have disco#items that list MUCs already", but then we need to define how to do all of the above, and we end up with a different way of doing pubsub. I don't get how that's better and it reads like "I've already started working on spaces-like functionality in my product without documenting it so I'm disapointed" > I wasn't around back then, but from <https://xmpp.org/extensions/xep-0054.html>: >> This specification documents the vCard-XML format currently in use within the Jabber community. > It looks like the exact reverse of what edhelas and I are doing. There was plenty of time to come up with other proposals, and there was none. I mean I think you know my answers here because they were in the original xep. Nevertheless I'm not here to prevent anyone from experimenting goodness knows I do enough of that myself 🙂 ↺

> And this is based on the idea that the pubsub service and the muc service are both on the same XMPP server. If you want to start to do exploded Spaces (accross the network) its a totally different topic and its out of scope regarding what we want to do there. Having federated spaces where any number of servers join and build the same community would be awesome anyway ↺

maybe I'm mistaking term's ussage but that one would be a great feature

i dont understand what you mean, we already have federation between servers, nobody needs to join something

A "space" AIUI is a single thing, like a discord server, where there is a single community, set of moderators, etc

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

🤔 yeap ... misunderstood it

the basic problem is "space" means a totally different thing to everyone

I think it means this: > Space: the final frontier. These are the voyages of the starship Enterprise. Its continuing mission: to explore strange new worlds; to seek out new life and new civilizations; to boldly go where no one has gone before!

> 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 if a space controlled the affiliations/members of all users in each room, then this changes from should to must ↺

technically not, but I've never seen an argument for why one community would put their stuff on two services anyway really

about the url preview, youtube is a bit crazy

i need to download > 600 kb to get even reach a <title> or any other og: attribute

before that its just javascript

are there any http headers how i can tell the server, that im not interested in javascript?

really? I limit to 4000 bytes and I've seen youtube work

no nevermind that's old info, looks like my limit got upped to 90k probably for youtube

with 90 i get nothing

600k is minimum where i start to see things

maybe google does something different if a android device asks for the url, who knows

or maybe they changed it recently and I'm broken now

hmm maybe i count the uncompressed size

Oh. Could be

indeed i measured the uncompressed size, 200 kb works now

even 150 seems enough

but still crazy yt has become so bad and slow

nicoco_, my comment wasn't a criticism of XEP-0503, nor of using PubSub (indeed the right place to put Spaces); I was referring to charging ahead with a 'hacky' client-side solution. It's understandable that people just want to have something working - and that's completely fine - but there is a tendency for such "this is a quick hack, but we'll definitely do it properly later, honest" solutions to become entrenched and difficult to replace with the better/cleaner solution later; which is exactly what happened with vcard-temp - and we _still_ have to deal with that (temporary?!) mess.

it's so common everywhere there's a saying https://en.wiktionary.org/wiki/there_is_nothing_more_permanent_than_a_temporary_solution

but ship it, might find "server support" isn't needed after all

for a very basic version it probably isn't, other than setting up the pubsub node to allow clients to mess with it

imho XSF needs far more code before XEPs

theTedd, my bad then. I think server maintainers have other things on top of their priority lists or something usable would have come up earlier. we'll experiment and hopefully not get something as ugly as vcard-temp in the long run

if you had a server dev that finished everything you needed today you couldn't count on it being generally available before 2030 anyway

indeed

Which XMPP server supports full text mam search? Ideally something that would be easy to run locally with Docker to test against.

well it's either P or E

Prosody doesn't

Found mongoose.

I think none. I don't think a field for that has even been standardized

Whatever draugr.de runs supports it

That's ejabberd then.

singpolyma, about the link previews, we plan to send the image as data uri, what size would be good?

I guess the main consideration is stanza size. And there may be two or three of them in a stanza

So I'd say not more than 30k?

i was more asking about the pixel size

we tested with 128x128 png, and this was around 4 kb

do we need to go higher?

That's about the quarter of a logical iPhone width so maybe twice that is better?

ok thanks, we will experiment a bit more