jdev - 2020-10-07

  1. mrsanjaya06

    HELLO EVERYBODY

  2. mrsanjaya06

    DO I CAN SELL CREDIT CARD HERE ?

  3. ralphm

    Bye

  4. o2

    real subtle

  5. moparisthebest

    hey I prefer a straightforward spammer

  6. jonas’

    yep, preferring that any day over the 5050-style uncommented OOB-link :)

  7. Moumen

    hello

  8. Moumen

    i have some question about xep201

  9. Zash

    Now that's a XEP I haven't heard in a long time.

  10. Moumen

    its about replay

  11. Moumen

    msg threading

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

  13. Moumen

    here is a chat thread according to the xep

  14. Moumen

    so if there anyone know about the value of thread and different between it and msg id

  15. Zash

    Moumen: Nothing to do with message ids

  16. Zash

    Completely separate

  17. Zash

    The @parent attribute refers to the value of some other <thread>

  18. Zash

    Ie they're forking off from a <thread>7edac73ab41e45c4aafa7b2d7b749080</thread>

  19. Moumen

    oh thanks zash your replay is helpful

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

  21. Zash

    I would handle it by implementing xep-0398 and just overwriting their avatar hash with the correct value.

  22. Zash

    Hm, wait, it says to not overwrite that.

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

  24. Zash

    Yes, the users server does that magic based on the XEP-0084 PEP node

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

  26. Zash

    Some kind of rate limit on querying for vcards perhaps?

  27. Wojtek

    well, "worst-case-scenario": we could cache the image with the hash received in presence, but I feel this is kinda wrong

  28. Zash

    Not sure what options there are if other clients are acting weird

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

  30. Zash

    So it's beneficial to move towards PEP Avatars and 398, as the server takes care of more of it for you.