-
Ge0rG
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?
-
daniel
is there are requirement on how short shortnames have to be?
-
jonasw
nafaik
-
jonasw
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
-
jonasw
(integrated with both PARS and what marc did)
-
marc
jonasw, that's nice, I had the same idea
-
marc
:)
-
jonasw
and then I’ll have to work on prosody to make all that happen and then I can actually invite people to XMPP
-
SouL
+1
-
marc
jonasw, are you prosody dev?
-
jonasw
no
-
jonasw
but writing a module isn’t that hard :)
-
marc
yes, I know
-
marc
I looked at bit into the prosody code
-
Ge0rG
jonasw: what's wrong with xmpp:muc@service?join ?
-
marc
Ge0rG, the action parameter :P
-
Ge0rG
marc: what about it?
-
marc
Ge0rG, just kidding and a bit trolling ;)
-
Ge0rG
marc: awww. now I'm really disappointed. You promised you'd never troll.
-
jonasw
Ge0rG, members-only MUC
-
marc
yes, just a second and I thought it's obviously :)
-
Ge0rG
jonasw: fake it by adding a password.
-
jonasw
Ge0rG, that still doesn’t give people an account and presence subscription to me
-
Ge0rG
jonasw: wait, so you want an account, prsence subscription AND a MUC?
-
jonasw
Ge0rG, yes.
-
jonasw
integrate all the things
-
Ge0rG
jonasw: one-push-warm-and-cozy?
-
jonasw
what?
-
Ge0rG
Also including Mr. Robot trivia?
-
SouL
Hahaha
-
jonasw
I have no Mr. Robot trivia
-
Ge0rG
one-tap would've been more appropriate, I suppose
-
Ge0rG
jonasw: once you have them onboarded and added to your roster, you can just invite them into the MUC
-
jonasw
Ge0rG, true
-
jonasw
Ge0rG, that requires me to be online to make it work smoothly though
-
Ge0rG
jonasw: that's all client-side-PARS over again
-
jonasw
exactly
-
jonasw
token-based MUC invitation woul dbe neat
-
daniel
> I have no Mr. Robot trivia I stopped watching after the fight club scene. That was a bit too much for me
-
Ge0rG
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.
-
zinid
Ge0rG: same here, two episodes was my PR
-
Ge0rG
But sorry for OTing this MUC once again.
-
Ge0rG
jonasw: you could use the `preauth` token in MUC invitations as well.
-
Ge0rG
I'm still struggling to create a yaxim UI to invite users into a MUC.
-
zinid
Ge0rG: just steal it somewhere
-
Holger
Just auto-join :-)
-
Ge0rG
Holger: not to handle invitations, that part is already implemented in a nice way. To send invitations
-
Holger
Ah.
-
Ge0rG
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.
-
zinid
Brilliant solution
-
Ge0rG
zinid: I'm sure you have awesome ideas for that workflow
-
zinid
Ge0rG: nah, I'm here to demotivate only
-
SouL
It's the approach I would follow, at least it is the first thing that comes to my mind.
-
Ge0rG
Except I don't have a "contact picker", I'm using the main window for that.
-
Ge0rG
but it would be really confusing to fall back from the MUC invitation to the main window and have no way back.
-
daniel
can I use links in a XEP?
-
daniel
to link to another section?
-
pep.
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
-
pep.
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
-
pep.
I agree a new code would be more explicit, but then changing the XEP, and people updating their clients..
-
jonasw
pep., sorry, I think that omitting 307 is the wrong way to go here.
-
jonasw
it’s misleading, while kick is just confusing
-
pep.
right
-
pep.
hmm, Conversations doesn't show kicks at all?
-
pep.
Unless it's me I suppose
-
pep.
This is meh
-
jonasw
conversations is minimalistic regarding these things
-
pep.
yeah I get that, still.
-
pep.
So I guess dino will have more or less the same pitch
-
jonasw
especially in the self-presence (code='110') it is highly misleading to omit any type of status code which indicates what’s going on
-
jonasw
pep., I think preparing a PR makes sense
-
jonasw
I don’t care who of us does it. If you won’t, I’ll do it right away.
-
pep.
Not that I don't want to, but I have no idea how to formulate it
-
jonasw
k, will do
-
pep.
Thanks
-
Flow
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?
-
jonasw
Flow, no
-
jonasw
optional is fine
-
jonasw
it only matters for UI purposes anyways
-
Flow
ahh, ok
-
jonasw
it may also matter for other things in some special cases, but having it as a MAY is still better than nothing
-
jonasw
brb
-
jonasw
Flow, in fact, the status codes are a registry
-
jonasw
so trivial to add new ones
-
jonasw
except that we probably don’t have anything to update the registry HTML files in pace✎ -
jonasw
except that we probably don’t have anything to update the registry HTML files in place ✏
-
Flow
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
-
pep.
jonasw, thanks, just saw the PR!
-
pep.
jonasw, Flow, in any case any client is going to need an update for this right? Because atm 307 is displayed as a kick✎ -
jonasw
pep., yes
-
pep.
jonasw, Flow, in any case all clients are going to need an update for this right? Because atm 307 is displayed as a kick ✏
-
jonasw
I wonder why this has come up only now. It has been like this for ages.
-
pep.
So bump or not bump, it's the same issue right?
-
pep.
I'd say bump in this case, and make it required :x
-
pep.
jonasw, prosody rewrote their muc implementation in trunk
-
pep.
I guess they had a similar behavior to ejabberd/mlink before
-
jonasw
pep., I’m very sure that not
-
jonasw
because I’m observing this behaviour in prosody MUCs on 0.9
-
pep.
oh
-
pep.
ok
-
jonasw
bump MUC, are you out of your mind?!
-
pep.
yay standards
-
pep.
Well not just standards
-
pep.
*Dear Santa, please help me deliver features to users faster, without bumps on the road*
-
jonasw
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
-
tux
There's a reason it is often called "bump version to X.X".
-
pep.
jonasw, how do we have more non-technical people
-
jonasw
pep., it is just my suspicion
-
pep.
This particular discussion about muc spawned from Link Mauve and me
-
daniel
feedback welcome: https://gultsch.de/files/pep-vcard-conversion.html
-
jonasw
daniel, when you get a chance, update your CSS, it’s nicer to read then.
-
jonasw
daniel, neat
-
jonasw
Does it make sense to have servers apply the same Access Control for the vCard as they do for PEP-Avatar?
-
daniel
i rather not change a historical xep; the default access model would not work in muc
-
daniel
the only sensible way is to do the conversion only if the access model of pep is whitelist
-
jonasw
why is that?
-
daniel
what?
-
jonasw
I don’t understand why it makes sense to do the conversion iff the whitelist access_model is used.
-
jonasw
I would have expected the opposite?
-
daniel
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)
-
jonasw
I thought vcards is open access?
-
daniel
s/whitelist/open/ in everything i said
-
jonasw
now it makes sense, thanks!
-
jonasw
how would a server deal with a client which does both vcard and pep-avatar?
-
daniel
that uploads both after each other?
-
jonasw
yeah
-
daniel
they would simply override each other
-
jonasw
I see
-
daniel
it's not ideal but i don't see how that can cause conflict
-
daniel
if iq queries are processed in order
-
daniel
which they are
-
jonasw
I love it :)
-
jonasw
we’re working on our vcard impl currently, we might integrate that as well
-
daniel
i should say that i didn't come up with that. both prosody and ejabberd have implemenations for that already
-
daniel
minus the presence broadcast thing on prosody
-
jonasw
do they advertise the feature already?
-
daniel
no
-
jonasw
k
-
daniel
the presence broadcast thing is essential for the method to work properly though. but should be an easy fix in prosody
-
jonasw
it is indeed
-
jonasw
the presence broadcast rules of xep-0153 are crazy, I’m happy to see that this might be fixed magically
-
daniel
jonasw, crazy because you have to download it first?
-
jonasw
yeah, and the interaction with non-153 clients
-
jonasw
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.
-
daniel
to what end? not triggering a notification in PEP?
-
jonasw
hm
-
jonasw
nevermind I guess
-
zinid
daniel, thanks a ton for the XEP 🙂
-
daniel
zinid, did you write the ejabberd module that does this?
-
zinid
yes
-
daniel
in that case i'm gonna mention you in the acknowledge section of the xep
-
daniel
(unless you object to that of course)
-
zinid
there is a minor bug though: vcard:x:update is not injected into direct presences
-
zinid
no objection of course
-
zinid
I mean it's injected, but not resent on avatar update (unlike broadcast, which is resent)
-
daniel
zinid: oh. I haven't thought of that. That might be difficult...
-
jonasw
daniel, I think it’s reasonable to state that clients need to re-send that themselves
-
jonasw
they need to handle directed presence manually anyways
-
zinid
jonasw, probably a good idea
-
jonasw
(and it is sufficient for them to send a blank presence, the vcard thing will be injected)
-
zinid
not sure if client authors agree 🙂
-
jonasw
I’m a client author
-
jonasw
I’m not happy with having to re-send directed presence manually, but I need to do that anyways.
-
Holger
So if you publish a PEP avatar you're supposed to resend direct presence?
-
jonasw
having to do this for avatar updates is fine.
-
zinid
well, you're a special one, you're not afraid of difficulties 🙂
-
jonasw
Holger, no?
-
daniel
jonasw: yeah maybe. In reality it's probably not gonna be a huge problem
-
daniel
How often are you changing your avater
-
jonasw
daniel, ack. even if the update doesn’t get through immediately, so what :)
-
jonasw
having that written down is good though
-
daniel
Holger: not when publishing. But when receiving the notification about it
-
zinid
daniel, I know a guy with 15 year old avatar 😀
-
daniel
Otherwise it won't work if another client changes that
-
daniel
But yeah...
-
daniel
That's very very minor
-
Holger
It affects MUC right?
-
jonasw
yes
-
Holger
"Look guys my funny new avatar!"
-
Holger
But yes compared to today's situation it's minor.
-
zinid
yeah, that's how I revealed the bug, hehe
-
jonasw
Holger, indeed, good point.
-
daniel
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
-
Holger
Sounds weirdo to me.
-
jonasw
my vcard dev also thinks your XEP is great, daniel :)
-
zinid
Holger, in order to resent direct presences you need to store them on the server
-
zinid
do we want it?
-
daniel
Arguably better than tracking directed presences on the server
-
jonasw
zinid, don’t you have to do that anyways, because you must send unavailable when the server leaves?✎ -
jonasw
zinid, don’t you have to do that anyways, because you must send unavailable when the client disconnects? ✏
-
Holger
zinid: I'm confused, don't we have that in the c2s state?
-
Holger
But I must run, BBL.
-
zinid
jonasw, no, direct presences are not affected during server broadcasts
-
zinid
ah
-
zinid
yes, it's resent on unavailable 😉
-
zinid
but not the original presence, but the broadcasted one
-
jonasw
ah I see you rpoint
-
jonasw
you’d need to know how to compose the original directed presence
-
jonasw
makes sense
-
zinid
yes
-
zinid
they can be different
-
daniel
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
-
jonasw
daniel, I don’t see an issue with that, tbh, clients need to manage their directed presence either way.
-
jonasw
and they need to re-send their directed presence with vcard-temp too if they care
-
jonasw
this is still better
-
daniel
Totally
-
zinid
ah, another question is what to do if presence contains hash already
-
zinid
ejabberd currently rewrites it anyway
-
jonasw
zinid, if it doesn’t match, somebody made a mistake, and if the server overrides that, that’s probably good
-
zinid
but seems like someone doesn't like this, e.g. they don't want to propagate their avatars to mucs
-
zinid
jonasw, yes, but see my next point
-
jonasw
ah, but then you wouldn’t write a hash in it?
-
jonasw
but an empty element?
-
zinid
so probably some mechanism to avoid injecting is needed
-
daniel
zinid: yeah that's why I said don't override
-
jonasw
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"
-
daniel
zinid: however that doesn't work as a security feature. The avater can still be retrieved
-
zinid
daniel, I'm fine with not overriding it on server 🙂
-
jonasw
hm
-
zinid
<x xmlns="vcard-temp-foobar"/> means there is no avatar
-
zinid
at least from what I rememeber
-
daniel
An empty photo means it's empty
-
daniel
An empty x means something else. Lol
-
jonasw
yup
-
jonasw
empty x means "I understand vcard, but I don’t know the current hash, don’t mind me"
-
daniel
Either way it's probably better to not touch it
-
jonasw
while absent x means "I don’t understand vcard-avatar, so neither of you all must publish vcard avatars"
-
zinid
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
-
jonasw
daniel, but then clients would have to fetch the photo to properly join a MUC
-
jonasw
zinid, I’d suggest to override whenever there’s an <x/> element which doesn’t indicate absent avatar.
-
daniel
jonasw: no. Just don't set it at all
-
jonasw
daniel, I don’t think that’s a good idea
-
jonasw
or maybe it is
-
zinid
jonasw, a lot of stupid clients don't inject anything despite they have avatar, that's the problem...
-
jonasw
I’m not sure
-
zinid
that was initial goal of mod_vcard_xupdate actually, it's later I adopted it to new behav
-
daniel
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
-
zinid
yeah, this is bikeshedding mostly
-
jonasw
true
-
zinid
if you don't mind a little more bikeshedding, what I would suggest is to not rewrite the hash if it's empty
-
zinid
so we work-around "transcoding" problem
-
jonasw
zinid, I think that’s sane
-
zinid
and make crypto paranoics happy
-
jonasw
yup
-
zinid
and regarding "an avatar anyway can be retrieved via vcard direct request": this could be solved by privacy rules, but we deferred them, hehe
-
daniel
> 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?
-
zinid
yes
-
zinid
well, need to re-read xep-153 carefully to remember what empty photo element means
-
zinid
so we don't contradict
-
lovetox
no avatar published if i correctly remember
-
jonasw
zinid, it means "I don’t want to publish an avatar"
-
jonasw
or de-publishing essentially
-
jonasw
yes
-
daniel
I don't see the argument for touching the x element at all
-
daniel
If it exists
-
zinid
what if the server has changed the avatar, for example png->jpeg or something?
-
lovetox
why should he do that?
-
zinid
well, yes, that's a separate unrelated story, but anyway
-
daniel
zinid: ok. Fair enough
-
zinid
lovetox, because some put webp into avatars 😛
-
lovetox
yeah and? why would the server care?
-
zinid
lovetox, an admin might care about the users, you know, that can happen
-
lovetox
i think this opens a lot of problems
-
lovetox
we depend on hash
-
lovetox
i upload something, know my hash
-
lovetox
afterwards i get something different back
-
zinid
and?
-
lovetox
such a server mod would be bad in my opinion
-
zinid
what problems?
-
zinid
you can receive another hash from another resource for example
-
zinid
so a client should be prepared to receive another hash
-
jonasw
yup
-
jonasw
lovetox, it’s just as if another resource of yours did that
-
lovetox
iam if its from another resource
-
jonasw
why would you care about the resource? :)
-
lovetox
i dont know, its just weird
-
zinid
it's xmpp
-
lovetox
makes no sense to me
-
zinid
of course it's weird
-
jonasw
I find this pretty elegant
-
lovetox
and you do this only because of conversations lol
-
jonasw
if more things work by doing less, that’s most of the time a good thing
-
lovetox
elegant is if clients support more than jpeg and png
-
lovetox
elegant would be clients respecting a standard and uploading in a agreed format
-
lovetox
this is all BUT elegant
-
jonasw
lovetox, except that the agreed-upon format does not cope well with the defined limits in the RFCs
-
lovetox
i dont really care, i was just arguing that you seriously think thats elegant
-
jonasw
I wish we had a way to properly put multiple formats into the avatar node in an XMPPy way
-
jonasw
lovetox, I’m not arguing that doing some server-side conversion is particularly elegant
-
lovetox
maybe i should start uploading in some even more exotic format, so we can write more server mods
-
zinid
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)
-
jonasw
I’m arguing that not caring about the /resource of vcard updates is elegant, because you don’t need that extra check.
-
jonasw
zinid, except that jpeg sucks
-
zinid
jonasw, yes, but png is really huge
-
jonasw
depends
-
daniel
Fwiw Conversations stopped uploading webp
-
zinid
so they both suck
-
jonasw
zinid, yes
-
jonasw
trade-offs all over again
-
zinid
daniel, good to know 😛
-
daniel
Should we create or own image format?
-
jonasw
daniel, like we created our own Markup?
-
jonasw
daniel, what does conversations do now?
-
daniel
Jpeg
-
daniel
Duh
-
jonasw
"meh"
-
daniel
Eps
-
daniel
Lol
-
daniel
jonasw: don't worry it will still work with your avatar because there is an exception if the image contains transparency
-
jonasw
daniel, neat!
-
jonasw
so if I want an uncompressed avatar, I just make one pixel with alpha=254 :)
-
daniel
It will resize it of course. But yes
-
daniel
Or use a different avatar
-
daniel
Client
-
jonasw
sure
-
daniel
To upload it
-
zinid
daniel, muc vcard avatars are left!
-
zinid
daniel, movim did it already 🙂
-
zinid
ejabberd supports them since stone age
-
daniel
zinid: is there a xep?
-
zinid
well, I asked XSF back in the time, they said no xep is needed for this
-
zinid
the only problem is how to update the avatar, since a conference doesn't generate presences
-
zinid
I mean how to propagate updates
-
daniel
'the only problem'
-
zinid
😀
-
jonasw
MIX will fix that ;-)
-
jonasw
we should get stickers with that
-
zinid
well, I'd really love to see conference avatar in my conversations list instead of a square with 4 squares inside
-
daniel
So what does movim do? Just query it opportunisticly on every join?
-
zinid
daniel, no, every couple of hours or so 😀
-
zinid
what if a presence comes from bare conference jid?
-
zinid
would clients get crazy because of this?
-
jonasw
I think we should definitely write down a XEP about how to deal with the bare MUC JID
-
daniel
Conversations would just ignore it I guess
-
jonasw
services are already making use of the bare MUC JID for sending service messages, and having that written down somewhere would be good
-
jonasw
I have no idea what aioxmpp would do on a presence from the bare MUC JID.
-
zinid
daniel, so we probably can utilize it for avatars dissemination
-
daniel
Probably... We can try to implement it next year as a PoC
-
zinid
PoC?
-
daniel
Proof of concept
-
daniel
Proof that it works in quick demo
-
zinid
and we prove it to ... ?
-
zinid
XSF? 🙂
-
daniel
I never personally had the desire for muc avatars but it's easy enough to implement I guess so I'm not opposed
-
daniel
Nah the world
-
daniel
Or to ourselves
-
jonasw
do MUCs have to implement PubSub then, too?
-
daniel
I think we are talking about vCard avatars
-
jonasw
for now :)
-
zinid
and if mucs implement pubsub, why would we need mix? 🙂
-
zinid
I'm actually agreed already to implement pubsub on mucs, just not to implement this dredful MIX
-
daniel
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
-
zinid
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
-
Holger
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?
-
daniel
yes it doesn't do anything security wise
-
daniel
it might stop certain clients from discovering that you have a client
-
daniel
but thats not even security by obscurity
-
daniel
*that you have an avatar
-
zinid
Holger, but in theory you can restrict your access to vcards via privacy rules (e.g. subscription=none => deny)
-
daniel
zinid, but then it doesn't matter what hash you annouce
-
zinid
well, you can be identified by the hash 😛
-
zinid
I don't know how the brain of crypto maniacs work, so I just guessing 🙂
-
daniel
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
-
zinid
fine by me 🙂
-
zinid
thx
-
zinid
when approved, I'll fix that in ejabberd
-
daniel
and prosody needs to do the x_update thing. maybe i'll code that myself at some point
-
zinid
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.
-
zinid
what is the 'wrong hash'? Is empty hash ('') wrong?
-
zinid
the example is clear, though
-
daniel
do you have a suggestion on how to make this more clear?
-
daniel
(even though you are drunk?)
-
daniel
…as well as photo elements with a non-empty content MUST be overwritten?
-
zinid
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
-
daniel
fair enough
-
zinid
not sure whey we want to override presences without <photo/> element though 🙂
-
zinid
I just read the XEP-0153 and didn't get what means "a client is not yet ready to advertise an image"
-
daniel
sending presence before receiving the iq response for the avatar
-
zinid
ah
-
zinid
good point
-
zinid
then it makes sense, yes
-
daniel
> 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.
-
zinid
yes, much more clear