XSF Discussion - 2019-02-22


  1. Andrew Nenakhov

    https://twitter.com/brunoborges/status/1098472238469111808?s=19

  2. Andrew Nenakhov

    About that recent matrix discussion )

  3. Zash

    > Pick your markup YAML ain't markup. Netiher is JSON.

  4. Guus

    Can we stop comparing ourselves to Matrix? Let them be.

  5. Ge0rG

    YAML. Where MAC address strings become sexagesimal (yes, this is a word. no, it's not a dirty word): https://yaml.org/type/int.html > canonical: 685230 > sexagesimal: 190:20:30

  6. jubalh

    do jids have to be lowercase?

  7. Ge0rG

    jubalh: no, but IIRC you need to lowercase the bare JID part for comparisons

  8. Ge0rG

    TL;DR: it's a deep deep rabbit hole... start at https://tools.ietf.org/html/rfc7622#section-3.1

  9. zinid

    the whole idea of case-insensitivity is broken completely

  10. Zash

    That's the PRECIS version?

  11. zinid

    putting it on servers is the worst thing invented

  12. Zash

    Does anyone implement PRECIS yet?

  13. zinid

    Zash, not me 🙂

  14. Zash

    It is indeed a deep rabbit hole, and you will find only sadness at the bottom.

  15. zinid

    I barely can understand what is written in the PRECIS spec

  16. zinid

    like some alien wrote that for dogs

  17. Zash

    Hm? IIRC it's not too different from STRINGPREP

  18. zinid

    well I didn't read stringprep either, just took a ready-to-use table

  19. MattJ

    I think a problem with PRECIS is that it varies by Unicode version

  20. MattJ

    which is a good idea in theory (no table to go out of data, all the work is done by the maintainers of Unicode)

  21. MattJ

    But in practice it will cause interop problems on the network, as everyone will be using different versions

  22. Zash

    Didn't that problem exist already?

  23. MattJ

    Also some JIDs that are valid one year will become invalid the next year

  24. Zash

    Do you remember robot face?

  25. zinid

    Zash, I think there is a problem with emojis in resources

  26. zinid

    does it count?

  27. MattJ

    Zash, different issue

  28. MattJ

    Related, but different

  29. Zash

    Sadness.

  30. Ge0rG

    Emojis in resources are also Unicode code points which may or may not be supported by a given XMPP implementation

  31. Ge0rG

    Joining a MUC as 🤖 will make certain clients quit and some servers drop s2s.

  32. Ge0rG

    And don't even think about sending a MUC message from that nickname

  33. MattJ

    But that's not a problem with the definition of stringprep, is it?

  34. zinid

    I like how virtually nobody understands exactly why there is a problem with emojis in resources 😀

  35. Zash

    That was a problem with some library allowing things by default and some others disallowing by default?

  36. zinid

    I honestly have no idea

  37. jubalh

    Ge0rG, thx

  38. MattJ

    Zash, right

  39. Ge0rG

    And then there are things like https://discourse.igniterealtime.org/t/smack-disconnects-if-priority-is-out-of-range/73401

  40. Link Mauve

    Ge0rG, https://issues.prosody.im/921

  41. Ge0rG

    Link Mauve: what if prosody receives that via s2s? Drop the link?

  42. Ge0rG

    Link Mauve: what about <show>fubar</show> or the invalid MUC JIDs on conference.jabber.org?

  43. Zash

    Drop the link and report them to the authorities

  44. Ge0rG is in a world of sad. https://discourse.igniterealtime.org/t/gajim-presence-can-dos-xmpptcpconnection/84179/5

  45. pep.

    Zash, authorities in a decentralized world :

  46. pep.

    Zash, authorities in a decentralized world :P

  47. zinid

    pep., let's encrypt

  48. pep.

    True

  49. Link Mauve

    Ge0rG, fix the emitting server’s software, then use 0157 to tell the sysadmin of the emitting server to update.

  50. pep.

    And sad at the same time

  51. Zash

    pep.: Our one true glob, ICANN

  52. Ge0rG

    Error> No Contact Addresses for jabber.org

  53. pep.

    Zash, We need blockchains, namecoin!

  54. zinid

    pep., I consider this as a natural limitation, like a CAP theorem for example, you cannot do anything with it

  55. zinid

    seems like nature decided "you cannot go fully decentralized, muahahaha"

  56. Zash

    pep.: Someone will just end up with 51% of the power

  57. zinid

    yeah, the Byzantine Generals theorem sums it up clearly

  58. pep.

    And in practice it's not even 51 but less than that :/

  59. zinid

    1/3 afair

  60. zinid

    according to the Byzantine theorem

  61. theTedd

    hi kids

  62. pep.

    hey there

  63. theTedd

    could Ge0rG and jonas’ confirm/deny their vote for PR #744 -- -1 (as-is, +1 with "thereby taking up the role of XEP author" removed)

  64. zinid

    > https://issues.prosody.im/921 Zash heh, we don't validate that in ejabberd, I added the check, but then reverted because there was a lot of scream

  65. Zash

    zinid: What kind of check?

  66. zinid

    Zash, [-127, 127]

  67. Zash

    zinid: And what kind of action?

  68. Link Mauve

    -128*

  69. zinid

    Zash, back then there was a lot of nerdy clients which allow a user to set any priority, so some of snow flakes set it to 666 or 1024

  70. Zash

    I mean, did you reject them or rewrite into that range?

  71. zinid

    Zash, reject with stanza error (not stream)

  72. Zash

    There's a setting in Prosody that rewrites all presence priority to zero, which don't think anyone has had all that much truoble with.

  73. zinid

    I can fix it instantly since the check is in a single place, that's a one-line commit, but I'm not sure

  74. jonas’ throws praise at theTedd

  75. jonas’

    I’m at work right now though and won’t be able to clarify until tomorrow

  76. Andrew Nenakhov

    I think that priorities are an outdated concept.

  77. Andrew Nenakhov

    So best value is zero.

  78. theTedd

    okay, no problem

  79. zinid

    Andrew Nenakhov, yeah, that's why I started the discussion now

  80. Andrew Nenakhov

    👍

  81. Ge0rG

    theTedd: IIRC the introduction of the shepherd was an accepted solution in the council meeting two weeks ago?

  82. zinid

    Andrew Nenakhov, if priorities are kinda meaningless nowadays, it's better to be RFC compliant in order not to confuse other implementaions

  83. theTedd

    I was just checking whether the changes satisfied your voting condition

  84. Ge0rG

    zinid [13:16]: > Zash, reject with stanza error (not stream) And if you received that from a MUC participant, you get yourself kicked?

  85. jonas’

    theTedd, in the end, the vote on #744 (if I’m not mixing things up) by council is informational only, anyways.

  86. zinid

    Ge0rG, MUC what? I just merged MIX into ejabberd 😀

  87. Andrew Nenakhov

    zinid, we set them to zero by default and are thinking to make in non changeable.

  88. zinid

    Andrew Nenakhov, yeah, that's fine

  89. Zash

    Ge0rG: Something something liberal about what you receive, except ugh

  90. Ge0rG

    zinid: ah, then you can `git rm mod_muc.erl` now

  91. zinid

    Ge0rG, sure I'll do after mod_mix_muc become a thing(y)

  92. theTedd

    jonas’, meaning the PR is accepted or not?

  93. jonas’

    theTedd, board voted on it

  94. jonas’

    one would have to check board votes

  95. Ge0rG

    I have a nerd use case for negative priority, because my main client can't mam and I don't want to consume messages with the other clients when the main one is offline.

  96. theTedd

    jonas’, so what was the council vote for?

  97. jonas’

    theTedd, to give board an idea on what we want

  98. jonas’

    *if I recall correctly*

  99. Zash

    So priority should be in (-1, 0)

  100. theTedd

    jonas’, understood

  101. pep.

    Zash, True/False?

  102. Ge0rG

    I'm +1 on 744, but it's not formally binding

  103. theTedd

    Ge0rG, thanks

  104. Zash

    Alternatively, don't send presence.

  105. Ge0rG

    Zash: did I mention "implementation defined message routing rules" yet?

  106. Zash

    Ge0rG: mod_firewall with an xmpp interface next?

  107. Zash

    Something's gotta replace privacy lists!

  108. zinid

    by privacy lists!

  109. Ge0rG

    Replace RFC 6120 with mod_firewall?

  110. Matthew wishes folk remembered that the enemy (if any) here are the proprietary locked-down silos

  111. Matthew

    and the open decentralised comms community might do better to support each other than try to stab each other in the neck...

  112. pep.

    Agreed. There is a history of splitting efforts nonetheless in the free software community, and that's meh

  113. zinid

    Matthew, really, so you think IM fragmentation will help fighting with silos?

  114. Matthew

    does this conversation look fragmented to you?

  115. MattJ

    +1 :)

  116. zinid

    Matthew, what are you talking about?

  117. pep.

    zinid, he's probably joined from matrix :)

  118. zinid

    pep., wow

  119. Matthew

    i am. talking from one open network to another

  120. Matthew

    albeit by a bridge

  121. zinid

    Matthew, so your suggestion is to build many IM networks and connect them via hacky gateways?

  122. zinid

    dude, I wrote gateways to MSN, ICQ, AIM and Yahoo back then

  123. zinid

    so I will never buy the argument, I know how shitty they are

  124. Matthew

    I'm saying that it's healthy to experiment with new approaches in any field or technology. Perhaps the new stuff works; perhaps it doesn't; perhaps it dies off and gets incorporated elsewhere. And yeah, i think it's great when people experiment with new networks - e.g. Briar and Cwtch and stuff are insanely cool.

  125. zinid

    please, spare my time

  126. Matthew

    and yeah, bridges are never going to be perfect, but at least we have the option

  127. Matthew

    and empirically they work well enough for a convo like this.

  128. zinid

    "new approaches", lmao

  129. MattJ

    zinid, Matrix is a pretty different model to XMPP, so yeah

  130. MattJ

    I happen to personally prefer the XMPP model, but I have nothing against people trying others :)

  131. zinid

    sorry, I cannot reply to you, you're not joined 😀

  132. Matthew

    zinid: i'm not trying to waste your time; just pointing out (objectively) that being grumpy and "how dare people try to build new IM protocols" all over HN does not reflect at all well on the XMPP community

  133. zinid

    Matthew, I don't represent the community

  134. Matthew

    i somehow doubt your audience sees it that way.

  135. Matthew returns to his stuff anyhoo

  136. Guus

    Matthew, remind me to buy you a beer.

  137. Matthew

    Guus: i will come claim chimay next year in brussels ;P

  138. Guus

    Matthew last month, I discovered something called "beer mania" there. I'm not to worried. 😃

  139. Andrew Nenakhov

    Building matrix is nih syndrome. Makes sense from business perspective though

  140. Guus

    Andrew Nenakhov even if that were true - point that out over and over and over and over and over again does not do anyone any good.

  141. Guus

    Andrew Nenakhov even if that were true - pointing that out over and over and over and over and over again does not do anyone any good.

  142. waqas agrees with Guus

  143. Guus

    And probably makes the one doing the pointing out looking worse than the one being pointed at.

  144. zinid

    if everyone agrees with everyone, what's the point of the discussion?

  145. Guus

    And probably makes the one doing the pointing out look worse than the one being pointed at.

  146. zinid

    I personally agree with Andrew Nenakhov - this is technically speaking NIH

  147. zinid

    and I'm the last guy to blame as XMPP diehard, ejabberd supports XMPP, SIP and MQTT (since 19.02, coming next week)

  148. zinid

    and we considered implementing Matrix btw

  149. waqas

    XMPP was IRC NIH'd with XML. I suspect some still feel that way.

  150. zinid

    waqas, true, lessons learnt

  151. Guus

    IRC is NIH'd multiplayer notepad.

  152. waqas

    There are a few xkcd's that apply

  153. Guus

    my point is that it's fine to prefer XMPP over Matrix (I do) - but let's not continue a pointless argument over it.

  154. zinid

    anyone who agrees, please enlighten me what's the point in producing many IM networks and building gateways

  155. waqas

    As a user, I suspect many of us think of UIs and not underlying tech. With that mindset, the point would be improved UIs (since I personally feel all of them range from mediocre to annoying).

  156. zinid

    well, I'm not a user here

  157. zinid

    and Matthew asked to stop fighting or something, did he asked the "users"?

  158. MattJ

    zinid, what's the point of any software development? You know ejabberd wasn't the first jabber server...

  159. Andrew Nenakhov

    Some time ago when I was young and stupid I thought that xmpp transports is a good idea to bring more people on board

  160. zinid

    MattJ, there is a difference in producing software and standards

  161. MattJ

    I don't know why git exists when we were happy with rcs, etc.

  162. waqas

    Andrew Nenakhov: Have you stopped being young and stupid? :)

  163. Andrew Nenakhov

    Now I know that it just strengthens silo's network effects

  164. zinid

    waqas, nice ad hominem 🙂

  165. Andrew Nenakhov

    Yes, now I'm significantly more experienced. )

  166. Andrew Nenakhov

    Also, youth is a trait that you inevitably lose.

  167. waqas

    The effects of transports are interesting. I still believe in them in that they strengthen the network that has them.

  168. Seve

    From what I feel, bridges are just usually used by people who do not want to be in the silo, and they are a minority. But I'm no expert on the topic.

  169. MattJ

    waqas, I don't believe in them (I used to)

  170. Andrew Nenakhov

    I think they weaken XMPPs network effect

  171. MattJ

    They're 9 times out of 10 a far worse experience than the native one

  172. waqas

    Yes, and that's the problem ^

  173. Link Mauve

    IRC is the 10th time. :p

  174. pep.

    Something something lowest common denominator

  175. zinid

    so we think this time we will solve the problem with transports

  176. MattJ

    Link Mauve, ...

  177. pep.

    :D

  178. MattJ

    Link Mauve, XMPP->IRC->Matrix is how I've been in Matrix rooms for some time now

  179. waqas

    I believe XMPP as a technology had been a low level features that the IM networks of last decade had. That's why transports could do a reasonable job at the time, and I did use them with MSN/Yahoo/etc. That's no longer true for IM networks of today.

  180. MattJ

    Works pretty well usually

  181. Link Mauve

    MattJ, I guess so.

  182. Link Mauve

    My point was more that IRC is a terrible user experience out of the box, and that gateways are almost always an improvement over it.

  183. MattJ

    Link Mauve, sure

  184. waqas

    The XMPP network effect isn't being particularly helpful these days, as I think the proprietary platforms' network effects are an order of magnitude stronger than any of the non-proprietary ones.

  185. pep.

    XMPP, network effect?

  186. pep.

    What's that

  187. MattJ

    pep., the thing that saddled us with the Pidgin users

  188. Seve

    Haha

  189. pep.

    Matthew, well played, I see you've started another meaningful discussion :P

  190. waqas

    MattJ: To clarify, do we want the pidgin users or not?

  191. zinid

    pep., +1

  192. Guus

    Pidgin provides such poor XMPP experience, that it's chasing the users away.

  193. zinid

    started and hides

  194. Seve

    +1 to Guus, I could feel that in my own skin at FOSDEM

  195. Seve

    people making statements that weren't true

  196. Seve

    based on their experience using Pidgin

  197. pep.

    waqas, we want the users, we don't want pidgin

  198. zinid

    so we will also build voip gateways to SIP, i.e. Jingle<->SIP

  199. zinid

    and Jingle<->Matrix

  200. zinid

    do I understand correctly the postion?

  201. zinid

    what else?

  202. Guus

    gotta pick up the kids. ttyl

  203. zinid

    what a waste of human resources...

  204. Guus

    whut? My kids?

  205. waqas

    That's not a nice thing to say zinid

  206. Seve

    Come on guys :D

  207. zinid

    wut? I didn't mean to say anything about kids

  208. zinid

    relax guys

  209. pep.

    zinid, sarcasm.

  210. zinid

    wtf is wrong with you?

  211. Guus

    I was joking 🙂

  212. Guus

    (well, trying to, at least)

  213. Guus

    ok, off with me. Later

  214. zinid

    oh, Matthew decided to continue debating with me at HN

  215. Ge0rG

    zinid: can you please add to all your public statements a sentence that you are not associated with the xmpp community? 😁

  216. pep.

    What does that mean to be associated to the XMPP community

  217. Ge0rG

    pep.: I'm speaking of this Matthew [17:09]: > zinid: i'm not trying to waste your time; just pointing out (objectively) that being grumpy and "how dare people try to build new IM protocols" all over HN does not reflect at all well on the XMPP community

  218. Seve

    zinid, could you share the link to the discussion, please?

  219. zinid

    Seve, no

  220. Ge0rG

    It doesn't mean anything to us in here.

  221. zinid

    I did this like 10 times today already

  222. zinid

    > how dare people try to build new IM protocols indeed, how dare whatsapp building IM protocols. But let's fight with them!

  223. zinid

    just contradictions in every sentences

  224. MattJ

    Seve, https://news.ycombinator.com/item?id=19216527

  225. Seve

    Thank you MattJ, very appreciated

  226. mrDoctorWho

    KDE community also created a matrix server. They said that there was no foss replacement for IRC and now there is

  227. pep.

    FUD, FUD all around

  228. j.r

    mrDoctorWho: XMPP is also a good replacement

  229. Link Mauve

    mrDoctorWho, I have some @kde.org people in my roster. :p

  230. Link Mauve

    In my XMPP roster.

  231. j.r

    > mrDoctorWho: XMPP is also a good replacement But people don't unterstand

  232. mrDoctorWho

    j.r: I totally agree with you

  233. Seve

    I haven't read their announcement yet, but I feel they already had a decision before even looking up for solutions/alternatives.

  234. zinid

    relax, we have gateways 😀

  235. waqas

    Hey, sometimes you just want to make something new, and you feel it's different from what's already out there

  236. waqas

    I'm not sure I've ever seen anyone succeed in trying to stop people from doing that, despite many wanting to

  237. mathieui wishes good luck to Matthew in his interactions with zinid

  238. moparisthebest

    honestly I don't really have a problem with competing open protocols, that's how you narrow down to the best one, it'd be pretty crazy to think XMPP is the best there will ever be

  239. zinid

    so?

  240. zinid

    Matthew started with "let's just define our enemy", how does that relate to building something new?

  241. moparisthebest

    it's the closed ones that trap users with lock-in that I despise

  242. moparisthebest

    personally I still like XMPP best from what I've seen so far so you don't need to boot me from the XSF :D

  243. MattJ

    zinid, I don't really know what you like about XMPP, to be honest

  244. MattJ

    zinid, to me, I value users being able to choose the client and service that they use, and service operators being able to choose the software they use

  245. MattJ

    I don't particularly value the XML, or any of the other stuff (which I assume you also don't)

  246. zinid

    MattJ, I don't value XMPP quite high honestly except it being a standard

  247. zinid

    MattJ, yeah, I also value users choosing their phones by what battery connector it has

  248. MattJ

    If Matrix wants to do their own thing, but also bridge to XMPP, I don't see how that's a problem

  249. MattJ

    It's more choice for users, and service operators

  250. zinid

    I also would love the situation when every fridge has it's own power supply

  251. MattJ

    It would be bad if it wasn't bridged (which it wasn't for a long time), but that is changing

  252. zinid

    and when you have a fridge from Samsung you cannot store stuff in the fridge of your relative's Phillips

  253. MattJ

    From the goals and values perspective, Matrix aligns pretty closely with XMPP. More than any other attempt at "free as in freedom" communication networks around

  254. zinid

    that's a true choice and freedom for users

  255. zinid

    well I disagree

  256. MattJ

    Maybe you don't realise the goals and values of the original Jabber project

  257. MattJ

    which were pretty much identical to Matrix today

  258. zinid

    I don't care about original goals, please again note I like cooperation via standardization, not a competition

  259. zinid

    if you think that competition is always good then go compete for food with your children

  260. MattJ

    And that is one thing that actually annoys *me* - that Matrix folk say "we're all about bridging though!", which is *exactly* where XMPP's roots are too

  261. waqas

    zinid: I'm a bit confused, can you point out the the main thing you disagree with?

  262. MattJ

    But that's just a difference of perspective

  263. pep.

    MattJ, same here

  264. pep.

    (re bridging)

  265. MattJ

    I don't go ranting on HN about it, and I don't bash their project, and I love to see the collaboration happening

  266. zinid

    MattJ, the point is they don't want cooperate

  267. MattJ

    I don't know what silo you are living in, but that's not true

  268. MattJ

    They are cooperating

  269. zinid

    what silo I'm living in...

  270. zinid

    gosh

  271. Seve

    zinid, if they wanted to cooperate they would just work with XMPP, you mean?

  272. MattJ

    I mean, they are right in this XSF MUC

  273. zinid

    Seve, yes

  274. zinid

    Seve, I don't see anything that stops XMPP from implementing that crazy distributed thing

  275. zinid

    that's the only "advantage" I see, at least what they *now* claim

  276. MattJ

    zinid, if XMPP started today, it wouldn't use XML I'm quite sure

  277. zinid

    MattJ, so let's change the wire format, I suggested that in 2006 IIRC

  278. MattJ

    and XML isn't even one of the things I dislike about XMPP :)

  279. MattJ

    I'm just saying, new projects aren't forced to use old stuff

  280. zinid

    abstract data structures from encoding. BTW, Matrix doesn't do that so it will be "outdated" in a next decade

  281. MattJ

    They are bridging, and that's pretty much all I care about, so we don't produce fragmentation

  282. zinid

    MattJ, are they going to bridge Jingle? Our new brand stuff whatever it is?

  283. MattJ

    zinid, why not? If XMPP is so successful, they only have to lose by not bridging to it :)

  284. zinid

    lmao

  285. zinid

    it will be definitely successfull when every HN user claims it's so bad in comparison to Matrix 😀

  286. MattJ

    Just so you know, HN isn't representative of the general population

  287. zinid

    I knew you say that

  288. MattJ

    Whether the people on HN favour one thing or another isn't a good indication of reality, or whether X is better than Y

  289. zinid

    so, XMPP will be definitely successful, that's only the way to get Matrix bridges?

  290. zinid

    so you bet on it?

  291. MattJ

    There are Matrix bridges now

  292. zinid

    I know, but I asked about what will be next

  293. MattJ

    You mentioned Jingle specifically - I don't think Matrix has user->user calling fully sorted out yet, but to be honest neither do we (look at clients dropping Jingle support recently)

  294. zinid

    yeah, I mentioned Jingle for a reason, it's just a classical example of wheel reinvention

  295. MattJ

    Peak Jingle was when the N900 was a thing

  296. MattJ

    and it had built-in XMPP and Jingle calling out of the box, and it just worked

  297. zinid

    anyway, Jingle is just an example

  298. zinid

    let's not change the discussion subject

  299. MattJ

    Sure, but what else? The discussion was the bridging, which I think is a core part of this debate

  300. zinid

    let's say we go MIX

  301. MattJ

    If a good quality bridge exists, the fragmentation argument is not an issue

  302. zinid

    MattJ, what about we go p2p?

  303. zinid

    if, if, if

  304. MattJ

    Treat the bridge just like any of the other clients we have to convince to implement MIX

  305. zinid

    that's more people to convince

  306. MattJ

    And we already have Xabber which never will (perhaps), and so on

  307. pep.

    (Talking about jingle, I found that a few days ago: https://blogs.gnome.org/danni/2010/06/07/muji-multi-user-jingle/)

  308. zinid

    so we will have nothing new?

  309. MattJ

    so let's figure out MIX and then decide whether it's worth Matrix bridges supporting it, eh

  310. MattJ

    Like I said, if we do cool stuff that works, it's in the best interests of Matrix to bridge that stuff

  311. zinid

    if?

  312. zinid

    if, probably

  313. MattJ

    If we don't, XMPP is pretty irrelevant and Matrix can drop the bridge and everyone can just use Matrix

  314. zinid

    you see, that's the main problem with gateways, you add another element of complexity

  315. MattJ

    so it's up to us, nothing to do with Matrix

  316. zinid

    so if they drop the network is fragmented?

  317. pep.

    So we're back to resources in the XMPP community

  318. MattJ

    They will drop if XMPP isn't worth supporting, sure, why wouldn't they?

  319. MattJ

    I can name many smaller networks XMPP doesn't bridge to, because nobody cares enough

  320. zinid

    yeah, and we will end up with two IM networks

  321. MattJ

    Some of them are even Standards

  322. zinid

    two irrelevant IM networks 🙂

  323. zinid

    because I doubt any of us will attract masses

  324. MattJ

    *shrug*

  325. MattJ

    Not with that attitude :)

  326. zinid

    that's pragmatism

  327. zinid

    ~20 years and where are we?

  328. MattJ

    and not by fighting with each other on HN, or anywhere

  329. zinid

    why do you calling this a fight?

  330. MattJ

    Because that's what it looks like, to many people

  331. zinid

    that's just a debate, actually they try to move the discussion to fight

  332. MattJ

    Maybe you don't intend it to

  333. zinid

    also, what I'm saying at HN is irrelevant according to you, even you put me in the XMPP community

  334. zinid

    *even if

  335. zinid

    and I personally don't "fight" with them elsewhere 😀

  336. MattJ

    It's not irrelevant to the people on HN, I said HN was not a true indicator of anything outside of HN

  337. MattJ

    But many developers are there for example

  338. zinid

    whatever, I think users will choose the best one, let them decide by reading "fights"

  339. MattJ

    That's what I'm concerned about :)

  340. zinid

    about what part of the statement? 🙂

  341. zinid

    that they will choose the best one? yeah, that's what you want, do I get it right?

  342. MattJ

    Because I think you think those "fights" make XMPP look good

  343. MattJ

    or make Matrix look bad

  344. zinid

    I already said I don't think so, again, I don't care that much, I mostly do that for fun

  345. MattJ

    Many people reading those will just see someone who refuses to accept the new technology replacing their favourite one

  346. MattJ

    something that happens all the time on HN...

  347. zinid

    new technology... okay

  348. MattJ

    XMPP is 15 years older than Matrix, yes

  349. zinid

    let them choose matrix, and I will continue "fighting" because I find that funny enough

  350. zinid

    I also can claim that I'm not the part of XMPP community! In my every post 😀

  351. pep.

    Anybody can claim anything!

  352. zinid

    Anybody can claim the person is in the community!

  353. zinid

    that's a nice ad hominem argument btw

  354. zinid

    people read that and think "ah, he is from that outdated 20 y.o. XML Cobol taliban", I see

  355. MattJ

    zinid, are you saying that I'm attacking you by saying this?

  356. MattJ

    I'm not. I know you rant about XMPP daily, trust me, I don't think you are an XMPP fanboy :)

  357. zinid

    MattJ, no you attacked me once by saying I'm living in kinda "silo"

  358. Andrew Nenakhov

    MattJ, why would Xabber implement this stupid mix?

  359. MattJ

    zinid, I apologise, my point was that you didn't seem to be accepting the visible facts (that cooperation between the communities is happening)

  360. Andrew Nenakhov

    It already has something far better

  361. zinid

    MattJ, that's not very acceptable for us cooperation

  362. Andrew Nenakhov

    If it has some level of muc compatibility it's failure

  363. zinid

    MattJ, it's like a cooperation with a human and linked dog

  364. waqas

    us?

  365. zinid

    oh shi~

  366. MattJ

    Andrew Nenakhov, I don't want to start yet another debate :)

  367. Ge0rG

    zinid: now you are trolling... 🙄

  368. MattJ

    Andrew Nenakhov, I wasn't judging you for implementing MIX or not, I was just using you as an example of a project that will not implement MIX in a hurry

  369. moparisthebest

    Moreover unless you read Russian you can't yet MattJ :)

  370. MattJ

    Andrew Nenakhov, FWIW I also have not implemented MIX, and have no concrete plans to

  371. moparisthebest

    Need specs

  372. zinid

    Ge0rG, thanks for your thoughtful input

  373. MattJ

    moparisthebest, there are "specs" on the mailing list

  374. MattJ

    i.e. an overview of how it works without the XML parts

  375. MattJ

    I know enough

  376. zinid

    what I see is that community really falls apart actually, the future direction is quite moot

  377. zinid

    "community" is implementors and standard writers

  378. Seve

    zinid, what are we missing in that regard?

  379. Ge0rG

    zinid: I think it's really awesome that Matthew and Half-ShotX are here and doing meaningful work on bridging the communities. Yes, bridges are imperfect. However, the ugliness depends on the mismatch between the feature sets, and I think the mismatch between matrix and xmpp isn't that large

  380. MattJ

    zinid, the summit this year had great attendance, it had great discussions and I assume we'll see standards and implementation progress this year

  381. zinid

    MattJ, so what to do with MIX?

  382. zinid

    Daniel convinced me to implement it

  383. Ge0rG

    Maybe we can learn something from matrix about reliable message delivery. That's something I have failed to fix in XMPP for a decade now.

  384. Andrew Nenakhov

    Btw, our glorious group chat protocol can be supported at basic level by processing just two stanza types. Or even one.

  385. Andrew Nenakhov

    Adding support is like, maybe an hour.

  386. Andrew Nenakhov

    Of course without viewing participants , etc

  387. zinid

    MattJ, who will resolve the disambiguation with MIX?

  388. lovetox

    zinid i look forward to the realease, i also want to play with it

  389. MattJ

    zinid, implementers, as always

  390. MattJ

    You potentially already did, by providing the first open server implementation

  391. zinid

    MattJ, I see at least one here who is opposing

  392. MattJ

    There are always people who oppose, even within communities... that's a fact of life, not the end of the road

  393. zinid

    lovetox, the branch is merged, the release is next week with 95% guarantee 😀

  394. waqas

    Rough consensus and running code is how XMPP has mostly operated

  395. MattJ

    A community isn't a group of people who always agree 100% on everything

  396. MattJ

    It's a group of people who generally have similar goals and values

  397. zinid

    MattJ, I understand there are always opposing, please. But what you suggest is completely stochastic process which I disagree with

  398. MattJ

    What?

  399. zinid

    like that implemented, this implemented, those two didn't implement

  400. MattJ

    If ejabberd and Conversations implements MIX, that's a huge milestone, no?

  401. MattJ

    It has to start somewhere

  402. MattJ

    Servers will upgrade, and MIX will be supported

  403. zinid

    MattJ, yes, but I don't see any consensus here, shouldn't I?

  404. zinid

    whatever

  405. moparisthebest

    that takes time

  406. zinid

    you will answer something very general like always

  407. MattJ

    Sure, probably

  408. zinid

    moparisthebest, that took already 3 years

  409. moparisthebest

    right, and maybe others will implement soon, not so soon, or never, and then you'll have consensus

  410. zinid

    so stochastic process, okay

  411. zinid

    the point is that back then it was not so stochastic, so Matrix indeed looks much better here

  412. MattJ

    zinid, what do you want the XSF to do? Kidnap developers of projects and force them to implement stuff? :)

  413. waqas

    It'd be effective...

  414. MattJ

    That's a signficant advantage that Matrix (currently) has, agility due to the mostly single implementation and deployment

  415. MattJ

    I think they know that, and are making the most of it

  416. zinid

    MattJ, I ask the XSF to produce a recommendation

  417. MattJ

    Compliance Suites

  418. zinid

    no need to go with absurd like kidnapping

  419. zinid

    MattJ, I don't see MIX there

  420. MattJ

    So that's the recommendation

  421. zinid

    so MIX is not recommended?

  422. MattJ

    A 2018 XMPP implementation does not need to support MIX

  423. Ge0rG

    zinid: propose it

  424. MattJ

    Which is sensible given that there is no stable implementation of it currently

  425. zinid

    Ge0rG, and what will you do? I'm already working on 5 XEPs, so such arguments don't work anymore to me 🙂

  426. Ge0rG

    zinid: you might still get into last call for 2019

  427. zinid

    going in circles...

  428. zinid

    and you conveniently ignored the question about you doing what 🙂

  429. Ge0rG

    zinid: im not going to implement mix yet

  430. zinid

    Ge0rG, but you can "propose" something (not sure what)

  431. Ge0rG

    zinid: send a mail to standards@ and ask for inclusion of mix into compliance Suite 2019

  432. zinid

    I'm really lost, who can clarify: 1) XSF doesn't produce recommendation without implementations. But constantly discussing something at endless meetings to come to some agreement? 2) XSF is only a standardization body, but it doesn't produce specs 3) XSF continues telling about the mythical community, but doesn't represent any do I get it right? What is it now responsible for? I see only XEP submitting process, which takes a lot of time looking at my own contributions, but that's kinda okay: lack of time, lazyness, understaffed

  433. zinid

    Ge0rG, and to end up in endless discussions?

  434. zinid

    like the one I had recently with you: "remove that MUST!!!"

  435. Zash

    zinid: This is why I think there should be something separate from the compliance suite that describes a vision, what "we" want XMPP too look like in the near future. Compliance suites are mostly about what we think XMPP should look like right now.

  436. zinid

    Zash, I think this idea will face some opposition instantly

  437. zinid

    XSF is reduced to XEP submitting process

  438. zinid

    I see no other value currently

  439. Andrew Nenakhov

    We won't support compliance suites at all.

  440. Andrew Nenakhov

    Cause we intend to drop some xeps that are in it completely

  441. zinid

    Andrew Nenakhov, what's the point in being so reluctant? Do you think I like MIX or carbons or something?

  442. Andrew Nenakhov

    That not what I'm telling

  443. zinid

    well it looks like that

  444. zinid

    you suggest nothing as replacement

  445. Andrew Nenakhov

    But we have that vision you're talking about

  446. Andrew Nenakhov

    zinid, actually we do.

  447. Andrew Nenakhov

    One of the reasons we still didn't release spec for our group chat is cause it is based on some other protocols

  448. zinid

    yeah...

  449. Andrew Nenakhov

    We call em xep-0XXX reliable message delivery Xep-0RRR Message Retract and replace

  450. zinid

    reliable delivery again?

  451. Andrew Nenakhov

    Not again. For once.

  452. zinid

    😀

  453. pep.

    What's your magical solution

  454. pep.

    I'm interested

  455. Andrew Nenakhov

    Get server id from destination server. It acts as a recipe and also tells the client a server time. Thus allowing to sync message orders on all parties

  456. Andrew Nenakhov

    Tricky part is making it work with carbons

  457. zinid

    destination server?

  458. Andrew Nenakhov

    And to account for potential not delivery of some msgs

  459. pep.

    What does reliable delivery mean to you? Is that message ordering?

  460. Andrew Nenakhov

    Yes, if it's a simple chat between two persons, destination server is sender's server

  461. Andrew Nenakhov

    If it's a group chat, receipt is generated by group chat server

  462. Ge0rG

    Andrew Nenakhov: just request carbons with a special flag, and then your server sends carbons of your own messages with the server-id

  463. Andrew Nenakhov

    Reliable delivery means ensuring sending client that message was delivered to where it intended to. If not, sender will retry. And protocol must not duplicate messages if retry is attempted.

  464. waqas

    So the proposal allows strict serializability of messages? Between two full JIDs or bare JIDs or what?

  465. zinid

    yeah, looks like synchronous call to me

  466. Andrew Nenakhov

    Works for us well.

  467. zinid

    yeah, I can say the same about current mess with IDs 😀

  468. Andrew Nenakhov

    It's not really complex. As I said,tricky part was carbons and capability to support legacy clients without fuss

  469. waqas

    Andrew Nenakhov: Is there a link to the proposal?

  470. Andrew Nenakhov

    I can give link to Google doc. It's in Russian though.

  471. zinid

    waqas, it's in Russian, I tried to read it once 😀

  472. Andrew Nenakhov

    No you didn't.

  473. zinid

    I did

  474. Andrew Nenakhov

    Also it evolved since that time.

  475. zinid

    I *tried*

  476. waqas

    You mentioned server time, does it rely on the server acting as the authority, and using timestamps to order?

  477. Andrew Nenakhov

    waqas, yes.

  478. waqas

    What happens when there are multiple servers involved (i.e., s2s)?

  479. zinid

    I would prefer lamport clock and rely on timestamp in the case of conflicts only

  480. Zash

    What happens when one server has its clock waaaay out of sync?

  481. zinid

    so definitely I don't like relying solely on timestamps

  482. Andrew Nenakhov

    Reliable delivery cares to only deliver to destination server. Once my message is on my server, I get a recipe, the rest is like normal xmpp

  483. zinid

    Zash, his protocol assumes the time never goes backward

  484. waqas

    Andrew Nenakhov: Okay, so this means the client is in sync with its server, but this doesn't try to make all clients in a chat sync across servers. Do I understand that correctly?

  485. Andrew Nenakhov

    Yes, you understand correctly.

  486. Zash

    Good thing time doesn't go backwards then. Clocks OTOH...

  487. Andrew Nenakhov

    For a two person chats. In group chats ots a bit different

  488. zinid

    Zash, so you basically should just prevent the server from stopping if you detect backward screw

  489. zinid

    also, need to store the last timestamp on disc for that 😀

  490. zinid

    *from starting, sorry

  491. Andrew Nenakhov

    Let me check something...

  492. Zash

    Tho nothing likes time jumps, most NTP things should be trying hard to do things gradually these days, maybe it's not too much to worry about :)

  493. zinid

    Zash, yeah

  494. zinid

    unless you start the server on some crappy embedded device

  495. zinid

    and if you don't have that protection you will face some fancy side effects which is hard to debug and understand 🙂

  496. zinid

    so basically, server should go full ACID in timestamp generation

  497. Zash

    Hard to do anyting if something starts before network is up after some failure that reset the clock to 1970

  498. Andrew Nenakhov

    Well yes that protocol relied on more or less consistent time on authority server.

  499. zinid

    not sure how this will work in clustering where you cannot guarantee ACID due to CAP

  500. Zash

    Global transactions!

  501. Zash

    Have the entire world agree before commiting!

  502. zinid

    Andrew Nenakhov, what about clustering? Should the nodes synchronize time?

  503. Andrew Nenakhov

    I'm not qualified enough in clustering questions. 😁

  504. zinid

    well I'm just telling that time synchronization tolerance is a hard problem

  505. Andrew Nenakhov

    But I'm pretty sure that does not have to be part of a protocol.

  506. zinid

    so we should avoid it in the spec

  507. Andrew Nenakhov

    If servers generating stamps are slightly out of sync it won't have any really bad effects

  508. Andrew Nenakhov

    Maybe some msgs will appear in different order

  509. Andrew Nenakhov

    We treat situations if you send 3 msgs and they arrive on different time and this reordered as ok.

  510. zinid

    lamport clock anyone?

  511. zinid

    this is already resolved in 1970

  512. zinid

    okay, whatever, that's not a drastical change in the protocol

  513. zinid

    though I think the ID must be generated by a client using lamport clock and formed into a vector clock in a conversation with other party

  514. Andrew Nenakhov

    I think that can be done actually.

  515. waqas

    Synchronization stops being a hard problem when you accept a central authority, which is what it looks like has happened here

  516. Andrew Nenakhov

    Yes. We postulate that in general sense users server is an authority.

  517. waqas

    Sync is only hard if you need to figure out distributed consensus for your serializability without a central authority

  518. zinid

    waqas, which just moves the problem to this central authority

  519. Andrew Nenakhov

    Cause we heavily rely on message archive

  520. zinid

    central authority can consist of several nodes

  521. zinid

    and actually MUST

  522. Andrew Nenakhov

    That's why we are getting rid of offline messages, for example

  523. Andrew Nenakhov

    Cause we fetch msgs from an archive anyway

  524. waqas

    zinid: MUST? The vast majority of XMPP servers today are single node, generally single process, often single thread.

  525. zinid

    waqas: okay

  526. waqas

    zinid: Note that I fully agree with you in principle: clustered nodes should be allowed.

  527. waqas

    But I suspect making things such that it's the server's problem to sync things up between its nodes, and not every single client implementation has to worry or even know about it is the way to go.

  528. Andrew Nenakhov

    zinid, how big can one cluster time difference be?

  529. Andrew Nenakhov

    Realistic estimate? I don't have much experience with those

  530. waqas

    The answer is it can vary a lot, and there are all kinds of algorithms and software and databases to help you in this area. This is up to the server implementation.

  531. waqas

    This is essentially the distributed database problem, and there are many distributed databases, and probably just as many approaches to tackling this.

  532. zinid

    Andrew Nenakhov: in my practice once and it was full of sync due to ntp daemon failure

  533. Andrew Nenakhov

    Well I think that's not really a protocol problem. I like idea of vector time actually, but we didn't include it because we've got too much on our hands already

  534. Andrew Nenakhov

    So for now we settled for the simplest approach

  535. zinid

    usually clocks are synced very well

  536. zinid

    sure, not a protocol problem, it will be my problem

  537. zinid

    okay, I already used to this in XMPP world

  538. zinid

    we resolve only *your* problems

  539. waqas

    A XEP should not attempt to solve an implementation's internal details

  540. zinid

    what if I say I have no problems?

  541. zinid

    as I server dev I really have no problems you're constantly discussing: mam, ids, routing, carbons

  542. zinid

    why would I solve your problems when you don't care about mine?

  543. zinid

    fair question

  544. Andrew Nenakhov

    Hey, we have server developer too, you are no longer alone

  545. waqas

    I'm a server dev. Ultimately the server was written for end users, and their problems matter :)

  546. zinid

    I'm a cluster server dev 😀

  547. Andrew Nenakhov

    waqas, what server are you developing?

  548. waqas

    Andrew Nenakhov: I'm on the Prosody team.

  549. zinid

    Andrew Nenakhov, none 🙂

  550. zinid

    currently none

  551. Andrew Nenakhov

    ))

  552. zinid

    yeah, always remember how the XSF community is formed 😀

  553. Andrew Nenakhov

    Evgeny you are a bitter and jaded old man

  554. zinid

    Andrew Nenakhov, just as you!

  555. Andrew Nenakhov

    Scarred by lost battles

  556. waqas

    I'm young and innocent.

  557. Andrew Nenakhov

    And traumatized by the rise of Signals and Telegrams

  558. Andrew Nenakhov

    But not all is lost and we will prevail

  559. zinid

    everything is lost already

  560. Andrew Nenakhov

    Join us, and together we'll defeat the emperor and rule the Galaxy!

  561. Andrew Nenakhov

    Oh sorry got carried away. Wrong script.

  562. zinid

    you guys cannot even defeat Matrix!

  563. Andrew Nenakhov

    Yes we can!

  564. waqas

    zinid: We are missing Neo obviously

  565. zinid

    yeah, being a dog on a leash is a good achievement!

  566. Andrew Nenakhov

    But really we're mostly aiming at Slack's market

  567. zinid

    maybe our Master will improve our leash!

  568. zinid

    maybe not

  569. waqas

    That's an important thing by the way: Different people in the XMPP community are focused on separate messaging problems. Team/company chat like Slack, consumer chat like whatsapp/messenger/etc, special purpose stuff like video conferencing (Zoom, etc).

  570. zinid

    not sure what XMPP community is

  571. zinid

    I'm really lost after today's debate

  572. Andrew Nenakhov

    I think xmpp should be a universal messaging protocol.

  573. Zash

    The intersection of a bunch of unrelated communities, come together to write XEPs and argue about things, and we're fresh out of XEPs.

  574. zinid

    Andrew Nenakhov, that was a goal in 1999

  575. zinid

    we failed

  576. zinid

    20 years passed, in IT that's an epoch

  577. Andrew Nenakhov

    Because xmpp always came with a knife to a gun fight

  578. zinid

    so you suggest some nuclear weapon? with that your proposals? 😀

  579. Andrew Nenakhov

    Yes. We have some wunderwaffen in our secret labs

  580. Andrew Nenakhov

    But even without wunderwaffen, so far xmpp developers produced exactly ZERO great xmpp clients

  581. zinid

    I'm fine with Conversations, and seems like Dino is back on track

  582. Andrew Nenakhov

    Most close client that I can call great is surprisingly Xabber for Web

  583. Andrew Nenakhov

    Conversations is ravaged by cryprocancer

  584. waqas

    Ah yes, the crypto faction

  585. zinid

    true, but I can live with that

  586. zinid

    there is a switch to disable cancer, in Advanced Preferences

  587. Andrew Nenakhov

    What I also have about it is that it omits too many important xmpp parts,like statuses and presence information

  588. Andrew Nenakhov

    I hate not being able to see who's online. I get this 'always online' concept but it's not always good

  589. zinid

    and vcards!

  590. Andrew Nenakhov

    Yes!

  591. Andrew Nenakhov

    Im actually happy with that recent new vCard XEP

  592. Andrew Nenakhov

    Old vCard is a shame

  593. zinid

    yeah, vcards is our main problem...

  594. zinid

    and IDs

  595. pep.

    !xsf_Martin, you're blinking

  596. Andrew Nenakhov

    IDs are important.

  597. Andrew Nenakhov

    I'd say extremely important.

  598. Andrew Nenakhov

    Too bad they weren't enforced in 1999

  599. zinid

    first attempt with IDs was not so successful, politely saying 🙂

  600. Andrew Nenakhov

    Which one?

  601. zinid

    Andrew Nenakhov, what about stream management, do you eliminate them with your proposal?

  602. zinid

    I mean do you eliminate that stupid SM counter?

  603. Andrew Nenakhov

    Yes, of course. My hate for 198 is widely known

  604. zinid

    right, just asking to understand what you don't hate 😀

  605. Andrew Nenakhov

    Vcards! )

  606. Andrew Nenakhov

    Presences

  607. Andrew Nenakhov

    Xml

  608. zinid

    meh

  609. Andrew Nenakhov

    Also, federation )

  610. Andrew Nenakhov

    0071 I liked too, actually. But *they* killed it.

  611. pep.

    Can somebody temporarily kick or ban !xsf_Martin?

  612. zinid

    that was SamWhited mostly, he is not in the XSF anymore, we can resurrect it

  613. zinid

    yeah, that XEP has attracted so many debates, probably the most controversy XEP I ever seen

  614. waqas

    I'm somewhat to blame for XHTML-IM getting deprecated

  615. Andrew Nenakhov

    I think we'll implement it despite deprecation. One day.

  616. waqas

    I'd done a study of XMPP clients implementing XHTML-IM, and basically found security issues (RCE vulnerabilities) in almost all of them. I'd done a presentation at an XMPP Summit about it too. This was quite a few years back.

  617. zinid

    I recall the same about carbons or something like that

  618. zinid

    when a lot of clients were affected

  619. zinid

    and there was a billion laugh attack...

  620. Andrew Nenakhov

    Vulnerabilities are bad. But how come browsers are not vulnerable?

  621. waqas

    Web applications have vulnerabilities all the time

  622. zinid

    yeah, super-puper Signal for instance

  623. zinid

    that was glorious fail

  624. waqas

    And when you are displaying user provided rich HTML input, and your code to prevent <script> tag injections and such isn't airtight, suddenly someone can send a message to take over your client.

  625. Andrew Nenakhov

    They are vulnerable because they have js

  626. waqas

    If it's a web client, you can e.g., take over the XMPP session by just resetting the password or whatever

  627. Andrew Nenakhov

    But there was no js in 0071

  628. waqas

    Yes, but that doesn't prevent me from sending you a message which has js

  629. waqas

    And if your code can't detect it and clean it up, bad things can happen to you

  630. zinid

    Andrew Nenakhov, there were a lot of arguments about these in that 0071 debate

  631. Andrew Nenakhov

    Of course.

  632. waqas

    And my evidence for this being a real problem was reviewing ~10 XMPP clients which implemented XHTML-IM, and getting all of them to remotely run my JS.

  633. waqas

    Including at least one desktop client, which basically gave me full access to the OS

  634. Andrew Nenakhov

    waqas, anyway, browsers exist. It's a proof enough that html code can be safely contained by a parser

  635. waqas

    Browsers get constant security updates. And web applications have security issues all the time.

  636. Andrew Nenakhov

    Web apps have updates because they are within same sandbox where scripts work are

  637. waqas

    Yes, and securing browsers is a hard, non-trivial problem. All browsers come with security teams of their own. This isn't true for XMPP clients.

  638. Andrew Nenakhov

    And we dont need much in xmpp. B I U and maybe UL OL, that's about it

  639. Andrew Nenakhov

    I'm pretty sure that anything resembling scripts or styles can be safely dropped without too much effort.

  640. Andrew Nenakhov

    Most likely those clients just used a ready components like web views or something

  641. moparisthebest

    which always include a full running javascript engine

  642. moparisthebest

    hence the problem

  643. Andrew Nenakhov

    Yeah.

  644. waqas

    "I'm pretty sure that anything resembling scripts or styles can be safely dropped without too much effort." — this is what I disagree with. Sanitizing HTML is not easy.

  645. pep.

    XHTML-IM is not HTML

  646. waqas

    HTML and also CSS (which can also contain JS)

  647. waqas

    It isn't, but you can't block me from sending you stuff that's not in the spec, and if your client doesn't clean that out, I win.

  648. pep.

    Sure, but I can be pretty strict about it, (and I should)

  649. pep.

    It's not like I had to support whatever crap you throw at me, like browsers do

  650. waqas

    pep.: That's basically what I found: clients trying to be strict about it and failing.

  651. pep.

    Ok, so what, it's better to take them down rather than fix them?

  652. waqas

    I even wrote a library to be strict about it: https://github.com/zeen/xhtml-im.js/blob/master/xhtml-im.js

  653. pep.

    cool

  654. waqas

    2013, that was quite some time ago

  655. Andrew Nenakhov

    Actually I think that due to specifics of our medium all css can be just dropped.

  656. Andrew Nenakhov

    No colors. No scripts. No margins.

  657. waqas

    What do you actually want to keep?

  658. pep.

    What about providing tests then for devs to use, alongside your reference impl that they can also reuse, instead of taking the XEP down and creating 393

  659. Andrew Nenakhov

    B I U UL OL, quotes

  660. Andrew Nenakhov

    393 and 394 are abominations

  661. waqas

    Just to be clear, I didn't take personally take the XEP down. I'd mostly presented my findings, and the discourse on XHTML-IM from that point was negative. This was around when there was a Last Call for the XEP to become final.

  662. zinid

    that was quite moot decision and basically heavily relied on personal point of view, I already said that in that mail list discussion

  663. zinid

    like "fixing clients" vs "we're doomed"

  664. zinid

    you cannot debate between those point of views

  665. zinid

    *points

  666. waqas

    zinid: The XSF (XMPP Standards Foundation) has tried hard to be a neutral org which just focuses on standards. There's no wing of the XSF where you send folks out to fix things in clients, and everything relies on individual projects implementing spec updates. There's also no strong outreach to the community.

  667. waqas

    I'm not a fan of this state of affairs, for what it's worth

  668. zinid

    waqas, well, maybe I'm currently not very clear, but whatever

  669. zinid

    "can we rely on client devs: yes or no"

  670. zinid

    let's say it that

  671. waqas

    I'm saying "fixing clients" isn't something the XSF can actually do

  672. zinid

    yes, yes

  673. zinid

    waqas, and no, XSF is not focused on standards

  674. zinid

    XSF is focused on XEP publishing process

  675. Andrew Nenakhov

    +1

  676. zinid

    it has converted recently in a completely beaurocratic body

  677. waqas

    Yes, but that's what "focused on standards" has been defined as. Note that this is by design, many /wanted/ this to happen, and for us to be more similar to e.g., the IETF.

  678. Matthew

    > <@_xmpp_pep.=2fxsf=40muc.xmpp.org:matrix.org> Matthew, well played, I see you've started another meaningful discussion :P gah, sorry all

  679. zinid

    (sorry for the spelling, I can never remember how this word is spelled in english)

  680. zinid

    waqas, well I see a very little point in the XSF now in comparison to the IETF

  681. zinid

    anyone can go straight to the IETF, where there will no be a bunch of judges

  682. oli

    xep publishing process. use a collaborative wiki ...

  683. waqas

    "where there will no be a bunch of judges" — you've never been part of the IETF process, have you...

  684. zinid

    waqas, the IETF is a platform which gives you tools to develop a standard

  685. zinid

    waqas, no, I wasn't

  686. zinid

    even so, why should I care who will judge me?

  687. zinid

    so we copied the worst from the IETF?

  688. zinid

    what's the real meaning of the XSF now?

  689. zinid

    not how it was, not on the paper, but now de facto

  690. waqas

    A body which oversees the standards process for XMPP and it's XEPs

  691. Andrew Nenakhov

    I wonder how will this body react to our XEPs

  692. zinid

    same as IETF?

  693. waqas

    Similar. The IETF is generic. The XSF for example worked within the IETF framework to get the XMPP RFCs published.

  694. zinid

    waqas, so IETF restricted to "oversee" the XMPP related specs only

  695. zinid

    as a standard write why would I care?

  696. zinid

    *writer

  697. waqas

    The IETF is quite a bit about the process, yes

  698. zinid

    yeah, same stuff the XSF converted to

  699. waqas

    The few paragraphs here basically describe what the XSF has been about: https://xmpp.org/about/xmpp-standards-foundation.html

  700. Andrew Nenakhov

    Zinid let's form our own council, just you and us. Whatever we agree to, it'll be standard.

  701. waqas

    Note that I'm probably in agreement with you that that's not particularly helpful in making open messaging and XMPP succeed and compete against other solutions.

  702. zinid

    Andrew Nenakhov, nah, I don't invent wheels, sorry

  703. zinid

    Andrew Nenakhov, I can always got to IETF, which I think I will with my XOR

  704. zinid

    *go

  705. Andrew Nenakhov

    Xmpp currently badly needs weels.

  706. zinid

    😀

  707. waqas

    And the XMPP Software Foundation used to be the Jabber Software Foundation, and that old thing was much more in line with what you are hoping for.

  708. Andrew Nenakhov

    What is 'your XOR'

  709. waqas

    *XMPP Standards Foundation

  710. zinid

    Andrew Nenakhov, http://upload.zinid.ru/xeps.html first link

  711. zinid

    waqas, exactly, so I kinda agree with Ge0rG's rantings

  712. waqas

    I too agree with Ge0rG's rantings :)

  713. lovetox

    I can only speak from my experience, and yes xeps and process etc are sometimes a painpoint, but i dont feel this is the reason that holds the xmpp community back

  714. zinid

    we constantly laugh about endless Matrix's TODO, but we don't even have any, how ironic

  715. waqas

    lovetox: I'm curious about what you think the reason is

  716. lovetox

    its not like there are a lot of developers who want to do stuff, but are actively inhibited by process of xsf or xeps

  717. zinid

    lovetox, as a server dev I can do a lot actually, I'm currently very bored

  718. lovetox

    the reason is to few developers in my opinion

  719. zinid

    so I even resorted to implement that dredful MIX, ha

  720. Andrew Nenakhov

    Well, currently I have 5-6 developers working on XMPP full time

  721. Andrew Nenakhov

    zinid, you shouldn't have.

  722. zinid

    Andrew Nenakhov, but you didn't provide anything, and what should I do?

  723. zinid

    I'm kinda stuck in the development

  724. zinid

    really, what should I implement?

  725. Andrew Nenakhov

    You didn't ask. More precisely you said you're not interested )

  726. lovetox

    yeah zinid its also not about server development

  727. lovetox

    its about good clients with nice GUI

  728. lovetox

    nobody wants to do that

  729. Andrew Nenakhov

    Good clients can't exist without good servers

  730. zinid

    lovetox, I'm not competent enough

  731. lovetox

    :D

  732. Guus

    lovetox - I was talking to a company that's actively looking to sponsor project to do just that.

  733. lovetox

    Andrew Nenakhov, i feel servers are good enough

  734. Andrew Nenakhov

    Nope. Not yet.

  735. lovetox

    its not servers who hold us back :)

  736. zinid

    lovetox, he has his own vision 😀

  737. Andrew Nenakhov

    In telegram I can log in and in mere seconds get a list of recent conversations and their metadata

  738. waqas

    I don't think lack of standards is a real issue. I think better-than-the-competition UIs are the real issue.

  739. zinid

    Andrew Nenakhov, that's not a problem with servers, c'mon

  740. Andrew Nenakhov

    How many unread messages, which are read by recipient, etc

  741. Andrew Nenakhov

    > Andrew Nenakhov, that's not a problem with servers, c'mon It absolutely is.

  742. zinid

    Andrew Nenakhov, and? What do you want from servers? To implement what?

  743. Andrew Nenakhov

    Mam does not contain metadata. Mam does not allow getting recent msgs from conversations

  744. Guus

    lovetox: I agree that we're currently lacking the resources to create good UI/UX in many frontend-based projects. I don't think that we're unable to get these resources though - I think we generally didn't bother to try.

  745. lovetox

    such things are nice features the cherry on the top, we fail at much more basic stuff

  746. Guus

    which is what I like about having Matrix as a mirror: to me, their client made it painfully clear what we're lacking.

  747. waqas

    +1

  748. lovetox

    Guus, yes i think it also doesnt take much

  749. Andrew Nenakhov

    Guus, I'm more often looking at Telegram

  750. lovetox

    pick 3-4 clients, assign 2 motivated developers to each

  751. lovetox

    i think this goes a long way

  752. waqas

    Who does the assignment and who pays for this?

  753. waqas

    And who decides what these devs should do?

  754. Andrew Nenakhov

    Well I'm paying my developers and decide what they do. :)

  755. lovetox

    thats not how i meant this, i meant maybe we are getting lucky and someone comes up

  756. lovetox

    :)

  757. waqas

    That's one way to do it, and that's also what the Matrix team is doing.

  758. lovetox

    but yeah a bit of money could help

  759. waqas

    But money means you need profits (unless this is all donation money). The Matrix folks raised capital, which does interest things to motivations and direction.

  760. Guus

    I strongly believe that it is up to the individual projects to arrange this for themselves.

  761. Andrew Nenakhov

    Yes.

  762. Guus

    The XSF, however, can facilitate, and spread 'best practices'

  763. waqas

    Guus: And there's no evidence that that would really succeed at scale.

  764. Guus

    I tried to supply a couple of them a couple of days before

  765. Andrew Nenakhov

    Current approach didn't succeed thus far

  766. Guus

    waqas true, but there's sufficient evidence that not doing anything does not get us _any_ progress.

  767. waqas

    Guus: You basically get one or two winners, and their philosophy "wins", except most of the community doesn't like the currently popular UIs.

  768. Andrew Nenakhov

    So maybe it's worth a try to do things differently

  769. Guus

    waqas I think we're talking about different things

  770. waqas

    All vision and future-oriented conversations in this room ^

  771. Guus

    waqas the 'winners' would be those clients that get adopted by the general public end user, right?

  772. waqas

    Guus: So… Pidgin?

  773. waqas

    I suspect it has the largest user base, no?

  774. Guus

    I don't think so

  775. Andrew Nenakhov

    I don't think pidgin has any relevance these days

  776. Guus

    more like the what-apps of these days

  777. Guus

    waqas I'm unsure if I understand your argument

  778. Guus

    (or if we're arguing the same thing)

  779. lovetox

    Its really basics i think, for example Gajim cant find someone who makes a nice installer for MacOS for years, though the application runs fine on it

  780. waqas

    What would be good is even a clear idea of what "we" want. You said the XSF can facilitate and spread best practices for example. It'd be great to know what those could be. Is the crypto crowd defining the best practices? Is the IETF-like crowd? is the UX-first crowd?

  781. waqas

    It's hard to even know if I like or dislike an argument when you don't know what the argument is trying to achieve in the long term.

  782. Guus

    My thoughts are: Many here seem to agree that a common issue with most of our frontends are a lack of UI/UX. Also, a lack of funding is seen as a key issue that prevent problems from being fixed. As these issues are common in our group, I see a role for the XSF to facilitate improving on this point - but in the manner of "helping individual projects to raise money and/or design resources" as opposed to "raise money/hire designers and donate that to projects."

  783. waqas

    Guus: I can agree with that, with one concern: many projects/developers have their own incompatible ideas for what good UX is, and I'm not sure if there's much money in the ecosystem.

  784. lovetox

    It happened often that users tell me they use Gajim in their company

  785. Guus

    waqas I don't think that either is true. I think that the majority of projects/developers realize that they don't know what a good design is, and that they need help.

  786. lovetox

    I always think, yeah nice for you, but it would be nice if the company gives something back to the project

  787. Guus

    waqas also, I'm pretty sure that there's much money in the ecosystem, but that we're failing to raise it (or even _attempt_ to raise it)

  788. lovetox

    and be it only a developer that spends 1 hour per week

  789. Guus

    lovetox I think you'd be surprised how many people would actually be willing to do that, if they're asked to.

  790. Guus

    I suspect that our biggest issue is that we're not asking.

  791. lovetox

    you are right, i never asked, i will do next time

  792. waqas

    I agree with that Guus

  793. waqas

    There was a time when there were a lot of folks offering to do stuff

  794. waqas

    We were talking about forming teams of volunteers and some of that actually happened

  795. Guus

    lovetox: and I think that there might be good ways of asking for somethign, and bad ways to do that. I think that there's a role for the XSF to help people figure out the best way.

  796. Guus

    waqas sure, but that time has gone. XMPP isn't sexy any more

  797. Guus

    we need to adapt and move on.

  798. waqas

    But then it fizzled out, because there was a lack of direction, the XSF folks at the top didn't necessarily agree with the volunteers on what needed to happen.

  799. waqas

    And the XMPP community sorely lacks much project planning/management/design experience. Most efforts fizzle out because either nobody cares much, or too many care and suddenly there's a todo list of a dozen random things.

  800. lovetox

    also a point that i noticed is, that i cant spend much time on UI, because the core codebase is so old and stuffed together over 15 years by X people

  801. Guus

    waqas I believe that much fizzles out because it remains in the realm of 'hobby' and 'pet project' - which is _awesome_, but is very unlikely to get the attention it needs, as people need to do stuff that they can earn a living wiht.

  802. lovetox

    so i spend most of my time refactoring stuff,

  803. lovetox

    but i will get there eventually :)

  804. Guus

    lovetox I suffer from the same issue with our ancient Spark client (which isn't particularly good, but which I would like to see improved)

  805. lovetox

    what i find really nice, are the xmpp meetups that i noticed over the last year, i wasnt able to attend one but planning to go :)

  806. Guus

    you should definitely do that!

  807. zinid

    lovetox, nice in what sense? I mean as a social event it might be good (beer and stuff), but what is the outcome for XMPP?

  808. lovetox

    no zinid, i meant the meetings where they code

  809. Andrew Nenakhov

    I don't have any faith for coding at meetings

  810. lovetox

    get together for a weekend sit down talk about stuff and help each other out implementing some feautre

  811. lovetox

    as i said i never was, i hope they do that :D

  812. Andrew Nenakhov

    Why would someone need to get together with someone to code?

  813. zinid

    ah, that's not xmpp related...

  814. lovetox

    maybe they only drink beer

  815. Guus

    In my experience, it adds tremendous value

  816. Andrew Nenakhov

    Drinking beer together, is very different from drinking alone at home

  817. lovetox

    Andrew Nenakhov, because i have a family and other things to do at home

  818. zinid

    Andrew Nenakhov, as I see it people are different in europe, we probably cannot understand that 😀

  819. lovetox

    i cant spend 5 hours on the computer

  820. Andrew Nenakhov

    Lol

  821. lovetox

    but if i tell my girlfriend im going to berlin over the weekend

  822. lovetox

    i can concentrate on the task

  823. Guus

    I think most value is actually in the social part of the meet, not the code (Which is nice, too)

  824. zinid

    beer, that is

  825. waqas

    Ha, if the XSF or equivalent can just fund weekend drinks and food, we'll not lack for dev resources :P

  826. Guus

    but discussions like the one we're having here are much faster and effective when done in person

  827. Andrew Nenakhov

    lovetox, if you tell her that and instead go to the attic and work there, you'll be able to work those hours that would otherwise be wasted on commute

  828. Andrew Nenakhov

    Guus, faster, but equally inconsequential

  829. Guus

    Andrew Nenakhov to how many have you been?

  830. zinid

    Guus, nah, depends on your communication skills (including foreign language)

  831. Andrew Nenakhov

    Guus, I attend 5 eight hours gettogethers of xmpp developers every week

  832. Andrew Nenakhov

    I actually pay them to show up.

  833. Andrew Nenakhov

    😂

  834. Guus

    I've been at two, and I've learned things that changed things for the better for me, a lot. I need not look back further than the last 24 hours, in which I've gotten an XMPP customer that I would not have gotten if I had not done the things that others at such meetings told me to do

  835. Guus

    that's direct XMPP-based income. I've already earned back my tickets.

  836. zinid

    Andrew Nenakhov, like hookers 😀

  837. Guus

    zinid communication skills are always important - but what stops you from having a russian meetup?

  838. Guus

    that takes away the foreign language issue.

  839. Andrew Nenakhov

    Hahaha

  840. Andrew Nenakhov

    The vast distances of Russia

  841. zinid

    Guus, lmao, I'm quite antisocial and I don't like such events

  842. Andrew Nenakhov

    Also 1500km to moscow

  843. zinid

    Andrew Nenakhov, I'm in Moscow, there are no people outside Moscow, you know that

  844. zinid

    only bears

  845. Andrew Nenakhov

    You was in Krasnodar, no?

  846. zinid

    Andrew Nenakhov, I moved

  847. Andrew Nenakhov

    Ah, ok. Maybe we should meet next time I'm there then. See, Guus, I'm just 2000km east of Moscow

  848. zinid

    that's almost near

  849. Andrew Nenakhov

    So meeting people is kinda more difficult than in Germany.

  850. zinid

    at least not Vladivostok with 9000km 😀

  851. Andrew Nenakhov

    Lol.

  852. Andrew Nenakhov

    Btw do you guys know the town with a most per-capita concentration of Xmpp developers?

  853. pep.

    I've learned lots of things in sprints! Now I know how to stack vim buffers! (thanks jc!) I think that was the best thing I learned out of sprints :P (/s)

  854. Guus

    Guys, I'm happy for you to go about it your own way. I'm only offering suggestions, and i'm trying to find solutions. If you have a better idea, by all means, share it, so that everyone can benefit.

  855. Matthew

    random question; do you guys have a code of conduct for xsf moderated rooms?

  856. pep.

    I don't think so

  857. Matthew

    s/guys/folks/

  858. Guus

    Matthew nope

  859. zinid

    wut? I was banned once

  860. waqas

    First time I've even heard the phrase "xsf moderated rooms"

  861. Guus

    also: can how do I add you as a contact via that bridge?

  862. pep.

    zinid, no need for a code of conduct for that

  863. pep.

    You just need moderator permissions

  864. waqas

    The, the MUC XEP doesn't require a code of conduct for the banning feature

  865. zinid

    pep., indeed, it's convenient

  866. Andrew Nenakhov

    Matrix guy wants to steal our codes of conduct!

  867. pep.

    ban them already!!

  868. zinid

    +1

  869. Guus

    So basically, they'll start banning zinid ? 🙂

  870. Andrew Nenakhov

    First, they came for our uses. Then, codes of conduct. That's next, our beautiful women?

  871. zinid

    yeah, banning people is funny, muc drama

  872. pep.

    I'm not sure at what frequency heated discussions happen fwiw

  873. pep.

    XHTML-IM, OMEMO, zinid, that's about the main events

  874. Guus

    as far as I've seen: once. And he got banned.

  875. Andrew Nenakhov

    What was the Omemo drama?

  876. pep.

    the _ongoing_ omemo drama

  877. lovetox

    Its mostly Ge0rG hating it

  878. zinid

    Ge0rG is hating everything

  879. lovetox

    probably because he has not enough time to implement it, and his users bug him :D

  880. pep.

    Yeah, that's usually how you get features in implementations anyway

  881. pep.

    Having users bully other developers :P

  882. Andrew Nenakhov

    I hate Omemo too. Protocol written like shit, with race conditions, and has zealous users who believe it to be the silver bullet

  883. zinid

    Andrew Nenakhov, you will not such arguments for the upcoming MLS 😛

  884. pep.

    Andrew Nenakhov, thanks, let's not redo the OMEMO discussion right now

  885. zinid

    *will not have

  886. Andrew Nenakhov

    What's MLS?

  887. zinid

    I bet the MLS WG will produce high quality spec, they all look very *clever* 😀

  888. zinid

    https://datatracker.ietf.org/wg/mls/about/

  889. zinid

    namely, https://tools.ietf.org/html/draft-ietf-mls-protocol-03

  890. Andrew Nenakhov

    DISCLAIMER: This is a work-in-progress draft of MLS and has not yet seen significant security analysis. It should not be used as a basis for building production systems.

  891. Andrew Nenakhov

    I wonder if there ever was a serious security analysis of OMEMO

  892. pep.

    OMEMO itself, or signal's encryption mechanism?

  893. lovetox

    there was for both

  894. Andrew Nenakhov

    Actually both

  895. lovetox

    omemo is only about wrapping signal in xmpp

  896. lovetox

    not much you can do wrong

  897. Andrew Nenakhov

    It bugged me when reading that terminology is different in different documents.

  898. Andrew Nenakhov

    Very so-so

  899. zinid

    Andrew Nenakhov, there was for OMEMO afair

  900. Guus

    I'm off. goodnight!

  901. Andrew Nenakhov

    Bye.

  902. moparisthebest

    Andrew Nenakhov, re security analysis of omemo https://conversations.im/omemo/audit.pdf

  903. Andrew Nenakhov

    I saw that. I meant serious )

  904. moparisthebest

    then you'll have to define serious :)

  905. Andrew Nenakhov

    Those that have their most interesting part being just a link to some other research done of course but a very respectable experts, ha

  906. moparisthebest

    I mean the signal protocol has been pretty extensively reviewed hasn't it? what else can an implementation of it get than a 3rd party audit?

  907. Andrew Nenakhov

    moparisthebest, was signals protocol really reviewed? Or, it's so popular itmust have been reviewed?

  908. lovetox

    Andrew Nenakhov, it is reviewed you can find this out pretty fast

  909. Andrew Nenakhov

    Anyway I'm not really in the mood arguing about that

  910. lovetox

    there is nothing to argue about

  911. lovetox

    :)

  912. moparisthebest

    well I ddg'd "signal protocol review" and found a ton of results so, probably?

  913. moparisthebest

    > In October 2016, researchers from the UK's University of Oxford, Australia's Queensland University of Technology, and Canada's McMaster University published a formal analysis of the protocol.[15][16] They concluded that the protocol was cryptographically sound.[15][16]

  914. moparisthebest

    knock yourself out following all the citations https://en.wikipedia.org/wiki/Signal_Protocol

  915. moparisthebest

    like lovetox said, nothing to argue about, 100% has been widely reviewed

  916. Ge0rG

    lovetox [22:02]: > probably because he has not enough time to implement it, and his users bug him :D Is this a troll or a massive misinformation?

  917. lovetox

    it was a joke, dont take it to serious

  918. Ge0rG

    Alright