XSF Discussion - 2017-10-24

  1. matlag

    Yes, and apparently the take away for the moment is someone does not like your mascote

  2. Arc


  3. edhelas

    yup saw that, I answered on the discussion already

  4. edhelas

    at least people are not talking about Matrix :p

  5. Zash

    Great success

  6. zinid

    is matrix still alive?

  7. zinid

    I still remember the claim "Insanely scalable and performant next-generation server (Dendrite) on the horizon" and waiting patiently

  8. edhelas


  9. Zash

    You get a ruby thing that needs 2 gigs of memory for a few users

  10. edhelas

    RAM is meant to be used

  11. zinid


  12. zinid

    it's in Go

  13. Zash

    I mean the current server

  14. zinid

    the current is in python

  15. Zash

    Same same :P

  16. zinid

    yes, crap

  17. zinid

    and then they chose another crap

  18. zinid

    every server in Go I used is leaking and unstable as hell

  19. zinid

    damn, I cannot even read the MIX XEP, yet I have to implement it, wtf...

  20. edhelas

    I know that feeling

  21. dwd

    zinid, You're implementing MIX? Our implementation still doesn't entirely match the XEP. Too many things don't work well in practise.

  22. zinid

    dwd: I implemented the very first version, it's outdated of course

  23. zinid

    and looking at the current XEP I'm losing motivation, it's overly complex

  24. Ge0rG

    Maybe we can just fix MUC.

  25. dwd

    zinid, Some parts are fine. Others get a bit weird, mostly around proxy vs real jids.

  26. Zash

    Ge0rG: Make me motivated to work on mod_minimix or whatever I called it. Makes you join MUCs with your bare JID. I forget what parts got weird.

  27. zinid

    Ge0rG: I also tend to think it's easier to fix MUC

  28. zinid

    or implement "simple" muc

  29. Ge0rG

    Zash: write to standards@!

  30. Zash

    Ge0rG: Implementation first!

  31. Zash

    Ge0rG: Technically not requiring any standards yet. Protocol doesn't change.

  32. Ge0rG

    Zash: joining with a bare JID is a protocol change.

  33. Zash

    Does MUC forbid that?

  34. Ge0rG

    I'm pretty sure it does

  35. zinid


  36. Ge0rG

    okay, I'm not sure.

  37. Zash

    Arbitrary JID limitations should go away

  38. dwd

    No, it doesn't.

  39. Zash

    What if a server wants to join a room that doesn't have a node? :)

  40. dwd

    Oh, room jids have to be of specific forms.

  41. Ge0rG

    what if a server wants to join a room that runs at the bare JID of the server?

  42. Ge0rG

    dwd: you can join chat.yax.im as a MUC.

  43. dwd

    Ge0rG, You're not making the argument you think you are there.

  44. Ge0rG

    dwd: I'm not sure I wanted to make an argument at all

  45. dwd

    Ge0rG, First bullet-point in XEP-0045§3.

  46. Ge0rG

    dwd: that is not normative

  47. dwd

    Ge0rG, What? Why not?

  48. Zash

    > For the sake of backwards-compatibility [with] groupchat 1.0

  49. dwd

    Zash, That is indeed the rationale for the requirement stated.

  50. Ge0rG

    dwd: it merely states a result of some historical quirks, it doesn't require that a MUC MUST have that form.

  51. Zash

    dwd: How does that translate into bare host rooms being forbidden?

  52. dwd

    Ge0rG, You think unless it uses a mystical incantation of RFC 2119 you can ignore it?

  53. Ge0rG

    dwd: I think that "well written" and "XEP 0045" don't belong into the same sentence.

  54. dwd

    Zash, It says they're requirements. Seems they're probably required. Whether that's a good idea or not is an entirely different matter.

  55. Zash

    dwd: What, and here I was just grepping for MUST and ignored everything else! :)

  56. zinid

    yeah, this is very important problem: should a room have node part? it should be resolved asap!

  57. Zash

    dwd: But does that mean you need to support room@host or *only* room@host?

  58. Zash mumbles on about ambiguity

  59. Ge0rG

    dwd: there is no requirement that the room name must be non-empty

  60. dwd

    Zash, It's there as a statement of fact: "Each room is identified as a "room JID" <room@service>", so I'd say if a room cannot be so identified it's not conformant to the spec.

  61. dwd

    Ge0rG, Yes there is, the local-part of a jid cannot be zero-length.

  62. dwd

    Zash, I'm not saying this is a sensible requirement, or that it wouldn't work any other way. I'm merely saying that this is what the XEP says.

  63. Ge0rG

    except the XEP is not very clear in its wording

  64. zinid

    Ge0rG: "each room is identified"

  65. zinid

    isn't this clear?

  66. dwd

    Zash, But anyway. It says nothing I can find on the subject of what the occupant's real jids are (though it infers they're full jids a few times, it never states this as a requirement).

  67. Zash

    So MUC at bare host aren't rooms, but special magical hidden places for cool people only! :)

  68. zinid

    of course, "MUST be of <room@server>" would be clearly, but XEP authors prefer very long sentence with cryptic words :)

  69. Zash

    dwd: Shiny

  70. Ge0rG

    Zash: XEP authors are people, too

  71. Zash

    dwd: So nothing prevents a server from just sending one join stanza, then keeping track of which local resources have joined, forking incoming groupchats as needed

  72. Ge0rG

    Zash: so you are moving MSN from the MUC to the user's server

  73. dwd

    zinid, "Each room MUST be identified as" would be longer, not shorter. But FWIW, I really hate littering a document with RFC 2119 language, and prefer to use it more sparingly to highlight more subtle cases.

  74. Zash

    Which also means it can easily do MAM without a mess

  75. Zash

    Ge0rG: Pretty much, yes

  76. Ge0rG

    Zash: and MUC-PMs

  77. Ge0rG

    But it would probably break biboumi in surprising ways

  78. dwd

    Zash, More or less. But presence would remain a mess. And if you avoided that, you're getting very close to MIX.

  79. Zash

    dwd: Why I called my draft code "minimix" :)

  80. Ge0rG

    Zash: write it in a way that you can plug it into MUC or into the server, and fix nick changes etc.

  81. Ge0rG

    and presence priority.

  82. zinid

    dwd: I just wanted to say that would be great to have shorter sentences with simplier words, think about non-native speakers

  83. zinid

    dwd: I recall there is even RFC stating that

  84. Ge0rG

    zinid: there is a reason for so many Shakespeare references in the XEPs.

  85. dwd

    zinid, Yes, I agree simple sentences are better.

  86. zinid

    Ge0rG: to promote English culture?

  87. dwd

    zinid, Even though its an American doing so, most of the time.

  88. dwd

    zinid, I'd be tempted, myself, to use Tolstoy. More characters, for a start.

  89. zinid

    dwd: but this is clearly your move :P In other RFCs are just used Bob and Alice

  90. Ge0rG

    dwd: that reminds me of http://idlewords.com/talks/website_obesity.htm

  91. dwd

    zinid, Also, I read War and Peace (and various other Tolstoy, Chekov, Dostoyevsky) back in my teens and cannot remember the characters anymore.

  92. zinid

    dwd: lol, I didn't even read them :D

  93. dwd

    zinid, Well, I did read them in English, in fairness.

  94. SamWhited

    I think I skipped War and Peace in highschool, but Anna Karenina is still one of my favorite books.

  95. SamWhited

    zinid: what servers in Go gave you trouble? One of Go's features is that it makes resource leaks hard, so that surprises me.

  96. zinid

    SamWhited: ipfs

  97. zinid


  98. zinid

    one of the point is memory leaking

  99. zinid

    gc performance sucks also

  100. SamWhited

    How did they manage that? Go's gc can correct a 50 gig heap in under 10ms in most cases

  101. SamWhited


  102. zinid

    is it from Google's advertisement? :)

  103. Holger

    Complex systems run into memory leaks more or less easily no matter what the language, no?

  104. SamWhited

    No, it's from data I've seen in prod.

  105. zinid

    Holger: we have ejabberd with several month uptime without leaking for example

  106. zinid

    yes, the consumption might be high, but not leaking

  107. Holger

    zinid: Yes sure, I'm not saying all complex systems are leaking :-)

  108. Ge0rG

    All complex systems are leaking, just at different speeds ;)

  109. Holger

    But if you get something wrong, i.e. if you accumulate references to blobs over time, no GC in the world will save you from that.

  110. SamWhited

    I'm reasonably sure none of these things have anything to do with the language though; you can't have a traditional memory leak in go because there's gc, but if you always add things to an append only list and keep a reverence forever then obviously there's nothing the language can do

  111. SamWhited

    You can leak resources in Go, eg. forget to close a file descriptor or have an infinitely looping coroutine, but defer/close makes that pretty hard to do.

  112. zinid

    the point is that it doesn't matter how you leak it

  113. zinid

    also, would be great to have tools

  114. zinid

    to see where is leaking

  115. zinid

    and looking at IPFS guys there are no such tools :)

  116. SamWhited

    It does if you're going to blame the language, because if it's a bug I'd like to fix it. What kind of tools?

  117. SamWhited

    There is extensive tooling for that

  118. zinid


  119. zinid

    one year already, with several duplicates

  120. zinid

    you might want to suggest them the tool :)

  121. Zash

    Tooling for what, exactly?

  122. SamWhited

    I will, that sounds like the ipfs people just don't know what they're doing. Pprof can ve used to monitor the heap size, and all Go binaries have built in gc logging (you can set an environment variable and they'll dump runtime statistics)

  123. Holger

    I'm not sure Go servers will typically use goroutines in a similar way to Erlang processes. If so I'd want tools to query resource usage and state of individual goroutines (or groups of them), to modify the state, to kill them; or I'll return to Erlang :-)

  124. Zash

    I want tools too

  125. SamWhited

    Holger: I don't think it makes sense to do that, they're much lighter weight and you might have multiple per task, but you could.

  126. Holger

    Zash: Says the Lua programmer ... :-)

  127. Holger

    SamWhited: Much leighter weight than what? It makes a *lot* of sense in Erlang.

  128. SamWhited

    It doesn't make sense in Go, I mean. Go's coroutines are lighter weight.

  129. Holger

    Than what :-)

  130. Holger

    If you're a server, would you typically use a goroutine to handle a client connection?

  131. SamWhited

    Yes, maybe several.

  132. Holger

    If so you will of course take advantage of being able to introspect that at runtime.

  133. SamWhited

    Yes, it's certainly not as easy as in a dynamic language, but there are process monitoring tools to show you long running goroutines

  134. SamWhited

    Monitoring is common, manually killing or changing the state isn't, it's not a dynamic language. Although there are debuggers that can do that, I guess.

  135. SamWhited

    Well, monitoring is as easy, mutating isn't.

  136. zinid

    supervision can be implemented in any language

  137. zinid

    but seems like everyone copies idea of "goroutines" and think they got Erlang

  138. Ge0rG

    But everbody knows that you need overpriced special experts for Erlang and C++ projects.

  139. zinid

    lack of runtime introspection is the stopper factor for me in any such fancy language

  140. Holger

    They have hype. Go is a bit like Matrix :-)

  141. Holger

    (Well except that Go is actually successful.)

  142. zinid


  143. zinid

    fair remark :D

  144. edhelas

    Matrix is successfull, there's thousands of subscribers on their chatrooms

  145. Zash

    Shun the hype!

  146. zinid

    edhelas: they have even me there!

  147. zinid

    but I don't use Matrix...

  148. Zash

    edhelas: Is that an accurate indicator of success?

  149. edhelas

    zinid you're a spy on cover sent by the XSF ?

  150. zinid

    edhelas: I used to be a spy once (or twice)

  151. SamWhited

    I really wanted to like matrix, but the basic premise of the protocol is crap and they built it in an unsustainable way (and then were surprised when the money dried up)

  152. Zash

    SamWhited: Why did you want to like it?

  153. zinid

    "unsustainable way"? what do you mean? like they don't have enough resources to develop/promote/etc it?

  154. SamWhited

    Zash: So that I could have something that was an interoperable and federated standard that wasn't our broken crap, unfortunately it never became the alternative I hoped it would

  155. SamWhited

    zinid: they had enough resources, until they didn't. It's unsustainable because they expected one company to pay them for full time developers forever

  156. zinid


  157. SamWhited

    And we saw how that works out… not that they couldn't continue it in a more sustainable way now, but they seem to expect to still be able to be paid full time for it.

  158. Guus

    What irks me is that it's just one implementation - done by the same people that develop the standards.

  159. zinid

    well the idea that a single company controls a *federated* protocol is broken

  160. Guus

    not sure if it's broken - but it does not bode well.

  161. SamWhited

    Yah, I hoped they'd get other implementations later, but it wasn't a healthy ecosystem

  162. edhelas

    what about OStatus/ActivityPub ?

  163. zinid

    from innovative perspective I used to find Tox even more interesting than Matrix, but it's dead too

  164. zinid

    There is Ring.cx, but buggy as hell

  165. edhelas

    Ring is interesting but unfortunately their architecture prevent them to have advanced features

  166. edhelas

    like history, sync and profiles

  167. edhelas

    you cannot compare apples and oranges

  168. zinid

    edhelas: I think it's possible with dumb servers

  169. zinid

    Aka backup servers

  170. edhelas

    WhatsApp like

  171. zinid

    Well it scales good

  172. Zash

    Talking about p2p with servers?

  173. edhelas


  174. zinid

    Zash: hybrid

  175. zinid

    But more p2pish

  176. edhelas

    the whatsapp accounts are bound to the devices

  177. edhelas

    so to sync history between devices, or migrating them they use "backup servers"

  178. Zash

    Like Skype?

  179. zinid

    You see, if you have several devices you can synchronize yourself, you don't even need backups

  180. edhelas

    Skype is now a dumb centralized service since Microsoft bought them

  181. Zash

    Any client dev interested in doing client to client MAM?

  182. edhelas

    but why :D

  183. zinid

    And if all your devices offline and someone sent you a message, you will request it on login (via Delta from the contact)

  184. Zash

    edhelas: IIRC they switched it to the MSN infrastructure

  185. zinid

    So backups might not even be needed, at least for everyone

  186. zinid

    There is a problem with conferences in such system tho

  187. dwd

    As edhelas says, Skype centralized a while back, mostly because of mobile devices.

  188. zinid

    dwd: yes, mobile complicates everything, especially ios restrictions