moparisthebesthey I prefer a straightforward spammer
jonas’yep, preferring that any day over the 5050-style uncommented OOB-link :)
Moumenhas joined
Moumenhello
Moumeni have some question about xep201
ZashNow that's a XEP I haven't heard in a long time.
Moumenits about replay
Moumenmsg 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>
Moumenhere is a chat thread according to the xep
Moumenso if there anyone know about the value of thread and different between it and msg id
ZashMoumen: Nothing to do with message ids
ZashCompletely separate
ZashThe @parent attribute refers to the value of some other <thread>
ZashIe they're forking off from a <thread>7edac73ab41e45c4aafa7b2d7b749080</thread>
Moumenoh 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
Wojtekquestion: 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
ZashI would handle it by implementing xep-0398 and just overwriting their avatar hash with the correct value.
ZashHm, 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?
ZashYes, the users server does that magic based on the XEP-0084 PEP node
Wojtekso, 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?
ZashSome kind of rate limit on querying for vcards perhaps?
shachontalhas left
Wojtekwell, "worst-case-scenario": we could cache the image with the hash received in presence, but I feel this is kinda wrong
ZashNot sure what options there are if other clients are acting weird
Wojtekif 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
ZashSo it's beneficial to move towards PEP Avatars and 398, as the server takes care of more of it for you.