XSF Discussion - 2018-01-24


  1. SouL

    https://www.fsf.org/blogs/community/victory-for-libre-networks-activitypub-is-now-a-w3c-recommended-standard

  2. edhelas

    yeah, this means that we will have two standards now, the XMPP-Pubsub one and the Web-ActivityPub one

  3. zinid

    what a mess, we need another one, unique!

  4. zinid

    oh wait...

  5. Zash

    For what? Do they even cover the same things?

  6. edhelas

    personally I was explaining the advantages of building a social-feed standard on Internet protocols and not only Web ones

  7. edhelas

    for several years now

  8. edhelas

    because building on top of HTTP brings maybe lots of advantages (including the "simplicity at first")

  9. edhelas

    but also drawback (overhead, scalability…)

  10. edhelas

    this is only for the protocol layer, functionnality wise there's lots of differences

  11. zinid

    > The W3C has allowed DRM to move forward on the web All you need to know about W3C

  12. goffi

    activity pub is pushed by web based networks such as Diaspora or Mastodon which are the most famous ones even if both are youger than XMPP based ones. While I'm sad that they never tried to talk to us or follow what we have done, at least it's standardized and it should be easy to communicate with them.

  13. SouL

    I shared with you guys that link from the fsf because I felt sad about that. I haven't heard anything about considering XMPP for that standard. And what worries me now is, people involved in ActivityPub, did even know XMPP? I wonder if XMPP didn't make it because people don't know what great things can you have with XMPP.

  14. SouL

    I know that we have still a lot of work to do in that regard, but for me seems like a loss in our side :/

  15. SouL

    Not meaning that we have to give up or anything, of course!

  16. zinid

    > did even know XMPP? I think the problem is NIH, not ignorance

  17. SouL

    Yeah, could be...

  18. goffi

    I think you can find easily what we have done after a quick search on any search engine.

  19. goffi

    SouL: after nearly 10 years, I'm not going to give up, trust me ;)

  20. goffi

    even if FOSS community is mostly ignoring us

  21. edhelas

    SouL I already talked several times with those guys, also proposed to work with them (and the XSF then)

  22. edhelas

    the thing is that we're not living in the same world, those guy are basically talking about synchronising articles and publications between nodes using HTTP and JSON, because they always done that (they're from the Web)

  23. edhelas

    which is a bit the opposite than us conceptualy wise

  24. zinid

    let's move XMPP to JSON

  25. edhelas

    there's always the proposal "yeah but we can build a transport/bridge" but we all know how bad it will be

  26. edhelas

    the big difference is that for Pubsub, it's a piece of XMPP, so we are offering way more than just publication synchronisation

  27. edhelas

    basically Diaspora is trying for years to add chat features to the social network, they are actually trying to use XMPP

  28. edhelas

    but because of their architecture it's really difficult

  29. pep.

    zinid: {xep 295} o/

  30. Bunneh

    zinid: JSON Encodings for XMPP (Humorous, Active, 2011-04-01) See: https://xmpp.org/extensions/xep-0295.html

  31. edhelas

    with Movim for example, creating links/features between the social part (Pubsub/Microblog) and the Chat part (MUC…) it's way more easier

  32. edhelas

    and everything is coming from the same stream, use the same protocol

  33. zinid

    pep., yeah, I know about that one

  34. zinid

    honestly, I think JSON is doomed as well, just like XML

  35. Zash

    Everything is doomed

  36. Zash

    Let's sing the doom song!

  37. edhelas

    even if it can be a mess between all the XEPs and their related features, it's still way more coherent in the end

  38. zinid

    after webassembly is widely adopted, javascript will start losing position along with json

  39. zinid

    so people don't learn

  40. zinid

    we have a great example with stuck XML: xmpp

  41. zinid

    then we will have examples with json

  42. Ge0rG

    I❤JSON. `{"secure":true,"secure":false}`

  43. edhelas feels like talking in the wind

  44. Ge0rG

    All of IT is doomed. Let's become potato farmers!

  45. Zash

    Ge0rG: YES!

  46. Ge0rG

    Oh wait, farming is infested with Bad IT as well... https://motherboard.vice.com/en_us/article/xykkkd/why-american-farmers-are-hacking-their-tractors-with-ukrainian-firmware

  47. zinid

    potato is not doomed?

  48. goffi

    even our CPUs are doomed anyway

  49. Ge0rG

    goffi: it's not the CPUs, it's the assumption that you can share your CPU between code that belongs to you and code that belongs to somebody else.

  50. Ge0rG

    and by the latter I mean all of the web and cloud and probably some other things.

  51. Holger

    Will we be competing with the potatoe thing? Zash invents a simple and popular way to grow potatoes, though only a single potatoe at a time? Kev won't show anyone how he does it but try to sell the potatoes to the military? zinid will note how all your potatoe taste like utter crap and will try to grow millions in parallel?

  52. zinid

    Holger, sounds doomy

  53. Ge0rG

    That analogy has gone too far.

  54. Holger

    Ge0rG: And I didn't even start with the client potatoes!

  55. Ge0rG

    Holger: maybe those are peaches instead?

  56. zinid

    "peaches"

  57. zinid

    there is a single "maybe peach", others are "rotten peaches"

  58. Ge0rG

    Those are called lemons. https://en.wikipedia.org/wiki/The_Market_for_Lemons

  59. Holger

    Whatever they are, they will only be eaten by other farmers.

  60. SouL is lost now.

  61. Holger

    Normal people will just stick to French fries.

  62. vanitasvitae

    Has anyone tried to make a potatoe battery powered xmpp client/server?

  63. pep.

    "xsf@muc.xmpp.org/@Alacer: 403 - modify: Messages from strangers are rejected" @Alacer you might want to fix this

  64. pep.

    I didn't send any message to you

  65. Zash

    I also got that

  66. Zash

    Bork?

  67. Ge0rG

    Me too!

  68. SouL

    Me too

  69. SouL

    It replied my messsages sent here

  70. SouL

    and at dino's MUC too

  71. zinid

    http://upload.zinid.ru/muc-errors.png

  72. zinid

    LOL :)

  73. Zash

    Hm, things I said... MUC bug?

  74. zinid

    Zash, no

  75. SouL

    That's what I'm saying, I got my messages back :)

  76. zinid

    Zash, the Alacer is not joined the room, but the room doesn't know this and continues to send messages, those are rejected by mod_block_stranges (because outgoing presence is lacking)

  77. Zash

    Appearing as PMs from @Alacer

  78. Zash

    Augh what

  79. zinid

    yes, Alacer has mod_block_strangers enabled on his server

  80. zinid

    at least this is my theory

  81. pep.

    zinid, you might want to give a try to poezio's dark theme btw :p

  82. zinid

    pep., nah thanks, I still need my eyes

  83. Ge0rG

    mod_block_strangers blocking type=groupchat must've been an awesome idea.

  84. Ge0rG

    Probably as good as rejecting type=error.

  85. Ge0rG

    <message from="xsf@muc.xmpp.org/@Alacer" to="georg@yax.im/poezio" type="error" xml:lang="en" id="999020f9-896b-49fb-8a2f-e820b3dab185-3B48E"><inactive xmlns="http://jabber.org/protocol/chatstates" /><delay xmlns="urn:xmpp:delay" stamp="2018-01-24T09:41:26.596476Z" from="jabber.at">Resent</delay><error type="modify" code="403"><policy-violation xmlns="urn:ietf:params:xml:ns:xmpp-stanzas" /><text xmlns="urn:ietf:params:xml:ns:xmpp-stanzas" xml:lang="en">Messages from strangers are rejected</text></error><body>Those are called lemons. https://en.wikipedia.org/wiki/The_Market_for_Lemons</body></message>

  86. Ge0rG

    zinid: you are right, "Messages from strangers are rejected"

  87. zinid

    yeah, and poezio renders them in a strange way

  88. zinid

    at least ejabberd is not involved here, so I'm clean :D

  89. zinid

    this time

  90. zinid

    ah, Alacer might be using ejabberd with mod_block_strangers

  91. zinid

    damn

  92. zinid

    Ge0rG, if we don't block groupchat, spammers can set type='groupchat' to send spam

  93. zinid

    and maybe some clients will render this

  94. Holger

    Yes it's not obvious to me that we wouldn't want to block groupchat.

  95. Holger

    Maybe not return an error for groupchat? But that's not obvious to me either.

  96. Zash

    Shouldn't Prosody kick them out when receiving an error?

  97. zinid

    yeah

  98. zinid

    another weirdness is why Alacer's server didn't send presence-unavailable to the conference

  99. zinid

    because the server is clearly available and sends stanzas

  100. zinid

    ah, oh, just noticed it, the server is jabber.at

  101. Holger

    The errors are returned to full JIDs, not to the bare MUC JID. Should the MUC service kick him nevertheless?

  102. Holger

    ejabberd didn't kick him either, I got the same error PMs in the Conversations and ejabberd MUCs.

  103. zinid

    really weird

  104. Ge0rG

    Holger: no, errors to full-JID are PM errors

  105. Ge0rG

    Holger: so it's useful to pass them on

  106. Ge0rG

    Maybe mod_block_strangers should error to the bare JID instead?

  107. Holger

    So this is all expected.

  108. Holger

    Hmmm.

  109. zinid

    Ge0rG, indeed, that's why they are rendered in a separate window of poezio, hehe

  110. Holger

    Or only return error to bare JID in case of groupchat?

  111. Ge0rG

    Holger: in case of groupchat, it should track directed presence and not consider those as "strangers"

  112. Holger

    It does.

  113. zinid

    Ge0rG, it does, I think there was some connection error or something and presence-unavailable has lost

  114. Holger

    Right.

  115. Ge0rG

    Then you need to send errors before processing the presence-unavailable?

  116. zinid

    what?

  117. Ge0rG

    It looks like the session collapsed.

  118. zinid

    ah, you mean in mod_block_strangers

  119. Ge0rG

    Yes

  120. Holger

    It took less than a day for this to happen after the jabber.at upgrade. I wonder how much we'll spam people this way. \o/

  121. Ge0rG

    XMPP, where the corner cases have corner cases.

  122. Holger

    mod_block_mod_block_stranger_errors

  123. Ge0rG

    What I need now is mod_block_siwssjabber.

  124. Ge0rG

    http://web.swissjabber.ch/ - "Apache2 Ubuntu Default Page" That's how a well-maintained XMPP server looks like.

  125. zinid

    Ge0rG, you're too picky

  126. Ge0rG

    zinid: I prefer the term discerning :P

  127. zinid

    sorry, my dictionary is lacking this term

  128. edhelas

    https://news.ycombinator.com/item?id=16222478 3. 2. 1. GO :D

  129. zinid

    Nice advertisement, but no

  130. edhelas

    > AFAIK XMPP is more geared towards IM than microblogging and it's very complex and difficult to get right due to many extensions.

  131. zinid

    And webshit is so much simpler, yeah

  132. edhelas

    :D

  133. jonasw

    I really like the idea of an entry-point XEP for the different "profiles" of XMPP

  134. jonasw

    somewhat like the compliance suites

  135. jonasw

    I still need to read through the posts on-list

  136. Ge0rG

    jonasw: aren't you the new compliance suite author? Make them better! 😀

  137. Dave Cridland

    jonasw, You can apply #557 and close #556 and #555, by the way. I'll get a vote started, at least, on #576 and #559. That's all I see there for Council's action for now, is that right?

  138. mathieui

    https://lwn.net/Articles/741218/ I missed this apparently

  139. edhelas

    https://mail.jabber.org/pipermail/standards/ down ?

  140. SamWhited

    Works for me

  141. edhelas

    ah no back now

  142. edhelas

    SamWhited thanks for the fix

  143. goffi

    ah ah "https://news.ycombinator.com/item?id=16223683" :D

  144. goffi

    not sure if it's a joke or serious

  145. SouL

    mathieui, I will read the article, thanks for sharing.

  146. zinid

    Oh, xmpp agents in the thread

  147. goffi

    zinid: yes me ;)

  148. zinid

    goffi: there is yet another one

  149. SamWhited

    > and it's definitely not complicated I feel like this is untrue. While I'm all for advocating XMPP, we need to acknowledge that we have a complexity problem and not tell people things like this (which will only make them dislike it even more when they try it and can't figure it out because it actually is complicated) </two-cents>

  150. pep.

    zinid, me

  151. pep.

    and jcbrand

  152. zinid

    Yeah, all criticism is so typical

  153. pep.

    zinid, I think SamWhited was replying to goffi?

  154. zinid

    pep.: Not sure who replied to whom 😁

  155. Kev

    I don't think there's any question that XMPP is complicated. There is a question about whether it's more complicated than it needs to be, although I don't think we're doing too badly on that front, for what we're providing.

  156. Ge0rG

    So some people claim the Blockchain is a solution to Zooko's Triange. Is that true?

  157. Kev

    If you list out all the things XMPP does and ask "Is it complicated to write a system that does X?" the answer is 'yes', whether you use XMPP or not.

  158. goffi

    SamWhited: what do you find complicated ? The basis is just 3 messages, and feature are well separated thanks to namespaces. Of course some features are complicated (Jingle), but it's normal for this kind of feature, and as Kev said, I don't think it's more complicated than needed (I specified for a decentralized network in my comment).

  159. goffi

    s/3 messages/3 stanza/

  160. zinid

    Kev: yes, it's to complicated for what it does, mostly due to priorities and resource routing, round trips, inconsistency with mam and stream management (this should be done by a single replication mechanism)

  161. zinid

    *too

  162. goffi

    priorities is a legacy feature that should be removed IMHO

  163. goffi

    and I would appreciate mandatory unique ids on message too, but it's hard to grow a standard like XMPP without this kind of little annoyances

  164. Ge0rG

    I'd kill for XMPP with GUID message IDs and MAM-Subscription-instead-of-Carbons

  165. zinid

    can't we redesign everything with with keeping some very basic compatiblity (probably on server-side gateways)?

  166. Ge0rG

    I'd just define GUID message IDs as mandatory and require all clients to be patched OR ELSE.

  167. Ge0rG

    But I'm pretty sure there will be some Council opposition.

  168. Kev

    It's slightly more complicated than that in the face of malicious clients, I suspect.

  169. Ge0rG

    Kev: I'm sure we can sort out that by restricting the scope to a single user's clients.

  170. Kev

    That would, sadly, break some of the things I want to do with GUID messages.

  171. Kev

    Which includes uncontroversial things like message URIs :)

  172. Ge0rG

    I could arrange with server-generated GUIDs, but then you'd say "but malicious servers"

  173. Kev

    I think we need to think through these things

  174. Kev

    Because message URIs (or similar) are a thing we could really do with.

  175. zinid

    not sure how GUID will help

  176. Ge0rG

    I'm not asking for much. All I want is to associate MUC reflections to what I sent and to properly merge history resyncs.

  177. zinid

    I'm thinking about monotonically increasing ids forming version vectors, used for database replication

  178. Ge0rG

    zinid: but then you can see how many messages I sent!

  179. zinid

    Ge0rG, true

  180. Ge0rG

    `SELECT _id FROM chats WHERE jid=? AND from_me=1 AND (message_id=? OR body=?) AND _id >= ?` - this just doesn't cut it.

  181. Kev

    Especially not if the server is rewriting message bodies.

  182. Ge0rG

    And it breaks on multi-line messages in IRC transports.

  183. zinid

    oh yes, IRC transports are very important, we cannot break them

  184. Ge0rG

    Kev: that wouldn't be a problem if MUC servers wouldn't rewrite message IDs.

  185. Kev

    Right.

  186. zinid

    Ge0rG, it should append it though

  187. Ge0rG

    zinid: what should append what, where?

  188. Kev

    It. There.

  189. Ge0rG

    Kev: ITYM "It. It. There."

  190. Kev

    That's for version 2.

  191. Ge0rG

    Oh.

  192. deckardstp

    hi