XSF Discussion - 2019-02-18


  1. Zash

    Why is there a xep for what game or music you're playing but not whatbbook you're reading?

  2. edhelas

    Zash there is one for games?

  3. Seve

    If I recall correctly, the example was World of warcraft, but I'm not sure if it was deferred or retracted

  4. Seve

    Done by stpeter I think

  5. intosi

    Zash: those XEPs were from a time before reading electronically was done much. With tablets and ereaders, automatically pushing what you're reading is much easier :)

  6. Ge0rG

    it's actually _harder_ to _not_ automatically push what you are reading to some "interested" third parties.

  7. intosi

    These days? Yup.

  8. Ge0rG

    I just realize that CS-2019 is missing XEP-0066 for file attachments.

  9. Ge0rG

    As it is used by multiple widely-deployed clients, it should be mentioned. On the other hand, _how_ it is used is not documented anywhere.

  10. pep.

    Ge0rG, "used by multiple widely-deployed clients" and "recommended" doesn't have to match. And https://github.com/siacs/Conversations/issues/2637 as pointed out the other day.

  11. pep.

    Ge0rG, "used by multiple widely-deployed clients" and "recommended" don't have to match. And https://github.com/siacs/Conversations/issues/2637 as pointed out the other day.

  12. pep.

    Ge0rG, "used by multiple widely-deployed clients" and "recommended" don't have to match exactly. And https://github.com/siacs/Conversations/issues/2637 as pointed out the other day.

  13. edhelas

    https://crypto.cat/

  14. edhelas

    for those that reads french, https://nl.movim.eu/?blog/edhelas@movim.eu/ebc3a98e-3a37-440f-8cb4-8de1fa7eed3b Cryptocat is basically a crentralized XMPP client + OMEMO

  15. pep.

    > Furthermore, this domain name, crypto.cat, is for sale. I hope they didn't have XMPP users on it. Otherwise it's going to be fun.. :/

  16. edhelas

    well they had

  17. pep.

    That's one thing I don't like with XMPP

  18. edhelas

    just that is was not s2s enabled

  19. pep.

    k

  20. Ge0rG

    pep.: this boils down to the philosophical question of whether CS is a tool to document what's widely used or to define what we endorse for the future. Last time I checked it was the former, so 0066 would make sense. SIMS might as well.

  21. Ge0rG

    Are CRLF newlines valid in XMPP <body> elements?

  22. moparisthebest

    don't know why they wouldn't be?

  23. Zash

    I suspect the answer would be iherited from XML

  24. intosi

    If XML 1.0 doesn't forbid it, then XMPP will allow it here, I think.

  25. intosi

    (which it doesn't)

  26. intosi

    * which XML 1.0 doesn't.

  27. Ge0rG

    I'm asking because I want to remove quotes from multi-line messages

  28. Ge0rG

    And as always in Java, I can choose between ugly, inelegant and broken-from-stackoverflow

  29. bowlofeggs

    java is a great language to use if you have a lot of XML and want to turn it into very long, backwards tracebacks…

  30. Zash

    edhelas: https://xmpp.org/extensions/xep-0196.html

  31. Zash

    also https://xmpp.org/extensions/xep-0195.html

  32. Zash

    I use that sometimes to share links with the void

  33. Zash

    Altho, if you can identify the book by an URI, like I'm pretty sure there's one ISBN, you could overload the browsing one

  34. Zash

    urn:isbn: yeeaaaah

  35. debacle

    Talking about links and URIs: I would like to see a link/URL syntax in XEP-0393 Message Styling. There are multiple syntax forms to choose from: AsciiDoc: https://foo.bar/[foo bar] BBCode: [url=http://foo.bar/]foo bar[/url] Creole: [[http://foo.bar/|foo bar]] Markdown: [foo bar](http://foo.bar/) MediaWiki, Trac: [http://foo.bar/ foo bar] Org-Mode: [[http://foo.bar/][foo bar]] ReST: `foo bar <http://foo.bar/>`_ Textile: "foo bar":http://foo.bar/ I don't care which atrocity is selected, but I believe we need one.

  36. Zash

    <a href="http://example.com/">Foo bar</a>

  37. debacle

    too beautiful for my taste, but whatever, why not?

  38. pep.

    Markdown already allows that right, and since most people confuse 393 for markdown, I think we're good :)

  39. Zash

    Where "good" is code for "DOOMED"

  40. pep.

    ssshhh

  41. debacle

    pep. I'm fine with whatever syntax, however, I needed years to not put round and squared brackets in the wrong order in MD

  42. pep.

    debacle, same here, I'm still making the same mistake over and over

  43. pep.

    But markdown also allows html

  44. pep.

    So we're even better

  45. Zash

    So the obvious choise is to do the opposite of Markdown?

  46. pep.

    Zash, You mean []() ?

  47. Zash

    I mean whatever the opposite of Markdown is

  48. Zash

    I'd have to look it up

  49. pep.

    Yeah I think that's it

  50. pep.

    Ah wait no that's the correct one

  51. pep.

    pff

  52. Zash

    ~$ pandoc -f html -t markdown <<< '<a href="link">text</a>' [text](link)

  53. debacle

    pep. since I remember, that round brackets are more common, therefore more likely happen in "normal" text, I now remember, that the part with the text must be surrounded by the less common square brackets. But I really have to think about this, every time I write MD.

  54. Zash

    <link> text

  55. pep.

    yeah, links in md are meh. But then rst is not better. I also use phabricator regularly, and mediawiki, which all use different markup formats, yay

  56. debacle

    whatever the syntax is, the idea of a link in 0393 might conflict with the idea, that the syntax should always be "transparent" to the user

  57. debacle

    MediaWiki syntax is ugly, but the link syntax is better than MD and most others

  58. debacle

    MediaWiki syntax is ugly, but its link syntax is better than MD and most others

  59. debacle

    I understand the idea of 0393 is, that clients present both the markup symbols and the styling. With links it would be different, at least in some clients. The idea of a link syntax is to see only the text, while the actual URL is only visible e.g. by hovering, or whatever is appropriate for the device/client. That breaks the concept. Which is fine in XMPP :)

  60. pep.

    what is fine in XMPP?

  61. debacle

    breaking the concepts of XEPs in the middle

  62. pep.

    I just wish we burned 393 already

  63. debacle

    pep. It's (more or less) implemented in Gajim (with some differences) and Conversations (so I heard).

  64. pep.

    There's always been some kind of markup in gajim like that, it's never been like 393

  65. pep.

    So it was of course easier to implement yet another markup format

  66. debacle

    But 0394 is not that cool IMHO.<span start="16" end="20"><emphasis/></span>

  67. pep.

    I agree. We had a totally fine XEP before all that :)

  68. debacle

    which one?

  69. Zash

    71

  70. pep.

    0071

  71. debacle

    oh, yes, but who uses HTML anyway nowadays?

  72. pep.

    XHTML-IM*

  73. Zash

    It was in theory fine as a transport format

  74. debacle

    come on, this is totally broken: It uses XML! It has a regular syntax! It has all the features! No, go away with 0071!

  75. Zash

    Type markdown or whatever you want into your client, XHTML-IM goes on the wire

  76. pep.

    yep

  77. Zash

    debacle: What, being reasonable? NEVER, WE'RE XMPP!

  78. debacle

    Zash, ah sure, forget it :(

  79. debacle

    "insane since 1999"

  80. pep.

    "20 years of deception"

  81. debacle

    Zash, I like having some level of consistency over different clients.

  82. pep.

    debacle, then you could have a XEP that specifies an input format, but that doesn't have to go over the wire

  83. Zash

    debacle: Nothing prevents having semi-standardized client UX

  84. Zash

    https://xmpp.org/extensions/xep-0392.html is pretty close to that already

  85. debacle

    E.g. when somebody uses different clients, it's nice to have an idea how to enter some formatting.

  86. debacle

    Well, I would not oppose reviving 0071, but at the moment I need more urgent a link syntax to enter easily and consistently in XMPP clients. Whatever the wire format is. Therefore the idea to add a link syntax to 0393. It doesn't do any bad to 0071 nor 0394.

  87. pep.

    Clients still support 71, they haven't removed it because it got deprecated

  88. pep.

    You can still use that

  89. debacle

    pep. Unfortunately, Conversations does not support it, it seems. It's more likely that an URL syntax will be added to it, than 0071 support, I assume.

  90. pep.

    If conversations doesn't support it then it must be wrong indeed

  91. debacle

    pep. Exactly! (Well, it's about a specific project I have, where we need an Android app as most important part. Xabber and yax.im do not support 0071 neither. I fear, that there is no free software Android client with 0071 support.)

  92. Andrew Nenakhov

    Deprecation of xep 0071 is an almost criminal offence.

  93. Andrew Nenakhov

    Suggestion to use markdown are silly because markdown was meant to be rendered into HTML

  94. Andrew Nenakhov

    So if someone suggests having a wysiwyg editor that is used to form and send markdown text, well, that's borderline crazy

  95. Andrew Nenakhov

    debacle, for what it's worth I plan to add support of 0071 in Xabber, maybe even this year.

  96. Andrew Nenakhov

    Most likely it won't cover everything, but it would be good enough for basic bolds and italics.

  97. Andrew Nenakhov

    393 and 394 are both silly ideas born out of false slogan that 0071 can't be implemented safely. Especially 0394 - like, really, a NEW text markup system, in 2018??!

  98. debacle

    Andrew Nenakhov, I'm happy, that I'm not the only one mourning over 0071.

  99. pep.

    Where were you people when the war started!

  100. Andrew Nenakhov

    Well I wasn't reading the xsf mailing lists. However, I don't think these 'rules' that dictate xep workflow are really written in stone.

  101. Andrew Nenakhov

    If we implement xep0071 who's gonna stop us? :)

  102. pep.

    Nobody, it's just discouraging externals I guess, and reinforcing the fact that the standard process is weird, for these people, because most client implement it and don't plan to remove it, some plan to even if it's deprecated. *confused*

  103. pep.

    Not entirely sure I have a point, but I would also feel confused.

  104. Andrew Nenakhov

    Btw we'll soon have VoIP working in iOS version of Xabber. The things we do to have legitimate access to those niiiice background notifications, lol

  105. Andrew Nenakhov

    Will have to rewrite appserver though. We lazily used Google's FCM to send simple push notifications to iOS, but FCM doesn't support VoIP pushes for some reason