jdev - 2026-06-06

singpolyma, you support 172 nickname in muc presences as i heard

is there anything special you did to display that, or can simply anyone now assume the same nickname

i kind of think that does not really introduce some real new attack surface .. but i wonder how other platforms deal with that, or maybe it has been shown in practice to be not a problem at all

I only actually show it in some special circumstances right now since no MUC I know of supports enforcing policy on these

(the special circumstances I still allow without any disco are a hack where if the nick punycoded matches the resource then I show it)

meh, almost no value for the complexity ..

Yes I agree. I did as an experiment for the "emoji in MUC nick" issue but it's not my favourite thing as is

so this is then a special feature for transports only

partly yeah. Slidge uses it when the foreign user has emoji in nick etc

damn PM is so broken

we forgot to add to xep0045 that server MUST add the PM marker when sending message errors

I still think the only way is for clients to be forever aware once they join a muc that all messages from that bare JID are from a muc and all messages from other JIDs are not MUCs regardless of that marker

it's just not enforced by any server ever so can't really be trusted in an open network

but sometimes you setup a new client, and then you miss that knowledge

also its a bad architecture, if i need to check my db everytime i want to interpret a message

another (easier imho) alternative is to have a stream for MUCs and a different stream for not-MUCs, then you always know without looking up anything

I guess that leaves... old MAM entries for MUCs you've already left on an old client ? I don't know the fix there...

the way it was done afterwards is the right direction, the server must mark that in the message

we just forgot errors

if i would start new, i would add a new message type=pm even

what server must mark them ? and what server must un-mark them if they come from a not-MUC ?

of course the sender

why would you need to unmark something

the second part is the big missing piece that even if it were spec'd now can't be relied on for years

it is speced, MUCs mark PMs

and since they do, this works ok

> why would you need to unmark something oh because an attacker can spam the crap out of you with messages they mark as a MUC PM and most clients handle this very very poorly ↺

?! they can do this with any other message type also

there is zero difference

as in messages or a phone ring from a random muc participant and don't even show enough in the UI to let you block them

> if i would start new, i would add a new message type=pm even I mean, if I would start new I wouldn't include "muc pm" as a thing ↺

> as in messages or a phone ring from a random muc participant and don't even show enough in the UI to let you block them that's bugs. we should fix bugs of course ↺

anyway, other topic, i see in prosody mucs

muc#roomconfig_allowpm = moderators

and i should interpret that as not only moderators *can* send PMs

also users can send PMs to moderators?

yes

or is this an extension that only prosody has and is not dependent on that setting

AIUI that means can send pms to moderators and moderators can pm anyone

or maybe mods can always send PMs regardless of settings ? 🤔

its pretty clear from the XEP that the setting controlls who is allowed to send PMs

the other direction is i think a prosody interpretation or extension

i just wonder if other servers support that

does it make sense to ever restrict an admin from doing anything ?

maybe not, but the spec is written like it is, so there is no changing it

but im interested in the *other* direction

a visitor can PM a Mod

as it seems in prosody mucs

its even unclear why this was added in prosody

as we have a dedicated mechanism to request voice

somehow users learn that they have to PM mods in some prosody channels .. because they dont answer voice requests?!

i dont understand the dynamics at play here

> i just wonder if other servers support that I'm pretty sure ejabberd did first, but not sure what their config form looks like to do it ↺

> as we have a dedicated mechanism to request voice oh. this is a bit odd but it's because *some* clients don't implement this at all. no way to request and/or no way for mods to know a request has happened... this is IMHO rather a problem in general ↺

> somehow users learn that they have to PM mods in some prosody channels .. because they dont answer voice requests?! because no clients have a good way to handle voice requests, very few can send them, all support MUC PMs ↺

client-wise not sure why you wouldn't just let anyone PM always, just display any error

as a mod I really need like a dashboard to handle voice requests

>> somehow users learn that they have to PM mods in some prosody channels .. because they dont answer voice requests?! > > because no clients have a good way to handle voice requests, very few can send them, all support MUC PMs Gajim has a very good way. I think Cheogram Android has a passable way but it could be better ↺

> as a mod I really need like a dashboard to handle voice requests that's basically what Gajim does ↺

cheogram android is the only client I know that at least displays them to the mod, but mixed in the chat and no way from there to voice them, have to remember the name , 2 clicks to member list, search the name, voice them (hope they are still online or you can't)

gajim sounds very nice in that regard then, kudos :)

> client-wise not sure why you wouldn't just let anyone PM always, just display any error cant, prosody does not mark message error as PM, hence gajim parses JID wrong, hence cannot join to PM JID ↺

>> client-wise not sure why you wouldn't just let anyone PM always, just display any error > cant, prosody does not mark message error as PM, hence gajim parses JID wrong, hence cannot join to PM JID lol oof ↺

its all connected :D

so my next step is, try to parse that PM setting, and allow the user to only send PMs to whatever the setting says

what the heck, i make a db lookup for the error, errors should not happen often so this should not impact performance

sounds like famous last words :) but what other choice do you have

Errors are an update query by id for me