jdev - 2025-02-27

> Thanks for bringing this up, I created an issue ;) https://dev.gajim.org/gajim/gajim/-/issues/12196 Sorry cal0pteryx, I've noticed a thing. I've tested this issue with a lot of public MUCs that I specially created in Conversations.im server for testing. If the MUC has got PM messages disabled between users, Gajim return a Yellow Icon with an "exclamation point" (so there is a warning even if not very communicative). But yes, if I try with the "Jdev" MUC nothing happen, no yellow Icon appears. So the bug I think is related with something of this MUC "Jdev". Perhaps could be useful to insert in the issue the link to this MUC. p.s. I post here a screenshot of the yellow warning ↺

https://xmpp-uploads.autistici.org/upload/3381081b-b0a4-4360-ab41-379a2fef5649/1b62214a-babf-401b-8c05-81e4de2efe2a.png

I've modified https://wiki.xmpp.org/web/Sysops to warn about private messages not coming through in this MUC. Hopefully that helps avoid future confusion.

FWIW private messages to admins work, but yes, some of the people on that list are not admins here

question this setting in MUC allowpm=moderators, does it mean everyone can send messages also *to* moderators, or only moderators can initiate sending messages?

Up to the sever I guess but Ive only seen the former in practise

and admins can send PMs to participants, I think

is that a prosody plugin? can't find muc#roomconfig_allowpm in Prosody's source

Yes it's a community module

ah, the code speaks for itself https://hg.prosody.im/prosody-modules/file/default/mod_muc_block_pm/mod_muc_block_pm.lua

oh no, someone wrote readable code? better optimize that right away!

allowpm controls who can _send_ private messages, according to the XEP. I guess that in a strict interpretation, recipients couldn't even talk back.

What, there's a XEP for this?

I thought the XEP had a boolean and it was either all or nothing

muc#roomconfig_allowpm is in XEP-0045

``` <field var='muc#roomconfig_allowpm' type='list-single' label='Roles that May Send Private Messages'/> ```

gotta run, ttyl

I'm 100% certain that was a boolean last time I looked!

Zash, you have been once again fooled by the quantic state of XEP-0045!

i also thought until yesterday that this was a boolean

i mean its clear that if a moderator sends a message to a user, that then the user should be able to answer

but this probably would need more tracking logic on the server

but i think this is not even a useful mode

people should be able to message a moderator. The moderator can act if he is in some kind of spam situation, and can kick/ban users

i dont think its necessary to prevent users messaging a moderator

while normal users can do nothing if other people spam them with messages

unless the client implements somekind of ignore functionality which is not standard

so by that argument, i would interpret it as all users can message moderators

> unless the client implements somekind of ignore functionality which is not standard It is though, block by occupant-id ↺

would be nice if it would exist as a standard

I also voted for block by avatar across MUCs but haven't seen clients implement that yet :P

> would be nice if it would exist as a standard What standard do you need? ↺

You just let users block by occupant-id... cheogram supports it

You mean locally, yeah sure it's on the list

But would be nice to sync this via pubsub

blocking client-side works, but is kind of meh, indeed

Yes, I'm not even sure if it's desirable to sync this across clients, it's perfectly reasonable to want to block certain people on one device only

moparisthebest, do you have an use case for that?

moparisthebest, that's not how we do things anymore. everything's gotta get synced everywhere all the time

users demand it!

> moparisthebest, do you have an use case for that? blocking NSFW people/avatars on work/publicly used devices for example ↺

That's surely the not common case

> users demand it! Which users? Looking at worldwide user statistics they don't even demand being able to use more than 1 device ↺

> That's surely the not common case what's "common" ? I know a number of people that do exactly that ↺

Whatever users demanded Carbons and MAM to sync all their messages everywhere!

Maybe you don't want bot comments on your mobile but do on your laptop etc

I'm not saying it's not a valid use case

I'm not saying one is better than the other, they are just different use cases

One does not affect the other

I think we can at least all agree the status quo of not being able to ignore anyone is terrible though

Even IRC can do it...

Although it does if you have a client that does not sync right now

Basically your use case was faster implemented, and if we do element sync now we should not break the existing use case

Perfect is the enemy of good and we are often paralyzed by > well it could be better so I'll wait... of course everything is a trade-off