jdev - 2024-03-18


  1. nicoco

    Hey all. https://xmpp.org/extensions/xep-0447.html#multi-file defines out to send multiple files in a single message and https://xmpp.org/extensions/xep-0447.html#sims how to do SFS and SIMS at the same time. So, the million dollar question is: can I send multiple files in a single message as recommended, and still be compatible with SIMS? My understanding right now is that this isn't possible, can someone confirm?

  2. singpolyma

    nicoco: you can, though no client supports it yet

  3. singpolyma

    I plan to add support

  4. nicoco

    singpolyma: mmmmmmmm so I would add a `<reference>` with several `<media-sharing>`s in the first message (photo1-3.jpg), but then the `adding-photo[1-3]` following messages would need to specify that they are fallbacks for SFS *or* SIMS. Is this done by adding two `<fallback>` elements, one for SFS, the other for SIMS? Is that legal?

  5. singpolyma

    I think it would be one reference per media-sharing (unless we get rid of the reference thing, which has been talked about but no one supports yet)

  6. singpolyma

    And yes, two fallback elements with different for=

  7. singpolyma

    honestly I mostly use fallback for=jabber:x:oob but I should support for=sims as well obvioulsy

  8. singpolyma

    honestly I mostly use fallback for=jabber:x:oob but I should support for=sims as well obviously

  9. lovetox

    can it make sense to parse multiple fallback elements as receiving clients?

  10. lovetox

    or would this be always a OR condition?

  11. singpolyma

    yes, multiples

  12. singpolyma

    for example if there is a reply and also a sims :)

  13. lovetox

    hm, how would that work, the fallback body for reply would probably reference a quoted section? and what would the fallback body reference then for sims?

  14. lovetox

    would then not both result in a different body after i cut whatever fallback?

  15. singpolyma

    so for example: > some reply some text https://some.sims.example.com fallback for=reply, snip quote fallback for=sims, snip URL final body if supporting both: some text

  16. lovetox

    hmm .. how would you propose to process this as receiving client

  17. lovetox

    should i check if i support the fallback namespace and then cut the text and throw away whats not needed immediately?

  18. lovetox

    or somewhere store the original text?

  19. lovetox

    i think there is no reason to store the fallback text in the database ..

  20. nicoco

    > And yes, two fallback elements with different for= Oh, this was the part I wasn't sure about. Thanks for the replies! Slidge will do multiattachment SIMS+SFS with oob fallbacks the way it's exemplified if the SFS XEP then

  21. lovetox

    so not with a single message?

  22. lovetox

    because i see no example of multi files in a single message in the XEP, in fact it recommends to use multiple messages to "attach" sources

  23. singpolyma

    > should i check if i support the fallback namespace and then cut the text and throw away whats not needed immediately? up to you of course. I err on the side of storing more, but either can work

  24. singpolyma

    lovetox: it suggests that for sources, but not for the images themselves. and adding all sources up front is allowed (and required for sims of course)

  25. lovetox

    a message without source is useless

  26. lovetox

    the example shows sending only metadata without sources and recommends to send sources in different messages

  27. lovetox

    all good, just wanted to note that the XEP does not have an *example* written down of what nicoco wants to do

  28. lovetox

    i agree it should be fine with the current XEP text

  29. nicoco

    > so not with a single message? lovetox: with a single message + the "extra" messages indeed, but at least we have a way to mean to the XMPP clients "this is meant to be a single message" which has implications for replies, reactions, retractions…

  30. nicoco

    > so not with a single message? lovetox: with a single message + the "extra" messages indeed, but at least we have a way to indicate to the XMPP clients "this is meant to be a single message" which has implications for replies, reactions, retractions…

  31. lovetox

    now im confused, so you want to send extra source attaching messages?

  32. lovetox

    how would a client that supports only SIMS recognice the source attaching messages as something he does not need to display?

  33. singpolyma

    well they would be messages with only sfs stuff in it

  34. singpolyma

    oh I see, but if it has seperate fallbacks

  35. singpolyma

    yeah

  36. singpolyma

    using the extra messages is going to be messy

  37. lovetox

    447 should define the attching source only for additional sources, and mandate that at least one source needs to be always in the original message

  38. lovetox

    that way some weird feature where people want to do some torrent kind of thing, is still possible

  39. lovetox

    but you can implement the spec perfectly fine without supporting that

  40. lovetox

    i probably know what larma wanted to achieve, to have a fallback for multi files, which would need multiple messages as fallback

  41. lovetox

    i find this unnessary complex to stay backwards compatible with some hack that someone sometime thought of (body = oob )