yep, preferring that any day over the 5050-style uncommented OOB-link :)
Moumenhas joined
Moumen
hello
Moumen
i have some question about xep201
Zash
Now that's a XEP I haven't heard in a long time.
Moumen
its about replay
Moumen
msg threading
Moumen
<message
to='romeo@example.net/orchard'
from='juliet@example.com/balcony'
id='asiwe8289ljfdalk'
type='chat'
xml:lang='en'>
<body>Art thou not Romeo, and a Montague?</body>
<thread parent='7edac73ab41e45c4aafa7b2d7b749080'>
e0ffe42b28561960c6b12b944a092794b9683a38
</thread>
</message>
Moumen
here is a chat thread according to the xep
Moumen
so if there anyone know about the value of thread and different between it and msg id
Zash
Moumen: Nothing to do with message ids
Zash
Completely separate
Zash
The @parent attribute refers to the value of some other <thread>
Zash
Ie they're forking off from a <thread>7edac73ab41e45c4aafa7b2d7b749080</thread>
Moumen
oh thanks zash your replay is helpful
shachontalhas left
shachontalhas joined
Moumenhas left
machas joined
machas left
Yagizаhas left
xeckshas left
xeckshas joined
test2has joined
test2has left
sonnyhas left
sonnyhas joined
sonnyhas left
sonnyhas joined
shachontalhas left
raghavgururajanhas left
raghavgururajanhas joined
raghavgururajanhas left
raghavgururajanhas joined
shachontalhas joined
DebXWoodyhas left
raghavgururajanhas left
shachontalhas left
raghavgururajanhas joined
shachontalhas joined
Wojtek
question: how to handle situation from xep-0153 when client advertises one hash but query returns image that yields another hash? section 4.2 says that client must not advertise an avatar without downloading it first from the server (that should prevent such problem) but it seems that's not the case
Zash
I would handle it by implementing xep-0398 and just overwriting their avatar hash with the correct value.
Zash
Hm, wait, it says to not overwrite that.
Alexhas left
Beherithas left
shachontalhas left
shachontalhas joined
Wojtek
> Hm, wait, it says to not overwrite that.
not? "Presences where the content of the photo element is not empty and not equal to the hash calculated by the service MAY be overwritten."
however, this still highly depends on users server - right?
Zash
Yes, the users server does that magic based on the XEP-0084 PEP node
Wojtek
so, rule of thumb: cache what we calculate and because client can't publish correct hash with presence just re-query the vcard each time such presence is received?
Zash
Some kind of rate limit on querying for vcards perhaps?
shachontalhas left
Wojtek
well, "worst-case-scenario": we could cache the image with the hash received in presence, but I feel this is kinda wrong
Zash
Not sure what options there are if other clients are acting weird
Wojtek
if that's a mobile client I could understand not wanting to download the avatar before publishing, for example on every connection. but that just breaks things
kikuchiyohas joined
kikuchiyohas left
kikuchiyohas joined
kikuchiyohas left
Beherithas joined
kikuchiyohas joined
kikuchiyohas left
kikuchiyohas joined
kikuchiyohas left
kikuchiyohas joined
kikuchiyohas left
kikuchiyohas joined
kikuchiyohas left
kikuchiyohas joined
kikuchiyohas left
kikuchiyohas joined
kikuchiyohas left
Zash
So it's beneficial to move towards PEP Avatars and 398, as the server takes care of more of it for you.