jdev - 2026-02-04


  1. MattJ

    What spec are Movim/Monocles following for comments?

  2. singpolyma

    What are other people doing about this problem: <presence from muc/NICK><x xmlns=vcard-temp:x:update><photo>HASH</photo></x></presence> <iq GET VCARD TEMP /> <iq type="result"><vCard xmlns="vcard-temp"><PHOTO><TYPE>image/jpeg</TYPE></PHOTO></vCard></iq> so since I didn't get a photo, next time I get their presence they still claim they have one, and give me the hash for it, but I still don't have anything matching that hash so I fetch again... and again... and again...

  3. singpolyma

    I really wish whatever server is doing this would stop, but in lieu of that...

  4. moparisthebest

    cache the negative response for some time?

  5. moparisthebest

    or maybe forever...

  6. singpolyma

    forever would be a problem I think. but maybe "until next app start" or something yeah

  7. moparisthebest

    in theory next upload to fix it should upload correctly *then* set the new hash

  8. moparisthebest

    but yea... relying on clearly broken thing to do the right thing feels sketchy lol

  9. singpolyma

    I don't think the hash is wrong. I'm currently chasing it down but I think it's permissions related

  10. singpolyma

    yup, confirmed.

  11. singpolyma

    if avatar in prosody is set to "contacts only" then prosody always injects the hash to presence, but strips only the binary from the vcard-temp

  12. singpolyma

    if I fetch the same vcard-temp from a contact or a non-contact (including of course via a muc) it acts differently

  13. singpolyma

    which seems correct on the fetch side. but then I get this hash...

  14. jjj333_p (any pronouns)

    could that be wrong behavior on the prosody side?

  15. singpolyma

    IMHO yes it is

  16. singpolyma

    if I wouldn't allow the target jid to see the photo, then I shouldn't tell it about the photo hash in presence

  17. singpolyma

    IMHO

  18. singpolyma

    but maybe that's hard I dunno