XSF Discussion - 2019-03-13


  1. rion has left

  2. UsL has left

  3. UsL has joined

  4. rtq3 has left

  5. karoshi has left

  6. waqas has joined

  7. wurstsalat has joined

  8. Alex has joined

  9. kokonoe has left

  10. lumi has left

  11. Alex has left

  12. kokonoe has joined

  13. tux has left

  14. Yagiza has joined

  15. neshtaxmpp has left

  16. neshtaxmpp has joined

  17. rion has joined

  18. alacer has left

  19. alacer has joined

  20. alacer has left

  21. alacer has joined

  22. alacer has left

  23. alacer has joined

  24. lskdjf has left

  25. larma has left

  26. alacer has left

  27. alacer has joined

  28. bowlofeggs has left

  29. bowlofeggs has joined

  30. alacer has left

  31. Nekit has joined

  32. alacer has joined

  33. arc has left

  34. arc has joined

  35. j.r has left

  36. j.r has joined

  37. j.r has left

  38. j.r has joined

  39. blabla has left

  40. oli has joined

  41. Neustradamus has left

  42. Neustradamus has joined

  43. Nekit has left

  44. Nekit has joined

  45. oli has left

  46. oli has joined

  47. karoshi has joined

  48. Tobias has joined

  49. blabla has joined

  50. rtq3 has joined

  51. lnj has joined

  52. oli has left

  53. oli has joined

  54. moparisthebest has left

  55. moparisthebest has joined

  56. wurstsalat has left

  57. wurstsalat has joined

  58. contrapunctus has left

  59. contrapunctus has joined

  60. rtq3 has left

  61. rtq3 has joined

  62. lnj has left

  63. ralphm

    Ge0rG: well yeah, there's still no reasonable choice for MacOS, I think.

  64. Ge0rG

    Anu needs another pair of hands

  65. alacer has left

  66. neshtaxmpp has left

  67. oli has left

  68. neshtaxmpp has joined

  69. Steve Kille has joined

  70. andy has joined

  71. goffi has joined

  72. wurstsalat

    > Anu needs another pair of hands +1

  73. j.r has left

  74. alacer has joined

  75. vaulor has left

  76. contrapunctus has left

  77. 404.city has joined

  78. j.r has joined

  79. Guus

    Ah, yes. I was talking to people that were interested in providing those

  80. Guus

    I'll try to revive that effort.

  81. j.r has left

  82. j.r has joined

  83. Guus

    I've never spoken to Anu, I think. He's not in this MUC, I think. Is he still travelling?

  84. Guus

    Can anyone introduce me?

  85. vaulor has joined

  86. alacer has left

  87. rtq3 has left

  88. lnj has joined

  89. j.r has left

  90. j.r has joined

  91. contrapunctus has joined

  92. Kev has joined

  93. Seve

    Guus, he is usually here monal@chat.yax.im (I don't know him personally either)

  94. kokonoe has left

  95. oli has joined

  96. neshtaxmpp has left

  97. andy has left

  98. neshtaxmpp has joined

  99. kokonoe has joined

  100. ThibG has left

  101. ThibG has joined

  102. j.r has left

  103. j.r has joined

  104. j.r has left

  105. j.r has joined

  106. Seve

    There's a comment of a guy called Mark Nottingham on the comments section of that article, and he says: "I talk to various parts of the IETF Jabber mafia about this, and they can give detailed reasons about why XMPP failed. Unfortunately, we don't seem to have learned; we're still building federation-optional systems like WebRTC." I wonder if anyone here is one of those `IETF Jabber mafia` and knows why XMPP failed

  107. Steve Kille has left

  108. andy has joined

  109. contrapunctus has left

  110. contrapunctus has joined

  111. Steve Kille has joined

  112. j.r has left

  113. j.r has joined

  114. Guus

    Thanks Seve

  115. intosi has joined

  116. Guus

    I do not know who Mark Nottingham is. I wonder who he refers to (and chooses to keep talking with people he chooses to characterize as 'mafia')

  117. Dele Olajide has joined

  118. contrapunctus has left

  119. jonasโ€™

    because one doesnโ€™t turn ones back to family?

  120. contrapunctus has joined

  121. zinid

    yeah, the naming is very important to discuss

  122. zinid

    when in fact his conclusion is correct

  123. contrapunctus has left

  124. contrapunctus has joined

  125. alacer has joined

  126. zinid

    federation leads to a marginal network in the worst case and to a power-law network with too-big-to-fail supernodes in the best case

  127. zinid

    and nothing in between

  128. contrapunctus has left

  129. contrapunctus has joined

  130. Guus

    ๐Ÿ‘

  131. zinid

    and yeah, regarding wtf is Mark: https://datatracker.ietf.org/person/Mark%20Nottingham

  132. Guus

    Thanks

  133. Seve

    Oh, he even appears as one of the contacts on that article :)

  134. waqas has left

  135. waqas has joined

  136. waqas has left

  137. waqas has joined

  138. waqas has left

  139. ralphm

    Grr, dwd, now I have to spend most of the day writing a response to your MIX braindump

  140. waqas has joined

  141. MattJ

    It was a good braindump

  142. ralphm

    It was, but there's so much there. I am probably going to do a separate response on the PubSub/MAM thing.

  143. ralphm

    Because that's a whole discussion just by itself.

  144. Guus

    I'd say that any braindump that makes Ralphm spend an entire day is pretty successful ๐Ÿ™‚

  145. contrapunctus has left

  146. contrapunctus has joined

  147. alacer has left

  148. dwd

    I know Mark slightly. In as much as I've had a beer with him before. The mafia is probably Peter and Joe.

  149. Guus

    if he continues to engage them, then 'mafia' was more sarcastic than an indication of discontent, then?

  150. dwd

    ralphm, To make it clear, I don't know which parts of that brain dump are hills I wish to die on yet.

  151. dwd

    Guus, Remember that nobody uses XMPP, except for the people that do. Mark, on the other hand, works in the web, so has a different view of what constitutes success.

  152. Wiktor

    Mark is the guy that oversees .well-known URI registry, also link relation registry. Not some random guy :)

  153. dwd

    Also HTTP 2, etc.

  154. Wiktor

    Also depreciating X- http headers

  155. Wiktor

    Yep.

  156. Wiktor

    Maybe he thinks that xmpp should be managed by ietf, not separate organization (just a guess)

  157. Seve

    That's the reason XMPP failed?

  158. Wiktor

    No, lack of good clients is a reason xmpp failed. Why this question now?

  159. Guus

    I'd argue that XMPP didn't fail.

  160. Guus

    Maybe it fails on certain aspects

  161. Seve

    Wiktor, well, you seem to know him very much, and my question was about he says XMPP failed.

  162. Wiktor

    I was referring to "jabber mafia" previously.

  163. Guus

    but it certainly does not fail as a whole,.

  164. Wiktor

    I know him because I've seen his name here and there. I don't know him personally.

  165. Guus

    The only reason why I asked about his wording was to figure out if he holds a grudge, or was semi-jokingly referring to people.

  166. waqas has left

  167. Zash

    What's the relationship between the XMPP mafia and the xmpp memorial society ?

  168. Wiktor

    I don't know in case you're asking me. That's why I used "just a guess".

  169. zinid

    Guus, I think Peter and Joe are his friends, so he can afford those words

  170. Guus

    zinid good, thanks.

  171. zinid

    like calling another WG is mafia, I think it's pretty much normal in those circles

  172. Seve

    I understood mafia as just the people that care about that, nothing else. But I was quite interested in knowing the detailed reasons about XMPP as he says. Sad that we don't have members of that mafia here

  173. Guus

    zinid that makes sense, yes.

  174. zinid

    Seve, because XMPP didn't attract as much attention as HTTP?

  175. Guus

    Seve I think you should become part of the mafia ๐Ÿ˜‰

  176. zinid

    Seve, Mark is from HTTP mafia btw

  177. Guus

    be our wiseguy! ๐Ÿ˜‰

  178. Seve

    I will get in there and take all their secrets!

  179. Seve

    zinid, yes, I realize that now, reading a bit :D

  180. Seve

    (Although I don't see why they should be compared)

  181. Wiktor

    Oh, now I found and read the actual comment by Mark: > I currently use Monal and am not terribly happy with that, which is probably why I don't log in much these days. So it's a "lack of good client" problem after all...

  182. intosi has left

  183. intosi has joined

  184. Zash

    The iOS situation is sad.

  185. dele has joined

  186. ralphm

    I can totally see why people feel XMPP failed. There was a lot of excitement, mind-share if you will, for having XMPP succeed as the SMTP of chat, as well as the use cases for non-chat. Google got on board, several of the other large companies did XMPP (Google, Microsoft Lync, Nokia, Orange, Facebook). Some federated, others not so much. All of the big IM systems around 2008 were ready to federate, but no-one wanted to go first. And then business decisions, not technical issues, undid most of that.

  187. dele has left

  188. Wiktor

    Zash, It's interesting because I thought it's iOS where people pay for apps.

  189. ralphm

    Like Sam, having a full roster of people that then diminishes because of that really sucks and contributes to your view on the technology.

  190. ralphm

    And the client situation on MacOS has always been a problem, but I cannot oversee how much of that impacted the success of XMPP in general.

  191. Zash

    Wiktor: Huh. Monal is free?

  192. Wiktor

    Zash: yes, that's a problem. It should be paid and developed like a normal app (just a random advice)

  193. Zash

    Tell the dev. "If Conversations can be $5, so can Monal!"

  194. ralphm

    I want to note that the years around 2008 was a time where *many* interesting new protocols around social popped up (webfinger, activity streams, oauth, openid, etc.) and then 'something' happened that destroyed momentum.

  195. Wiktor

    ralphm: xmpp problem stems from years of slumber. It's slowly getting better with new XEPs, new client features, etc.

  196. Wiktor

    ralphm: all of them work over http:)

  197. Zash

    Well in 2008, XMPP was a solved problem. Why do anything when it was perfect! :)

  198. Wiktor

    Zash: ๐Ÿ‘

  199. Zash

    Then smartphones came along and ruined everything

  200. Wiktor

    Exactly. For some definition of "ruined".

  201. ralphm

    Zash: I definitely think that smartphones is related to the 'something'

  202. Holger

    Wasn't our multi-device support always horrible and the problem just hidden by nobody having multiple devices?

  203. Wiktor

    On Android it got better, no need to ditch xml or rework the protocol. Clients are working fine, low battery usage, useful features.

  204. Guus

    That's basically the same thing, I think ๐Ÿ™‚

  205. Zash

    It was fine.. if you managed it correctly.

  206. ralphm

    The n900 had it all though, XMPP fully integrated in the calling and messaging infrastructure. Jingle calls with GTalk/Hangouts.

  207. ralphm

    Holger: totally

  208. Guus

    But I'm with @Wiktors train of thought, I think. To be more successful, it helps (or maybe even is required) that people start making money from their efforts.

  209. Guus

    But I'm with Wiktor 's train of thought, I think. To be more successful, it helps (or maybe even is required) that people start making money from their efforts.

  210. Guus

    I can at least not see how you can give enough attention to things while also being able to earn enough money to feed your family.

  211. ralphm

    Wiktor: the problem, though, is that if Linux and Android are the primary places where things do work properly, but not on MacOS and iOS, this affects a particular influencial set of people.

  212. Seve

    Indeed

  213. Zash

    The FOSS community has a complicated relationship with Apple

  214. ralphm

    No kidding. I had a look at the laptops at the XMPP Summit. The percentage of ThinkPads was very high.

  215. Guus

    Yeah, it amused me that you mentioned that.

  216. alacer has joined

  217. Seve

    It's normal.

  218. kokonoe has left

  219. Seve

    But that does not stop anyone from not-the-FOSS-community to build XMPP for Apple :(

  220. zinid

    > The FOSS community has a complicated relationship with Apple Yet, a lot of developers use MacOS for development

  221. Wiktor

    ralphm, I didn't get it, you mean Apple don't want good XMPP clients on iOS?

  222. ralphm

    Wiktor: well, it is not that easy

  223. Guus

    zinid I wonder if that's true for the FOSS community, to be honest.

  224. zinid

    Guus, XMPP is not FOSS

  225. ralphm

    Wiktor: I think that iOS actively hampered efforts to write good clients in the past, with its restrictions.

  226. zinid

    so there should be no difference

  227. Wiktor

    I don't see any technical reasons why it shouldn't work, especially with all these "mobile friendly XEPs"

  228. Wiktor

    ralphm, you mean need for push notifications?

  229. zinid

    I'm not sure why XMPP is positioned or percepted as FOSS, that's a strategic mistake

  230. ralphm

    Wiktor: there were no good solutions for this initially

  231. Wiktor

    agreed. but there is now, and I see proofs that good mobile clients can be done

  232. ralphm

    Wiktor: I agree it can be done now, but this history made it more difficult

  233. ralphm

    When my company started XMPP development on mobile, they could easily use Smack on Android, but mostly had to start from scratch on iOS.

  234. kokonoe has joined

  235. contrapunctus has left

  236. Wiktor

    I see

  237. ralphm

    I.e. the ecosystem is much less developed there.

  238. contrapunctus has joined

  239. Guus

    (and/or we lucked out with Google using Java for Android)

  240. Guus

    (and/or we were lucky with Google using Java for Android)

  241. ralphm

    Guus: and because of its opener nature, devices are cheaper etc.

  242. Guus

    unsure if that makes much difference. As zinid pointed out - many developers use Macs.

  243. Guus

    but that's besides the point.

  244. Wiktor

    Adium was nice... years and years go :)

  245. ralphm

    Guus: yeah, it baffles me that there's still no decent XMPP client for MacOS, as far as I know.

  246. ralphm

    Adium was always a pain, but there wasn't anything better.

  247. Guus

    (mac and google app stores hold approximately as many apps - so the ecosystem for regular developers apparently is not absent enough to make a difference)

  248. Guus

    ralphm, maybe it's a kind of echo chamber that we're in

  249. Guus

    regardless, I think we all agree that better ios/mac support is something we want.

  250. Seve agrees.

  251. Guus

    so maybe we should stop agreeing with eachother and move on ๐Ÿ™‚

  252. Guus

    how do we get there?

  253. Seve

    Would crowdfunding be an option, I wonder

  254. Guus

    As I wrote earlier - I think sharing ideas on how to 'make money' could be a good start.

  255. yon has left

  256. Guus

    and, although I don't want to rule out options like crowdfunding, we maybe should focus on those options that already have been proven to be at least somewhat successful.

  257. Guus

    Identify those options, and spread knowledge.

  258. alacer has left

  259. Guus

    I've given a couple of examples a few weeks ago - but I think that coudl be done more structurally, somehow.

  260. Seve

    Is there something about that on a Wiki page or somewhere specific to look at it?

  261. Guus

    not that I know of (but might be a good start)

  262. Guus

    I am trying to find the logs of what I talked about here, but am unsuccessful so far

  263. Guus

    aside: http://logs.xmpp.org/xsf/ seems to have had an update, and no longer allow for join/part messages to be filtered. I kind of liked that feature.

  264. alacer has joined

  265. contrapunctus has left

  266. contrapunctus has joined

  267. yon has joined

  268. waqas has joined

  269. Guus

    This is what I referred to: http://logs.xmpp.org/xsf/2019-02-20#2019-02-20-5f32e6fa28106cba

  270. Zash

    Guus: Shouldn't be difficult to add. *hint*

  271. rtq3 has joined

  272. Seve

    I can't read it right now, but let's start with a page on the wiki and see where it goes from there, Guus?

  273. Guus

    I've created this placeholdeR: https://wiki.xmpp.org/web/Fostering_success

  274. Guus

    I can't immediately spend more time on that, without disappointing customers

  275. rtq3 has left

  276. Seve

    :D

  277. Seve

    Guus, thank you very much :)

  278. tux has joined

  279. alacer has left

  280. alacer has joined

  281. waqas has left

  282. larma has joined

  283. contrapunctus has left

  284. contrapunctus has joined

  285. kokonoe has left

  286. kokonoe has joined

  287. alacer has left

  288. Dele Olajide has left

  289. neshtaxmpp has left

  290. debacle has joined

  291. alacer has joined

  292. dwd

    I think that the lack of good clients - generally, as well as in particular on Apple - is because the bulk of inward investment into the community is for servers. If you look at all the major deployers of XMPP - ganmes, military etc - tehy all develop their own clients, and do not create generalized user-level clients.

  293. dwd

    IOW, this is a matter of straightforward economics. I'm not sure what the solution is, but I'm very confident that the aversion in the community toward saying any particular client is good in any particular way isn't helping, since it removes incentive.

  294. kokonoe has left

  295. contrapunctus has left

  296. contrapunctus has joined

  297. kokonoe has joined

  298. krauq has joined

  299. zinid

    dwd, however, a lot of them fail to write a client, like 9/10 among our customers, which is quite bad

  300. zinid

    and raises the question: why do they fail?

  301. MattJ

    dwd: to be clear I don't think the latter point is entirely true. Many of us believe in promoting good clients, just not using the XSF as a vehicle for that

  302. dwd

    zinid, In part, because writing clients is just hard.

  303. zinid

    dwd, true

  304. Guus

    dwd I don't think the community has an aversion towards saying any particular client is good. It's the XSF that doesn't do that, but it's fairly well known what clients are good.

  305. Guus

    (which, sadly, includes just a handful)

  306. kokonoe has left

  307. dwd

    Guus, MattJ - insert "officially" anywhere you like.

  308. Guus

    I officially need more coffe.

  309. Guus

    I officially need more coffee.

  310. dwd

    "coffee", but that just proves your point.

  311. ralphm

    part of what dwd says points out what I said about the perceived failure for some people. I.e. people working outside of games, military, have seen a degradation of the XMPP ecosystem.

  312. waqas has joined

  313. Guus

    I don't think that the incentive that's lost/gained by the XSF promoting individual implementations compares to those projects being able to make money from their project, to be honest.

  314. zinid

    well, the federated xmpp (aka jabber) has failed apparently

  315. zinid

    we will hardly count a million of federated users, most probably

  316. Guus

    iow: I don't think that the XSF extensively promoting some clients will have much effect.

  317. zinid

    when for gaming 1M is a good start ๐Ÿ™‚

  318. ralphm

    I have no way of telling how many users are federated right now.

  319. ralphm

    Or how that changed over time.

  320. kokonoe has joined

  321. krauq has left

  322. dwd

    ralphm, It'd be interesting to see if such a metric could be measured.

  323. zinid

    after "stats" XEP was deferred we now never know, that was such a mistake

  324. krauq has joined

  325. dwd

    Guus, I think the XSF pointing to success stories and helping to onboard users certainly couldn't hurt.

  326. dwd

    zinid, WHich one? I have only the vaguest recollection.

  327. Guus

    dwd it doesn't hurt. I don't think it will help much, either. Not to an extend that I'd be willing to open the can of worms that is neutrality.

  328. zinid

    dwd, what success stories? currently we only have a bunch of walled gardens typically with heavily modified protocol

  329. Guus

    if projects need the XSF to promote them to be successful, they won't be.

  330. Guus

    I'd love to use projects as an example of how XMPP is successful, though. But that's the other way around.

  331. dwd

    zinid, Harsh, but not a complete distortion.

  332. zinid

    I think the only success story currently is Conversations

  333. zinid

    if we're speaking about "Jabber"

  334. Guus

    So, let's reproduce that success.

  335. zinid

    time, dedication and money?

  336. Andrew Nenakhov

    Zash, > The iOS situation is sad. Not really.

  337. Guus

    but I do believe that more people are making a living based on federated, non-walled garden solutions

  338. kokonoe has left

  339. alacer has left

  340. Guus

    we have various hosting providers, which I'd be interested in finding out if they're successful (I might be joining those, soonish, btw)

  341. alacer has joined

  342. Guus

    we have various contractors that make a living from doing walled as well as non-walled stuff

  343. Guus

    (me!, but I know others that I shall not name without their approval)

  344. Andrew Nenakhov

    https://photos.app.goo.gl/Yuqyud7otrjAiUNu5

  345. Guus

    so, I don't think it's al bad as you might think. But, we can, and should, improve.

  346. zinid

    Andrew Nenakhov, but no groupchat support

  347. ralphm

    Indeed a client without MUC is a non-starter for me.

  348. Andrew Nenakhov

    There will be, just not that MUC or MIX shit

  349. zinid

    Andrew Nenakhov, and how this can be promoted?

  350. zinid

    Andrew Nenakhov, I just wonder, what should I say to users: use the one with incompatible implementation?

  351. Guus

    having a proprietary group chat smells like recreating a silo again.

  352. Andrew Nenakhov

    Like maybe new Xabber protocol that is partly compatible with xmpp and not held back by ineffective governance. ๐Ÿ˜‚

  353. Andrew Nenakhov

    > having a proprietary group chat smells like recreating a silo again. It's not meant to be proprietary.

  354. kokonoe has joined

  355. zinid

    Andrew Nenakhov, partially compatible is a bad selling point

  356. Guus

    (what he said)

  357. Andrew Nenakhov

    Better than the current situation.

  358. zinid

    Andrew Nenakhov, better for whom?

  359. Andrew Nenakhov

    For users of course.

  360. zinid

    for all users, like me included?

  361. lskdjf has joined

  362. zinid

    how can I join your groupchat from Conversations, Dino or Gajim?

  363. Guus

    I fear you'll mostly fragment things further.

  364. Andrew Nenakhov

    Probably. Our new group chat will work more or less ok on conversations, yes.

  365. Andrew Nenakhov

    Without any modifications.

  366. zinid

    yeah, how?

  367. kokonoe has left

  368. zinid

    and what will I see? partially working piece of shit?

  369. Andrew Nenakhov

    In fact it's already working. Just add support@gc.xabber.com to contacts.

  370. zinid

    so it's basically GroupChat 1.0?

  371. jubalh has joined

  372. zinid

    I mean from my perspective

  373. zinid

    I wonder how this can be selled by anyone except Xabber devs?

  374. Andrew Nenakhov

    There is a spec online xabber.com/protocols/

  375. zinid

    Guus, wrt fragmentation: what did you expect after 3 years of no progressing MIX?

  376. dwd

    Andrew Nenakhov, What's ineffective about the governance?

  377. Andrew Nenakhov

    We'll release standalone server that can be used on any xmpp server

  378. Guus

    zinid I'm not saying I'm happy about that. But creating a third variant does not help.

  379. jubalh

    is it possible to create a MUC on this server for profanity? looking for a server that could host our channel

  380. dwd

    jubalh, Profanity in general, or the project? :-)

  381. jubalh

    dwd, project ;)

  382. zinid

    Andrew Nenakhov, so you diverge and create a separate standards body with your governance? ๐Ÿ˜€

  383. zinid

    Andrew Nenakhov, I admit your work, but here is where our opinions diverge

  384. Guus

    jubalh - unsure - but why not host your own?

  385. waqas has left

  386. Guus

    jubalh - unsure - but why not host your own domain?

  387. zinid

    Guus, because it's a PITA? even for me actually

  388. jubalh

    Guus, because the orignal author who also owns the domain stopped hosting because he had a lot of problems with spam and idk. so i'm looking for an alternative

  389. Andrew Nenakhov

    > Andrew Nenakhov, What's ineffective about the governance? Take that story of extending xep-0085 to send extended notifications. Recording audio, video, ... - moved exactly nowhere in almost a year despite quite pressing need

  390. Guus

    jubalh - as I'm experimenting with setting up a hosting provider, I'd consider running a service for Profanity

  391. Guus

    maybe take that out of this MUC, though?

  392. jubalh

    Guus, yeah lets talk about it

  393. ta

    jubalh isnt github and a muc enough?

  394. Guus

    kindly contact me at guus.der.kinderen@igniterealtime.org

  395. Andrew Nenakhov

    > Andrew Nenakhov, so you diverge and create a separate standards body with your governance? ๐Ÿ˜€ A great xmpp schism. We'll denounce the council rule and install our own anticouncil.

  396. jubalh

    ta, for me github is enough. but i got several requests whether we could have a MUC for users

  397. kokonoe has joined

  398. zinid

    Andrew Nenakhov, ๐Ÿ˜€

  399. Andrew Nenakhov

    zinid, we'll invite you to it. All developers are welcome who want to build something working

  400. zinid

    Andrew Nenakhov, I'm not interested in fragmenting infrastructure

  401. ta

    The MUC can be hosted on any server. Just announce it on github.

  402. zinid

    worst case I can go to the IETF directly

  403. jubalh

    ta, just looking for a suitable server. wasnt sure if i can just create a MUC on any and they have to accept it. so i wanted to ask first

  404. ta

    The profanity.io domain should be saved though i think.

  405. dwd

    Andrew Nenakhov, So you made a suggestion, I offered a counter-proposal that would (I think) be acceptable, and you... did nothing. And it's me that's being ineffective?

  406. Andrew Nenakhov

    I'm ok with that counter proposal actually. Anything that works is ok. But it's still ineffective way that bloats the specification.

  407. Andrew Nenakhov

    Those matrix guys aren't exactly wrong with criticism of specs, cause Instread of amending one simple xep we create yet another xep

  408. zinid

    nah

  409. Guus

    and to fix that, you create yet another one.

  410. Andrew Nenakhov

    Recent example: xep166 that is incompatible with push

  411. zinid

    the problem is that someone cannot come to agreement ๐Ÿ™‚

  412. Andrew Nenakhov

    To fix it we need deferred 353

  413. Guus

    https://xkcd.com/927/

  414. zinid

    and so far Matrix community is in agreement, and we are constantly fighting

  415. Andrew Nenakhov

    We'll use that 353, ok, but it's not exactly healthy process that bloats standards count

  416. zinid

    Andrew Nenakhov, how are you going to address those problems in *your* standards body? ๐Ÿ˜€

  417. Zash

    You don't need a standards committee if everyone agrees with each other

  418. Andrew Nenakhov

    zinid, we'll rule it with an iron fist! โœŠ

  419. ralphm

    Regarding 3 years of no progress on MIX. I think this is unreasonbly unfair.

  420. zinid

    ralphm, why? still no implementations, still the XEPs have a lot of questions, still no agreement whether it should be recommended for implementation or not

  421. ralphm

    This is not easy, given what we want to achieve here, and it is not like many people have been spending time in trying to implement it, so far, but a lot of commentary about its perceived non-progress.

  422. ralphm

    I'm happy with dwd's message yesterday, and will use my day to respond to his implementation experience with my own.

  423. zinid

    I never said standards are easy, but this must have sane deadlines

  424. igoose has left

  425. ralphm

    zinid: I very much disagree.

  426. zinid

    I know that

  427. zinid

    I see that ๐Ÿ™‚

  428. zinid

    because, well, the XSF is just a standards body, blah-blah-blah

  429. dwd

    ralphm, I think it's reasonably fair, actually. Designing MIX with a fork-lift upgrade was a mistake we should - I should - have seen from the outset. We also took far too long to get a reasonable upgrade pathway from MUC.

  430. ralphm

    dwd: oh, I agree that in its current state we well never get a decent migration path, and I thought we made some headway at the Summit.

  431. dwd

    ralphm, Had we had those two from the outset - so a MIX could be accessed by MUC clients, or MIX clients on non-MIX servers - the upgrade path would have been simpler, and a lot more incentive around for people to move on with deployment.

  432. neshtaxmpp has joined

  433. contrapunctus has left

  434. contrapunctus has joined

  435. wurstsalat has left

  436. ralphm

    zinid: I'm not sure what you think the XSF *should* be doing, but I don't think that attempting to set deadlines to the creation of a standard, to a loosely connected set of people that voluntarily do what the XSF is currently doing, is a good approach. I'm happy for people to attempt other protocols.

  437. Guus

    I don't think deadlines are a good solution - but I do think that explicitly taking into account the time-to-adoption as a factor of the XEP would be a good idea.

  438. ralphm

    Many protocols we have standardized at the XSF were one of several. MUC has seen several iterations, so has Disco, PubSub, media streaming. In the end, implementation experience decided what we went with.

  439. zinid

    ralphm, I'm not going the deadlines should be written in stone, that's way I said "sane", not 10 years

  440. zinid

    *not saying

  441. ralphm

    Guus: we already do have this. Before a XEP goes Final, it must have multiple implementations.

  442. ralphm

    If there's commentary about the slowness of getting widely used specifications to Final, that's entirely valid.

  443. Guus

    ralphm that's to late in the process.

  444. ralphm

    Guus: it depends on how you look at it, and I disagree.

  445. Guus

    I disagree with your disagreement ๐Ÿ™‚

  446. Guus

    but, sure.

  447. ralphm

    Guus: it is not the case when a group of people wants to work on MIX, other people can't work on other solutions in the same problem domain. I welcome this, and in the end running code will strongly affect the outcome.

  448. ralphm

    It is not that the XSF is mandating all efforts to go into MIX.

  449. Guus

    Surely not, no

  450. ralphm

    So, I am happy to work on MIX, and people that like to see more implementations can work on it.

  451. Guus

    Well, in that light Andrew Nenakhov s MUC spec is a good idea. ๐Ÿ™‚

  452. Guus

    MUC-replacement*

  453. Guus

    kindly submit it as a XEP. ๐Ÿ™‚

  454. ralphm

    yes

  455. ralphm

    I also said the same to the ESL people that did MUC Light.

  456. pep. has left

  457. pep. has joined

  458. zinid

    ralphm, my vision of the XSF is to point into the right direction of the standardization process, otherwise I see not point in the XSF, as I said I can work with the IETF directly

  459. zinid

    really, how are you different from the IETF currently?

  460. kokonoe has left

  461. kokonoe has joined

  462. zinid

    as a developer I don't care about promotion and endless meetings yielding into nothing

  463. ralphm

    zinid: we are a standards body dedicated to XMPP. So I agree we are similar to the IETF.

  464. zinid

    you're now EXACT copy of the IETF

  465. ralphm

    What do you mean with 'now'?

  466. zinid

    after you reformatted from JSF to XSF

  467. ralphm

    zinid: I think you have a twisted view of the JSF.

  468. zinid

    I have a good view, I remember it circa 2004

  469. ralphm

    Besides the name, the XSF didn't change in direction.

  470. zinid

    it does in practice

  471. rtq3 has joined

  472. zinid

    back then the specs were designed by the people from the XSF, I could come, report about problem and it's fixed, and now?

  473. ralphm

    I've been on the Council between 2004 and 2013.

  474. ralphm

    And the process hasn't changed, and specs were designed by people in the community.

  475. zinid

    sure, and there were a lot of productive work, done mostly by Peter and friends, they didn't redirect me to "hey, do it yourself"

  476. zinid

    ralphm, the analogy: I started an OSS project, but I don't write code, I only accept PRs - that's the current state of the XSF, it was *different* back then

  477. ralphm

    zinid: yes Peter indeed did a lot of things, because he happened to be payed by his employer to do this.

  478. ralphm

    This was not a function of the XSF, but rather of a very active person being able to dedicate his time to it.

  479. zinid

    ok, maybe that, but I don't care that much why it was the way it was

  480. Andrew Nenakhov

    zinid, see, they support my idea of anticouncil

  481. ralphm

    So if your point is, the pace of things in the XSF changed since Peter moved to other things, I agree.

  482. zinid

    okay, let's say that's my point, so the XSF has bus factor = 1?

  483. Andrew Nenakhov

    I'll raise some more funds, hire you, and together we will rule the galax^Wxmpp

  484. ralphm

    zinid: but do you really feel it is unreasonable to ask people in the community to put in effort to change things? The Council's job, for example, is not to create standards, it is to assist the process of getting them there.

  485. contrapunctus has left

  486. contrapunctus has joined

  487. zinid

    ralphm, and the whole point of the XSF is now?

  488. ralphm

    still the same as ever

  489. zinid

    why should I work with the XSF?

  490. Andrew Nenakhov

    Soo why don't we get the 0085 standard "there" to meet modern requirements?

  491. zinid

    maybe we will just resurrect xmpp wg at the ietf?

  492. ralphm

    You don't have to, and indeed some people have instead opted to go to the IETF directly with a draft.

  493. zinid

    ralphm, so the only your answer is "go do it in a different place" without convincing me as a developer?

  494. ralphm

    No, that's not what I said.

  495. zinid

    but I'm not convinced, really, why shouldn't I go directly to the IETF?

  496. zinid

    or even better, maybe we will move the process to the xmpp wg?

  497. zinid

    that will be fair and my complaints will become invalidated

  498. ralphm

    zinid: If you want something to happen at any standards organization (the XSF, the IETF, IEEE, or wherever), you will have to put in work to create your proposal, convince people to support your ideas, find people to give their view on things, and get people to implement it.

  499. zinid

    ralphm, and? how the XSF will help me?

  500. zinid

    please don't abstract

  501. jubalh has left

  502. ralphm

    zinid: the XSF is not a magical group of people that just do things on your behalf. The Council is an elected set of individuals that want to dedicate time and their expertise to help out (other) people to create good standards. You could be one of them.

  503. Wiktor

    ralphm, I think zinid's point is that XSF could (should?) just be replaced by IETF WG and everything else would stay the same (process etc.), so there are no advantages of having XSF over XMPP WG... that's how I get it

  504. zinid

    Wiktor, right

  505. zinid

    and the current situation is even worse: if I say wtf is matrix.org - I'm replied "and wtf is XSF"?

  506. zinid

    and when I say I'm working on the IETF specs - that will sound much more solid

  507. ralphm

    To whom?

  508. zinid

    ralphm, to the XMPP opponents

  509. alacer has left

  510. zinid

    and I cannot use the argument that Matrix is a non-standard body

  511. ralphm

    I don't work on XMPP to appease its opponents.

  512. zinid

    but I digress actually

  513. waqas has joined

  514. zinid

    ralphm, sure, but when you have business you kinda deal with competetors

  515. zinid

    anyway, so what stops the XSF to move the process to the IETF entirely?

  516. Andrew Nenakhov

    XMPP as a platform is on fire. And many here refuse to accept it.

  517. Zash

    If you have a business you should spend money on marketing yourself, not negative marketing on your competitors.

  518. Andrew Nenakhov

    I'm unhappy because I want to create great federated chat products, but can't do it with current xmpp standards.

  519. ralphm

    Andrew Nenakhov: because of the XSF?

  520. Wiktor

    Zash, I think that's zinid's idea, having XSF inside IETF would give XMPP better position, that XEPs are developed inside IETF not XSF

  521. Wiktor

    better image* or however one would put it

  522. zinid

    sure, IETF is an "industry standard", that's pure marketing thing

  523. ralphm

    I think creating great federated chat products is not related to where the standards have been defined.

  524. zinid

    general words again

  525. zinid

    you're dropping some obstacles to make a general claim which sounds valid

  526. Andrew Nenakhov

    ralphm, we can create great products on our own set of standards. Yes.

  527. ralphm

    zinid: I'm just giving you my perspective. I think the idea that labeling a standard XSF or IETF doesn't necessarily help to actually get traction or success. I think that working on standards within the XSF helps with getting insight of people that have worked on similar problems, but in the end it comes down to people (XSF or not) having to put in the work.

  528. zinid

    and my question still holds: what makes the XSF a lot more different than XMPP WG at IETF?

  529. neshtaxmpp has left

  530. zinid

    > helps with getting insight of people that have worked on similar problems like in the ietf xmpp wg mail list? ๐Ÿ˜‰

  531. ralphm

    Yes, they are functionally equivalent.

  532. alacer has joined

  533. zinid

    okay, I see

  534. ralphm

    Except the IETF XMPP WG isn't a thing right now, and the XSF is.

  535. zinid

    why? because it's formally concluded?

  536. contrapunctus has left

  537. zinid

    we can call it xmpp-ng!!!

  538. contrapunctus has joined

  539. zinid

    people at the ietf like this -ng stuff ๐Ÿ˜€

  540. Zash

    What difference would that make?

  541. ralphm

    You could do a new XMPP WG at the IETF, but I wonder if that would help you in any way.

  542. ralphm

    As likely the same (active) people would get involved.

  543. zinid

    ralphm, just like the XSF doesn't help me like at all?

  544. neshtaxmpp has joined

  545. zinid

    I'm probably not clear enough

  546. Wiktor

    zinid, XSF is operational, I guess people don't want change for change sake and setting up XMPP WG would be extra work that no-one wants to do (that's understandable)

  547. kokonoe has left

  548. ralphm

    XSF is just a formalisation of processes around work that needs to be done by people. You can move the process elsewhere, but you still need the people, and the process to get to a similar place.

  549. dwd

    zinid, One benefit of the XSF over the IETF is domain expertise of the Council. The Council's absolutely not perfect, but the IETF has only one person who knows anything about XMPP (or, indeed, messaging) and that itself is only by fluke.

  550. dwd

    zinid, Also, we move a lot faster than the IETF, surprising as that might seem.

  551. zinid

    Wiktor, but maybe, marketing wise, it worth the effort to move to the xmpp wg?

  552. dwd

    zinid, As an example, TLS 1.3 was approved in November 2017, but finally published in August 2018.

  553. zinid

    dwd, and we have tons of experimental or drafts being widely deployed

  554. kokonoe has joined

  555. zinid

    I recall that drama

  556. Guus

    Just got back from lunch.

  557. dwd

    zinid, A benefit of doing (more) work in the IETF is greater visibility, particularly within that group. I would like to encourage people to do that where it makes clear sense (like security areas). Your recent work is a good candidate here, I did wonder about pushing that way, venue-wise.

  558. Guus

    What is the benefit from moving to an ietf workgroup?

  559. ralphm

    Guus: what dwd says

  560. waqas has left

  561. Guus

    Visibility within the ietf?

  562. dwd

    zinid, But I have, equally, had a huge amount of push-back when i've done this before, with people telling me that I'm doing process for process sake. But I get that all the time anyway. :-)

  563. ralphm

    So typically we ventured out to the IETF for things like SASL, TLS, nameprep/prรฉcis, DNS related issues

  564. zinid

    dwd, and will XSF help me with the IETF bureaucracy? Like resurrecting the WG, IANA contacts? I bet it won't

  565. ralphm

    zinid: you keep mentioning you want help, but what do you expect others to do for you, exactly?

  566. ralphm

    zinid: what do you want to achieve?

  567. zinid

    ralphm, I don't ask the XSF anything to do already, you just said me that's pointless

  568. zinid

    so I use it as a very slow wiki to publish my XEPs

  569. zinid

    thanks at least for that

  570. ralphm

    I didn't say the XSF is pointless, that's *your* opinion.

  571. zinid

    okay

  572. dwd

    zinid, The XSF has resisted, in the past, having a formal Liaison with the IETF - but we could do that. That would give us a more fomralised pathway through to the IESG etc.

  573. ralphm

    And also, I didn't say I (or even the XSF) didn't want to help you.

  574. ralphm

    zinid: it just seems that you want something different. Faster, or in another way. But it is not entirely clear to me what.

  575. dwd

    zinid, In turn, a liaison relationship would allow the XSF to do a lot more to actively help steer XMPP work through the IETF.

  576. zinid

    dwd, sorry, I don't understand what you're saying, I'm not into bureacracy of the IETF, but I'm aware of the XSF's one

  577. zinid

    but seems like yeah, I need to deal with that eventually

  578. dwd

    zinid, Effectively, a formal relationship with the IETF where they recognise us and have a defined contact for combined work.

  579. dwd

    zinid, As opposed to now, where while several senior IETFers are current or previous XSF participants (and often members), there's no formal relationship, and so no way for "The XSF" to do things like request the WG is reopened.

  580. dwd

    zinid, GIven there's active XMPP work going on in the IETF now, this seems like something we should explore.

  581. ralphm

    dwd: I think a Liaison is not a bad idea in itself. How does it help zinid, though?

  582. Guus

    Is it fair to summarize the discussion up til now with "Zinid is unhappy with the slow bureaucracy of the XSF, and suggests we replace the XSF with an IETF workgroup to speed things up" ?

  583. zinid

    dwd, goot to know

  584. zinid

    Guus, I actually admit that IETF bureaucracy is worse, please don't misunderstand me

  585. dwd

    ralphm, It'd help him navigate some of his RELOAD work through, if we wanted to do that. Or at least help us highlight the work in the right places there. Similarly, it'd give MILE and SACM a pathway through to request reviews on their XMPP work.

  586. Guus

    zinid then I don't understand the reason for your suggestion. Or I don't understand your suggestion itself, maybe.

  587. dwd

    Guus, FWIW, I understood his comments to be about exploring ways to improve the standards process and the outcome of it, and not any particular concrete suggestion.

  588. ralphm

    dwd: to be honest, even the Board got involved with his RELOAD work, and even though it might have been slowish, we discussed https://xmpp.org/extensions/inbox/eax-car.html and requested modifications.

  589. ralphm

    I'd like to understand how we are *not* helping.

  590. dwd

    ralphm, Yes, understanding how the XSF could help more is indeed useful.

  591. Guus

    So is the idea to look at how the IETF has structured their processes for that?

  592. dwd

    ralphm, But I don't think that needs to be a particularly adversarial process.

  593. ralphm

    No, the idea is that we first understand the problem, before we jump to solutions.

  594. Zash

    Problem Statements are good

  595. dwd

    Guus, The XSF's process is essentially a streamlined version of the IETF's, with various tweaks to promote safe early adoption.

  596. ralphm

    dwd: agreed. And if I came across as adversarial, that was not my intent.

  597. Guus

    Yes, I'm trying to understand the reasoning behind this discussion

  598. Guus

    I'm not suggesting any change or solution at this point

  599. Guus

    I simply want to understand what all of this talk is aiming to achieve.

  600. neshtaxmpp has left

  601. dwd

    ralphm, Sometimes, the best way to uncover a problem is to see what solutions people propose. :-)

  602. dwd

    ralphm, From there, one can explore their rationale for the solution, and see what the problem might be.

  603. ralphm

    If the XSF (or bodies within) is preventing people to move forward, I'd to like to see how we can help that. But similarly, if people have a different perception on what the XSF does, I'd like to help explain that

  604. igoose has joined

  605. rtq3 has left

  606. Andrew Nenakhov

    As a developer, I'd be happy with xsf that I could ask, "I need to send recording video notifications instead of just typing", and would be told, "ah cool, we'll add XEP-0499 chat notifications subtype", I say "cool!" and implement it

  607. ralphm

    Andrew Nenakhov: ok, but

  608. Guus

    Doesn't the XSF do exactly that - likely not for that exact feature that you're looking for, but for 100's of others?

  609. ralphm

    Andrew Nenakhov: why would it then not be ok to ask for a contribution to the document to that effect?

  610. Guus

    on top of that, the XSF facilitates a process in which you can add specifications for the feature that you're missing in such a way that it can be adopted by everyone that's interested.

  611. ralphm

    Andrew Nenakhov: do I understand correctly that you expect the XSF to whip up a spec for a suggestion for something like this?

  612. Andrew Nenakhov

    That would be more of what I would expect of a standards body. Maybe after a discussion.

  613. Guus

    Isn't that _exactly_ what the XSF does?

  614. ralphm

    Andrew Nenakhov: I'm asking because indeed that kinda happened before. People would suggest things, and Peter would go and create a spec for it as Author, and submit it to, well, himself as Editor, and then get it to Council, where he'd (also) vote on it.

  615. zinid

    ralphm, eax-car is actually would be a very good help from the XSF, but I was asked to do moar bureaucracy, and to spend several weeks forming business rules of CA coordination, which I can only copy from the CA/B Forum's requirements. So even here useless. And that's absolutely not for RELOAD, I described it in details in my email, but still nobody reads

  616. zinid

    whatever

  617. Guus

    you supply a suggestion (in the form of a XEP). The XSF discusses it. It gets published.

  618. zinid

    ralphm, I decided not to work on the XEP. Let it be just random collections of CA certificates on every client

  619. ralphm

    zinid: well, it would have been great that have given that feedback after our meeting. This is the first I hear about you not being happy about what we discussed.

  620. zinid

    and my EAX technical XEPs I will discuss with the Council

  621. Andrew Nenakhov

    ralphm, yes, what you describe about Peter would make me more happy that necessity to write own XEP. I can probably do that and will do that in the future, if it's necessary.

  622. Alex has joined

  623. Guus

    zinid, if you think that any feedback that we give is pointless, yeah, then I can see how that frustrates you.

  624. ralphm

    Andrew Nenakhov: ok, so then indeed it seems to be an expectance mismatch. The XSF does not create new XEPs. It adopts them and manages the process of making it a good protocol by using the expertise of the Standards JIG (basically everyone in the XMPP interested in standards, on the standards mailinglist) under the guidance of the Editor and Council. So indeed we currently *do* expect people to write XEPs themselves.

  625. Guus

    I for one, think it offers value - yes, it slows things down, but it will also prevent issues down the road.

  626. zinid

    > So indeed we currently *do* expect people to write XEPs themselves. And the incentives?

  627. ralphm

    zinid: I agree with Guus, and I think it is reasonable to write up details on what you expect the XSF to do in practice, before asking it do it.

  628. Guus

    I'm out for a dentist appointment.

  629. zinid

    also, regarding my "frustration", I can work with the Council, it's not pointless, but the whole XSF with its board is useless, sorry

  630. ralphm

    zinid: people have different incentives to write specfications, and then also for submitting them to a standards body. This is up to you. I can only comment on what we then will attempt to facilitate.

  631. ralphm

    zinid: the Council is the most important part of the XSF indeed. The Board is primarily there for having a legal structure to do our work in, regarding funding of resources (like website, mailinglists), having a process for electing the Council from a membership, and facilitating events like the Summit.

  632. Andrew Nenakhov

    ralphm, actually this situation is kinda uneven. We write software , we write XEPs, and then XSF will decide if it's accepted or not. Kinda not cool.

  633. zinid

    Andrew Nenakhov, +1

  634. ralphm

    Andrew Nenakhov: there is *no* requirement to have your extensions approved by the XSF before you can use them.

  635. Andrew Nenakhov

    If all xsf does is approval, maybe we can join efforts with zinid and have our own anticouncil. ?

  636. zinid

    ralphm, thus we will have his non-standard imlementation, great

  637. zinid

    Andrew Nenakhov, I'm not going into anticouncil!!! ๐Ÿ˜€

  638. zinid

    Andrew Nenakhov, even working with IETF turtle would be much less effort

  639. ralphm

    zinid: so either you work with a standards body, and then have a document vetted by hopefully more people, or you don't. Also, a standard is only a standard if it is used by multiple parties, not if we rubberstamp it.

  640. zinid

    ralphm, I got your point, yes, clearly

  641. zinid

    I just disagree

  642. lnj has left

  643. Zash

    Being published by the XSF doesn't force anyone else to implement it.

  644. ralphm

    zinid: so what *do* you expect then?

  645. zinid

    ralphm, the DIRECTION

  646. zinid

    what's the decision on MIX? should we stop accepting hacks and patches to MUC?

  647. zinid

    because the XSF is supposed to be clever, it should analyze current adoption and decide

  648. ralphm

    zinid: it seems that MIX is not in a place where it could replace MUC. There are a few people that have slowly started working on implementations (my team, isode, dwd), and there's probably still work to do.

  649. alacer has left

  650. zinid

    ralphm, good to hear you started, I finished already ๐Ÿ™‚

  651. Zash

    Having Someoneโ„ข with a vision and enough energy to be driving would be good, but hard to produce in a volonteer based org.

  652. zinid

    Zash, then no point pretending?

  653. ralphm

    My personal opinion is that there are a lot of good things in there, but it is lacking in a proper upgrade path, unclear in some areas (that e.g. dwd has pointed out yesterday).

  654. lumi has joined

  655. zinid

    in my book, the best the XSF can do is to move process to the IETF

  656. zinid

    for example to help me working with the IETF

  657. zinid

    (since you asked what help I wanted)

  658. zinid

    it's not solely because of me of course, before you start ranting ๐Ÿ™‚

  659. zinid

    moving to the XSF will bring more recognition to the XSF and XMPP

  660. zinid

    currently XSF is like "who is it?"

  661. ralphm

    zinid: I'm sad about you feeling I'm ranting. I'm trying to help understand what issues you have with the XSF, the Board, or me.

  662. ralphm

    zinid: I have seen some epressions of frustration by you and Andrew Nenakhov over the last few months, and I thought this was as good time as any to see if I can get it resolved.

  663. zinid

    so I suggested the solution

  664. Yagiza has left

  665. zinid

    I will have zero complaints then

  666. ralphm

    zinid: if your suggestion is closing up shop and moving to the IETF, I'm not sure how that is constructive.

  667. zinid

    I will just work within WG discussing technical stuff

  668. zinid

    ralphm, marketing wise

  669. ralphm

    I don't see the marketing angle at all.

  670. zinid

    ralphm, okay

  671. zinid

    I think you just don't want to see, I understand that you like all this XSF community around you, and you're the chair

  672. ralphm

    I.e. I don't see how it helps you that the rubberstamp is from the IETF rather than the XSF. Who would actually care about this, and is this really a problem we need to address?

  673. ralphm

    zinid: well, I like the community, I don

  674. yon has left

  675. ralphm

    't care that I am the Chair. I'm happy that I can help the community in that role.

  676. ralphm

    If if the reverse isn't true, I'd do other stuff

  677. ralphm

    Like help out with Council, or the Editors

  678. zinid

    my customers actually care, because when I say we support "industry standard" we're lying, XSF is not accepted as a standards body, unlike IETF

  679. Zash

    Why are you here then?

  680. zinid

    nice question ๐Ÿ™‚

  681. zinid

    sorry for disturbing your bubble

  682. waqas has joined

  683. ralphm

    zinid: for all things XMPP, I'd say we've been generally accepted as the body that defines its "industry standards".

  684. ralphm

    It is not like there's a vote on which standards bodies are 'real' or not.

  685. zinid

    marketing wise there is

  686. yon has joined

  687. ralphm

    zinid: so if the IETF would say: for all your XMPP business go to the XSF, it would help?

  688. zinid

    who will read what they say? the customers will read I E T F.

  689. zinid

    means no vendor lock-in, good

  690. Zash

    The IETF doesn't make standards. Everyone using the specifications is what makes it into standards.

  691. zinid

    > The mission of the IETF is to make the Internet work better by producing high quality, relevant technical documents that influence the way people design, use, and manage the Internet.

  692. ralphm

    yeah, also the IETF allows for publishing drafts outside of WGs that are not really vetted

  693. ralphm

    โ€œThe XMPP Standards Foundation (also known as the XSF and formerly the Jabber Software Foundation) is an independent, nonprofit standards development organisation whose primary mission is to define open protocols for presence, instant messaging, and real-time communication and collaboration on top of the IETFโ€™s Extensible Messaging and Presence Protocol (XMPP).โ€

  694. Zash

    XMPP is an IETF standard, but you can still build lock-in, not federeate etc.

  695. zinid

    Zash, are we talking about marketing here?

  696. zinid

    or do you think I don't know what you're saying?

  697. Zash

    Are we?

  698. zinid

    I can write in my facebook blog "I create standards", does it count?

  699. zinid

    Zash, well, yes, we're talking about marketing until you chimed it

  700. zinid

    asking me stupid question about "why I'm here"

  701. Zash

    Ignore me then

  702. Guus

    XMPP is an IETF standard. Us acting as a IETF workgroup would not add much on top of that in the sense of marketable exposure.

  703. ralphm

    zinid: also note that RFC 6120 points to the XSF in several places, like section 8.4, that among other things says: โ€œAn extension element or extension attribute is said to be "extended content" and the qualifying namespace for such an element or attribute is said to be an "extended namespace". Informational Note: Although extended namespaces for XMPP are commonly defined by the XMPP Standards Foundation (XSF) and by the IETF, no specification or IETF standards action is necessary to define extended namespaces, and any individual or organization is free to define XMPP extensions.โ€

  704. zinid

    okay, you disagree with everything I say, I disagree with everything you say, we should probably stop here

  705. ralphm

    zinid: so you can write "I develop protocols" on facebook. Whether they become standards, is to be seen. As I mentioned before, a specification becomes a standard because of being used by multiple parties, not because of the rubberstamps on it.

  706. ralphm

    zinid: I'm sorry about that. Thanks for taking the time to explain your point of view, though.

  707. Ge0rG

    I agree that it would be great to have a better documented common vision of where xmpp is moving, and it would be great to have council members working full time on xmpp. Unfortunately, the latter is not going to happen.

  708. Zash

    I believe someone said that the council was more active in the past, rather than just voting on things

  709. Alex has left

  710. kokonoe has left

  711. alacer has joined

  712. Ge0rG

    Yes. And having council members being paid for that task immediately brings up conflicts of interest.

  713. winfried has joined

  714. ralphm

    Zash: I don't feel that the Council is now less productive than when I was on it (for 8 years).

  715. Alex has joined

  716. igoose has left

  717. ralphm

    I'd love people being payed by their employer to be able to spend time on the volunteer efforts in the various roles at the XSF.

  718. Zash

    That's mostly how the IETF works

  719. ralphm

    It is how all standards bodies work.

  720. ralphm

    Although, of course, some of them have entry fees for organizations to be able to participate.

  721. kokonoe has joined

  722. igoose has joined

  723. Zash

    Our Summits are notoriously cheap compared to the ETFs :)

  724. Zash

    Our Summits are notoriously cheap compared to the IETFs :)

  725. rtq3 has joined

  726. waqas has left

  727. zinid

    and the outcome of your meetings?

  728. ralphm

    And less humming

  729. zinid

    drinking beer? I'm not against beer, but that's probably not the goal

  730. ralphm

    zinid: I found our meeting useful, and just assuming we just drunk beer is not a very good argument.

  731. Zash

    There's beer at IETF meetings too

  732. zinid

    ralphm, useful? I don't know, where to read about that?

  733. zinid

    just my voice from the floor

  734. ralphm

    zinid: we even allowed people to remotely participate.

  735. rtq3 has left

  736. zinid

    that's impressive ๐Ÿ˜€

  737. Andrew Nenakhov

    On the positive side: we have working calls on iOS. Can so done at XSF resurrect xep-353? 0166 doesn't cut it.

  738. rtq3 has joined

  739. Andrew Nenakhov

    *can someone

  740. zinid

    Andrew Nenakhov, nobody can, do it yourself or GTFO

  741. zinid

    that's the official position

  742. Andrew Nenakhov

    But it's in deferred state

  743. zinid

    Andrew Nenakhov, take the authorship

  744. ralphm

    zinid: I'd have loved you to have been there, physically or remotely.

  745. Andrew Nenakhov

    I assume it's the council that moves XEPs between states?

  746. ralphm

    Andrew Nenakhov: we've recently made a change to XEP-0001 to deal with orphaned specs.

  747. zinid

    Andrew Nenakhov, yes, because the author's inactivity, so it requires new authorship to move it back

  748. ralphm

    zinid: it *doesn't*

  749. zinid

    ralphm, so you changed that?

  750. Andrew Nenakhov

    zinid, actually I'd rather change 0166 than support 0353

  751. ralphm

    zinid: yes, I actually wrote the text for it.

  752. zinid

    okay, I misread that

  753. Zash

    Andrew Nenakhov: Is 0353 in need of anything specific or could it be advanced as-is?

  754. ralphm

    zinid: but we do require someone to help guide it through the process of proposing it as Draft in case the author has abandoned it: the Document Shepherd.

  755. Andrew Nenakhov

    Zash, my developer says he did everything as is in 0353, so it's probably good to use

  756. ralphm

    zinid: the first step, in case of XEP-0353 would be to contact fippo or stpeter. Sending a message to the standards list would be good first step.

  757. ralphm

    Andrew Nenakhov: for what it is worth, we did it slightly differently, with IQs, which required server support. Even if we don't end up doing it like XEP-0353 says, there's clearly a need for a solution.

  758. Zash

    Andrew Nenakhov: If they have any feedback then that would be good to share with the list. Even if it's just "It's fine, it could made Draft"

  759. Andrew Nenakhov

    Ok.

  760. ralphm

    Andrew Nenakhov: what we found is that you want to indeed share the session-initiate to all the resources, and then define how accepting the session works (there might be two resources sending a response).

  761. rtq3 has left

  762. rtq3 has joined

  763. ralphm

    The problem with XEP-0353 doesn't do that, it precedes the process.

  764. ralphm

    So you get more roundtrip.

  765. ralphm

    Instead, if you somehow got the payload of the session-initiate to all resources, they could already start doing things, like setting up a session with a TURN server, or something.

  766. Dele Olajide has joined

  767. Dele Olajide has left

  768. lumi has left

  769. Andrew Nenakhov

    ralphm, we don't think that two resources sending a response is a big problem. User can't answer a call from tablet and pnohe at once. And even if he does , second device will get 'line busy' answer, I think

  770. ralphm

    Sure, but it would need to be defined.

  771. Alex has left

  772. ralphm

    I just spoke to a colleague and he mentioned that in a previous project they actually 'just' replaced the initial iq for a session-initiate with a message to the bare JID.

  773. Zash

    ralphm: Do you do anything so that a currently offline client can later see what calls were made? Eg missed calls while being offline seems like a useful feature.

  774. ralphm

    And then had some kind of conflict resolution.

  775. ralphm

    Zash: yes, separately

  776. ralphm

    Zash: we have this concept of CDR messages (Call Detail Record) to alert all resources of the result of a session.

  777. Zash

    This seems like something you'd get partially by using messages for initial setup.

  778. ralphm

    https://ralphm.net/publications/xmpp_chat_voip/#/6/5

  779. ralphm

    The CDRs are after the fact.

  780. ralphm

    That is after the call has been terminated in one way or the other.

  781. Andrew Nenakhov

    Zash, If calls are initiated by a message they'll be in message archive, I guess

  782. ralphm

    But you want other clients to know which resource accepted the session-initiate.

  783. Zash

    Yes. But a proper CDR would include whether it was answered and how long the call was.

  784. Yagiza has joined

  785. Andrew Nenakhov

    True.

  786. ralphm

    Zash: indeed, as in my example

  787. ralphm

    We didn't get to propose this to the XSF.

  788. alacer has left

  789. rtq3 has left

  790. Zash

    ralphm: That's from the presentation you gave at the Summit right?

  791. Zash

    Server-assisted Jingle does seem in line with the routing changes proposed.

  792. alacer has joined

  793. ralphm

    Zash: yes

  794. ralphm

    Zash: well, yes and no. Our implementation was server assisted, but I'm unsure if that's ideal.

  795. ralphm

    Again because of the deployment issues (not unlike MIX)

  796. Zash

    353 + MAM could get you some of it.

  797. contrapunctus has left

  798. contrapunctus has joined

  799. ralphm

    I don't think XEP-0353 is the right approach though, because it precedes the actual initiation.

  800. ralphm

    So a client knows it has a call, but cannot setup anything yet, because he doesn't yet have the details of the call.

  801. Zash

    Hm, and it has some overlap with SIMS

  802. ralphm

    Zash: how so?

  803. Zash

    In the abstract "Jingle initiaded via <message>" sorta way.

  804. waqas has joined

  805. ralphm

    oh

  806. Zash

    SIMS as in https://xmpp.org/extensions/xep-0385.html

  807. Andrew Nenakhov

    I actually think SIMS is a very bad idea

  808. Andrew Nenakhov

    Like yet another markup language for year 2019

  809. ralphm

    Well, we used SIMS for sharing media in our app.

  810. moparisthebest

    I don't *think* you are talking about SIMS Andrew Nenakhov ?

  811. ralphm

    I don't see it as another markup, but more as a format to describe a shared image, video, audio thing.

  812. moparisthebest

    Andrew Nenakhov, I *think* you are talking about https://xmpp.org/extensions/xep-0394.html Message Markup

  813. moparisthebest

    ?

  814. ralphm

    We used it without the begin/end attributes on the reference container, though.

  815. Zash

    I see it as reusing the Jingle FT descriptor in

  816. Zash

    ... a message

  817. ralphm

    So if the objection is on that wrapper, I think that's worth discussing.

  818. Zash

    I can understand that it looks a lot bigger than OOB that's used currently with http upload, but it allows some nice things.

  819. yon has left

  820. ralphm

    Those extra things were essential in building something similar to sharing media as for example WhatsApp.

  821. ralphm

    Particularly thumbnails, and caption.

  822. ralphm

    I think they ended up not really using the hashes for caching, although I still think they should have.

  823. Andrew Nenakhov

    moparisthebest, SIMS is using references

  824. Andrew Nenakhov

    <reference xmlns='urn:xmpp:reference:0' begin='17' end='20' type='data'>

  825. Andrew Nenakhov

    Pretty much a very ugly markup language to me

  826. ralphm

    Andrew Nenakhov: first of all, you don't actually have to use the begin/end attributes, and just included it as some kind of attachment.

  827. ralphm

    Second, the idea of References came from how Twitter allows for marking up Tweets in their API.

  828. Andrew Nenakhov

    Twitter did a number of changes to how they mark up their messages

  829. ralphm

    Particularly useful for marking up @mentions, #hash, links, etc. in a plain-text string. Potentially after the fact.

  830. Andrew Nenakhov

    Currently any images now are expempt from 280 char limit, they are just "added"

  831. ralphm

    (much like how Slack sends a separate message when you submit a plain-text message to highlight stuff)

  832. Andrew Nenakhov

    I'd rather resurrect xep-0071 :-/

  833. ralphm

    Andrew Nenakhov: I'm not talking about that, I'm talking about this: https://developer.twitter.com/en/docs/tweets/data-dictionary/overview/entities-object.html

  834. waqas has left

  835. ralphm

    Andrew Nenakhov: sure, there are pros and cons.

  836. ralphm

    But XEP-0071 didn't allow for marking up the stuff I mentioned above in much the same way.

  837. ralphm

    At least not semantically.

  838. Andrew Nenakhov

    Well at least you don't use JSON ๐Ÿ˜‚

  839. Andrew Nenakhov

    I'll think about 385.

  840. ralphm

    With References you can say: "this bit here is a hashtag, and here is a link to something useful to do with that"

  841. Andrew Nenakhov

    I'm not entirely happy with 221 xep modification we currently is to share media files

  842. Andrew Nenakhov

    https://xmpp.redsolution.com/upload/4bddf4f264f5c6577f16551f16a0abdf3f7ff84d/TKd1DfB6/IMG_20190228_161844266.jpg https://xmpp.redsolution.com/upload/4bddf4f264f5c6577f16551f16a0abdf3f7ff84d/1cjpVG7c/images_2_.jpg https://xmpp.redsolution.com/upload/4bddf4f264f5c6577f16551f16a0abdf3f7ff84d/FFCwhXmN/IMG_20190303_163919048.jpg

  843. ralphm

    Or: "this piece of text really is a think that can be interpreted as a custom emoji, and here is a link to a thumbnail to replace it with when rendering on a device that can show arbitrary images (unlike, say, a console client).

  844. UsL has left

  845. Yagiza

    Andrew Nenakhov, why resurrecting XEP-0071 instead of improving XEP-0393?

  846. ralphm

    Yagiza: for what it is worth, XEP-0393 doesn't resolve this issue of References, but they can work side-by-side.

  847. Andrew Nenakhov

    Yagiza, because 393 is silly bad horrible idea

  848. Yagiza

    Andrew Nenakhov, ok, XEP-0394, of course.

  849. ralphm

    Andrew Nenakhov: why? It just documents some convention on how people *already* markup their plain-text.

  850. UsL has joined

  851. Yagiza

    ralphm, so, why it's a standards track, not informational or historical in that case?

  852. ralphm

    Yagiza: ah, yes, that _is_ similar to References.

  853. valo has left

  854. ralphm

    Yagiza: valid question, maybe because it also tells clients how they can interpret it, which is something that is not that widespread.

  855. ralphm

    I.e. the difference between what users type, and what clients show.

  856. Andrew Nenakhov

    ralphm, because markdown is a method of WYSINWYG editing, a means to encode html in a more human readable way. It is not supposed to be passed as markdown markuped text, it is supposed to be rendered into html

  857. Zash

    Nothing is perfect in this area

  858. ralphm

    Zash: right

  859. Andrew Nenakhov

    So if you format with markdown, you render html and send HTML

  860. ralphm

    Andrew Nenakhov: well, outside of XMPP there are so many uses of Markdown contrary to your point, that I'm not even sure where to begin.

  861. Zash

    393 isn't Markdown tho

  862. ralphm

    People even write books with markdown files as the the source

  863. ralphm

    Zash: and that

  864. pep. has left

  865. pep. has joined

  866. Yagiza

    Andrew Nenakhov, anyway, sending HTML version of the text along with plain text is much worse idea, than sending formatting along with the text.

  867. Yagiza

    ralphm, so, why XEP-0245 is informational, but XEP-0393 is standards track?

  868. Andrew Nenakhov

    ralphm, I've seen services where you enter html formatted table and they render a markdown formatted table. Existence of such services doesn't prove anything about markdown but that the creators of service apparently forgot that you can use html to format tables directly in markdown.

  869. Zash

    ralphm: Unfortunately often mistaken for Markdown tho, which produces the same problem XHTML-IM has, due to HTML-passtrough being a feature of many markdown libraries

  870. Andrew Nenakhov

    Zash, > 393 isn't Markdown tho Uglier, yes. Same principle, though.

  871. lnj has joined

  872. Zash

    Andrew Nenakhov: Roughtly what people have been using in plain text email since before I was born. Probably.

  873. Andrew Nenakhov

    Why, if we have html, for, like, 30 years?

  874. Yagiza

    Andrew Nenakhov, XEP-0393 is just another LML description.

  875. ralphm

    Yagiza: XEP-0245, which documents /me, is about specifying how the markup *and* implementation have been done historically. The use of /me predates XMPP, and by the time this spec was submitted, all clients already did this.

  876. Nekit has left

  877. Nekit has joined

  878. Yagiza

    ralphm, so, why it is not hystorical?

  879. ralphm

    I don't remember

  880. ralphm

    Yagiza: oh wait

  881. ralphm

    Yagiza: historical is for things from before we had a JEP/XEP process. I suppose it could have been historical. But it is probably Informational because it is more a best-practice kind of thing.

  882. ralphm

    I think it could have gone either way.

  883. Alex has joined

  884. Yagiza

    ralphm, so, why XEP-0393 is not a best-practice of LML implementation in XMPP client software?

  885. ralphm

    Yeah, I can see the argument for it being informational instead.

  886. Guus

    back. No cavities! ๐Ÿ™‚

  887. ralphm

    Guus: good for you

  888. Maranda has left

  889. Maranda has joined

  890. ralphm

    ๐Ÿ˜

  891. Alex has left

  892. Andrew Nenakhov

    Btw a question on 385 Sims. If I share 5 images, what's fallback behavior? It doesn't look like I can put urls to 5 shared images in <body>

  893. ralphm

    Our client sent 5 images as 5 separate messages

  894. ralphm

    But it is a good question.

  895. Andrew Nenakhov

    > Our client sent 5 images as 5 separate messages We decided against such approach.

  896. Andrew Nenakhov

    Because when we send several items we want them to be presented as nice gallery of images

  897. ralphm

    It flowed naturally from our product team's requirements, so that was convenient.

  898. ralphm

    Right.

  899. Andrew Nenakhov

    And if they are separate there are weird effects when loading from message archive

  900. ralphm

    Well, if the gallery also has some kind of web presence, you might be able to link to that instead.

  901. Andrew Nenakhov

    Like we've loaded 5 most recent of 10 and gallery looks kinda broken

  902. ralphm

    otherwise, I see no real alternative to include links to all images

  903. Andrew Nenakhov

    See above.

  904. ralphm

    Maybe I misunderstood, but other than it not being appealing visually, why couldn't you include 5 links in the body?

  905. Andrew Nenakhov

    Currently we use data forms media element xep 0221 that allows us to pass metadata like size, video duration, etc, and duplicate links in body

  906. ralphm

    I'm not too familiar with XEP-0221, but I remember not being a fan when I voted on it in Council.

  907. Andrew Nenakhov

    > Maybe I misunderstood, but other than it not being appealing visually, why couldn't you include 5 links in the body? But with 0385 if I want to have just images with empty body?

  908. Andrew Nenakhov

    Naturally with client that supports 0385 I think I can send empty body and 5 items with images and get desired behavior

  909. ralphm

    Andrew Nenakhov: oh, right, that's a good point. In our case we didn't use begin/end and used the body as a fallback.

  910. Andrew Nenakhov

    But how to provide fallback?

  911. winfried has left

  912. ralphm

    So our body had the urls of the images.

  913. ralphm

    But you can do the same in case the client does understand SIMS, as the client could see that the body only has things being referenced and just ignore the body.

  914. ralphm

    But good point.

  915. Andrew Nenakhov

    I think that body should in all cases treated as fallback method. Obvious solution Is to add <formatted> to XEP

  916. ralphm

    By point is that if the body has 'https://example.org/1.jpg https://example.org/2.jpg', and SIMS that refers to them, it would see that it is basically image + space + image, and choose to ignore it.

  917. ralphm

    On the other hand, we were also going to do more rich formatting, with carrousels for images, etc. For that, maybe SIMS is less ideal as-is.

  918. ralphm

    And buttons

  919. ralphm

    Unfortunately we didn't get to define those fully, yet.

  920. winfried has joined

  921. ralphm

    At some point, fallbacks become hard, and you have to admit defeat. I.e. accept that some clients will have a degraded experience.

  922. waqas has joined

  923. ralphm

    In the case where a newer version of the client would support it, the fallback text could reference that fact instead.

  924. ralphm

    It all depends on the ecosystem, in our case we controlled both client and server deployment.

  925. Andrew Nenakhov

    We always treat body as fallback to dumbest possible client.

  926. Andrew Nenakhov

    So pasting all links is a must.

  927. Andrew Nenakhov

    But making advances client follow some vague rules to ignore body because it has specific type of format... No I dont think it'll work well

  928. Andrew Nenakhov

    I'll think of it.

  929. Andrew Nenakhov

    Do any clients support 0385? I'm not a fan of it, but if it has some spread, I might reconsider

  930. andy has left

  931. Andrew Nenakhov has left

  932. Andrew Nenakhov has joined

  933. UsL has left

  934. ralphm

    Not sure, outside of our app

  935. Andrew Nenakhov

    What is that app you are referring to?

  936. UsL has joined

  937. Dele Olajide has joined

  938. contrapunctus has left

  939. contrapunctus has joined

  940. Dele Olajide has left

  941. Dele Olajide has joined

  942. Maranda has left

  943. Maranda has joined

  944. alacer has left

  945. m has joined

  946. intosi has left

  947. intosi has joined

  948. alacer has joined

  949. valo has joined

  950. kokonoe has left

  951. kokonoe has joined

  952. alacer has left

  953. alacer has joined

  954. winfried has left

  955. winfried has joined

  956. Dele Olajide has left

  957. Dele Olajide has joined

  958. Dele Olajide has left

  959. Dele Olajide has joined

  960. ralphm

    The VEON app. You can no longer get it.

  961. lnj has left

  962. Andrew Nenakhov

    Oh ok.

  963. debacle has left

  964. oli

    "For many years Iโ€™ve interacted with my fellow humans, I think perhaps more than any other way, via the medium of Internet chat. But in my chat window, theyโ€™re fading, one by one. This problem is technical and personal and I felt it ought not to go unrecognized." https://www.tbray.org/ongoing/When/201x/2019/03/11/Lights-Going-Out

  965. j.r has left

  966. Dele Olajide has left

  967. Dele Olajide has joined

  968. ralphm

    oli: http://logs.xmpp.org/xsf/2019-03-12#2019-03-12-d63cfafd77ebcb99

  969. oli

    ralphm: thx

  970. ralphm

    Some more discussion this morning, so you want yo check the next day in the archive

  971. 404.city has left

  972. Dele Olajide has left

  973. Dele Olajide has joined

  974. ThibG has left

  975. ThibG has joined

  976. m has left

  977. rtq3 has joined

  978. contrapunctus has left

  979. contrapunctus has joined

  980. Dele Olajide has left

  981. Nekit has left

  982. lovetox has joined

  983. lnj has joined

  984. andy has joined

  985. rtq3 has left

  986. rtq3 has joined

  987. valo has left

  988. valo has joined

  989. yon has joined

  990. Steve Kille has left

  991. Steve Kille has joined

  992. ThibG has left

  993. ThibG has joined

  994. j.r has joined

  995. andy has left

  996. valo has left

  997. valo has joined

  998. zinid

    dwd, here?

  999. zinid

    dwd, how is it hard to reopen XMPP WG?

  1000. Nekit has joined

  1001. neshtaxmpp has joined

  1002. dwd has left

  1003. Yagiza has left

  1004. 404.city has joined

  1005. 404.city has left

  1006. kokonoe has left

  1007. kokonoe has joined

  1008. Maranda has left

  1009. Maranda has joined

  1010. lorddavidiii has joined

  1011. m has joined

  1012. wurstsalat has joined

  1013. m has left

  1014. oli has left

  1015. oli has joined

  1016. dwd has joined

  1017. Maranda has left

  1018. Maranda has joined

  1019. zinid has left

  1020. Zash has left

  1021. Zash has joined

  1022. yon has left

  1023. oli has left

  1024. yon has joined

  1025. kokonoe has left

  1026. nyco has left

  1027. kokonoe has joined

  1028. lorddavidiii has left

  1029. Nekit has left

  1030. nyco has joined

  1031. lnj has left

  1032. goffi has left

  1033. kokonoe has left

  1034. kokonoe has joined

  1035. yon has left

  1036. yon has joined

  1037. valo has left

  1038. nyco has left

  1039. nyco has joined

  1040. ThibG has left

  1041. ThibG has joined

  1042. m has joined

  1043. m has left

  1044. m has joined

  1045. arc has left

  1046. arc has joined

  1047. m has left

  1048. valo has joined

  1049. j.r has left

  1050. yon has left

  1051. debacle has joined

  1052. yon has joined

  1053. lumi has joined

  1054. arc has left

  1055. karoshi has left

  1056. arc has joined

  1057. lovetox has left

  1058. Andrew Nenakhov has left

  1059. Andrew Nenakhov has joined

  1060. debacle has left

  1061. arc has left

  1062. arc has joined

  1063. intosi has left

  1064. intosi has joined

  1065. intosi has left

  1066. intosi has joined

  1067. moparisthebest has left

  1068. moparisthebest has joined

  1069. waqas has left

  1070. rtq3 has left