jdev - 2024-08-15

  1. singpolyma

    No, the fallback just says that the body is just a fallback and not to use it (or that part of it is)

  2. ubq323

    i see

  3. ubq323

    well, i think

  4. ubq323

    anyway, it would be nice if there was somewhere where things like this were documented

  5. ubq323

    it's not obvious to anyone implementing xep-0066 that you need the url and message body to match

  6. ubq323

    (in fact, that xep contains an example where they directly don't)

  7. singpolyma

    Well, you don't

  8. singpolyma

    You just do if you want certain clients to behave in certain ways. Arguably those clients are wrong

  9. Schimon

    I would be thankful if anyone, who is familiar with 4.5 Node Access Models, would guide me and test whether this is implemented correctly on Blasta. https://xmpp.org/extensions/xep-0060.html#accessmodels ✎

  10. Schimon

    Good day! I would be thankful if anyone, who is familiar with 4.5 Node Access Models, would guide me and test whether this is implemented correctly on Blasta. https://xmpp.org/extensions/xep-0060.html#accessmodels ✏

  11. Schimon

    https://xmpp.pimux.de/file_share/a1ff98f3-612b-4926-8ae2-7e725720fd76/scrot-rofi_20240815-123353.png

  12. Schimon

    Is it possible to make an item, of an open node, private by setting Affiliation? https://xmpp.org/extensions/xep-0060.html#affiliations

  13. ubq323

    singpolyma: well, i do want clients to behave in certain ways. why else would i even be implementing this spec?

  14. ubq323

    i agree that it's unfortunate when actual implementations differ from the prescribed spec

  15. ubq323

    it'd still be nice to have somewhere where this difference can be documented though, that's all i'm saying

  16. lovetox

    ubq323, but thats kind of a recipe for failure, you writing code in your client in the hope that a different client behaves in a certain way

  17. ubq323

    if i stick exactly to the spec then the client doesn't do what i want

  18. ubq323

    if i add the extra restriction, that the two things must match, then the client does do what i want

  19. lovetox

    not sure i get you, 0066 is a spec to communicate a link

  20. ubq323

    certain clients display the image as a nice embed

  21. ubq323

    rather than just rendering the url

  22. lovetox

    but thats not the idea of the spec and none of its goals

  23. ubq323

    the ones i have tested on, only do this when the <body> of the message exactly matches the <url>

  24. lovetox

    a transport protocol spec does not mandate how a client need to build his GUI

  25. ubq323

    well, is there another spec specifically for telling clients to display images inline?

  26. lovetox

    why do you want to mandate how my GUI looks like from your remote client?

  27. ubq323

    i want images to display inline in my client

  28. lovetox

    just communicate the information that you want to communicate, and let clients do what they feel is best

  29. lovetox

    ubq323, then programm a client that displays images inline when it receives a link via oob

  30. lovetox

    you are talking about stuff that you want *other* clients do

  31. ubq323

    surely the purpose of a chat protocol is to specify what thnigs you want to appear on other people's screen?

  32. lovetox

    Oo not at all .. not sure where you get this idea from

  33. ubq323

    like, sending an image to someone is quite a common thing to do

  34. ubq323

    why must it be so difficult to do that?

  35. lovetox

    its not difficult, send the information .. and thats what the spec is for

  36. lovetox

    if you are not happy what a client does with this information, file a feature or bug request on their tracker

  37. ubq323

    it doesn't seem so unreasonable to me to have a spec specifically for displaying images inline

  38. ubq323

    maybe we just disagree on the goals and scope of xmpp

  39. ubq323

    to put it another way: many clients implement displaying images inline. the purpose of specifications is to standardize client behavior. therefore, it seems like a good idea to standardize exactly how to get clients that support this feature to display things inline

  40. ubq323

    if the spec just says "here is a way to, abstractly, transfer information about out-of-band files; clients can interpret that how they want", and then clients interpret it differently, then what's the point in having a spec in the first place?

  41. Kev

    > the purpose of specifications is to standardize client behavior Well, no. The purpose is to allow interop.

  42. ubq323

    what does interop mean to you?

  43. lovetox

    transfering information in a standardized and well defined way

  44. lovetox

    would be my guess

  45. lovetox

    you give me the informations i need, but its still my decision what i do with it, and the goal of XMPP is to transfer the information, not tell a client how it displays it to the user (at least in most cases)

  46. lovetox

    we have multiple terminal clients, guess what they cannot display images ..

  47. lovetox

    but thats fine, because they users chose the client knowing about that

  48. lovetox

    and users that want to have images displayed inline, will maybe choose your client, because thats what you do

  49. ubq323

    i see your point

  50. ubq323

    i still think it would be good if the clients that did display images inline, documented the precise circumstances under which they do that

  51. lovetox

    the way some clients do it now is a historical hack, that all just did without much asking why

  52. lovetox

    im perfectly fine with removing that hack in Gajim to be honest

  53. ubq323

    is there a more modern way to do the same thing?

  54. lovetox

    yes there are a few competing xeps let me look them up

  55. lovetox

    https://xmpp.org/extensions/xep-0385.html

  56. lovetox

    https://xmpp.org/extensions/xep-0447.html

  57. lovetox

    but support for them varies greatly

  58. lovetox

    but at least one of the two is the future where everything migrates to

  59. lovetox

    this is a federated environment, you will never achieve that every client does what you want

  60. lovetox

    i would concentrate to try to do the right thing, and discuss with other developers, so they eventually will also do the right thing

  61. ubq323

    that's understandable

  62. lovetox

    sometimes this means, you are the first one that does the right thing

  63. lovetox

    but often it needs someone to start, and then others follow :)

  64. lovetox

    or you show users how something looks good, and then those users bug other developers and tell them, hey look client X does this really nice

  65. lovetox

    but anyway, the whole oob thing is not a thing to be proud of in the community and definitly something we should get rid of

  66. lovetox

    you are not the first one to notice that

  67. ubq323

    that makes sense

  68. ubq323

    thanks for explaining

  69. singpolyma

    > im perfectly fine with removing that hack in Gajim to be honest Would be nice ↺

  70. moparisthebest

    > we have multiple terminal clients, guess what they cannot display images .. lovetox: no longer true https://github.com/hackerb9/lsix šŸ˜ ↺

  71. jonasā€™

    moparisthebest, but none of the clients implements sixels, do they?

  72. moparisthebest

    No idea, just pointing out that they could (:

  73. MattJ

    Didn't Link Mauve implement it for poezio? or was that something else?

  74. jonasā€™

    no I think that was simple ANSI-block-graphics with colours

  75. MattJ

    ubq323, https://docs.modernxmpp.org/client/protocol/#communicating-the-url

  76. jonasā€™

    I don't think it was sixels

  77. jonasā€™

    (and that never hit mainline I think)

  78. moparisthebest

    Wow I was only vaguely aware of sixels but had no idea it was defined in 1988 ? TIL

  79. singpolyma

    Yeah there have been forks of eg w3m with graphics for a long time

  80. jonasā€™

    `mpv --vo=sixel --really-quiet` if you like to watch movies really choppily in your terminal

  81. MSavoritias (fae,ve)

    ah of course mpv supports that