XSF Discussion - 2019-10-15


  1. Ge0rG

    Zash: treat them like chat messages?

  2. aliex@exploit.im

    aliex@exploit.im

  3. aliex@exploit.im

    aliex@exploit.im hi

  4. Guus

    ah, my favorite domain. It ranks high in my spamlist.

  5. Ge0rG

    pep., jonas’: please merge https://github.com/xsf/xeps/pull/841

  6. pep.

    k

  7. Ge0rG

    rendered version for quality control: https://op-co.de/tmp/xep-0423.html

  8. Ge0rG

    (it's got a gimmick for you, pep.)

  9. pep.

    hmm is there a revision block somewhere?

  10. Ge0rG

    pep.: unfortunately, the revision block is not suitable for CS purposes.

  11. Ge0rG

    pep.: feel free to rip off "Changes since 2019" into the rev block though

  12. pep.

    What does that mean

  13. Ge0rG

    pep.: you can't have the "Changes since 2019" in a single place of the revision block

  14. Ge0rG

    because it has a section for each minor version

  15. Ge0rG

    so pre-Last-Call and post-Last-Call go into separate blocks there

  16. pep.

    sure

  17. pep.

    Are we talking about the same thing

  18. Ge0rG

    pep.: I don't know?

  19. Ge0rG

    pep.: what you probably wanted to hear instead of my rant is: no, I didn't add a revision block

  20. pep.

    And yeah that would probably look like your §1.1, since 0.1 is more or less similar to 412 right?

  21. Ge0rG

    pep.: yes, 0.1 was an identical copy

  22. Ge0rG

    plus "future changes", which is noted there, of course

  23. pep.

    Ok let's see..

  24. jonas’

    pep., so you’re going to take care of that?

  25. jonas’

    please let me see the diff before hitting the button

  26. jonas’

    Ge0rG, as mentioned, no revision block is not an option

  27. Ge0rG

    jonas’: I know. This is why I added §1.1

  28. Ge0rG

    jonas’: I was just hoping that an Editor would add the rev block so that I don't mess up anything

  29. pep.

    jonas’, yeah doing for it now. Ge0rG I have as many chance as you of messing it up :)

  30. pep.

    going*

  31. Ge0rG

    pep.: but I don't have that Editor hat, so now I can sleep calmly at night ;)

  32. Ge0rG

    hm. Chat Markers were just suggested for addition.

  33. Zash

    Wasn't that meant to get the overlap with receipts and chat states removed?

  34. Ge0rG

    we also wanted to reword chat states as presence.

  35. pep.

    Ge0rG, so.. what does that mean for editors

  36. Ge0rG

    pep.: nothing so far.

  37. Zash

    Can you even do that wih a Final Standard?

  38. Ge0rG

    pep.: please go on with your work

  39. pep.

    ok

  40. Ge0rG

    pep.: I'll put that into the Last Call bucket.

  41. Ge0rG

    Zash: sure, given a new XEP number

  42. ralphm

    FYI, there's been a call for the Decentralized Internet & Privacy devroom at FOSDEM. Discuss over at summit@muc.xmpp.org.

  43. lovetox

    whats the deal with the published XEPs by pep?

  44. lovetox

    the are published but the link leads to the old version

  45. jonas’

    lovetox, what isn’t?

  46. jonas’

    ah, pep. sent the emails too early

  47. pep.

    oh

  48. pep.

    CI

  49. Zash

    Wait for the foreverbuild!

  50. pep.

    Ok I'll wait for the CI next time

  51. jonas’

    CI isn’t the thing you need to wait for

  52. pep.

    lovetox, you're too quick for me

  53. jonas’

    docker hub is broken, too

  54. jonas’

    throws 500s at me

  55. jonas’

    pep., you need to wait for https://cloud.docker.com/u/xmppxsf/repository/docker/xmppxsf/xeps/builds to finish

  56. jonas’

    the page may not load at the moment, docker cloud/hub seems to be broken

  57. pep.

    I don't have access to that apparently (I get redirected to the main page)

  58. Zash

    Mmmmm Cloud

  59. jonas’

    pep., that happened to me too, it’s the brokenness right now

  60. jonas’

    you should have access

  61. pep.

    ok

  62. jonas’

    pep., maybe send an email in reply to the CS-2020 notification

  63. jonas’

    so that people don’t get confused

  64. lovetox

    why how long does this build take?

  65. lovetox

    i mean its 20 minutes already

  66. pep.

    lo[..]oong

  67. jonas’

    lovetox, about 1h

  68. jonas’

    lovetox, possibly longer if dokcer cloud is currently broken

  69. jonas’

    so a note about that seems sensible to have

  70. pep.

    Here

  71. Ge0rG

    Looks like our hoster has gone Serverless, eh?

  72. Zash

    It is the modern thing to do, right?

  73. pep.

    Is there any other good reason to do anything

  74. Zash

    Depends, do you support Nihilism over XMPP?

  75. lskdjf

    > lskdjf: also I'm curious what your actual problem with 0392 is, besides of it being out-of-scope of the XSF powers. Ge0rG, your question was a day ago, but anyways, now I have the time to answer. It's ok to write down a common way of generating colors, even if maybe not in the standarts track. The specification has it's flaws, but they can be improved, there was a mail on the ML about that. My main problem really is that you want to write 0392 into the compliance suites. Some days ago I complained that I couldn't do slack/github style avatars anymore. You said: "nothing prevents your smart pattern avatar generator from applying the same color as other clients do". But that's wrong, the XEP doesn't allow that. It says: Generate a color, fill a shape with it and render the first character of the name onto it. Thus, if I want to generate an avatar, I'm not allowed to have patterns, I'm not allowed to put two letters onto the avatar. Both are common approaches. If the XEP is in the compliance suites, I have to choose between having a UI that might better fit my application or being an Advanced IM client. You basically hinter potential UI improvements. Also, some environments strongly suggest to use a specific color palette. E.g. GNOME does and Android previously did, too. Or maybe my design department simply evaluated in user studies that this specific green tone fits best into my application. The XEP only allows me to use a specific palette if my device doesn't support otherwise, not if I want/should do so because of other constaints. Thus, I can choose between following the GNOME suggestions and being an advanced XMPP IM client. XMPP is a protocol and the compliance suites should define features. Not a set of user interface rules. We can have things like easy xmpp for that.

  76. lskdjf

    s/easy xmpp/modern xmpp

  77. jonas’

    lskdjf, > Generate a color, fill a shape with it and render the first character of the name onto it. Okay, I did not intend this to be a *requirement*

  78. jonas’

    It was meant as a non-normative inspiration

  79. lovetox

    yeah, i agree, user interface stuff should be strictly separate from XEPs

  80. lovetox

    only thing you get with putting this stuff into XEPs is, it gets simply ignored

  81. larma

    jonas’, sorry, but hard to read "auto-generating an avatar SHOULD happen as follows" as an inspiration, inspirations SHOULD use MAY 😉

  82. jonas’

    that’s true

  83. lovetox

    not even a MAY

  84. Zash

    RFC 2119 language about UI things is weird

  85. lovetox

    it should be in a different section without any keywords

  86. pep.

    just "may"

  87. lovetox

    or not at all in the XEP

  88. pep.

    (because 8174)

  89. lovetox

    why does a XEP have to make UI suggestions

  90. jonas’

    lovetox, it doesn’t *have* to

  91. lovetox

    we should find another venue for that

  92. jonas’

    lskdjf, I see your points, and I think there is some merit to them

  93. Zash

    And as pep. touched on, Council isn't made to review UI/UX things.

  94. larma

    lovetox, as I just wrote "It makes a lot of sense to give hints how things could/should be displayed, especially when it has security implications"

  95. lskdjf

    > only thing you get with putting this stuff into XEPs is, it gets simply ignored well it's hard to ignore the compliance suites if you want to be an advanced client. You'd have to either do what the XEP says or be downgraded to a basic client just because you want to display two letters in your generated avatars.

  96. pep.

    Technically it's only a SHOULD. :-°

  97. pep.

    (I know.)

  98. lskdjf

    yeah basically everything in there is a SHOULD. So I can ignore the XEP and still be compliant?

  99. Ge0rG

    lskdjf: we really need to move this to standards. I'm currently not focused enough to give an appropriate response.

  100. Ge0rG

    My reading of 0392 was to provide a consistent hue value for the visual element associated with a given user, not more and not less.

  101. pep.

    consistent *through UI

  102. lskdjf

    Ge0rG, pep brought it to standarts already and you basically replied with "I disagree, I would like to challenge Counil" ... So I fail to see the advantage of going to standards.

  103. Ge0rG

    lskdjf: you can provide your arguments to council. But in fact I much more appreciate your specific feedback on 0392, and I'm sure it will be incorporated to improve it

  104. lskdjf

    > My reading of 0392 was to provide a consistent hue value for the visual element associated with a given user, not more and not less. that already is problematic. Refer to what I wrote about reasons to use e.g. different color palettes. A body that standartizes a protocol does not have the task to mandate UI.

  105. lskdjf

    > But in fact I much more appreciate your specific feedback on 0392, and I'm sure it will be incorporated to improve it I can only repeat: My proplem is that 0392 is in the compliance suites, not 0392 itself. And feedback on 0392 was already given on the ML yesterday.

  106. Ge0rG

    lskdjf: you just gave additional feedback that wasn't on the list

  107. Ge0rG

    lskdjf: and as I said, I can't provide adequate feedback right now

  108. lovetox

    hm but still weird that this is a XEP

  109. lovetox

    as it has really nothing to do with the protocol

  110. lovetox

    not even remotely

  111. lovetox

    its only purpose is to shape UI

  112. lovetox

    weird that this was accepted

  113. lovetox

    i dont think there is another XEP like that

  114. jonas’

    lovetox, `/me` is close

  115. jonas’

    and '393 to some extent

  116. jonas’

    depending on how you look at it

  117. jonas’

    but yes...

  118. jonas’

    I’m not sure what a better place for this would be tho

  119. lovetox

    in these XEPs there is at least something sent over the wire ^^

  120. lovetox

    i just think we need a place where we put stuff like that

  121. jonas’

    true

  122. lovetox

    the modernxmpp project would be a start for example

  123. pep.

    lovetox, it's not supposed to be a Standards Track XEP tbh, 392

  124. jonas’

    I don’t think that existed back then

  125. Zash

    As I think someone said at last Summit, we can set up a process for this if people want to, like an UX track with a UX review council or a SIG or something.

  126. pep.

    I don't know about 0245, " /me" is "wire" format, but most of the rest is UI

  127. pep.

    Zash, sure that'd be more appropriate

  128. lovetox

    jonas’, this is not meant as a criticism of you writing the XEP, its just an observation from todays viewpoint :)

  129. lskdjf

    lovetox, as was pointed out on the ML, it's indeed not intended to specify anything but _wire protocol_ in the standarts track, according to XEP-0001.

  130. lskdjf

    so yeah, technically this XEP shouldn't exist in it's current form

  131. Zash

    XEP-0245 is Informational at least

  132. lovetox

    there are actually many XEPs that hin at UI stuff

  133. lovetox

    or even mandate it

  134. lovetox

    like larma just wrote on the list, even the avatar xep which has a very early number, mandates how a client should resize avatars

  135. Zash

    https://logs.xmpp.org/council/2017-09-20?p=h#2017-09-20-e90eb46fa7027b61

  136. Zash

    17:24:33 Link Mauve "SamWhited, also, why are the compliance suites standards tracks, instead of informational?"

  137. Zash

    Hah

  138. larma

    because they are supposed to, for some reason: https://xmpp.org/extensions/xep-0001.html#types-Standards-Track

  139. larma

    wire protocols and protocol suites are allowed on standards track

  140. Zash

    That's clear, yeah.

  141. Zash

    Hasn't anyone remarked the color XEP being in Standards Track before? Can't find anything in my email archives and there wasn't much discussion at that council meeting.

  142. pep.

    Yeah no I guess it wasn't on purpose and nobody noticed

  143. Zash

    2 years ago!