XSF Discussion - 2019-12-29


  1. pep.

    What if you want to have a group with channels from different components?

  2. pep.

    Would not a list of channels be easier to handle? You can also do MIX like this it's not specific to MUC

  3. pep.

    (Not that I have any interest in having MIX implemented for the time being)

  4. MattJ

    pep.: disco can return JIDs from other components :)

  5. pep.

    MattJ: you'd be breaking a SHOULD? (Behind a feature I guess..). "The service SHOULD return a full list of the public rooms it hosts"

  6. pep.

    I came across this but I was mostly looking at possible restrictions on the type of jid you can put in there

  7. Ge0rG

    It doesn't say it may only return rooms...

  8. pep.

    It doesn't insist on it..

  9. pep.

    I wonder how many people would interpret it this loosely though

  10. Ge0rG

    Most of them

  11. MattJ

    Who cares?

  12. pep.

    MattJ: dunno, some optimisation "because the xep says so"

  13. MattJ

    Disco has been used this way for a long long time, not necessarily on MUC components (that I'm aware of)

  14. MattJ

    But I don't see a difference

  15. Ge0rG

    Reminds me of https://wiki.xmpp.org/web/Client_Test_Cases

  16. MattJ

    The attribute is 'jid' not 'nodepart'

  17. MattJ

    In the olden days many servers would return conference.jabber.org in their disco items, or transports from another server, etc.

  18. MattJ

    Clients did not and should not expect that those services are always subdomains of the domain they disco, and the same applies here

  19. Ge0rG

    pep.: there is actual benefit in using jonas’' muc search API instead of the blunt disco#items, as it provides rich info without having to query each room individually

  20. Ge0rG

    And that doesn't come with the expectation of all rooms being on the same domain

  21. pep.

    Ge0rG: context?

  22. Ge0rG

    pep.: exposing a "community" room list

  23. pep.

    I don't especially think this should be restricted to being a "room" list

  24. Ge0rG

    Well, you could stuff anything into it, but what would be useful, and not too far away from normal xmpp clients?

  25. pep.

    By "normal" you mean chat?

  26. Ge0rG

    I mean the widely deployed ones, which is roughly the same

  27. pep.

    All clients support PEP right. Microblog is not too far away :p

  28. Ge0rG

    pep.: now just make it mandatory for CS'21 and we are set

  29. pep.

    Also I wouldn't be so sure our public space and enterprise have the same "norms"

  30. Ge0rG

    pep.: now just make it mandatory for CS'21 Core IM and we are set

  31. pep.

    Maybe someday people will stop assuming XMPP = IM

  32. Ge0rG

    Speaking of which, is it too early to fork off CS'21 yet?

  33. jonas’

    no

  34. jonas’

    it’s never too early

  35. Ge0rG

    It's not even 2020

  36. jonas’

    oh, right

  37. jonas’

    no wait

  38. jonas’

    it’s never too early :)

  39. Ge0rG

    Heh!

  40. Ge0rG

    XEP-0412 is still in Draft though

  41. jonas’

    that’s where compliance suites go to die

  42. Ge0rG

    And it doesn't even link its predecessor. Who wrote this shit?

  43. jonas’

    the same person who wrote the star wars prequels, I think. so some people would argue that makes sense.

  44. Ge0rG

    Well then

  45. jonas’

    (I am sorry)

  46. Ge0rG

    jonas’: are you really? 😋

  47. jonas’

    slightly

  48. goffi

    Hello here, I'm checking https://xmpp.org/extensions/xep-0045.html#continue to convert one2one chat to MUC, and I'm suspicious about sending the history from the one2one chat (cf. Example 63). Is there any client doing that? The text says that the <delay> element has the "from" of original message sender, but the example use the same "from" for the 2 messages (and using this, we could fake message from anybody).

  49. goffi

    Is this the actual recommanded way to convert one2one chat to a MUC?

  50. goffi

    recommended*

  51. Ge0rG

    goffi: I haven't seen it used anywhere, also there is the obvious trust problem

  52. Ge0rG

    goffi: one could principally send <forwarded> messages into the MUC, but there is also the privacy problem

  53. goffi

    Ge0rG: indeed. Doesn't look good to me. I think I'll skip this history sending in my implementation, at least for now.

  54. Ge0rG

    goffi: yeah

  55. goffi

    also we would need to know how much of history to send, it's not trivial to do it right.

  56. Ge0rG

    I've brought up those points in the context of MIX, and IIRC it lead to the removal of history upload

  57. Zash

    Is there a media type registered for XMPP stanzas?

  58. Zash

    https://xmpp.org/extensions/xep-0081.xml :/

  59. Zash

    Oh, application/xmpp+xml defined in https://tools.ietf.org/html/rfc3923#section-10

  60. Zash

    Huh, weird <xmpp> container

  61. vanitasvitae

    In case you missed Moxie Marlinspikes latest talk about why decentralized systems are inferior to centralized systems, I formulated a reply: https://news.ycombinator.com/item?id=21908712

  62. vanitasvitae

    (I hope this is not too OT for this channel)

  63. Zash

    Nice

  64. Zash

    vanitasvitae: "While this is and issue" s/and/an/ ?

  65. vanitasvitae

    fixed 🙂

  66. Ge0rG

    vanitasvitae: great! minor typo: "called compliance suits" --> "suites"

  67. vanitasvitae

    Ge0rG, fixed as well

  68. Ge0rG

    👍

  69. lovetox

    i dont know why this is even a discussion, there are pro and cons two both ways (decentralized/centralized) and they will not go away, talking about why a particular con or pro doesnt matter to you iin some specific project is irrelevant in my opinion

  70. lovetox

    there will always be people for which the pros/cons will matter

  71. lovetox

    thats why there are 2 ways of doing things

  72. vanitasvitae

    sure. I just thought it was worth a reply nontheless.

  73. lovetox

    *two/to

  74. lovetox

    vanitasvitae, the "you" was not directed at you

  75. lovetox

    i was speaking about moxie

  76. lovetox

    i dont see the value in giving a talk how the centralized approach worked for signal

  77. lovetox

    no shit it works, like it works for a million other projects

  78. lovetox

    and it has the same cons and pros like all other projects

  79. vanitasvitae

    😀

  80. lovetox

    i didnt listen to the talk, so if he brought something new groundbreaking to the discussion, ignore me

  81. MattJ

    lovetox: the problem is that Signal is trying to appeal to a privacy-conscious audience that has historically always been anti-centralization, so he needs to justify why Signal is not decentralized

  82. lovetox

    ah k, he should just go with, "its much easier, and we try to minimize the cons as much as possible, if you dont like it build something better decentralized"

  83. lovetox

    also why would he need to appeal to certain people

  84. lovetox

    what is the signal business model?

  85. vanitasvitae

    Get money from tech funds

  86. lovetox

    ok but why would they invest money?

  87. lovetox

    or do they invest money into openwhispersystems

  88. lovetox

    for doing other stuff

  89. lovetox

    and openwhispersystem just crossfinances signal on the side with it

  90. lovetox

    because if their goal is total privacy, i dont see a way how signal can ever make money

  91. vanitasvitae

    I mean, much of their money probably also comes from licensing libsignal to WhatsApp, Skype etc.

  92. lovetox

    its subscription or add revenue on the internet, and with so many chat applications out there i dont think a subscription service will be profitable

  93. lovetox

    its subscription or ad revenue on the internet, and with so many chat applications out there i dont think a subscription service will be profitable

  94. emus

    vanitasvitae: Well stated text. Will put ot to the newsletter I would like to say: "we do these things… …not because they are easy, but because they are RIGHT…"