XSF Discussion - 2020-02-05

  1. winfried

    Zash: free and open flu?

  2. flow

    more like: free andn openly distributed epidemic

  3. dwd

    Yeah, kind of wishing this were a more restrictive licence.

  4. Guus

    How are you feeling today, dwd ?

  5. dwd

    Terrible. But nothing that can't be fixed. Doctors coming later this morning.

  6. ralphm

    I hear Guus lost 3 kg, so look on the bright side :/ Hope you feel better soon.

  7. Guus

    (almost 4, actually)

  8. Guus

    I hope you feel better soon, Dave.

  9. Guus

    when did this start? Only after you got back?

  10. eevvoor

    my colleague lost purse and smartphone on the way back of FOSDEM. He travelled the whole monday due to lost identity. But he is healthy.

  11. pep.

    I was surprised at some point because my bag had been moved from one place behind the booth to another part of the booth (behind the Matrix people!!) and under a pile of bags :x

  12. ralphm

    pep., you're welcome. I think I've made it clear the lounge was not a bag storage facility, so I regularly moved stray bags there.

  13. pep.

    I probably wasn't there when you said that, but ok

  14. ralphm

    I think I mentioned it at the Summit, too, but no worries.

  15. intosi

    That's something we say every year, in quite some abundance.

  16. ralphm

    Most of them were from the Matrix people.

  17. pep.

    intosi, not all of us have been involved for the same amount of time

  18. pep.

    Also that's a FOSDEM-specific thing, because I've been running other conferences and it usually works well that way :)

  19. ralphm

    Having bags behind a booth is typical indeed, but destroys the concept of a lounge. That's why I mentioned it at the end of the summit.

  20. ralphm

    (there were other factors that caused the lounge to not work this year, but that's a different discussion that I don't have time for to go into now)

  21. Guus

    https://xmpp.org/extensions/xep-0424.html section 5: > Some clients may have been offline while the retraction was issued. The archiving service therefore MUST store the retraction message, regardless of whether the original message is deleted or replaced with a tombstone. This adds a server-sided restriction to this otherwise client-sided XEP, which I dislike. If the MAM implementation on the server does not follow this, retraction is very flaky (MAM retrieval will return the original message, but not the retraction). However, server support is not clearly signalled for in the XEP (service discovery examples imply that only partners are queried). Am I missing something?

  22. Guus

    (as the retraction message has no body, that message might not be archived by MAM implementations that are not aware of XEP-0424)

  23. pep.

    Maybe adding a store hint to the XEP would help?

  24. flow

    but aren't hints deprecated?

  25. larma

    flow, it's deferred

  26. Ge0rG

    but it was very much disliked by the Council that decided on it last time

  27. larma

    There is no replacement for it other than fallback bodies which is stupid for things like retraction really

  28. ralphm

    larma: fwiw, so is MAM itself (deferred) :-D

  29. Ge0rG

    there were two issues with Hints: a) you can't properly add hints later on; b) each hint has implications to a certain other XEP, and thus should better be described in that "master" XEP

  30. larma

    what do you mean by a)? And I agree to b) but that just means we need to update MAM instead of saying we don't do hints anymore

  31. Ge0rG

    larma: 334 contains the exhaustive list of hints. If you add a new hint, you need to version-bump Hints

  32. Ge0rG

    and if you don't version-bump, you can't have hints with new semantics that require special processing

  33. ralphm


  34. MattJ

    or just make another XEP with whatever other hints

  35. Ge0rG

    "Hints 4, this time it's serious"?

  36. pep.

    MattJ, same issue?

  37. MattJ

    What issue?

  38. MattJ

    The whole point is btw that they are "hints", it's meant to not be a disaster if they aren't followed

  39. pep.

    Not saying I understand what Ge0rG is saying, but bumping a XEP or creating a new one is technically equivalent in general

  40. MattJ

    They are also meant to be semantic, rather than tied to specific protocols

  41. Ge0rG

    pep.: with a new XEP, you don't auto-deprecate the old one, so you end up with five different Hints XEPs that all contain different hints

  42. MattJ

    So no-copy is not tied to Carbons, but any copying-to-other-resources mechanism

  43. pep.

    Ge0rG, even better!? :p

  44. larma

    Usually the hint should be in the XEP it belongs to, but now MAM and carbons don't have hints and those in 334 are widely supported and thus a de-facto standard. Also moving <store /> to MAM would mean that any other archiving XEP would need to redefine it and we'd need two hints. So at least for <store /> and related hints we should stay with the current

  45. Ge0rG

    pep.: so why not have each hint in the XEP that contains the actual processing semantics that are affected by the hint?

  46. Ge0rG

    larma: Carbons do have their own "hint"

  47. pep.

    Ge0rG, sure. It's not what I was replying to

  48. Ge0rG

    but I think that Carbons and MAM are actually good causes to fix message routing and persistence semantics, i.e. IM 2.0

  49. larma

    We started this discussion about store hint 😉

  50. Ge0rG

    msg to bare --> persistent, copy-everywhere message to full --> ephemeral, no Carbon, no MAM, no offline store

  51. ralphm

    We at some point tried to have comprehensive processing rules (https://xmpp.org/extensions/xep-0079.html, AMP) and that was a bit of a failure.

  52. Guus

    > There is no replacement for it other than fallback bodies which is stupid for things like retraction really I don't know if this is so stupid. It would make the retraction visible even to clients that do not support it - which makes a huge difference in semantics. Additionally, adding such a body has the side effect of the retraction having a better chance of being archived by existing MAM implementations.

  53. larma

    Ge0rG, I'd be fine with that, but legacy clients do send to full jid so we need to handle them (if we don't want a new IM network that is independent of the current)

  54. pep.

    Guus, how do you want to show retractions to clients that don't support it?

  55. pep.

    "The message you're still seeing above -- because I don't support retraction -- has been retracted" ?

  56. Guus

    pep. basically. I'd include a copy of the retracted body, prefixed with 'retracted' or something.

  57. Guus

    it can be ugly

  58. Guus

    that, if anything, motivates client developers to add support. 🙂

  59. pep.

    It is to me, and also useless

  60. Ge0rG

    larma: yes, there would be tagging of IM 2 zones, and conversion from / to hints or somesuch at the 'border'. Incidentally, the same rules as discussed will apply there.

  61. pep.

    Guus, you'd be helping the spammer to spam :P

  62. Ge0rG

    Guus: that's a nice reminder to screenshot the messages!

  63. Guus

    Definitely not useless. A client that receives a retraction, but does not support _or_ show it through a fallback, is dangerous.

  64. Guus

    both chat participants will have a very different understanding of the correspondence state.

  65. pep.

    Guus, how is it dangerous

  66. pep.

    I think we get into social territory, and I'd rather not

  67. Guus

    If I send you a bunch of messages, and retract one, and I am not aware that your client does not display the fact that I retracted that one message, very nasty stuff can happen.

  68. larma

    Ge0rG, so we do need hints, we just want to get rid of them longerm. Can we please stop with longterm being a reason to do stupid things now?

  69. pep.

    Guus, I could say the same of every single feature that's socially used in context.

  70. pep.

    I still use presence information and talk about it sometimes, should I put that as fallback body somewhere?

  71. Guus

    no, this is not a social thing

  72. Guus

    this is a semantic thing

  73. Ge0rG

    larma: what if we want to use longterm to not do stupid things now?

  74. Guus

    you, as a receiver, missed the fact that I, as the sender, changed the semantics.

  75. pep.

    You removed a spam message for convenience. It's fine if I still see it.

  76. Guus

    spam, sure

  77. pep.

    Or you removed information that I wasn't supposed to see, well too bad.

  78. Guus

    why would I delete my own spam, btw?

  79. pep.

    Not your own

  80. moparisthebest

    also true of any "styling" XEPs right? changed meaning and all that

  81. Guus

    you can only retract your own messages with that XEP, afaik.

  82. pep.

    Ah ok I had moderation in mind, similar case

  83. larma

    Ge0rG, we agree that longterm we do the IM 2 network without (or with less) hints and that the IM Legacy network that we are using now needs hints, so why is that a reason to deprecate hints when it is needed for the network we use now?

  84. Guus

    The fact that the receiver does not get that the information that was not ment to be sent is removed, makes the sender unaware of the fact that it was not ment to see that information.

  85. Guus

    that really has very nasty real-world problems.

  86. larma

    deprecation before replacement sounds like a stupid concept for me

  87. Guus

    If will lead to situations where people do not _trust_ the messages they receive from XMPP.

  88. Guus

    and that is killing.

  89. Ge0rG

    larma: I told you the reasons I remember for Council not advancing hints.

  90. pep.

    I don't really agree with this assessment

  91. Guus

    pep. suffer from it once, and you will. Trust me on that one.

  92. pep.

    [citation required]

  93. larma

    Ge0rG, I wasn't specifically talking about you, but more about what seems to be a general thing in XSF (there also were voices to deprecate OMEMO without replacement etc)

  94. pep.

    - I don't like XXX - Oops that wasn't for you - retracted: I don't like XXX

  95. pep.


  96. Ge0rG

    larma: regarding Hints, I even do agree with the argumentation

  97. Guus

    pep. now imagine that you didn't type "- Oops that wasn't for you"

  98. pep.

    Guus, so you see twice "I don't like XXX" in clients that don'T support it?

  99. Guus

    (why would you type that, if you expect the receiving entity to receive the retraction)

  100. pep.

    Very much fixing the issue

  101. Guus

    You see: - I dont like XXX - RETRACTED: I dont like XXX which is ugly as hell, but at least has the correct, intended, semantic value.

  102. pep.

    How does that help with anything

  103. pep.

    Now you've seen twice that XXX (potentially YOU), I don't like.

  104. Guus

    For clients that do not support the XEP, the message has been displayed at least once anyways, so there's little additional harm.

  105. pep.

    For clients that do support it the message may be removed, so the fallback is useless

  106. Guus

    If you don't include the fallback message in the retraction, the receiving entity might be completely unaware that the message is retracted.

  107. Guus

    Those would only see: - I don't like XXX

  108. Guus

    (no retraction)

  109. larma

    Guus, same as if the retraction message got lost 😉

  110. larma

    legacy clients might not be doing MAM

  111. Guus

    yes, so make sure that the retraction message never gets lost, by adding a fallback body. That way, XEP-support clients will remove/hide the retracted message, while clients that do not support the XEP can at least be trusted to 'receive the meaning'.

  112. Guus

    this is not a MAM issue.

  113. Guus

    the fact that it also makes it more likely that MAM implementations might behave a bit better is a nice side-effect.

  114. Guus

    the fact that it also makes it more likely that existing MAM implementations might behave a bit better is a nice side-effect.

  115. larma

    if my legacy client does not do mam/carbons it is likely to happen that this client does not receive the retraction message at all

  116. pep.

    I really don't like how we've been shoving everything into <body/> lately. This is of course not as bad as 393, as there would be a tag alongside (and hopefully the message would only be used for this), but it seems to be a trend anyway that everything and anything needs to appear in body as well

  117. larma

    let's call my legacy client pidgin, which apparently is the most popular XMPP client

  118. pep.

    It's like we're trying to write protocols on top of XMPP's <body/>

  119. Guus

    we can think of all kinds of situations in which this still would not work - but at the very least, it'd be a considerable improvement of not doing a fallback.

  120. Guus

    pep. I'm very much with you that this is ugly.

  121. Guus

    but I think it is necessary.

  122. pep.

    I don't

  123. Guus

    a situation in which a message was retracted by the sender, without the recipient being aware of it, must be avoided.

  124. larma

    Guus, I believe that those clients that work proper today (= not Pidgin and other legacy clients) will support retraction soonish once it's a stable standard

  125. Guus

    larma: we cannot have an ecosystem that is intentionally broken for some clients, and which is constantly waiting for the more modern clients to pick up the newer features (being broken untill they do).

  126. Guus

    we must have a decent fallback.

  127. Guus

    that's why it's called just that, a fallback.

  128. larma

    Guus, we already broke Pidgin effectively

  129. pep.

    Also these fallback things force any implementation to support things they wouldn't want to support

  130. Guus

    They don't force you to do anything

  131. pep.

    In a way yes. Now you're sending me that ugly RETRACTED: foo

  132. pep.

    Or > foo\n<reaction>, or.. some other fallback

  133. Guus

    I stand by my point that it is so much better to show that ugly message instead of receiving a retraction that your client completely ignores.

  134. Guus

    That's simply dangerous

  135. Guus

    ideally, the recipient shouldn't receive the retraction at all, of course, using service discovery. But how does that work with a user that uses two different clients, of which just one supports retractions?

  136. pep.

    Yes the "send everything to all clients because MAM/carbons" argument

  137. Guus

    I need to get back to work.

  138. larma

    (completely unrelated) I started to look into issues of XEP-0385 because of Stickers. My proposed changes are now rather substantial (I'd even want to change the title), should I maybe better make a new XEP instead?

  139. flow

    larma, i'd present the "new" xep the community and potentially council and see if there is a clear opinion on that

  140. flow

    also maybe reach out to Tobias the xep385 author

  141. Tobias

    larma, what kind of issues?

  142. larma

    Tobias, - Focus on media, not generic for any file type - Mixed content, body can not be used as a fallback - Depends on jingle file transfer for the metadata - Uses underspecified URIs - Uses XEP-0372 in underspecified fashion - Number of MUSTs that seem odd to me (must support http file upload and jingle ft, must specify description, media-type and hash)

  143. Tobias

    larma, media basically is any file format, not? i mean images, photos, videos, pdf, etc.. I don't see it limiting the kind of data you share...it only makes recommendations for video/images with regard to what should be supported so there is some interoperability.

  144. Tobias

    underspecified URIs?

  145. Tobias

    you mean these https://tools.ietf.org/html/rfc6920 ?

  146. larma

    It says "inline media sharing" which kind of implies that I can't use it to share an executable for example. The use cases literally only say how to share and receive a photo

  147. larma

    I was referring to the jingle pub uris which can hardly be used for file transfer because they just share a jingle session, but don't specify what those jingle sessions actually are. The client has to guess that it probably is the latest iteration of Jingle File Transfer

  148. larma

    (my proposal changes it to use the jinglepub element defined in XEP-0385 which allows providing a jingle description element)

  149. Tobias

    protocol wise there is nothing limiting the kind of things you can share, might as well share exe, zip, .iso images or whatever.... sure maybe examples are missing but i just went with the most common use case, of sharing audio/video/images.

  150. Tobias

    defined in 385 or 358?

  151. larma

    358, sorry

  152. Tobias


  153. larma

    I am not saying those can't be addresses in 385, but the changes are rather significant. Also the fact that you could use it for every file type IMO doesn't change the intention. The fact that there are SHOULDs for media codecs is an issue for a generic file transfer XEP

  154. Tobias

    the SHOULDs are there for interoperability in user interface

  155. larma

    Tobias, which are only needed for media, not for files

  156. Tobias


  157. larma

    which makes it unsuited for file transfer

  158. ralphm

    larma: FWIW, I didn't consider XEP-0385 to be limited to photos, videos at all. At VEON we considered it for all kinds of static media, as is mentioned in this XEP's introduction.

  159. Tobias

    i don't see how making recommendations for increased interop leads to it being unsuitable to share PDF, ISO, or whatever

  160. ralphm

    larma: On top of that, it is useful to define MTI codecs for common media you can show inline.

  161. larma

    Tobias, because those are SHOULD, which means I as a client SHOULD have a good reason to not implement those codecs

  162. larma

    The codecs are there because you do imply a user interface (that displays the media inline, as it says in the title). If I don't want to use this, many things in this XEP become obsolete

  163. ralphm

    I do have some concerns with this spec though: I'm not convinved about the 'inline' part, and its reliance on References in the way it is currently done. I think I'd rather have References optional and as a sibling. The inline nature is then also optional (for when you refer to a URL to a picture that is then included in the message, much like Twitter's media entities).

  164. larma

    This is what I'd like to have: https://gist.github.com/mar-v-in/48e0f3466871e6e149d166ad71728d1f

  165. ralphm

    larma: but you agree that having a list of MTI codecs doesn't prevent /other/ types of media to be transferred as 'other files'?

  166. Tobias

    for me it's kind of obvious that if you don't support inline display at all, the MTI recoomendations don't matter

  167. larma

    ralphm, I am not saying it does prevent that, it's just that the overall tone of the XEP is "use this to share media that is displayed inline" instead of "use this to share files"

  168. ralphm

    larma: I like the example, and think that's how XEP-0385 should work. Optionally with References to mark-up the text in the body.

  169. ralphm

    larma: right

  170. Daniel

    > This is what I'd like to have: https://gist.github.com/mar-v-in/48e0f3466871e6e149d166ad71728d1f +1

  171. Tobias

    i imagined that clients either get it via HTTPS or by https://xmpp.org/extensions/xep-0234.html#requesting from some JID

  172. ralphm

    larma: note that I had a similar usage in my blog post https://ralphm.net/blog/2019/09/09/fastening

  173. ralphm

    (scroll down to the image of a mouse)

  174. ralphm

    (although it is all inside in references, I don't think it has to)

  175. ralphm

    (although it is all inside in references, because it is referring to the previous message, I don't think it has to)

  176. jonas’

    > This is what I'd like to have: https://gist.github.com/mar-v-in/48e0f3466871e6e149d166ad71728d1f +1, though a mechanism for thunbnails would be good

  177. ralphm

    jonas’, that example has a thumbnail?

  178. Tobias

    jonas’, you could just have a 2nd file-transfer element in there for the hash of the thumbnail

  179. larma

    jonas’, I was thinking about thumbnails. Best thing I guess would be to use something like ppm in a data uri, but unfortunately most clients probably wouldn't support ppm out of the box and I think it doesn't even have a mime type

  180. jonas’

    ralphm: right.

  181. jonas’

    however, having two different syntaxes for mimetype etc is weird

  182. jonas’

    sibling file elements would make more sense? would also allow for alternative mime types for the same thing (embedded video for example)

  183. larma

    I was thinking of additional thumbnail as in blurha.sh-like thumbnails

  184. ralphm

    Unfortunately SIMS doesn't explicitly point to https://xmpp.org/extensions/xep-0264.html, but it is exactly what Tobias said.

  185. Tobias

    jonas’, kind of... but with the idea of SIMIS ( hashes of media/files + metadata + source ) it should be easy to extend it to provide sources for the hash of the thumbnail

  186. larma

    according to xep-0264, If the URI scheme is 'cid:' then the identifier MUST refer to a bit of binary data as described in Bits of Binary (XEP-0231) [1]

  187. larma

    so transport is already defined for 264 thumbnails

  188. ralphm

    The nice thing about XEP-0264, I think, is that it builds on Bits of Binary (XEP-0231).

  189. ralphm

    And then have an external storage for the actual, larger, media.

  190. larma

    The problem with bob thumbnails is that even those are pretty large for some networks (like mobile when you are throttled to 64kbit/s it can be a significant delay to fetch such image first)

  191. ralphm

    larma: if we'd add some kind of identifier to individual <media-sharing/> elements, then you could have a sibling references element to mark up the URL in the body, together with earlier suggestions I made with of having proper child elements in references instead of the current 'type' attribute: <reference start="0" end="100" xmlns="urn:example:reference:0"> <media id="[the id here]"/> </reference>

  192. Tobias

    my motivation for 285 was mostly to have a protocol describing what is shared and less so how (because there have been numerous file transfer protocols in the past). Furthermore, by making it content based (via secure hashes) you can easily cache things or have a small reference to the media in MAM where you know in a couple years that this messages includes an image with a certain hash. How you get the image is out of scope for the spec. Clients will likely have a cache of shared media, servers might help here too.

  193. larma

    ralphm, if we allow content in the body then we can no longer have a fallback body

  194. ralphm

    larma: I looked at your example?

  195. ralphm

    larma: my markup just says: that (fallback) body there has a URL in that, that is actually this media object I'm describing next to me, too.

  196. larma

    That seems unnecessary to me, as that's already what it is supposed to be

  197. larma

    That's like adding <i-behave-standards-compliant /> 😀

  198. ralphm

    larma: I think it gives us both worlds: 1) a readable plain-text message, 2) a fully marked up thing. Compare how Tweets work: there's plain text representation with a bunch of additional meta data (Tweet Entities and more) that make it possible to show a richer version of it.

  199. ralphm

    You then don't "need" a fallback anymore.

  200. larma

    I specifically don't want this to be a complex mixed content message, it should just be a file transfer

  201. larma

    The fallback in my example will be understood as a file transfer by the majority of clients already, allowing it to be anything else will cause it to no longer be displayed as such

  202. Daniel

    yes. i know what twitter is doing. that certainly has a place. but i also want a method to just share a file

  203. larma

    ^ that

  204. Daniel

    like we do now with xoob; but with more meta information

  205. ralphm

    larma: that's fine. I'm not saying you must, I'm saying you could, when you want to preserve the possibility to do 'inline' media sharing, this is how you could do it.

  206. ralphm

    I.e. adding the <reference/> would be optional, and not needed if you 'just' share a file.

  207. larma

    So that kind of concludes to: I want my proposal to be a new XEP because it does not provide what you call "inline" media sharing

  208. ralphm

    So it a) removes the references wrapper, with a way to still optionally do references.

  209. ralphm


  210. larma

    (I specifically don't want that as it adds a lot of complexity for a completely different usecase that I don't necessarily want to cover)

  211. ralphm

    And my proposal is such that XEP-0385 can be both what Tobias designed, with a slightly altered format, and what you want.

  212. ralphm

    The references could be left out entirely, or indeed in the References spec. The only thing you'd need is a way to refer to the media sharing element in case there are more than 1.

  213. larma

    ralphm, it's not about what the protocol can do, it's about the question what clients need to do when implementing it. I want to be able to implement file transfer in a compliant way that doesn't require me to support mixed content

  214. ralphm

    And you can.

  215. ralphm

    My proposal is basically: take XEP-0385, remove the wrapping references element, maybe add an id attribute.

  216. ralphm

    (instead of redoing all of this in a new spec)

  217. ralphm

    Tobias: does that sound right?

  218. larma

    So what do I do if I receive a message like https://gist.github.com/mar-v-in/fff8ff23ef8704229cb3e1dcccf79bfa but don't support mixed media? How do I display it? Just the body or just the file share?

  219. larma

    In my XEP I would just display the file share because the body should only be a fallback so anything in it is expected to be lost.

  220. larma

    In your XEP I'd need to implement mixed media which can be rather complex in some clients

  221. ralphm

    That's a valid point.

  222. ralphm

    I guess I assumed you'd always show the body.

  223. ralphm

    The thing is, if I go with what you suggest, how do we get to a place where we _do_ want a body with references?

  224. larma

    ah ok, that might not have been obvious from the XML I shared

  225. larma

    ralphm, that's why I said that it makes sense to consider this new thing (which I call SFS) something else than SIMS 😉

  226. ralphm

    larma: but then how do you "upgrade" from having just SFS, to something with SFS *and* a body with references?

  227. Daniel

    i guess we can just keep sims

  228. Daniel

    and do either sfs or sims

  229. larma

    it's two different things, there is no straight forward "upgrade" path

  230. Daniel

    it's just two different things

  231. ralphm

    Daniel, having two specifications that do exactly the same thing with different fallback behaviour seems suboptiomal, though.

  232. Daniel

    it's not the same thing

  233. ralphm

    Daniel, having two specifications that do exactly the same thing with different fallback behaviour seems suboptimal, though.

  234. Daniel

    one is twitter. the other one is file transfer

  235. Daniel

    (they can probably share their media meta data format wrapper element)

  236. ralphm

    Daniel: one is sharing media, and having a body that you show, two is sharing media with a body you only show when the media sharing element is not implemented.

  237. larma

    two is not sharing media, two is sharing a file

  238. ralphm

    a file is a medium, I don't understand the difference.

  239. larma

    something that may be impossible to display inline

  240. ralphm

    I'm not sure if it is that easy to make a clear division. A rich client could show PDFs or other documents "inline". Like Slack does.

  241. Daniel

    in any case i think it is perfectly fine to try both. if during that experiment we realize that there is a lot of overlap we can still merge one into the other

  242. jonas’

    and ISOs in an inline qemu window

  243. jonas’

    thanks to qemu.js or how it’s called

  244. ralphm

    Daniel, oh, let me be clear: I'm a firm believer in accepting proposals as XEPs and then experiment and pick a "winner" later.

  245. ralphm

    I cannot think of many reasons to *not* accept a specification that lands in the inbox. Other than known or suspected IPR concerns, and whatever formatting requirements Editors set.

  246. larma

    Oh and by the way, I think we shouldn't use references for that, but use message markup instead 😉

  247. ralphm

    larma: we can have a separate discussion on this, but I think message markup and references are the same thing with slightly different flavors.

  248. larma

    XEP-0372 seems to mix markup with semantic which is very odd to me

  249. larma

    mmh maybe semantic is the wrong word there

  250. ralphm

    larma: in my blog post, I altered the syntax, so that there's a <reference/> element with start and end, and then child elements that define the meta data (mention, media, message, link), so that you can do extend it independently.

  251. larma

    It definitely feels wrong to have markup change the routing behavior which is what the mention reference is supposed to do

  252. ralphm

    with message markup as I think you suggested, you also have a "thing with start and end" and "meta data about that thing" (emphasise, strike through, etc)

  253. ralphm

    larma: wait huh?

  254. ralphm

    larma: what does "change the routing behavior" mean?

  255. larma

    well, as we discussed on summit we want push notifications based on mentions.

  256. larma

    those are completely distinct concepts to me tbh

  257. ralphm

    I see mention notifications as a potential server-side side effect

  258. ralphm

    You can totally have mentions without notifications. References is primarily about markup.

  259. larma

    I don't want server side side effects based on markup, that's my point

  260. larma

    Also what I don't like about XEP-0372 is this "everything is a uri" concept

  261. ralphm

    That's ok. References doesn't specify or suggest notifications.

  262. jonas’

    larma, +1 against the everything is a URI thing

  263. ralphm

    larma: did you look at my examples I mentioned two times now?

  264. jonas’

    see also: https://mail.jabber.org/pipermail/standards/2018-March/034559.html

  265. larma

    ralphm, I did

  266. jonas’

    re markup with side-effects: markup is inherently semantic.

  267. jonas’

    or at least, Message Markup (my XEP) is, that’s the whole point

  268. ralphm

    larma: I intentionally moved away from the everything-is-a-URI model

  269. ralphm

    By having child elements with clear specific semantics

  270. larma

    yeah, but what is the purpose of the reference thing then? It just seems like a superfluous container element

  271. larma

    jonas’, Yeah, semantic is the wrong word, I just don't want markup to change how we deliver messages and I felt this was kind of the result of the discussion on summit

  272. jonas’

    larma, I think it’s the right thing to do

  273. ralphm

    larma: my idea was that you have a common thing (start and end attributes) and a specific description of what is to be found there. If you'd like to move the start and end attributes to the 'child' element, you could, but it isn't great for later (independent) extension with other types.

  274. jonas’

    mentions influence notification routing inherently

  275. jonas’

    to make this transparent to the user, it is required that it’s tied to some kind of markup, IMO

  276. ralphm

    jonas’, if you want this to be tied to a specific hint, I'd not be opposed I think.

  277. larma

    jonas’, but I might want to change notification routing without explicitly mentioning (slack does support that) or mention someone without notifying them (I don't think slack supports *that*)

  278. ralphm

    larma: well, you can still mention people in one-on-ones and channels the mentionee isn't in, and then you get asked what to do in the latter case.

  279. jonas’

    larma, I think the former case is a bad idea

  280. jonas’

    and the latter case is too

  281. larma

    jonas’, I want to talk about someone without them being notified, isn't that something rather usual?

  282. jonas’

    larma, then you don’t @mention them, what’s the problem?

  283. jonas’

    @mention -> notification

  284. ralphm

    I'd say in Slack, the thing that causes the notification is not unlike the user configuring keyword mentions for themselves.

  285. larma

    I want client to correctly reference that person (e.g. display their profile on hover)

  286. ralphm

    (which is a different way to look at it)

  287. jonas’

    larma, I suppose a mention-reference could have a silent=true thing in it, which would then also cause appropriate rendering in the recipients client

  288. larma

    How would it be displayed differently?

  289. jonas’

    but the way it’s presented and the way it’s routed needs to be tied together to avoid confusion and intransparent behaviour

  290. jonas’

    larma, probably grayed out or something?

  291. ralphm

    Should it be displayed differently?

  292. jonas’

    I don’t know the specifics, but it needs to be distinguishable. otherwise, people wonder where their notifications went.

  293. jonas’

    and then they blame the software because it doesn’t ping them when they’re mentioned

  294. jonas’

    being pinged when you’re mentioned (unless you turned that off) is pretty much standard and expected

  295. ralphm

    jonas’, if I implemented this, receiving side, I'd want all mentions of me to notify me, independently of what the sender suggested.

  296. larma

    re notify without mentioning, in slack if a message does not cause a user to be notified I can force a notification anyway. It makes sense if I want the message to be delivered in their silent hours even if I don't explicitly mention them

  297. jonas’

    ralphm, that’s also an option I guess

  298. ralphm

    And you can influence the behavior with hints, maybe.

  299. larma

    jonas’, I think the question how to do it client side (also how the client decides if they want to add the notify=false hint or not) is completely irrelevant for the spec

  300. larma

    But I personally would prefer if we just add a <notify jid="that@person.com /> hint to the message instead of having the server parse the markup. That notify also has the positive side effect that it can be used outside the e2ee so servers can actually parse it on e2ee messages

  301. ralphm

    larma: but you agree that actual notification is the responsibility of the receiving server then?

  302. larma

    ralphm, it's always the receiving server to decide, the question is what the server SHOULD base it's decision on

  303. larma

    I'd rather do it explicit in the message rather than implicit through specific markup

  304. ralphm

    Well, you could also take the position that the sending client or server explicitly send a notification.

  305. ralphm

    I don't like that one, but you could.

  306. ralphm

    So I wanted to make it clear.

  307. ralphm

    I'd be happy with a please-notify-hint.

  308. larma

    nah I want the sending client to add a hint such that the receiving server (and maybe even client) don't need to parse markup. If they want to do that anyway that's another story

  309. larma

    It just shouldn't be the intended way to parse markup

  310. ralphm

    Taking into account the use case of "forcing" a notification during dnd. Not sure how to spec that, yet.

  311. ralphm

    larma: sounds good to me

  312. nyco

    Sorry for this interruption: Call for help of promotion of the newsletter! https://fosstodon.org/@xmpp/103606882304524026 https://twitter.com/xmpp/status/1225073484176543747 https://www.linkedin.com/posts/xmpp-standards-foundation_xmpp-jabber-decentralised-activity-6630841055023558656-SFhw/ https://www.reddit.com/r/xmpp/comments/ezb3tg/the_xmpp_newsletter_full_speed_xmpp_universe_04/ https://www.facebook.com/photo.php?fbid=10158047204828454&set=p.10158047204828454&type=1&theater Like and Share, if you want, what you want, how you want :)

  313. ralphm

    larma: a while back you asked about the use of the <reference/> wrapper. Did my explanation make sense?

  314. larma

    ralphm, I kind of see the point. But then we would still probably want to merge reference into message markup maybe?

  315. ralphm

    I'd be happy with a common <markup> wrapper with start/end, and then merge the markup, so you can have <emphasize/> and <mention/> next to each other.

  316. ralphm

    Or something similar, I'm not sure what's better, start/end on the specific element itself, or on a wrapper, in the face of distributed extensibility. In non-XMPP cases with XML, you'd use namespaced attributes, but I think I don't like that either.

  317. nyco

    <emphasize/> also <empathize/> or <ironize/>?

  318. ralphm


  319. ralphm

    in your own namespace

  320. moparisthebest

    anyone see https://snikket.org/ ? pretty neat move

  321. moparisthebest

    what is it? messaging platform. how do I chat on it? grab this app. how can I run my own server? run this snikket docker container.

  322. moparisthebest

    ah, figured out who's involved now, nice work!

  323. jonas’


  324. jonas’

    MattJ, ^

  325. moparisthebest

    had to track down git repo and commits to figure it out lol, was linked to in jmp.chat muc first

  326. MattJ


  327. pep.

    moparisthebest, #old :p

  328. jonas’

    pep., never too old for praise

  329. moparisthebest

    was it linked in here before? I could have missed it I admit

  330. jonas’

    also, shaming people for re-sharing "old" news puts an odd incentive against sharing stuff at all

  331. pep.

    jonas’, can't joke anymore?

  332. pep.

    I'm not shaming anybody

  333. MattJ

    moparisthebest: I don't think it was linked here in particular

  334. pep.

    I haven't seen it here either

  335. MattJ

    I did publish a Prosody blog post yesterday: https://blog.prosody.im/introducing-snikket/

  336. MattJ

    To be honest the early reaction from XMPP community members wasn't exactly encouraging :)

  337. MattJ

    But pretty much anyone here is not the target audience

  338. jonas’

    pep., sorry, I didn’t get the joke part

  339. stpeter

    so true :-)

  340. moparisthebest

    if XMPP is weak at one thing, it's marketing, this looks good to me

  341. MattJ

    But hopefully the blog post gives some background - I've heard a lot of "why another Conversations fork?!"

  342. MattJ

    And yes, a bunch of it is simply a layer of marketing :)

  343. moparisthebest

    reaction in jmp.chat muc which is more users than developers/xmpp community looks promising

  344. stpeter

    moparisthebest: what's the chatroom for jmp?

  345. MattJ

    Yes, had a demo at the XMPP stand at FOSDEM this past weekend and I think it's fair to say it was a success

  346. pep.

    Everywhere I mentioned it outside of XMPP circles the reaction was good

  347. moparisthebest

    stpeter, xmpp:discuss@conference.soprani.ca?join

  348. stpeter


  349. jonas’

    moparisthebest, can you hint the admins of that room that their room title isn’t particularly useful (if set at all): https://search.jabber.network/search?q=discuss%40conference.soprani.ca

  350. moparisthebest

    jonas’, thanks, they set one!

  351. jonas’

    moparisthebest, :+1:

  352. jonas’

    (the usual delay of ~1h applies)

  353. ralphm

    MattJ: I personally think, I hoped to express, that I think the idea and execution so far for Snikket is really good.

  354. ralphm

    MattJ: I like that you focus on a product rather than the underlying protocol

  355. ralphm

    MattJ: I'm curious why you think the community wasn't encouraging. What kind of feedback did you get? Everyone I talked to at FOSDEM thought it was great.

  356. Zash

    Seen a bunch of things like "Why yet another Conversations fork?", "What's the point of this, we already have Prosody?"

  357. MattJ

    Nothing serious or surprising - I think it probably didn't click for many people (who weren't at FOSDEM) until I laid it out in the blog post yesterday

  358. MattJ

    Partly my fault, I'd aimed to post that sooner, but got held up by last minute demo preparation

  359. moparisthebest

    *personally* I see something like that, and the first thing I do is dig to see what the underlying protocol is, software is written in etc etc, I *suspect* I'm not a normal average person in that regard

  360. moparisthebest

    I see "XMPP" and instantly know all the advantages that provides, that are spelled out there in plain english, again I suspect the normal person does not

  361. MattJ

    Right, I totally get it, it's not a surprising reaction at all for a community of geeks :)

  362. MattJ

    We are used to assessing technology, but there is very little new tech here

  363. fippo

    the general concern with the trend to package client+server is that it reduces the need for specs (and spec compliance). not a concern in this case i think because of a long record :-)

  364. moparisthebest

    and to be clear I'm meaning this as praise, to a "normal person" I think that snikket looks a lot better than "grab any XMPP client or server and join in"

  365. Zash

    Given the flexibility of XMPP, having clients and servers optimized for each other makes sense.

  366. MattJ

    moparisthebest: yeah, the FOSDEM reception was great

  367. MattJ

    Lots of people new to XMPP had a simple gateway in, that was easily explained as a "self-hostable WhatsApp/Telegram/Signal/..."

  368. stpeter

    Snikket: The Gateway Drug to Hardcore XMPP [tm]

  369. MattJ

    Time will tell :)

  370. ralphm

    stpeter: :-D

  371. stpeter

    Not the best marketing, I suppose. ;-)

  372. ralphm

    MattJ: you should have put the logo in your post

  373. MattJ

    Yeah, would have delayed it further though :)

  374. ralphm

    Eh, ok.

  375. MattJ

    Currently working on docker images that actually work on a Raspberry Pi like we advertised :D

  376. MattJ

    (current ones are x86 only)

  377. ralphm

    Drug dealers often lie, so there's that.