XSF Discussion - 2023-07-19

> image.png.jpg: JPEG image data, JFIF standard 1.01, aspect ratio, density 1x1, segment length 16, baseline, precision 8, 640x1091, components 3 where's trolling? :P

and yes, my avatar still apparently can't be decoded by android clients ✏

why dont we have an i2p xep but we have a quic xep? is it just because nobody has bothered to write one and submit it?

If there are special protocol/implementation considerations for i2p that need documenting, probably that, yes

We don't have a Tor XEP either, and AIUI it's closer to i2p than QUIC

XMPP over Tor is just running XMPP on an onion domain

Optionally with outgoing s2s connections going through a SOCKS-ish proxy

Isn't that the same with i2p?

I believe so, hence the parallel

yeh, QUIC is a replacement for TCP; i2p and Tor are overlay networks that can transport TCP ✏

Does anyone know why the disclaimer appears after a new message, as in the attached image?

The disclaimer disappears after moving on to another chat and returning here.

disclaimer?

attached image?

We don't know what you are seeing, you will have to show us or describe in more detail.

> We don't know what you are seeing, you will have to show us or describe in more detail. Ok. I am using Beagle on my Mac and after reaching this group to read a new message, I see the disclaimer “Private messages are disabled”. The disclaimer disappears after moving on to another chat and returning here. I tried also to close and open again Beagle but nothing changed. Boh!

Curious.

your client shows you the configuration option of this muc

well, private messages are indeed disabled in this muc

Private messages _are_ disabled, but you should only see that if attempting to send one.

and tells you that private messages are disabled

no Zash, this is a status code on join i think

so clients show it

> Curious. It’s pretty annoying.

yeah, maybe ask in the beagle support chat

lovetox, actually, there isn't, I never implemented any status codes, only an error reply when attempting to send a PM

> yeah, maybe ask in the beagle support chat I’ll do it

Zash, some config option need to be communicated on join to every user

i didnt look it up, but this may be one of them

But private messages to/from moderators are allowed, wasn't sure if that could be communicated.

its weird if private messages are in fact not disabled :D

Also didn't actuallly read the XEP when dusting off that module, just made it work with modern Prosody

hm i just checked, only 110 is communicated on join

so indeed weird what beagle shows here

are avatar queries affected by that and do they cause such a message?

No, this should only affect chat messages

then I'm clueless

iteam could take a peek at the logs, see if there's any clues

Best would be xml logs from beagle, sent to the beagle support.

lovetox, you happen to know which status code you're supposed to send? and/or where in infinite maze that is XEP-0045 the relevant text is? if not that's fine and I can go find it myself later

ha i have it

this rooms disco info is missing muc#roomconfig_allowpm

which beagle default to False

which is sensible in my opinion

nicoco, does it say that about other Prosody-hosted chatrooms?

I'm pretty sure this here is the message from a module that just blocks and bounces PMs

Prosody never had the allowpm disco flag

And peeking at the logs, there are indeed private message stanzas being exchanged

... and rejected

everytime i look at the MUC xep i see something new

roomconfig_roomowners

does anyone use this, i never saw this in a config form

is beagle sending PMs to itself for some reason?

Beagle is sending PMs to itself, yes

???

And I have the error message issue in many MUCs

https://github.com/tigase/beagle-im/issues/132

and why? https://github.com/tigase/beagle-im/issues/121

muc self pmng?

> In the case of MUC rooms that are not members only, Beagle sends PMs (type="chat") with "read" notification to notify other resources joined with the same nickname that this message was read/received (same user different clients). > In case of MUC rooms that are members only, Beagle sends "read" notifications to the bare JID of the room with type="groupchat" to broadcast this notification to everyone.

to have "read state sync" across tigase clients in public mucs

I see

seems they forgot that pms can be disabled

Ugh, https://xmpp.org/extensions/xep-0045.html#privatemessage says nothing about partially disallowed PMs

or they depend on the disco flag correctly set

which would be correct assumption :D

oh wait it's a what?

> label='Who Can Send Private Messages?' Doesn't quite capture moderators being able to send PMs, and anyone being able to send PMs to moderators...

> > Curious. > It’s pretty annoying. nicola: yeah it renders beagle borderline unusable, I agree ✏

just to be clear, there is no check if PM can be sent or not, that is why Beagle sends chat markers to self

(in large MUCs I mean)

try once, disable that feature if an error is received?

actually, I'm working on the fix, to send them only if PMs are allowed

Hold up, is `muc#roomconfig_allowpm` meant to be advertised in disco#info? I'm not seeing text about that, tho IIRC there was something about putting any config option in disco#info being okay?

BeagleIM actually relies on this flag in disco#info

This seems problematic.

so missing this fields in disco#info would explain why this issue happened with Prosody

Because Prosody out of the box doesn't have such an option, this is provided by an addon module that just blocks PMs if any are sent, but allows PMs to/from moderators, because that seems useful.

I just wonder how harmful are PMs to self to be allowed?

I'm thinking that can be allowed

Question is how to communicate that PMs to moderators are allowed but PMs to other participants is not?

Try now

Zash, it looks like it is working as I cannot send PMs from BeagleIM UI anymore, while I could not so long ago

Does Beagle have the "request Voice" feature?

I do not recall implementing it

So now you have no way to request voice in the moderated channels. Seems suboptimal.

that is something that can be improved in the future version

Some sort of complement to `muc#roomconfig_allowpm` or variant thereof for when you can still PM moderators?

Now it seems working fine

or, new value?

> So now you have no way to request voice in the moderated channels. Seems suboptimal. Does any client or server implement this right? ↺

I believe so but don't have the list in my head

I wonder, if allowPM would allow to send PM by moderators, shouldn't it allow users to send PMs to moderators as well?

Does prosody support the request voice?

singpolyma, yes

Zash: what does it do?

Andrzej, the addon module for Prosody currently active here now allows messages to moderators, messages from moderators, messages to yourself. Otherwise it rejects them with an error.

singpolyma, what does what do?

Zash: prosody when processing request voice

https://xmpp.org/extensions/xep-0045.html#requestvoice is relevant

+ https://xmpp.org/extensions/xep-0045.html#voiceapprove

Zash: ok, that actually is even better as it allows syncing chat markers with PMs to self, however when I fix Beagle it will know that PMs are off and would not allow sending PMs anymore, so it will be back to as it should be

singpolyma, it notifies moderators, who can approve the request

Zash: ok, so the full dataform in message flow. So if Prosody already has this we just need client support for approval flow. I will play with this

Zash: when mod approves voice I guess that is temporary since roles are not persisted, yes? ✏

Correct

We have some ideas around making roles somewhat persistent, or maybe we just slowly abolish them

Temporary give voice is something some mods may want, not sure. Temporary remove voice is much less useful though 😅

Might be sensible to also have "grant membership" within reach in that dialog?

Crossing over into UX considerations tho

Yeah, I mean it's a form so certainly can have options in it :)

What server-sided support needs to be implemented for XEP-0333? The 'Determining Support' section has an example that queries a server/domain for support, which confuses me a little. Apart from some MAM optimizations, I'm not immediately seeing a lot of things to support for a server? https://xmpp.org/extensions/xep-0333.html#disco

Guus, none.

Just send say "done" along with an invoice! :)

If you're ambitious you could keep only the latest entry.

... https://github.com/xsf/xeps/pull/1289

So, optimizations is what can be done server-side, but not sure that needs to be advertised.

I've published a new beta version of BeagleIM with a fix for PM errors. If anyone is using beta version and has this issue still on some rooms please try new version and let me know if the issue is fixed now

XMPP will never be taken seriously until we support disabling anyone else's account with an email https://www.ghacks.net/2023/07/18/you-may-deactivate-anyones-whatsapp-account-with-a-simple-email/

Delete all the thingz