XSF Discussion - 2023-07-28

  1. 高杰1510

    I have a question that how to encrypt message in chat room?

  2. moparisthebest

    高杰1510: what client

  3. nicoco

    in the User Avatar XEP: > one of the formats MUST be "image/png" to ensure interoperability. Are there really devices/clients that only understand png and not jpg? Or am I misunderstanding what interoperability means in this context? Slidge is complying to that btw, but I realized that existing clients are largely tolerant to jpeg-only avatars, and I want to understand the rationale here.

    👍 1
  4. lovetox

    PNG is better in every regard or not

  5. lovetox

    And even back then it was widely adopted across the internet landscape

  6. lovetox

    So why settle on somethin older?

  7. edhelas

    JPG and GIF are from 1987, PNG 1995

  8. nicoco

    Hum I just realized that PNG compression could be lossy, I didn't even know.

  9. nicoco

    Thanks for the replies

  10. edhelas


  11. edhelas


  12. lovetox

    And please don't get the idea that the standard allows to publish multi format. This will not work. The XEP is a bit bad written in this regard.

  13. nicoco

    https://xmpp.org/extensions/xep-0084.html#examples-multiple ??

  14. edhelas

    I think XMPP should stick with MP3 and MPEG2, its goodenough and it was widely adopted across the internet landscape.

  15. edhelas


  16. nicoco

    I'm interested by your remark lovetox since offering multiformat was precisely what I had in mind?

  17. lovetox

    nicoco: ah sorry it was multi size

  18. lovetox

    So multi size for the same content type or something

  19. Zash

    Why not?

  20. lovetox

    I can't go into it I'm on the phone

  21. nicoco

    Multi-size is forbidden?

  22. lovetox

    It's because of the metadatanode id

  23. lovetox

    It's a hash of only one picture

  24. lovetox

    Now you can think how that works for notifications

  25. lovetox

    Clients will not pick up changes to the metadata node because the hash never changes

  26. lovetox

    So yes you can put everything in there but don't expect it to work

  27. lovetox

    It's simply not thought through and I'm sure it moved to stable before anyone implemented that part

  28. edhelas

    To me that part looks fine

  29. Zash

    And which client is it using uuid as metadata node id?

  30. nicoco

    But the notification itself contains the different formats, so I'm not sure I follow? <items node='urn:xmpp:avatar:metadata'><item id="hash of the PNG"><metadata><info of the png version/><info of another larger png version/><info of a jpeg awful version/>

  31. edhelas

    You can have a small mandatory PNG of 32x32 and then put the large format in JPG next to it no ?

  32. Zash

    And which client is it using uuid as metadata item id?

  33. lovetox

    edhelas: do you support multi formats?

  34. edhelas

    The existing clients ones will pick the 32x32 PNG and the other ones can pick the larger pictures

  35. lovetox

    Does anyone know of a client who does?

  36. edhelas

    lovetox I don't, but I could

  37. lovetox

    Yeah that probably everyone said 😜

  38. edhelas

    I'm not even respecting the PNG format, I'm just pushing a large JPEG

  39. lovetox

    I wait until someone has implemented it

  40. edhelas

    Because large PNG are just too big, and compressed they look awful.

  41. lovetox

    nicoco: anyway my advice is, publish a single picture

  42. edhelas

    350x350 JPG 95 I do

  43. lovetox

    Until you find at least a impl who supports that

  44. nicoco

    For context, telegram always provides avatar as "large", "small" and "thumbnail", all jpg. Right now I convert to PNG and that's it, but I'm think I should also provide the 3 other versions since it does not even require conversion, just serving. Even though gateways shouldn't dictate our specs, it can be seen as a nice playground I think, so I'm inclined to do that, and I think edhelas wants to try with movim :). It would also make sense to provide a http url which I think no client use either.

  45. edhelas

    HTTP URL can be cool as well, doing async avatar downloading <3

  46. lovetox

    That would violate the standard

  47. lovetox

    > where the "image/png" content-type is available only at the data node

  48. lovetox

    No sorry

  49. lovetox

    That's just a description of the example

  50. lovetox

    Not a normative text

  51. lovetox

    And it seems even wrong because the example offers the PNG over http

  52. nicoco

    not wrong, there is also the "main" PNG without url in the exemple

  53. nicoco

    but it's weird that there is another with the exact same "bytes", "width", and "height" but a different hash

  54. opal

    >hierarchical and free for all are not the only choices though. a community can still make their space safe without having a single dictator or an oligarchy. you misunderstand, i'm talking for myself, and i said i have trust problems

  55. opal

    i'm not putting words into anyone else's mouths here when i say what's on my mind for it

  56. opal

    no selection of moderators makes me feel safer than an unmoderated room, thats just how i am

  57. opal

    i hate power plays

  58. MSavoritias fae.ve

    it seems we are talking past each other because i didnt mention about any moderators needed. but anyway..

  59. opal

    i cant know what you did mention, only what you wrote

  60. opal

    but yeah like i said this is just me talking with my head in the clouds, it has no relevance to current xmpp

  61. theTedd

    wrt Avatars: the document initally only allowed PNG, so it's required as the definitive version of the image; if there are multiple image formats, which one should provide the item id -- still the png version is definitive, so its hash is used; what if you have multiple png images of varying sizes -- only one can have its data stored in the node, and thats the definitive version

  62. edhelas

    I was wondering if it could be possible to publish several avatars (as different items in urn:xmpp:avatar:metadata), then a use could upload several pictures on its profile

  63. edhelas

    This could allow having a kinda "gallery" feature, same as Telegram

  64. edhelas


  65. theTedd

    I'm not saying it's impossible, but that was never intended in this case, and a new XEP would be advised

  66. lovetox

    Thanks theTedd, I could not remember exactly what the problem was I just knew it had to do with the jash

  67. lovetox

    Thanks theTedd, I could not remember exactly what the problem was I just knew it had to do with the hash

  68. lovetox

    So this means one can provide all kind of format and sizes, but they all have to use different delivery methods like http

  69. theTedd

    That's the idea, yes

  70. Zash


  71. theTedd

    Hm hm?

  72. Zash

    Who says you can only store one item?

  73. theTedd

    The intention was that you'd have one png version in the data node

  74. Zash

    They're referenced by the id attribute of the <info> element, what stops you from having multiple formats and resolutions?

  75. theTedd

    The data node is identified by the item id, which uses the sha1 of the png version, even if other versions are available; you could add multiple data nodes, but they would be seen as separate images (different item id)

  76. Zash

    It would seem logical to me to store each image under the hash of itself in the data node, then reference them in the meta node by id.

  77. theTedd

    Of course that would be logical, but that's not what XEP-0084 says 😋

  78. Zash

    Ah under https://xmpp.org/extensions/xep-0084.html#proto-data

  79. Zash

    Seems inconsistent with https://xmpp.org/extensions/xep-0084.html#proto-info then

  80. singpolyma

    On format notes: pretty sure Conversations often uses only jpeg for avatar. PNG is always going to look nicer of course, but for photos can be quite large.

  81. Zash

    Didn't it use WebP for a while

  82. Zash

    Didn't it use WebP for a while?

  83. singpolyma

    It can. That's a hard coded setting

  84. Zash

    > id A hash of the image data for the specified content-type

  85. singpolyma

    If you use the animated avatars support in cheogram Android it will use webp or gif also

  86. theTedd

    The xep originally only support png/mng, and later extended to allow for others, so we could choose to see it as an editing lapse and 'fix' it 😉

  87. Zash

    > Of course that would be logical, but that's not what XEP-0084 says 😋 combined with people already violating the PNG-only requirement, let's change the XEP to make more sense?

  88. theTedd

    It's Stable, so as long as nothing breaks as a result, I don't see a problem

  89. Zash

    People publish JPEG without breakage apparently

  90. theTedd

    Clients just take whatever is there, and of course they supprot jpeg

  91. singpolyma

    Anecdotally most clients seem to support webp and gif just fine too

  92. Zash

    not my experience with webp

  93. theTedd

    Android clients will support webp since it's provided by the os, others may struggle

  94. Zash

    Anyone aware of a page like https://developer.mozilla.org/en-US/docs/Web/Media/Formats/Image_types but covering a wider (than browsers) scope?

  95. moparisthebest

    https://en.wikipedia.org/wiki/Comparison_of_graphics_file_formats#Technical_details ?

  96. Zash

    I'm thinking of platform support

  97. moparisthebest

    https://docs.unity3d.com/Manual/class-TextureImporterOverride.html#texture-compression-support-platforms ? Probably not :) I'm guessing you aren't gonna find that outside a particular standard or implementation

  98. Zash

    "Can I use" for XMPP!

  99. singpolyma

    > Android clients will support webp since it's provided by the os, others may struggle Any gtk based one too, so long as the webp decoder is installed

  100. Zash

    That's not my experience at all, but that was from a few years ago.

  101. Zash

    When there were barely CLI tools available on Debian

  102. Zash

    Probably better now

  103. Zash

    I'd expect PNG and JPEG to work *everywhere* tho, so having some recommendation of having at least one widely-supported in a good enough resolution seems sensible

  104. Zash

    And put that <info> first for compatibilty

  105. Zash

    And then publish whatever formats and resolutions you want, within reason.

  106. 高杰1510

    moparisthebest: monocles

  107. Trung

    +8K .dng for stills. +4K +120fps DNxHD/444 for flicks.

  108. moparisthebest

    高杰1510: then you'll need to join or start a private chat then turn on OMEMO on that screen