XSF Discussion - 2017-12-18


  1. 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?

  2. daniel

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

  3. jonasw

    nafaik

  4. 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

  5. jonasw

    (integrated with both PARS and what marc did)

  6. marc

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

  7. marc

    :)

  8. jonasw

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

  9. SouL

    +1

  10. marc

    jonasw, are you prosody dev?

  11. jonasw

    no

  12. jonasw

    but writing a module isn’t that hard :)

  13. marc

    yes, I know

  14. marc

    I looked at bit into the prosody code

  15. Ge0rG

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

  16. marc

    Ge0rG, the action parameter :P

  17. Ge0rG

    marc: what about it?

  18. marc

    Ge0rG, just kidding and a bit trolling ;)

  19. Ge0rG

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

  20. jonasw

    Ge0rG, members-only MUC

  21. marc

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

  22. Ge0rG

    jonasw: fake it by adding a password.

  23. jonasw

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

  24. Ge0rG

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

  25. jonasw

    Ge0rG, yes.

  26. jonasw

    integrate all the things

  27. Ge0rG

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

  28. jonasw

    what?

  29. Ge0rG

    Also including Mr. Robot trivia?

  30. SouL

    Hahaha

  31. jonasw

    I have no Mr. Robot trivia

  32. Ge0rG

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

  33. Ge0rG

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

  34. jonasw

    Ge0rG, true

  35. jonasw

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

  36. Ge0rG

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

  37. jonasw

    exactly

  38. jonasw

    token-based MUC invitation woul dbe neat

  39. daniel

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

  40. 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.

  41. zinid

    Ge0rG: same here, two episodes was my PR

  42. Ge0rG

    But sorry for OTing this MUC once again.

  43. Ge0rG

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

  44. Ge0rG

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

  45. zinid

    Ge0rG: just steal it somewhere

  46. Holger

    Just auto-join :-)

  47. Ge0rG

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

  48. Holger

    Ah.

  49. 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.

  50. zinid

    Brilliant solution

  51. Ge0rG

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

  52. zinid

    Ge0rG: nah, I'm here to demotivate only

  53. SouL

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

  54. Ge0rG

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

  55. Ge0rG

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

  56. daniel

    can I use links in a XEP?

  57. daniel

    to link to another section?

  58. 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

  59. 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

  60. pep.

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

  61. jonasw

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

  62. jonasw

    it’s misleading, while kick is just confusing

  63. pep.

    right

  64. pep.

    hmm, Conversations doesn't show kicks at all?

  65. pep.

    Unless it's me I suppose

  66. pep.

    This is meh

  67. jonasw

    conversations is minimalistic regarding these things

  68. pep.

    yeah I get that, still.

  69. pep.

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

  70. 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

  71. jonasw

    pep., I think preparing a PR makes sense

  72. jonasw

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

  73. pep.

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

  74. jonasw

    k, will do

  75. pep.

    Thanks

  76. 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?

  77. jonasw

    Flow, no

  78. jonasw

    optional is fine

  79. jonasw

    it only matters for UI purposes anyways

  80. Flow

    ahh, ok

  81. jonasw

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

  82. jonasw

    brb

  83. jonasw

    Flow, in fact, the status codes are a registry

  84. jonasw

    so trivial to add new ones

  85. jonasw

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

  86. jonasw

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

  87. 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

  88. pep.

    jonasw, thanks, just saw the PR!

  89. 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

  90. jonasw

    pep., yes

  91. 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

  92. jonasw

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

  93. pep.

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

  94. pep.

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

  95. pep.

    jonasw, prosody rewrote their muc implementation in trunk

  96. pep.

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

  97. jonasw

    pep., I’m very sure that not

  98. jonasw

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

  99. pep.

    oh

  100. pep.

    ok

  101. jonasw

    bump MUC, are you out of your mind?!

  102. pep.

    yay standards

  103. pep.

    Well not just standards

  104. pep.

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

  105. 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

  106. tux

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

  107. pep.

    jonasw, how do we have more non-technical people

  108. jonasw

    pep., it is just my suspicion

  109. pep.

    This particular discussion about muc spawned from Link Mauve and me

  110. daniel

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

  111. jonasw

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

  112. jonasw

    daniel, neat

  113. jonasw

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

  114. daniel

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

  115. daniel

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

  116. jonasw

    why is that?

  117. daniel

    what?

  118. jonasw

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

  119. jonasw

    I would have expected the opposite?

  120. 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)

  121. jonasw

    I thought vcards is open access?

  122. daniel

    s/whitelist/open/ in everything i said

  123. jonasw

    now it makes sense, thanks!

  124. jonasw

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

  125. daniel

    that uploads both after each other?

  126. jonasw

    yeah

  127. daniel

    they would simply override each other

  128. jonasw

    I see

  129. daniel

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

  130. daniel

    if iq queries are processed in order

  131. daniel

    which they are

  132. jonasw

    I love it :)

  133. jonasw

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

  134. daniel

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

  135. daniel

    minus the presence broadcast thing on prosody

  136. jonasw

    do they advertise the feature already?

  137. daniel

    no

  138. jonasw

    k

  139. daniel

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

  140. jonasw

    it is indeed

  141. jonasw

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

  142. daniel

    jonasw, crazy because you have to download it first?

  143. jonasw

    yeah, and the interaction with non-153 clients

  144. 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.

  145. daniel

    to what end? not triggering a notification in PEP?

  146. jonasw

    hm

  147. jonasw

    nevermind I guess

  148. zinid

    daniel, thanks a ton for the XEP 🙂

  149. daniel

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

  150. zinid

    yes

  151. daniel

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

  152. daniel

    (unless you object to that of course)

  153. zinid

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

  154. zinid

    no objection of course

  155. zinid

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

  156. daniel

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

  157. jonasw

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

  158. jonasw

    they need to handle directed presence manually anyways

  159. zinid

    jonasw, probably a good idea

  160. jonasw

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

  161. zinid

    not sure if client authors agree 🙂

  162. jonasw

    I’m a client author

  163. jonasw

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

  164. Holger

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

  165. jonasw

    having to do this for avatar updates is fine.

  166. zinid

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

  167. jonasw

    Holger, no?

  168. daniel

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

  169. daniel

    How often are you changing your avater

  170. jonasw

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

  171. jonasw

    having that written down is good though

  172. daniel

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

  173. zinid

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

  174. daniel

    Otherwise it won't work if another client changes that

  175. daniel

    But yeah...

  176. daniel

    That's very very minor

  177. Holger

    It affects MUC right?

  178. jonasw

    yes

  179. Holger

    "Look guys my funny new avatar!"

  180. Holger

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

  181. zinid

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

  182. jonasw

    Holger, indeed, good point.

  183. 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

  184. Holger

    Sounds weirdo to me.

  185. jonasw

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

  186. zinid

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

  187. zinid

    do we want it?

  188. daniel

    Arguably better than tracking directed presences on the server

  189. jonasw

    zinid, don’t you have to do that anyways, because you must send unavailable when the server leaves?

  190. jonasw

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

  191. Holger

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

  192. Holger

    But I must run, BBL.

  193. zinid

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

  194. zinid

    ah

  195. zinid

    yes, it's resent on unavailable 😉

  196. zinid

    but not the original presence, but the broadcasted one

  197. jonasw

    ah I see you rpoint

  198. jonasw

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

  199. jonasw

    makes sense

  200. zinid

    yes

  201. zinid

    they can be different

  202. 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

  203. jonasw

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

  204. jonasw

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

  205. jonasw

    this is still better

  206. daniel

    Totally

  207. zinid

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

  208. zinid

    ejabberd currently rewrites it anyway

  209. jonasw

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

  210. zinid

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

  211. zinid

    jonasw, yes, but see my next point

  212. jonasw

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

  213. jonasw

    but an empty element?

  214. zinid

    so probably some mechanism to avoid injecting is needed

  215. daniel

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

  216. 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"

  217. daniel

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

  218. zinid

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

  219. jonasw

    hm

  220. zinid

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

  221. zinid

    at least from what I rememeber

  222. daniel

    An empty photo means it's empty

  223. daniel

    An empty x means something else. Lol

  224. jonasw

    yup

  225. jonasw

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

  226. daniel

    Either way it's probably better to not touch it

  227. jonasw

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

  228. 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

  229. jonasw

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

  230. jonasw

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

  231. daniel

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

  232. jonasw

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

  233. jonasw

    or maybe it is

  234. zinid

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

  235. jonasw

    I’m not sure

  236. zinid

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

  237. 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

  238. zinid

    yeah, this is bikeshedding mostly

  239. jonasw

    true

  240. zinid

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

  241. zinid

    so we work-around "transcoding" problem

  242. jonasw

    zinid, I think that’s sane

  243. zinid

    and make crypto paranoics happy

  244. jonasw

    yup

  245. 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

  246. 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?

  247. zinid

    yes

  248. zinid

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

  249. zinid

    so we don't contradict

  250. lovetox

    no avatar published if i correctly remember

  251. jonasw

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

  252. jonasw

    or de-publishing essentially

  253. jonasw

    yes

  254. daniel

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

  255. daniel

    If it exists

  256. zinid

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

  257. lovetox

    why should he do that?

  258. zinid

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

  259. daniel

    zinid: ok. Fair enough

  260. zinid

    lovetox, because some put webp into avatars 😛

  261. lovetox

    yeah and? why would the server care?

  262. zinid

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

  263. lovetox

    i think this opens a lot of problems

  264. lovetox

    we depend on hash

  265. lovetox

    i upload something, know my hash

  266. lovetox

    afterwards i get something different back

  267. zinid

    and?

  268. lovetox

    such a server mod would be bad in my opinion

  269. zinid

    what problems?

  270. zinid

    you can receive another hash from another resource for example

  271. zinid

    so a client should be prepared to receive another hash

  272. jonasw

    yup

  273. jonasw

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

  274. lovetox

    iam if its from another resource

  275. jonasw

    why would you care about the resource? :)

  276. lovetox

    i dont know, its just weird

  277. zinid

    it's xmpp

  278. lovetox

    makes no sense to me

  279. zinid

    of course it's weird

  280. jonasw

    I find this pretty elegant

  281. lovetox

    and you do this only because of conversations lol

  282. jonasw

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

  283. lovetox

    elegant is if clients support more than jpeg and png

  284. lovetox

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

  285. lovetox

    this is all BUT elegant

  286. jonasw

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

  287. lovetox

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

  288. jonasw

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

  289. jonasw

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

  290. lovetox

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

  291. 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)

  292. jonasw

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

  293. jonasw

    zinid, except that jpeg sucks

  294. zinid

    jonasw, yes, but png is really huge

  295. jonasw

    depends

  296. daniel

    Fwiw Conversations stopped uploading webp

  297. zinid

    so they both suck

  298. jonasw

    zinid, yes

  299. jonasw

    trade-offs all over again

  300. zinid

    daniel, good to know 😛

  301. daniel

    Should we create or own image format?

  302. jonasw

    daniel, like we created our own Markup?

  303. jonasw

    daniel, what does conversations do now?

  304. daniel

    Jpeg

  305. daniel

    Duh

  306. jonasw

    "meh"

  307. daniel

    Eps

  308. daniel

    Lol

  309. daniel

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

  310. jonasw

    daniel, neat!

  311. jonasw

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

  312. daniel

    It will resize it of course. But yes

  313. daniel

    Or use a different avatar

  314. daniel

    Client

  315. jonasw

    sure

  316. daniel

    To upload it

  317. zinid

    daniel, muc vcard avatars are left!

  318. zinid

    daniel, movim did it already 🙂

  319. zinid

    ejabberd supports them since stone age

  320. daniel

    zinid: is there a xep?

  321. zinid

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

  322. zinid

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

  323. zinid

    I mean how to propagate updates

  324. daniel

    'the only problem'

  325. zinid

    😀

  326. jonasw

    MIX will fix that ;-)

  327. jonasw

    we should get stickers with that

  328. zinid

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

  329. daniel

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

  330. zinid

    daniel, no, every couple of hours or so 😀

  331. zinid

    what if a presence comes from bare conference jid?

  332. zinid

    would clients get crazy because of this?

  333. jonasw

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

  334. daniel

    Conversations would just ignore it I guess

  335. jonasw

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

  336. jonasw

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

  337. zinid

    daniel, so we probably can utilize it for avatars dissemination

  338. daniel

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

  339. zinid

    PoC?

  340. daniel

    Proof of concept

  341. daniel

    Proof that it works in quick demo

  342. zinid

    and we prove it to ... ?

  343. zinid

    XSF? 🙂

  344. daniel

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

  345. daniel

    Nah the world

  346. daniel

    Or to ourselves

  347. jonasw

    do MUCs have to implement PubSub then, too?

  348. daniel

    I think we are talking about vCard avatars

  349. jonasw

    for now :)

  350. zinid

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

  351. zinid

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

  352. 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

  353. 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

  354. 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?

  355. daniel

    yes it doesn't do anything security wise

  356. daniel

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

  357. daniel

    but thats not even security by obscurity

  358. daniel

    *that you have an avatar

  359. zinid

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

  360. daniel

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

  361. zinid

    well, you can be identified by the hash 😛

  362. zinid

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

  363. 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

  364. zinid

    fine by me 🙂

  365. zinid

    thx

  366. zinid

    when approved, I'll fix that in ejabberd

  367. daniel

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

  368. 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.

  369. zinid

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

  370. zinid

    the example is clear, though

  371. daniel

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

  372. daniel

    (even though you are drunk?)

  373. daniel

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

  374. 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

  375. daniel

    fair enough

  376. zinid

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

  377. zinid

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

  378. daniel

    sending presence before receiving the iq response for the avatar

  379. zinid

    ah

  380. zinid

    good point

  381. zinid

    then it makes sense, yes

  382. 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.

  383. zinid

    yes, much more clear