jdev - 2026-01-31

  1. theTedd

    So, technically yes, but it wouldn't be a big problem if you didn't

  2. vpzom

    I mean, it seems reasonable to do, except that I don't see how to mark it as a fallback

  3. singpolyma

    > right. so is there a standard for that specific method? Both oob and sims are XEPs yes ↺

  4. singpolyma

    > i also ask once again if there seems to be any consensus on sfs vs sims. iirc lovetox talked about implementing sfs in gajim I don't understand why SFS even exists. It's just sims but less modular ↺

  5. singpolyma

    > When replying to a message, should I include the fallback quote in the XHTML-IM body too? You would need to specify a way to do fallbacks for XHTML-IM first. I would support this but haven't proposed the change to the xep and for now I don't do it ↺

  6. singpolyma

    My idea would be to extend fallback indication with like a <html id=blah> sort of indicator

  7. jjj333_p (any pronouns)

    > I don't understand why SFS even exists. It's just sims but less modular fair enough, ill trust your lead on this one ↺

  8. jjj333_p (any pronouns)

    theoretical question, kinda just a curiosity, is there any reason that you couldnt reply to a message in a muc pm, kinda achieving the whatsapp reply privately feature?

  9. jjj333_p (any pronouns)

    and less importantly, by extension couldnt you also do a private reaction that way

  10. jjj333_p (any pronouns)

    also is there any necessity for muc pms to show up as a direct message rather than just a specially noted message in the muc chat itself?

  11. moparisthebest

    there's no necessity to show anything any way other than how you want you ✎

  12. moparisthebest

    there's no necessity to show anything any way other than how you want to ✏

  13. jjj333_p (any pronouns)

    that is fair

  14. moparisthebest

    Conversations shows them like i think you mean

  15. jjj333_p (any pronouns)

    imo it would be clearer ux

  16. jjj333_p (any pronouns)

    > Conversations shows them like i think you mean yeah i vaguely remember that ↺

  17. jjj333_p (any pronouns)

    idk i dont use android. tbh considering installing conversations and or cheogram in waydroid for compatibility testing as i leave minimum viable product territory for my bridge

  18. lovetox

    > I don't understand why SFS even exists. It's just sims but less modular you can read this in the first section of the XEP - No focus on media, generic for every file type. - Body can be used for fallback. - Using File metadata element (XEP-0446) - Using XML for structured data instead of URIs when possible, adding further extensibility (like providing proper means of sharing encrypted files on http servers). - Not relying on underspecified usage of References (XEP-0372) ↺

  19. lovetox

    and the first point is reason enough for me alone to favor SFS

  20. lovetox

    One is a "I want to share pictures, lets write a XEP to share pictures" -XEP The other is a XEP written in a generic fashing to solve a broader problem of sharing files

  21. lovetox

    Is the outcome of using both to share a picture in practice much different? No. But from a standards design view of the protocol, this is a obvious choice for me

  22. sunglocto

    so which one to implement lol

  23. sunglocto

    or... both?

  24. jjj333_p (any pronouns)

    That makes sense to me, though i suppose for my purposes with the bridge, ill probably for now implement sims since that more accurately matches the matrix implementation, and cheogram and i think dino use that for now, and i assume slixmpp has modules for both probably anyways so its probably fine i can switch later

  25. lovetox

    how does it match the implementation?

  26. jjj333_p (any pronouns)

    > or... both? tbh this was kinda my thought, send both, and probably parse the more verbose / detailed one first and fall back ↺

  27. jjj333_p (any pronouns)

    > how does it match the implementation? matrix only really provides metadata for images and videos ↺

  28. jjj333_p (any pronouns)

    and audio i suppose

  29. lovetox

    and?

  30. lovetox

    you can do both with SFS and SIMS

  31. jjj333_p (any pronouns)

    also the second hand of my statement was that i only so far have heard of clients now implementing sims, and i expect i can switch at a later date

  32. jjj333_p (any pronouns)

    or probably use both

  33. jjj333_p (any pronouns)

    though at some point we have to be concerned with bloating up the mam db

  34. lovetox

    as far as i know, dino implements sfs and sends sims for compatibility

  35. lovetox

    other clients i saw that support SFS is Kaidan

  36. lovetox

    then there is cheogram with SIMS, and more clients i dont know about

  37. sunglocto

    oh so SFS is basically just SIMS++

  38. lovetox

    jjj333_p (any pronouns), you can switch later, are you storing these elements in a database?

  39. jjj333_p (any pronouns)

    i remember being told monocles sending sims is why gajim wont embed media from it, but i dont know the accuracy

  40. jjj333_p (any pronouns)

    > jjj333_p (any pronouns), you can switch later, are you storing these elements in a database? currently im only sending xep006, which both of these xeps fallback to, and is entirely adequate. Im talking about implementation details for bridging new messages ↺

  41. sunglocto

    i mean correct me if i'm wrong but shouldn't monocles be using OOB in normal circumstances?

  42. jjj333_p (any pronouns)

    > i mean correct me if i'm wrong but shouldn't monocles be using OOB in normal circumstances? both sims and sfs have a oob (0066) fallback afaik ↺

  43. lovetox

    sunglocto, thats the thing also with SIMS, it cannot fall back to the old approach

  44. jjj333_p (any pronouns)

    > sunglocto, thats the thing also with SIMS, it cannot fall back to the old approach i thought it could? ↺

  45. lovetox

    as the old approach defines that the body needs to be the url, and SIMS wants the body to be text the user attaches to the picture

  46. lovetox

    you cannot have both

  47. jjj333_p (any pronouns)

    > as the old approach defines that the body needs to be the url, and SIMS wants the body to be text the user attaches to the picture i would like to remind that this is nowhere in the spec, this is based on an arbitrary decision by conversations devs, and it simply doesnt define how to handle when its not ↺

  48. lovetox

    yes and still it is possible to design a spec who considers that

  49. jjj333_p (any pronouns)

    the approach that singpolyma told me should be compatible with cheogram even for 0066 would be to simply provide a fallback range element for the oob embed, and everything else should get displayed

  50. jjj333_p (any pronouns)

    I also think it would be fine to if all else fails show the body including the url and an embed at the same time

  51. lovetox

    its not possible with fallback indication or not, to make it compatible to url+body which many clients support now

  52. lovetox

    you can design all kind of new ways to send a fallback, sure, but it will not be what clients use today

  53. lovetox

    your options are to simply say, i dont care, or use SFS

  54. jjj333_p (any pronouns)

    I dont understand why youre being so argumentative

  55. lovetox

    i thought this was a discussion pro/cons SFS vs SIMS

  56. lovetox

    both sides present arguments, at the end you can decide

  57. jjj333_p (any pronouns)

    yes, something that should be a relatively calm argument. but youre over here telling me what my opinions are and talking in very tilted language

  58. lovetox

    can you point to the section where i told *you* what *your* opinion is?

  59. jjj333_p (any pronouns)

    > your options are to simply say, i dont care, or use SFS ☝️ ↺

  60. lovetox

    how is this about opinions? this is a technical problem, and i iterated the options i think you have

  61. lovetox

    feel free to prove me wrong, and name a third option

  62. sunglocto

    i'm a bit confused. is out of band media (XEP-0066) a legacy format?

  63. jjj333_p (any pronouns)

    > i'm a bit confused. is out of band media (XEP-0066) a legacy format? you can imagine based on the xep number its pretty old. the only options to replace it are both experimental (well sims is deferred which is experimental but 12+ months old) ↺

  64. jjj333_p (any pronouns)

    afaik gajim doesnt _currently_ support anything other than oob (0066), as well as many other clients/bots/etc

  65. jjj333_p (any pronouns)

    unfortunately, given the state ios clients are in and my lack of an android (until i set up waydroid), gajim is most of my perspective on actually using xmpp at the moment

  66. sunglocto

    hmm ok so i should probably implement either sfs or sims if that's the case

  67. sunglocto

    i thoughts sfs and sims were fallbacks that were only used if HTTP File Upload was unavailable

  68. sunglocto

    and also for embedding shit like stickers

  69. jjj333_p (any pronouns)

    no, sfs and sims are embedding standards

  70. jjj333_p (any pronouns)

    theres other xeps for uploading media, but they arent commonly used nowdays, and it consists of p2p things like jingle

  71. jjj333_p (any pronouns)

    also afaik 0066, sims, and sfs all work with any uri based media source, with i think sfs or sims or both allowing multiple options to source the same file

  72. lovetox

    jjj333_p (any pronouns), do you store the metadata in a database?

  73. jjj333_p (any pronouns)

    Also the reason i started this conversation is i kinda wish the ecosystem would coalesce to one or both

  74. jjj333_p (any pronouns)

    > jjj333_p (any pronouns), do you store the metadata in a database? not currently, though the bridge is currently in active development and what is stored in the database changes every time i find time to work on it ↺

  75. jjj333_p (any pronouns)

    i mean it still has hardcoded addresses

  76. lovetox

    my only concern for implementors is, that SFS may need a different database layout than SIMS

  77. lovetox

    if you just transform xml and forward, just implement one, the work to transform to the other is minimla

  78. jjj333_p (any pronouns)

    we've discussed this before, but i still think storing the original xml is a good idea, and if/when i work on my own client would plan to do so

  79. lovetox

    not sure how that helps you

  80. jjj333_p (any pronouns)

    not much in this scenareo

  81. lovetox

    the point is still that you need to change the dabase layout once you support SFS

  82. lovetox

    you can design a database layout that supports SFS and SIMS at the same time

  83. jjj333_p (any pronouns)

    > the point is still that you need to change the dabase layout once you support SFS for the bridge? probably not as i wouldnt expect to be sending the actual message multiple times ↺

  84. lovetox

    thats what im trying to say, if you add a db layout, consider both

  85. lovetox

    and you will be fine

  86. jjj333_p (any pronouns)

    im so confused, for a bridge it doesnt need to store the data of either, at most a hash for deduplication which can be stored and computed irrelevant from this (also matrix doesnt hold such hashes, so in this case i would have to for the only time im actually handling the media itself)

  87. lovetox

    if you dont have a db storage, the discussion we had here are longer than to implement a transform from sims to sfs and back

  88. jjj333_p (any pronouns)

    > if you dont have a db storage, the discussion we had here are longer than to implement a transform from sims to sfs and back im so confused ↺

  89. jjj333_p (any pronouns)

    why am i resending the stanza that is now handled by the muc service / mam service

  90. lovetox

    i lost you there

  91. jjj333_p (any pronouns)

    also for now heres the only database table the bridge uses, i doubt ill ad much to this one but ill prob add other tables as i add configuration. i called it media_mappings but all messages get stored here for id translation:

  92. jjj333_p (any pronouns)

    https://downloadable.pain.agency/file_share/019c132f-7de9-7950-8f3b-76f19b0e3547/2cc2467c-845b-42d1-9236-4f7e5e34ee23.png

  93. jjj333_p (any pronouns)

    also a lot of that data is computed by the bridge, all the metadata im considering bridging is simply translating what is provided in the matrix event

  94. lovetox

    maybe lets start again I assume you are a developer implementing something with xmpp I assume you come to this channel and ask about SFS/SIMS to not put work towards a solution which will not be used in the future by many clients So what im trying to do is, help you to make that decision. What i said is if you dont have a db layout, it does not matter to talk about this much, because you just transform incoming xml and forward it. Implementing SIMS and later in a year decide you want to support additional SFS is probably done in an hour, as both formats are *very* similiar. If you have a database and store the data, you need to look at both XEPs and design your layout in a way that it supports both going forward. This makes it so you also have limited impact if you switch later

  95. jjj333_p (any pronouns)

    > maybe lets start again > > I assume you are a developer implementing something with xmpp > I assume you come to this channel and ask about SFS/SIMS to not put work towards a solution which will not be used in the future by many clients > > So what im trying to do is, help you to make that decision. > > What i said is if you dont have a db layout, it does not matter to talk about this much, because you just transform incoming xml and forward it. > Implementing SIMS and later in a year decide you want to support additional SFS is probably done in an hour, as both formats are *very* similiar. > > If you have a database and store the data, you need to look at both XEPs and design your layout in a way that it supports both going forward. This makes it so you also have limited impact if you switch later I'm asking for consensus mostly, the immediate use case, which i think i mentioned at some point but if not my bad, is for a bridge as i only want to add support that will get used right now, and at the end of the day falling back to 0066 is good enough. by the time im working on an application where storing matters, i expect either things to change, or more likely ill attempt to support both for the sake of it ↺

  96. jjj333_p (any pronouns)

    basically im hoping that if i discuss it, that everyone will start to agree, since currently it seems that most implementations dont consider compatiblity with other clients (this is a common stereotype people use against xmpp, and seems to mainly happen in cases like these)

  97. jjj333_p (any pronouns)

    also for when i implement shit, i kinda wanna know what is preferred by other clients, i.e. which would i try to display from first

  98. lovetox

    i dont think we will reach a consensus on this topic by talking

  99. lovetox

    only by implementations

  100. jjj333_p (any pronouns)

    > only by implementations we have implementations ↺

  101. lovetox

    seems not enough that you feel save to make a decision

  102. jjj333_p (any pronouns)

    > That makes sense to me, though i suppose for my purposes with the bridge, ill probably for now implement sims since that more accurately matches the matrix implementation, and cheogram and i think dino use that for now, and i assume slixmpp has modules for both probably anyways so its probably fine i can switch later ????? ↺

  103. jjj333_p (any pronouns)

    also as far as i can tell, as with seemingly a lot of things, only gajim is being a stick in the mud

  104. jjj333_p (any pronouns)

    maybe dino too, but dino follows gnome policy of remove 2 features every release

  105. lovetox

    i hold my options open, what we discuss here is my opinion about two specs

  106. lovetox

    i can hate a spec, but still implement it, if it has enough value for users

  107. jjj333_p (any pronouns)

    > i hold my options open every conversation i have with you, is an argument, and not because of me

  108. lovetox

    that maybe, but dont take it personally :)

  109. jjj333_p (any pronouns)

    its just fucking exhausting when its really not that deep, and it would be so much more productive to just i dont know discuss shit normally

  110. lovetox

    you are exagerating

  111. lovetox

    dont see what is exhausting about this discussion

  112. jjj333_p (any pronouns)

    🤦‍♂️

  113. sunglocto

    oh i have a question, is it reccomended to show all joins and leaves in a muc? i thought that maybe i should only show like member changes with a high priority like someone's role/affil changing or getting banend from the room

  114. lovetox

    you specifically pinged me

  115. lovetox

    i can retreat from this discussion if its exhausting for you

  116. jjj333_p (any pronouns)

    its okay, im retreating, i got shit to do

  117. lovetox

    let do some shit :)

  118. jjj333_p (any pronouns)

    ill make sure to put spaces in your nick next time

  119. lovetox

    sunglocto, if you show joins and leaves i would recommend to show them aggregated

  120. lovetox

    otherwise your whole chat will just be joins and leaves

  121. sunglocto

    yeah that seems like a good idea

  122. lovetox

    btw i just googled "stick in the mud" someone who is old-fashioned and too serious and avoids enjoyable activities

  123. jjj333_p (any pronouns)

    > btw i just googled "stick in the mud" > > someone who is old-fashioned and too serious and avoids enjoyable activities the way i meant it was more like http://stick-in-the-mud.urbanup.com/6858296 ↺

  124. lovetox

    ah yeah makes more sense in the context of a client

  125. lovetox

    its not so much as resisting change, with media sharing, more its a bigger effort client wise to support, there is a lot more to think about for a client than just a bit of xml interpretation

  126. lovetox

    thats why i ponder on this for quite a while

  127. lovetox

    and that specifically makes me uneasy with specs that focus on one aspect (audio / video / image) instead of specifing a broarder solution

  128. jjj333_p (any pronouns)

    I get the pondering, my point is more the insistence on being inflexible for seemingly no reason (i.e. even if traditionally 0066 required body = url, it might make sense to still allow embedding attached to the message, similarly to how you see with newly supported url previews)

  129. jjj333_p (any pronouns)

    my point isnt resistance to new things, my point is the insistence on a small world view when pondering, and then being stuck in that way

  130. jjj333_p (any pronouns)

    you say your opinions remain open, but the way you speak seems differently

  131. jjj333_p (any pronouns)

    such things require not such defensiveness

  132. lovetox

    i think you misunderstand me, if we talking about specs i want to clearly bring to the table and discuss pros and cons, every spec has them. And we need to clearly understand what they are to make an informed decision. there is no need for me for flexibility in this discussion. Either something supports a proper fallback and is backwards compatbile or not. Spelling that out, does not automatically favor one over the other. At the end we will decide on a spec and live with the spelled out cons.

  133. jjj333_p (any pronouns)

    > there is no need for me for flexibility in this discussion. Either something supports a proper fallback and is backwards compatbile or not. i strongly disagree on this point

  134. jjj333_p (any pronouns)

    while what you send should probably fit the spec as accurately as you can, i think when displaying things to the user, you should do your best to interpret the content as richly as possible, without information loss

  135. jjj333_p (any pronouns)

    theres no reason not to, when things not related to like authentication or state are involved

  136. jjj333_p (any pronouns)

    when its basically just formatting (i consider media embedding kinda just formatting) being pedantic only creates a poor ux for frankly no reason

  137. jjj333_p (any pronouns)

    i'll also note that i think its important to avoid information loss at all costs, hence why we had that discussion-come-argument about gajim eating messages with incorrect fallback ranges

  138. lovetox

    which spec loses information?

  139. lovetox

    or i dont understand how the conversation got to this

  140. jjj333_p (any pronouns)

    we've left the discussion of sims/sfs tbh. idk im trying to get some common ground because it doesnt seem like we're going to get anywhere discussing anything if we dont

  141. jjj333_p (any pronouns)

    in terms of loosing information, i was referring to reply fallbacks

  142. jjj333_p (any pronouns)

    where curently if the fallback is longer than the message, gajim just eats the message ✎

  143. lovetox

    but how do they factor into the SIMS/SFS discussion?

  144. jjj333_p (any pronouns)

    where curently if the fallback is longer than the message, gajim just eats the message, showing no trace of even an empty message ✏

  145. jjj333_p (any pronouns)

    > but how do they factor into the SIMS/SFS discussion? your argument is that the way monocles (and i guess sims) operate break compatibilty because it doesnt strictly follow the pseudo-spec which oob has been implemented into gajim with ↺

  146. jjj333_p (any pronouns)

    when you could easily while still following the actual spec, create better ux and this wouldnt be a discussion

  147. jjj333_p (any pronouns)

    i.e. if body != url, display the body with a media embed, and the user will probably assume the url belongs to the attached file

  148. lovetox

    ok i understand, you think this is about Gajim. I was discussing two specs on its merit, Gajim is irrelevant for me for the discussion

  149. lovetox

    what gajim will do, or could do, is irrelevant when discussing if a spec is a good spec and solves a problem in a good way

  150. jjj333_p (any pronouns)

    while im using gajim's implementation for context, as i assume you are familiar with its behavior, im still arguing that the fallback to body + url in the <body/> element is sufficient fallback

  151. jjj333_p (any pronouns)

    while your argument is that it is not

  152. lovetox

    no that was not my argument, you cannot do a body + url fallback with SIMS

  153. lovetox

    because the body is meant to be used to add context to your file transfer

  154. lovetox

    OR you argue that it is not, that the body should always be the url with sims for compatibility reasons

  155. lovetox

    then i would argue, SIMS just lost the capability to add context to your filetransfer

  156. jjj333_p (any pronouns)

    interesting, i went and rered the spec

  157. jjj333_p (any pronouns)

    i would expect you could add a fallback element to take care of the url being in the body, though that is in fact not apart of the spec at this time

  158. lovetox

    and also would not work, because the fallback element would be for clients that suppor tsims ✎

  159. lovetox

    and also would not work, because the fallback element would be for clients that support sims ✏

  160. lovetox

    so clients that do not support sims, again dont know what to do with it

  161. jjj333_p (any pronouns)

    i think body + url is a fine fallback mode, if clients supporting xep0066 didnt require body = url, which again is an artificial requirement due to the spec not specifying how to handle it

  162. jjj333_p (any pronouns)

    which takes us back to the start where i think in the case of xep0066, if url != body you then embed the url as an embed and show the entire body, as a soft failure mode

  163. lovetox

    yes but its the world we live in, again im saying this is not a show stopper for me, it just needs to be part of discussion to layout this facts clearly to know what we lose or gain if we do it that way

  164. lovetox

    it could well be a decision to say, dont bother about the few clients that implemented body=url logic

  165. lovetox

    and move on

  166. jjj333_p (any pronouns)

    i guess for context, the way i see it, not embedding the url at all i see as loss of information, and i think arent strictly following the xep and as such, such behavior can be considered irrelevant

  167. jjj333_p (any pronouns)

    this is of course assuming that sims had a fallback element, which it doesnt

  168. lovetox

    i also think that the fallback discussion is less important as factor for me

  169. jjj333_p (any pronouns)

    > i also think that the fallback discussion is less important as factor for me to me its very important, again i think information loss should be minimized at all costs ↺

  170. lovetox

    the more important point for me is, that the SIMS xep just focuses on media

  171. jjj333_p (any pronouns)

    lets just xkcd927 ourselves and make a forth xep :troll:

  172. jjj333_p (any pronouns)

    why does

  173. jjj333_p (any pronouns)

    https://downloadable.pain.agency/file_share/019c1360-5705-7487-bebc-4b88343bfb0b/7dd35cd9-d0a7-4293-b484-ea4d67c420bd.png

  174. jjj333_p (any pronouns)

    its an exact keyword match

  175. lovetox

    there would be no information loss, as you can include a fallback indication and put simply the url + text into the body

  176. lovetox

    its just that you break a convention that existed for a long time

  177. lovetox

    and probably make it a bit less nice for people using these clients

  178. jjj333_p (any pronouns)

    > there would be no information loss, as you can include a fallback indication and put simply the url + text into the body you can argue with me on this point, but i consider not also embedding it to be loss of the information if it being an attached file ✎ ↺

  179. lovetox

    as a sending client im not responsible how your client displays something

  180. jjj333_p (any pronouns)

    > there would be no information loss, as you can include a fallback indication and put simply the url + text into the body you can argue with me on this point, but i consider not also embedding it to be loss of the information of it being an attached file ✏ ↺

  181. lovetox

    https://www.example.com look at this url

  182. lovetox

    did you now just lose information?

  183. lovetox

    because i didnt include a oob element

  184. jjj333_p (any pronouns)

    > as a sending client im not responsible how your client displays something sure, but as a recieving client, you should attempt to display it as richly as possible ↺

  185. jjj333_p (any pronouns)

    > because i didnt include a oob element no, because example.com is not a file you intended to attach to the conversation ↺

  186. lovetox

    so think of it linking to a file

  187. jjj333_p (any pronouns)

    at least to me theres semantic differences

  188. jjj333_p (any pronouns)

    hold for 30 minutes, i have an assignment due at midnight that i mangaged to not do for an hour and a half

  189. lovetox

    yeah i need to go shopping

  190. lovetox

    i will be back in the afternoon

  191. jjj333_p (any pronouns)

    > so think of it linking to a file my argument is that theres a semantic difference between an attached file and a linked file ↺

  192. jjj333_p (any pronouns)

    also for context > the meaning or relationship of meanings of a sign (such as a word or morpheme) or set of signs https://www.merriam-webster.com/dictionary/semantics

  193. jjj333_p (any pronouns)

    similarly to how theres a semantic difference between a quote and a reply, or a reaction and a reply

  194. jjj333_p (any pronouns)

    anyways brain fuzzy, will come online in the morning

  195. singpolyma

    >> I don't understand why SFS even exists. It's just sims but less modular > you can read this in the first section of the XEP > > - No focus on media, generic for every file type. > - Body can be used for fallback. > - Using File metadata element (XEP-0446) > - Using XML for structured data instead of URIs when possible, adding further extensibility (like providing proper means of sharing encrypted files on http servers). > - Not relying on underspecified usage of References (XEP-0372) Using the file metadata element is one of the biggest problems with SFS yes. instead of reusing existing elements it invents a new one ↺

  196. singpolyma

    > One is a "I want to share pictures, lets write a XEP to share pictures" -XEP > The other is a XEP written in a generic fashing to solve a broader problem of sharing files This seems like an uncharitable reading of the xeps at best. They are identical ↺

  197. singpolyma

    > as the old approach defines that the body needs to be the url, and SIMS wants the body to be text the user attaches to the picture You can do this with sims and most current sims implementations do this? I'm sometimes not doing this even with oob but not in any release grade client yet ↺

  198. singpolyma

    > oh i have a question, is it reccomended to show all joins and leaves in a muc? i thought that maybe i should only show like member changes with a high priority like someone's role/affil changing or getting banend from the room This is a UX question so basically the answer is do whatever you want 🙂 whatever makes sense in your context. Which probably is best known by you. Different apps do different things here ↺

  199. singpolyma

    >> but how do they factor into the SIMS/SFS discussion? > your argument is that the way monocles (and i guess sims) operate break compatibilty because it doesnt strictly follow the pseudo-spec which oob has been implemented into gajim with If monocles does this is is their choice, not related to sims. Body of url fallback is fine and normal with sims ↺

  200. sunglocto

    > This is a UX question so basically the answer is do whatever you want 🙂 whatever makes sense in your context. Which probably is best known by you. Different apps do different things here mpted ✎ ↺

  201. sunglocto

    > This is a UX question so basically the answer is do whatever you want 🙂 whatever makes sense in your context. Which probably is best known by you. Different apps do different things here noted ✏ ↺

  202. lovetox

    > This seems like an uncharitable reading of the xeps at best. They are identical If those 2 are identical then it seems you dont care about the details anyway, so why have a strong opinion about it? ↺

  203. singpolyma

    They are identical in functionality. Which is exactly why I am grumpy that we have two competing XEPs where one just copied the other and changed the xmlns :P