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?
MattJ
That should be enough
goffihas left
goffihas joined
nicoco
thanks MattJ!
Laurahas left
atomicwatchhas joined
dezanthas left
dezanthas joined
Dele Olajidehas joined
Dele Olajidehas left
goffihas left
marc0shas left
marc0shas joined
lennarthas left
antranigvhas joined
marc0shas left
homebeachhas left
Matrix Traveler (bot)has left
homebeachhas joined
Matrix Traveler (bot)has joined
marc0shas joined
marc0shas left
marc0shas joined
stuart.j.mackintoshhas joined
nicolahas left
dezanthas left
dezanthas joined
goffihas joined
PapaTutuWawahas joined
goffihas left
goffihas joined
dezanthas left
dezanthas joined
Trunghas left
Trunghas joined
Trunghas left
Trunghas joined
antranigvhas left
antranigvhas joined
antranigvhas left
atomicwatchhas left
bootlickerhas left
marc0shas left
marc0shas joined
atomicwatchhas joined
atomicwatchhas left
atomicwatchhas joined
atomicwatchhas left
atomicwatchhas joined
atomicwatchhas left
atomicwatchhas joined
atomicwatchhas left
atomicwatchhas joined
atomicwatchhas left
atomicwatchhas joined
atomicwatchhas left
atomicwatchhas joined
dezanthas left
dezanthas joined
Alexhas left
Alexhas joined
ukrhas joined
ukrhas left
TheCoffeMakerhas left
TheCoffeMakerhas joined
nicoco
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 client can fetch the avatar via XEP-0084?✎
nicoco
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? ✏
Zash
XEP-0153 is the current thing, XEP-0084 in MUC is ... weird
Zash
Dunno if it works with anything but Prosody
nicoco
I thinking XEP-0084 not mediated by the MUC, since I'm talking about non anonymous MUCs✎
nicoco
I was thinking about XEP-0084 not mediated by the MUC, since I'm talking about non anonymous MUCs ✏
nicoco
so technically, client can send the request directly to the known "real" JID of the participant, or maybe they cannot for some reason?
Zash
Subject to the access model of the pubsub node(s)
Zash
So, users can choose who can see their avatar and other details
Zash
While vcard-temp has nothing like that
Zash
this is (one reason) why I want vcard-temp to go away
nicoco
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 =)
pep.
You can provide a 0153 interface to 0084 like prosody does
pep.
If access is restricted then there's no avatar
bootlickerhas joined
homebeachhas left
Matrix Traveler (bot)has left
homebeachhas joined
Matrix Traveler (bot)has joined
dezanthas left
dezanthas joined
sponjihas left
Zash
true 🙂
nicoco
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.
techmetx11
Zash: is vcard4 a good alternative to vcard-temp?
nicoco
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)
Zash
yes
TheCoffeMakerhas left
techmetx11
alright
techmetx11
i mean i've only implemented vcard-temp because my server only supported that at the moment when i wrote it
MattJ
The nice thing is that vcard4 doesn't actually require server support, other than PEP
Zash
It's also a standard developed elsewhere
TheCoffeMakerhas joined
Zash
while vcard-temp is our hacky fork of some unfinished vcard3-xml format that went nowhere
nicoco
hence the "-temp" part I guess?
Zash
https://xkcd.com/2730/
ukrhas joined
Ukrhas joined
marc0shas left
marc0shas joined
Ukrhas left
marc0shas left
marc0shas joined
Ukrhas joined
Patigahas left
Alexhas left
Alexhas joined
Ukrhas left
Vaulorhas left
Patigahas joined
Vaulorhas joined
tskhas left
tskhas joined
jgarthas left
xnamedhas left
xnamedhas joined
singpolyma
Next step beyond permissions: ad hoc command to set different vcard field values or different avatar depending on who is asking ;)
ukrhas left
pep.
Upload the avatar on the MUC?
nicoco
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 ^^
Zash
singpolyma, do you by chance remember OneSocialWeb? I think they had a proposal for that.
singpolyma
nicoco: yes, the protocol allows for it now just need a server module with an ad hoc command to allow setting it up
singpolyma
Zash: the name rings a bell I think
marc0shas left
marc0shas joined
kapadhas joined
nicoco
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?
Zash
NAFAIK, closest is https://xmpp.org/extensions/xep-0106.html
nicoco
yes, I was looking at that, and this: https://xmpp.org/extensions/xep-0106.html#example-5
antranigvhas joined
Zash
you could cry and use base32 and hope nobody sees the actual JIDs
singpolyma
Or use extended jid\20escaping only for capitals
Zash
singpolyma, that seems to be explicitly forbidden by 106?
nicoco
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
nicoco
singpolyma: I already need XEP-0106 since it's case sensitive AND contains forbidden chars in jid localparts :)
nicoco
Zash: thanks for the base32 suggestion, I'll have a look :)
Zash
or if there's some internal ID that makes sense to use
sponjihas joined
sponjihas left
nicoco
keeping a map is nice but much more annoying than having "stateless conversions" if that makes sense
nicoco
nice to have good looking JIDs I mean
Zash
For private chats they're already often just random strings that are sorta hidden from the UI
Zash
like in Conversations & forks
sponjihas joined
sponjihas left
sponjihas joined
sponjihas left
nicoco
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.
pep.
nicoco, something like https://github.com/moby/moby/blob/master/pkg/namesgenerator/names-generator.go ? for the mapping :P
pep.
If there ever is a mapping
sponjihas joined
sponjihas left
sponjihas joined
sponjihas left
nicoco
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 =)
sponjihas joined
sponjihas left
sponjihas joined
sponjihas left
Zash
Mercurial has a thing where uppercase is internally prefixed with `_`, so `README` → `_r_e_a_d_m_e`
sponjihas joined
sponjihas left
qy
yikes?
sponjihas joined
singpolymahas left
Zash
The things people do for Windows :/
Zash
or otherwise case insensitive file systems.
nicoco
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='
Zash
As long as it doesn't reach 1023 octets, you should be fine
Zash
... hold on, is that base64?
nicoco
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
Zash
The input, I mean
nicoco
oh...
singpolymahas joined
nicoco
I don't think so
Zash
It seems to be valid base64 tho, decodes to a 32 bit random looking binary string✎
moparisthebesthas left
Zash
It seems to be valid base64 tho, decodes to a 32 octet* random looking binary string ✏
nicoco
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!
selurvedu
> create a signal account
you're in the wrong chat m8 🙃️
nicoco
wait, do I need to JID escape, or does base32 already output valid localparts for JIDs?
Zash
base32 encodes arbitrary binary and is case insensitive
nicoco
selurvedu: of right, it's not sdev@??? ;)
selurvedu
i mean, there's no way anybody here would do that, amirite :)
marc0shas left
marc0shas joined
nicolahas joined
Millesimushas left
Millesimushas joined
lennarthas joined
Vaulorhas left
nicolahas left
nicoco
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?
pep.
If the MUC sends them an error they kick them in the process no?
nicoco
mmm I was not clear. I am the MUC, and I tried to send a message to a "joined resource", and received an error.
nicoco
or do you mean when that happens, I should send 'kick' presences?
singpolymahas left
pep.
hmm I was talking about the other way around yeah. I don't know here.
nicoco
I AM THE MUC, SKYLER
nicoco
(sorry)
singpolymahas joined
nicolahas joined
MattJ
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
pep.
(BB?)
pep.
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 ><
pep.
Kicked on gone/redirected?
Vaulorhas joined
nicolahas left
nicolahas joined
nicolahas left
nicolahas joined
nicolahas left
nicolahas joined
nicolahas left
nicolahas joined
nicolahas left
nicolahas joined
nicolahas left
nicolahas joined
homebeachhas left
Matrix Traveler (bot)has left
homebeachhas joined
Matrix Traveler (bot)has joined
nicolahas left
nicolahas joined
nicolahas left
nicolahas joined
nicoco
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"?
moparisthebesthas joined
MattJ
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)
nicolahas left
nicolahas joined
nicolahas left
nicolahas joined
nicolahas left
nicolahas joined
singpolymahas left
nicoco
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".