XSF Discussion - 2025-10-27

what are XSF's plans for FOSDEM devrooms this year?

and would you be up for getting involved in a protocol-neutral 'decentralised communication' devroom?

(covering xmpp, matrix, deltachat, and the various messaging/comms bits of the decentralised social media projects)

> Bold Extended is the font used in the logo, and I've used a combination of this and the regular non-bold Extended in various works My understanding from https://www.dafont.com/forum/read/516091/old-optifont-opti-edgar-bold-extended-font-to-use-in-app?highlight=1093420 is that it is a copy of Eurostile which is what was used in the logo. Optifont certainly no longer exists. Would feel safer if XSF just got its own copy of Eurostile, am not a font licensing legal expert, but if there is knowledge on rights associated with possible Eurostile derivatives, input would be very welcome.

> and would you be up for getting involved in a protocol-neutral 'decentralised communication' devroom? Hi Matthew! Are you looking for something that's significantly different from the Realtime Communications Devroom that's traditionally organised? On first glance, there would be overlap, I think.

Rtc has been rejected

Maybe in favor of the 'decentralized communication'?

Oh, I wasn't aware that the devroom assignment already took place. I read Matthew's request as "lets apply for one" while I now understand that the application period already closed? It would be sad to not have a RTC one - Saul has been organizing that forever. Although I don't plan to do a talk myself, I'd love for an applicable devroom to be available for people that do. For XMPP, having a 'decentralized communication' room would be as applicable as a 'rtc' room title, so I'd certainly not be against that.

Just read Saul's Mastodon toot that confirms the rejection of the RTC devroom application. #sad

Matthew, is the "decentralized comms" devroom on saturday or sunday?

so yup, i put in a 'decentralized comms' devroom proposal as distinct from RTC, in terms of focusing on the "save us from surveillance capitalism" angle, and because the FOSDEM folks said they weren't doing project-specific devrooms this year (so no dedi Matrix devroom, as we've had for the last N years)

but with the pitch of it being protocol neutral - so XMPP + Matrix + Deltachat + whatever the AP/ATP folks are up to

honestly i was a little surprised that it got seleccted, but apparently they do it based on votes, and it got the votes.

so i think there's basically overlap with the trad RTC devroom, and the ~trad Matrix devoom, and so i'm looking for interest in co-running it

if saghul normally runs the RTC devroom, then i'll ping him to see interest

but also wanted to propose sharing the organisation (selecting talks, etc) with y'all

and ensure XMPP gets good representation as well as other projects.

i'll also ping Holger from Deltachat

and probably the Germ folks who are busy reinventing both XMPP & Matrix on top of atproto

and the E2EE ActivityPub folks who are busy reinventing both XMPP & Matrix on top of Activity Pub

which if nothing else should be interesting in terms of encouraging some collaboration/cross-pollination rather than lapsing into "get off my lawn" mindsets.

i was about to say there are also attempts to reinvent IM on top of activitypub :-)

indeed. all the https://github.com/swicg/activitypub-e2ee stuff

it's interesting that folks clearly don't feel that either XMPP *or* Matrix are modular enough to be 'portable chat' layers for use in other protocols

Matthew, you don’t happen to be in Montreal next week?

The curse of "chat looks easy, I'll just NIH!" or something ✏

There's an XKCD for that.

> The curse of "chat looks easy, I'll just NIH!" or something Now that I read that, I remember the only programming thing I ever did was after my first and only computer class at school. It was writing a chat program with turbopascal. (never did any programming before and didn't read about it, but managed to get text appear [most of the times 😂] others could read) ↺

iirc this was discussed before but just got brought up in gajim@ again... any thoughts or pre-existing work (maybe in gc3?) about moderators getting JID of a message sender in a MUC with presence disabled? do we just need an IQ to request JID given an occupant-id or what?

could put real jid in with the messages like we do with occupant id, but only for mods?

what if you fetch the participant list manually, is real jid in there?

is "participant list" a thing you can fetch? not just flooded at you when you join (and presence is not disabled)

yes https://xmpp.org/extensions/xep-0045.html#disco-roomitems

1) no real jids there and 2) prosody removed that whole thing becasue it was a privacy leak

why is it a privacy leak? I can get the same info from presence (usually)

you could get it without joining

well don't allow that :)

we don't, anymore :)

> Note: These <item/> elements are qualified by the disco#items namespace, not the muc namespace; this means that they cannot possess 'affiliation' or 'role' attributes, for example. this probably means no

(or do, honestly, but that's a service policy question)

but it can still work when joined either way

singpolyma, https://prosody.im/doc/release/0.10.3#security fwiw

right, but removing the whole feature seems pretty heavy handed vs gating it on the needed permission?

🤷

don't think anything relied on it, so nicer to delete unused code :)

> An implementation MAY return a list of existing occupants aka we are allowed to simply not, and simplicity is what prosody is about! :)

Sure. Does prosody even support disabling presence though? And if so, then it sounds like some people are starting to use it so we are going to have a use case soon. Since if presence is off one still needs a way to get the list(s)

ejabberd (by default) automatically disables presence when muc user #1000 joins which makes this problem way worse

Prosody has a thing since 0.12.0

luckily morph has not yet discovered he can join any ejabberd muc with 1000 nicks, probably even from the same jid, and then spam all he wants without the possibility of ever being banned or rtbl'd

good job giving people ideas

moparisthebest: i was about to ask if that is possible

it's obvious... hence why we probably need a solve soon before our luck runs out

> could put real jid in with the messages like we do with occupant id, but only for mods? what do you all think about this idea?

already done in MAM¹ so not unreasonable to add that logic to presence-disabled rooms ¹ https://xmpp.org/extensions/xep-0313.html#business-storeret-muc-archives

> ejabberd (by default) automatically disables presence when muc user #1000 joins which makes this problem way worse yeah doing this automatically is a pretty big move. do they still support disco#items on muc? ↺

I'll try to test it later but even if so from the spec there's no indication that the response would have real jid right?

seems to work for at least one public ejabberd channel. sooooo you could check if it lets you query the names of private chats...

wait, but that wouldn't even work at all if they joined, spammed, and left right?

back to 'gimme JID for this occupant-id IQ' or? it's probably not even currently guaranteed servers even store these right now :/

could request just that message from mam to get the jid... only if mam is enabled in the muc

altho in my mind, you would _disable_ presence for those that can't speak anyway, e.g. broadcast-ish rooms with a few speakers or where you have to register to speak ✏

different use case though, these are just public MUCs with many joined nicks ✏

> could request just that message from mam to get the jid... only if mam is enabled in the muc does the jid come along with the message in mam? ↺

lovetox said so in gajim@ anyway

if it does then it could also come along live on rooms that have no presence

i'm not sure if relying on mam is a good idea, given ephemeral rooms exist (and some people do want mam off for reasons)

right, that's why I'm suggesting including it with the live messages :)

yea, i understand :)

anyhow, ejabberd does store jids inside mam, from a quick peek into the `archive` table of the db

> if it does then it could also come along live on rooms that have no presence could but doesn't currently ↺

i think what MIX tried to do to make presence an optional thing was the right direction

i think we should send all metadata of a message *with* the message, its very weird that real jid is not part of the message, its a very important metadata part

i tried from the beginning to convince MattJ to also do this for MUC Hats, as it can be important what Role or Hat someone had at the moment he sent a message

i dearly hope this necessary mapping process between presence data and message data can be gone in any future MUC protocol

> i think we should send all metadata of a message *with* the message, its very weird that real jid is not part of the message, its a very important metadata part I think this is right *at least* in any MUC with presence disabled. If not always ↺

yeah if you want to make life hard for client developers you think up rules that data is in different places depending on some combination of fields in a muc config dataform

before agreeing on a muc config dataform, i'd like to ask. Can servers send presence exclusively to mods already?

that might be a reasonable workaround (?) send presence to mods regardless of broadcast settings

right. that's another possible solution to the immediate issue

> yeah if you want to make life hard for client developers you think up rules that data is in different places depending on some combination of fields in a muc config dataform qft (quoted for truth) ↺

no, unfortunately i'm not going to be able to IETF this time; i have priors in europe.