XSF Discussion - 2017-12-18

pep.: the message you sent to standards@ re MUC and presence=error. Did you have multiple clients joined to the MUC at that time with MSN?

is there are requirement on how short shortnames have to be?

nafaik

when marc is done-ish with his XEP, I should start a MUC Invite URL XEP which would be something like PARS but for MUCs

(integrated with both PARS and what marc did)

jonasw, that's nice, I had the same idea

:)

and then I’ll have to work on prosody to make all that happen and then I can actually invite people to XMPP

+1

jonasw, are you prosody dev?

no

but writing a module isn’t that hard :)

yes, I know

I looked at bit into the prosody code

jonasw: what's wrong with xmpp:muc@service?join ?

Ge0rG, the action parameter :P

marc: what about it?

Ge0rG, just kidding and a bit trolling ;)

marc: awww. now I'm really disappointed. You promised you'd never troll.

Ge0rG, members-only MUC

yes, just a second and I thought it's obviously :)

jonasw: fake it by adding a password.

Ge0rG, that still doesn’t give people an account and presence subscription to me

jonasw: wait, so you want an account, prsence subscription AND a MUC?

Ge0rG, yes.

integrate all the things

jonasw: one-push-warm-and-cozy?

what?

Also including Mr. Robot trivia?

Hahaha

I have no Mr. Robot trivia

one-tap would've been more appropriate, I suppose

jonasw: once you have them onboarded and added to your roster, you can just invite them into the MUC

Ge0rG, true

Ge0rG, that requires me to be online to make it work smoothly though

jonasw: that's all client-side-PARS over again

exactly

token-based MUC invitation woul dbe neat

> I have no Mr. Robot trivia I stopped watching after the fight club scene. That was a bit too much for me

I stopped watching after the second episode. It was playing out way too slowly, and the main actor was reminding me of the Frodo performance in LotR.

Ge0rG: same here, two episodes was my PR

But sorry for OTing this MUC once again.

jonasw: you could use the `preauth` token in MUC invitations as well.

I'm still struggling to create a yaxim UI to invite users into a MUC.

Ge0rG: just steal it somewhere

Just auto-join :-)

Holger: not to handle invitations, that part is already implemented in a nice way. To send invitations

Ah.

I suppose the most logica place would be inside the MUC, and it would need to have some "Add/Invite participant" button, which would then show a contact picker of some sort.

Brilliant solution

zinid: I'm sure you have awesome ideas for that workflow

Ge0rG: nah, I'm here to demotivate only

It's the approach I would follow, at least it is the first thing that comes to my mind.

Except I don't have a "contact picker", I'm using the main window for that.

but it would be really confusing to fall back from the MUC invitation to the main window and have no way back.

can I use links in a XEP?

to link to another section?

jonasw, re https://mail.jabber.org/pipermail/standards/2017-December/034058.html should we PR? Or wait for a bit more input? Or PR and wait for input on these? :P

I'll comment on the thread, but it actually "works fine" on ejabberd and mlink, or rather it's just not shown as a kick, they don't include 307. https://bpaste.net/raw/5eb5eda0bd42

I agree a new code would be more explicit, but then changing the XEP, and people updating their clients..

pep., sorry, I think that omitting 307 is the wrong way to go here.

it’s misleading, while kick is just confusing

right

hmm, Conversations doesn't show kicks at all?

Unless it's me I suppose

This is meh

conversations is minimalistic regarding these things

yeah I get that, still.

So I guess dino will have more or less the same pitch

especially in the self-presence (code='110') it is highly misleading to omit any type of status code which indicates what’s going on

pep., I think preparing a PR makes sense

I don’t care who of us does it. If you won’t, I’ll do it right away.

Not that I don't want to, but I have no idea how to formulate it

k, will do

Thanks

wouldn't that be an example for a change either requiring a namespace bump of xep45, or, if you make it optiona, provide no real benefit?

Flow, no

optional is fine

it only matters for UI purposes anyways

ahh, ok

it may also matter for other things in some special cases, but having it as a MAY is still better than nothing

brb

Flow, in fact, the status codes are a registry

so trivial to add new ones

except that we probably don’t have anything to update the registry HTML files in place ✏

Doesn't matter if there is a registry: if the spec would suddenly say that this code is required for this case, then it would be a breaking change. But it's probably fine if you make it optional

jonasw, thanks, just saw the PR!

pep., yes

jonasw, Flow, in any case all clients are going to need an update for this right? Because atm 307 is displayed as a kick ✏

I wonder why this has come up only now. It has been like this for ages.

So bump or not bump, it's the same issue right?

I'd say bump in this case, and make it required :x

jonasw, prosody rewrote their muc implementation in trunk

I guess they had a similar behavior to ejabberd/mlink before

pep., I’m very sure that not

because I’m observing this behaviour in prosody MUCs on 0.9

oh

ok

bump MUC, are you out of your mind?!

yay standards

Well not just standards

*Dear Santa, please help me deliver features to users faster, without bumps on the road*

pep., this change allows you to do that. My suspicion is that it is only now that people notice because we have more non-technical people. Those people use clients which are actively developed and which will be able to adapt to 333 quickly

There's a reason it is often called "bump version to X.X".

jonasw, how do we have more non-technical people

pep., it is just my suspicion

This particular discussion about muc spawned from Link Mauve and me

feedback welcome: https://gultsch.de/files/pep-vcard-conversion.html

daniel, when you get a chance, update your CSS, it’s nicer to read then.

daniel, neat

Does it make sense to have servers apply the same Access Control for the vCard as they do for PEP-Avatar?

i rather not change a historical xep; the default access model would not work in muc

the only sensible way is to do the conversion only if the access model of pep is whitelist

why is that?

what?

I don’t understand why it makes sense to do the conversion iff the whitelist access_model is used.

I would have expected the opposite?

if you would expect vcard to have the same access control as pep; you can't do that by changing vcards. but you could only do the conversion if the pep access model is that of vcards (=whitelist)

I thought vcards is open access?

s/whitelist/open/ in everything i said

now it makes sense, thanks!

how would a server deal with a client which does both vcard and pep-avatar?

that uploads both after each other?

yeah

they would simply override each other

I see

it's not ideal but i don't see how that can cause conflict

if iq queries are processed in order

which they are

I love it :)

we’re working on our vcard impl currently, we might integrate that as well

i should say that i didn't come up with that. both prosody and ejabberd have implemenations for that already

minus the presence broadcast thing on prosody

do they advertise the feature already?

no

k

the presence broadcast thing is essential for the method to work properly though. but should be an easy fix in prosody

it is indeed

the presence broadcast rules of xep-0153 are crazy, I’m happy to see that this might be fixed magically

jonasw, crazy because you have to download it first?

yeah, and the interaction with non-153 clients

now I wonder if it should be possible to set the vcard without changing the photo, to be able to modify non-avatar things there.

to what end? not triggering a notification in PEP?

hm

nevermind I guess

daniel, thanks a ton for the XEP 🙂

zinid, did you write the ejabberd module that does this?

yes

in that case i'm gonna mention you in the acknowledge section of the xep

(unless you object to that of course)

there is a minor bug though: vcard:x:update is not injected into direct presences

no objection of course

I mean it's injected, but not resent on avatar update (unlike broadcast, which is resent)

zinid: oh. I haven't thought of that. That might be difficult...

daniel, I think it’s reasonable to state that clients need to re-send that themselves

they need to handle directed presence manually anyways

jonasw, probably a good idea

(and it is sufficient for them to send a blank presence, the vcard thing will be injected)

not sure if client authors agree 🙂

I’m a client author

I’m not happy with having to re-send directed presence manually, but I need to do that anyways.

So if you publish a PEP avatar you're supposed to resend direct presence?

having to do this for avatar updates is fine.

well, you're a special one, you're not afraid of difficulties 🙂

Holger, no?

jonasw: yeah maybe. In reality it's probably not gonna be a huge problem

How often are you changing your avater

daniel, ack. even if the update doesn’t get through immediately, so what :)

having that written down is good though

Holger: not when publishing. But when receiving the notification about it

daniel, I know a guy with 15 year old avatar 😀

Otherwise it won't work if another client changes that

But yeah...

That's very very minor

It affects MUC right?

yes

"Look guys my funny new avatar!"

But yes compared to today's situation it's minor.

yeah, that's how I revealed the bug, hehe

Holger, indeed, good point.

Yeah I'll add it to the xep. It's not terribly complicated to resend directed presences when receiving a pep update *and* the server announces that feature

Sounds weirdo to me.

my vcard dev also thinks your XEP is great, daniel :)

Holger, in order to resent direct presences you need to store them on the server

do we want it?

Arguably better than tracking directed presences on the server

zinid, don’t you have to do that anyways, because you must send unavailable when the client disconnects? ✏

zinid: I'm confused, don't we have that in the c2s state?

But I must run, BBL.

jonasw, no, direct presences are not affected during server broadcasts

ah

yes, it's resent on unavailable 😉

but not the original presence, but the broadcasted one

ah I see you rpoint

you’d need to know how to compose the original directed presence

makes sense

yes

they can be different

If the general modus operandi is that client developers push responsibility to the server developers and vice versa I'll happily take the responsibility in that case as a client dev

daniel, I don’t see an issue with that, tbh, clients need to manage their directed presence either way.

and they need to re-send their directed presence with vcard-temp too if they care

this is still better

Totally

ah, another question is what to do if presence contains hash already

ejabberd currently rewrites it anyway

zinid, if it doesn’t match, somebody made a mistake, and if the server overrides that, that’s probably good

but seems like someone doesn't like this, e.g. they don't want to propagate their avatars to mucs

jonasw, yes, but see my next point

ah, but then you wouldn’t write a hash in it?

but an empty element?

so probably some mechanism to avoid injecting is needed

zinid: yeah that's why I said don't override

zinid, maybe only override if clients send <x xmlns="vcard-temp-foobar"/>? that’s how clients signal "I know the vcard protocol, but I don’t know the hash"

zinid: however that doesn't work as a security feature. The avater can still be retrieved

daniel, I'm fine with not overriding it on server 🙂

hm

<x xmlns="vcard-temp-foobar"/> means there is no avatar

at least from what I rememeber

An empty photo means it's empty

An empty x means something else. Lol

yup

empty x means "I understand vcard, but I don’t know the current hash, don’t mind me"

Either way it's probably better to not touch it

while absent x means "I don’t understand vcard-avatar, so neither of you all must publish vcard avatars"

on the other hand, there is a situation when a client has uploaded the avatar via vcard, the server transcoded the image (thus new hash) and we have problems here if we don't override

daniel, but then clients would have to fetch the photo to properly join a MUC

zinid, I’d suggest to override whenever there’s an <x/> element which doesn’t indicate absent avatar.

jonasw: no. Just don't set it at all

daniel, I don’t think that’s a good idea

or maybe it is

jonasw, a lot of stupid clients don't inject anything despite they have avatar, that's the problem...

I’m not sure

that was initial goal of mod_vcard_xupdate actually, it's later I adopted it to new behav

Yeah I don't have hard feelings with that either way. Maybe just leave the xep as is for now and see if this creates problems

yeah, this is bikeshedding mostly

true

if you don't mind a little more bikeshedding, what I would suggest is to not rewrite the hash if it's empty

so we work-around "transcoding" problem

zinid, I think that’s sane

and make crypto paranoics happy

yup

and regarding "an avatar anyway can be retrieved via vcard direct request": this could be solved by privacy rules, but we deferred them, hehe

> if you don't mind a little more bikeshedding, what I would suggest is to not rewrite the hash if it's empty > so we work-around "transcoding" problem An empty photo element?

yes

well, need to re-read xep-153 carefully to remember what empty photo element means

so we don't contradict

no avatar published if i correctly remember

zinid, it means "I don’t want to publish an avatar"

or de-publishing essentially

yes

I don't see the argument for touching the x element at all

If it exists

what if the server has changed the avatar, for example png->jpeg or something?

why should he do that?

well, yes, that's a separate unrelated story, but anyway

zinid: ok. Fair enough

lovetox, because some put webp into avatars 😛

yeah and? why would the server care?

lovetox, an admin might care about the users, you know, that can happen

i think this opens a lot of problems

we depend on hash

i upload something, know my hash

afterwards i get something different back

and?

such a server mod would be bad in my opinion

what problems?

you can receive another hash from another resource for example

so a client should be prepared to receive another hash

yup

lovetox, it’s just as if another resource of yours did that

iam if its from another resource

why would you care about the resource? :)

i dont know, its just weird

it's xmpp

makes no sense to me

of course it's weird

I find this pretty elegant

and you do this only because of conversations lol

if more things work by doing less, that’s most of the time a good thing

elegant is if clients support more than jpeg and png

elegant would be clients respecting a standard and uploading in a agreed format

this is all BUT elegant

lovetox, except that the agreed-upon format does not cope well with the defined limits in the RFCs

i dont really care, i was just arguing that you seriously think thats elegant

I wish we had a way to properly put multiple formats into the avatar node in an XMPPy way

lovetox, I’m not arguing that doing some server-side conversion is particularly elegant

maybe i should start uploading in some even more exotic format, so we can write more server mods

we probably need to consider a different format, I don't think this will hurt, because I don't think there are clients not understanding jpeg (i.e. png-only)

I’m arguing that not caring about the /resource of vcard updates is elegant, because you don’t need that extra check.

zinid, except that jpeg sucks

jonasw, yes, but png is really huge

depends

Fwiw Conversations stopped uploading webp

so they both suck

zinid, yes

trade-offs all over again

daniel, good to know 😛

Should we create or own image format?

daniel, like we created our own Markup?

daniel, what does conversations do now?

Jpeg

Duh

"meh"

Eps

Lol

jonasw: don't worry it will still work with your avatar because there is an exception if the image contains transparency

daniel, neat!

so if I want an uncompressed avatar, I just make one pixel with alpha=254 :)

It will resize it of course. But yes

Or use a different avatar

Client

sure

To upload it

daniel, muc vcard avatars are left!

daniel, movim did it already 🙂

ejabberd supports them since stone age

zinid: is there a xep?

well, I asked XSF back in the time, they said no xep is needed for this

the only problem is how to update the avatar, since a conference doesn't generate presences

I mean how to propagate updates

'the only problem'

😀

MIX will fix that ;-)

we should get stickers with that

well, I'd really love to see conference avatar in my conversations list instead of a square with 4 squares inside

So what does movim do? Just query it opportunisticly on every join?

daniel, no, every couple of hours or so 😀

what if a presence comes from bare conference jid?

would clients get crazy because of this?

I think we should definitely write down a XEP about how to deal with the bare MUC JID

Conversations would just ignore it I guess

services are already making use of the bare MUC JID for sending service messages, and having that written down somewhere would be good

I have no idea what aioxmpp would do on a presence from the bare MUC JID.

daniel, so we probably can utilize it for avatars dissemination

Probably... We can try to implement it next year as a PoC

PoC?

Proof of concept

Proof that it works in quick demo

and we prove it to ... ?

XSF? 🙂

I never personally had the desire for muc avatars but it's easy enough to implement I guess so I'm not opposed

Nah the world

Or to ourselves

do MUCs have to implement PubSub then, too?

I think we are talking about vCard avatars

for now :)

and if mucs implement pubsub, why would we need mix? 🙂

I'm actually agreed already to implement pubsub on mucs, just not to implement this dredful MIX

Well we are now slowly getting to point where we fixed most of the muc bugs so it's about time to replace it with something else

daniel, another way is to utilize something like if-modified-since in join presence, and later a muc will send presence updates to those clients only

Sorry I'm late to the party; regarding overriding the avatar hash: If you think users might not want to publish the avatar to MUCs, then auto-publishing the PEP avatar as vCard is a problem, no? I mean there's no way to stop the server from injecting the hash after the client published the avatar via PEP, no?

yes it doesn't do anything security wise

it might stop certain clients from discovering that you have a client

but thats not even security by obscurity

*that you have an avatar

Holger, but in theory you can restrict your access to vcards via privacy rules (e.g. subscription=none => deny)

zinid, but then it doesn't matter what hash you annouce

well, you can be identified by the hash 😛

I don't know how the brain of crypto maniacs work, so I just guessing 🙂

https://gultsch.de/files/pep-vcard-conversion.html updated. i included a note that the server should not touch empty photo elemets but override photo with wrong hashes

fine by me 🙂

thx

when approved, I'll fix that in ejabberd

and prosody needs to do the x_update thing. maybe i'll code that myself at some point

I'm drunk, but I don't find this text clear: > Empty x elements qualified by the 'vcard-temp:x:update' namespace (those without a photo element as child), as well as photo elements with a wrong hash MUST be overwritten.

what is the 'wrong hash'? Is empty hash ('') wrong?

the example is clear, though

do you have a suggestion on how to make this more clear?

(even though you are drunk?)

…as well as photo elements with a non-empty content MUST be overwritten?

I would suggest to split the sentence in two short parts, which are clear, like 'A server MUST NOT override presences with empty <photo> element. A server MAY override all other presences', something like that

fair enough

not sure whey we want to override presences without <photo/> element though 🙂

I just read the XEP-0153 and didn't get what means "a client is not yet ready to advertise an image"

sending presence before receiving the iq response for the avatar

ah

good point

then it makes sense, yes

> To avoid this, services MUST include the hash on behalf of their users in every available presence that does not contain an empty photo element wrapped in an x element qualified by the 'vcard-temp:x:update' namespace. Empty x elements qualified by the 'vcard-temp:x:update' namespace (those without a photo element as child) MUST be overwritten. Presences where the content of the photo element is not empty and not equal to the hash calculated by the service MAY be overwritten.

yes, much more clear