jdev - 2023-02-22

according to xep0045, when a muc service receives a stanza from a resource that is not joined, it should reply with error=not-acceptable. is that enough, or should it send a 'kick-like' presence too?

That should be enough

thanks MattJ!

About participants' avatars in non-anonymous MUCs, am I right in understanding that the consensus is: Participants presences should include a `vcard-temp:x:update`, even if the MUC is non anonymous and that clients can fetch the avatar via XEP-0084? ✏

XEP-0153 is the current thing, XEP-0084 in MUC is ... weird

Dunno if it works with anything but Prosody

I was thinking about XEP-0084 not mediated by the MUC, since I'm talking about non anonymous MUCs ✏

so technically, client can send the request directly to the known "real" JID of the participant, or maybe they cannot for some reason?

Subject to the access model of the pubsub node(s)

So, users can choose who can see their avatar and other details

While vcard-temp has nothing like that

this is (one reason) why I want vcard-temp to go away

indeed. I was happy to ditch it and switch to 0084 for slidge, but I've now reintroduced it to have Room avatars, so I figured, alright, let's do participants too =)

You can provide a 0153 interface to 0084 like prosody does

If access is restricted then there's no avatar

true 🙂

No legacy service I support have the notion of 'channel', basically every group is a modernxmpp 'group'. Some clients seem to be "smart" about non anonymous mucs, they use the avatar they know for the "real" JID (maybe even try to fetch it if the user is not in the roster? not sure about that part). But some seem to expect XEP-0153 and nothing else in MUCs.

Zash: is vcard4 a good alternative to vcard-temp?

techmetx11: for avatars specifically, xep0084 is the way to go I think. for the rest of the vcard, I don't know, but I know that movim uses vcard4 over xmpp, yes (but not for the avatar)

yes

alright

i mean i've only implemented vcard-temp because my server only supported that at the moment when i wrote it

The nice thing is that vcard4 doesn't actually require server support, other than PEP

It's also a standard developed elsewhere

while vcard-temp is our hacky fork of some unfinished vcard3-xml format that went nowhere

hence the "-temp" part I guess?

https://xkcd.com/2730/

Next step beyond permissions: ad hoc command to set different vcard field values or different avatar depending on who is asking ;)

Upload the avatar on the MUC?

singpolyma: different avatars per MUC is already possible, right now, isn't it? but no client implement a UI for that =). I thought about that recently because I have a MUC for IRL RPG meetups and I would have been happy to use my very intelligent and beautiful elve as an avatar in this MUC ^^

singpolyma, do you by chance remember OneSocialWeb? I think they had a proposal for that.

nicoco: yes, the protocol allows for it now just need a server module with an ad hoc command to allow setting it up

Zash: the name rings a bell I think

is there a convention/XEP to encode "pseudo"-case-sensitive JID localparts? I was about to make my own convention for signal groups (since they have case-sensitive IDs...), but maybe I should not reinvent the wheel?

NAFAIK, closest is https://xmpp.org/extensions/xep-0106.html

yes, I was looking at that, and this: https://xmpp.org/extensions/xep-0106.html#example-5

you could cry and use base32 and hope nobody sees the actual JIDs

Or use extended jid\20escaping only for capitals

singpolyma, that seems to be explicitly forbidden by 106?

Zash: well, right now I use an internal mapping lowercase→CaseSentitive, and JIDs are already pretty damn ugly, eg xmpp:10sshgv8382qwrib%2Blsdoezigzzw%5C2furxzxjnpihag1y%3D@signal.slidge.im?join

singpolyma: I already need XEP-0106 since it's case sensitive AND contains forbidden chars in jid localparts :)

Zash: thanks for the base32 suggestion, I'll have a look :)

or if there's some internal ID that makes sense to use

keeping a map is nice but much more annoying than having "stateless conversions" if that makes sense

nice to have good looking JIDs I mean

For private chats they're already often just random strings that are sorta hidden from the UI

like in Conversations & forks

yes indeed. maybe later™ I'll try to have nicer looking bridged JIDs for mucs/contacts by ugly is very fine, as long as it works.

nicoco, something like https://github.com/moby/moby/blob/master/pkg/namesgenerator/names-generator.go ? for the mapping :P

If there ever is a mapping

pep. these are fun indeed :) but for context, I have some annoying race conditions on startup where my mapping is not filled yet and it messes things up, and although fixing would be the right thing to do, I'm actually going for "no mapping, stateless conversion" right now because 1.make it work and then 2.make it right =)

Mercurial has a thing where uppercase is internally prefixed with `_`, so `README` → `_r_e_a_d_m_e`

yikes?

The things people do for Windows :/

or otherwise case insensitive file systems.

problem is, I am not sure about what's allowed in a signal group ID. base32+JID escaping sounds like it might just work for me. base64.b32encode(b"10SSHGv8382QWrib+lSDoezIGZzw/urxZxJNPIhaG1Y=") b'GEYFGU2II53DQMZYGJIVO4TJMIVWYU2EN5SXUSKHLJ5HOL3VOJ4FU6CKJZIES2DBI4YVSPI='

As long as it doesn't reach 1023 octets, you should be fine

... hold on, is that base64?

nah, but python's base64 from the std lib actually holds the b32encode func: https://docs.python.org/3.9/library/base64.html#base64.b32encode

The input, I mean

oh...

I don't think so

It seems to be valid base64 tho, decodes to a 32 octet* random looking binary string ✏

be a hacker, find a way to convert that a to signal group invite URL, create a signal account, join my "slidge test" signal group, and then become rich!

> create a signal account you're in the wrong chat m8 🙃️

wait, do I need to JID escape, or does base32 already output valid localparts for JIDs?

base32 encodes arbitrary binary and is case insensitive

selurvedu: of right, it's not sdev@??? ;)

i mean, there's no way anybody here would do that, amirite :)

it's question day for me! as soon as my MUC service tries to send a message to a client and receives an "error" in reply, it should consider that this client is not "joined" anymore and stop trying to send stuff to it. is that OK or are there other stuff to look for?

If the MUC sends them an error they kick them in the process no?

mmm I was not clear. I am the MUC, and I tried to send a message to a "joined resource", and received an error.

or do you mean when that happens, I should send 'kick' presences?

hmm I was talking about the other way around yeah. I don't know here.

I AM THE MUC, SKYLER

(sorry)

nicoco, these are the errors a MUC should kick an occupant for sending: https://hg.prosody.im/trunk/file/tip/plugins/muc/util.lib.lua#l27

(BB?)

The thing about all these rules is that they're too many and it's hard to remember all of them.. and they're also often encoding in fancy wording in the spec or it's a combination of 50 different things ><

Kicked on gone/redirected?

MattJ: oh OK, so not all errors then. does prosody also send a presence with some status codes when happens or does "kicking" just means "I'm not going to send you anything from now on"?

I think we don't send anything to the leaving occupant - the assumption being that 1) we are unable to reach them, 2) it could cause an error loop (generally responding to an error is not something you should do)

Thanks a lot! This is what I was going for, without even thinking of the possible loop problem (d'oh!). So I was "accidentally right".