jdev - 2024-03-10

  1. larma

    Just use AI to describe the content at the sender, then use AI to create a new image from the description at the recipient

  2. wgreenhouse


  3. MSavoritias (fae,ve)

    and then have the AI draft a reply to the message since it understands the contents anyway and it is faster :P

  4. cal0pteryx

    As a client developer, I often wish for a service/server which gives me replayable/real world scenarios I would otherwise have to create myself. This can be "give me a contact with a MAM archive containing x messages" or "simulate a typical channel with x participants sending messages occasionally" or "give me an account which has a roster containing 5k entries". Is this a thing?

  5. MSavoritias (fae,ve)

    second that. that would be amazing

  6. MattJ

    cal0pteryx: afaik only as an unpublished side project of mine. I need to find time to actually finish it...

  7. Schimon

    I am looking for organizations that provide grants to develop software related to XMPP. I was thinking of: yaxim: adding support for OMEMO, Forms and Ad-Hoc. Monal: adding support for Ad-Hoc. I would be delighted to get your help.

  8. cal0pteryx

    MattJ: ah, nice! That's some kind of Prosody module I assume?

  9. MattJ


  10. lovetox


  11. lovetox

    i fear this will run into spam problems in a MUC

  12. Zash

    can you elaborate?

  13. lovetox

    sending 10 files, means 11 messages within a second

  14. lovetox

    when does spam control stop me from sending stuff?

  15. lovetox

    i guess it depends on the settings of the MUC

  16. Zash

    rate limits more than spam

  17. Zash

    and 11 vs 10 isn't _that_ much of a difference I think

  18. lovetox

    i think you misread

  19. lovetox

    there is no "vs"

  20. lovetox

    i said, 10 files, need 11 messages to be sent

  21. lovetox

    or are you comparing to the state without the new XEP?

  22. Zash

    compared to the current oob way it would be 10 files in 10 messages

  23. Zash

    so yes

  24. lovetox

    true, its not mich difference to now, except its a bit harder to interpret the errors, now its pretty clear what message failed, its a user facing message that i can attach a error too, and the user can decide to send it again

  25. lovetox

    now we are talking about messages that are not user facing that fail

  26. lovetox

    so probably i should add some automatic retry stuff?

  27. Zash

    letting someone send 10 files in 1 message would probably also require tweaking of the rate limits in some way

  28. lovetox

    maybe i should limit the files that can be sent in MUCs, to 5 or something

  29. lovetox

    or what is a common default rate limit for a muc?

  30. Zash

    not sure, it tends to be always wrong so gets tweaked until a balance is found, the exact values would depend on how many participants there are and how active they are and and and etc

  31. Zash

    can you catch the errors, slow down and retry?

  32. lovetox

    of course .. i take this into consideration from the beginning

  33. lovetox

    kind of treating the first message with the metadata like a start of a filetransfer

  34. lovetox

    with progress indicator, and then wait for other messages to arrive

  35. lovetox

    or something like this

  36. singpolyma

    I would do multiple files in one message if we're going to do it at all, honestly

  37. lovetox

    ... to late, its in the XEP someone will do it, its even RECOMMENDED

  38. singpolyma

    Which xep?

  39. lovetox


  40. singpolyma

    Which is what?

  41. Zash

    poor fallback for the oob-only clients?

  42. lovetox

    XEP-0447: Stateless file sharing

  43. singpolyma

    Oh I see. Hopefully no one implements SFS :/

  44. lovetox

    i dont see much difference to sims, its just this attaching of sources feature

  45. singpolyma

    and the NIH namespaces

  46. lovetox

    it makes the implementation, waaay more complex

  47. lovetox

    thats nothing you later just simply add ..

  48. lovetox

    this feature is not even mentioned in the introduction or requirements

  49. lovetox

    it makes it possible that other people can attach sources, and we can do some kind of torrent thingy where we can pull a file from multiple sources

  50. lovetox

    but was that a problem that needed solving? Because as it is now, this additional feature make the XEP way more difficult to implement

  51. singpolyma

    I would suggest to do sims and then there are others to test with anyway

  52. lovetox

    how would you do sending a collection of photos in sims?

  53. lovetox

    simply adding more media-sharing elements?

  54. lovetox

    not sure how i can stay compatible with clients which dont implement SIMS, how can i allow the user to add a custom body to the message, but still send the link in the body ..

  55. singpolyma

    Custom body + link in body use the fallback xep

  56. singpolyma

    And yeah collection with sims or oob is the same, add multiple elements

  57. singpolyma

    Note I'm doing body+oob/sims+falback sometimes already, I haven't actually done the multiple attachments thing in practise yet

  58. lovetox

    i dont understand, how can a body be a description of a image, and at the sametime a fallback with only a link?

  59. lovetox

    ah, just remembered the fallback xep

  60. singpolyma

    Yeah, fallback xep marking the part that is the url

  61. lovetox

    ah wait no this does not work ..

  62. lovetox

    ok it would break the stuff with body same as oob

  63. lovetox

    but i dont really need to care about that

  64. lovetox

    user gets the link

  65. singpolyma


  66. lovetox

    so we can do everything with 0385 that 0447 can do (minus the attaching sources)

  67. lovetox

    0447 looks in my opinion better designed, cleaner overall, but at the cost of splitting filetransfers into multiple messages

  68. lovetox

    which increases complexity by a lot

  69. singpolyma

    I certainly don't feel it's better designed, but this is a matter of taste :)

  70. lovetox

    the XEP certainly is better written and more complete, as it mentions all the important fallback and backwards compatibility cases

  71. singpolyma

    Ah, editorially you mean.

  72. lovetox

    SIMS seems a bit abondoned and more like "you will figure it out yourself"

  73. singpolyma

    Im not sure if the author is still around but I'm happy to do some polish on it based on implementations etc if there's desire for thad

  74. singpolyma

    Im not sure if the author is still around but I'm happy to do some polish on it based on implementations etc if there's desire for that

  75. lovetox

    the jingle namespace to define metadata is also .. hacky

  76. lovetox

    lets turn this around, what exactly design wise do you not like about 0447?

  77. lovetox

    as i read it is mostly a bit of a cleanup of SIMS, of course the attaching thing is something that can be discussed as not needed

  78. singpolyma

    Wortt thing is is makes up new namespaces for stuff we already had. Vs sims which reuses properly

  79. singpolyma

    Like using the jingle metadata namespace, which you seem to find hacky

  80. lovetox

    from a spec design point of view this seems the much more clean, why would i reuse a jingle namespace for something that is not necessarily jingle

  81. lovetox

    do you really think there are developers out there that think, oh no i cant reuse my super complex jingle metadata function

  82. lovetox

    do you really think there are developers out there that think, oh no i cant reuse my super complex jingle metadata parsing function

  83. singpolyma

    The whole point of using XML is this kind of

  84. lovetox

    jingle is 15 years old, we try to define a new standard for filesharing, adding a new dedicated independet metadata XEP seems to be an obvious decision

  85. lovetox

    but ok lets agree to disagree on that point, at least thats not a reason to not implement that

  86. MSavoritias (fae,ve)

    for what its worth i would love to see more integration with "native" xmpp like jingle in stuff

  87. lovetox

    the use of data-url in 0447 seems to be also a much better decision and flexible for all kind of HTTP stuff in the future

  88. lovetox

    but i think thats it, the differences are not big, as i said, overall cleaner bit more thought through, more flexible at times for future usecases or extensions

  89. lovetox

    of course the big thing is, the attaching sources makes it not at all trivial to implement anymore

  90. lovetox

    i would be happy if that could be factored out into its own XEP, because i dont believe this is something that sees a wide adoption and is probably a bit scary

  91. lovetox

    but seems we as a community still have not settled, i think i need to think of a way how to make SIMS work but in a way that i can also later make SFS make work

  92. moparisthebest

    > for what its worth i would love to see more integration with "native" xmpp like jingle in stuff What, what makes "jingle" "native" vs any other XEP ?

  93. singpolyma

    moparisthebest: jingle can for example operate with only an xmpp connection

  94. singpolyma

    While also supporting other transports suh as http of course

  95. singpolyma

    While also supporting other transports such as http of course

  96. singpolyma

    It is also jid-aware so can do authz

  97. moparisthebest

    point is that anything that is a XEP is "xmpp native" whether it uses other protocols or not, and jingle certainly does

  98. singpolyma

    Sure, jingle optionally negotiates non xmpp stuff for sure, no argument from me

  99. singpolyma

    Some XEPs contain zero xmpp things, like colour generation 😉

  100. moparisthebest

    "native" doesn't even really make sense when the entire protocol has "extensibility" in the name lol

  101. moparisthebest

    literally https://en.wikipedia.org/wiki/No_true_Scotsman

  102. singpolyma

    I mean it was an expression of preference so I don't think scotsman applies 😛

  103. moparisthebest

    well it is because the next (and previous) thing was "if it uses https it's not *true*(or *native*) XMPP" lol