XSF Discussion - 2017-09-28

  1. efrit has left

  2. tim@boese-ban.de has left

  3. tim@boese-ban.de has joined

  4. xnyhps has left

  5. Valerian has joined

  6. emxp has left

  7. jjrh has left

  8. jjrh has left

  9. la|r|ma has left

  10. la|r|ma has joined

  11. lskdjf has joined

  12. lskdjf has joined

  13. arc has joined

  14. la|r|ma has joined

  15. lskdjf has joined

  16. nyco has left

  17. Alex has joined

  18. Yagiza has joined

  19. tux has left

  20. tux has joined

  21. Valerian has left

  22. Alex has left

  23. Valerian has joined

  24. tim@boese-ban.de has joined

  25. tim@boese-ban.de has joined

  26. Valerian has left

  27. Valerian has joined

  28. Valerian has left

  29. Valerian has joined

  30. xnyhps has left

  31. Valerian has left

  32. tim@boese-ban.de has joined

  33. tim@boese-ban.de has joined

  34. xnyhps has left

  35. jonasw has left

  36. jonasw has joined

  37. dropcash77 has joined

  38. Zash has left

  39. dropcash77 has left

  40. dropcash77 has joined

  41. dropcash77 has left

  42. Tobias has joined

  43. Zash has joined

  44. Zash has left

  45. Zash has joined

  46. xnyhps has left

  47. Guus has left

  48. jere has joined

  49. Guus has left

  50. Guus has left

  51. Guus has left

  52. Guus has left

  53. ralphm has left

  54. arc has left

  55. SamWhited has left

  56. jonasw has joined

  57. jonasw has joined

  58. Guus has left

  59. daniel has left

  60. daniel has joined

  61. daniel has left

  62. daniel has joined

  63. daniel has left

  64. daniel has joined

  65. Guus has left

  66. tim@boese-ban.de has joined

  67. emxp has joined

  68. ralphm has left

  69. mimi89999 has joined

  70. daniel has left

  71. daniel has left

  72. Kev has left

  73. uc

    Right to be Forgotten!

  74. daniel has left

  75. xnyhps has left

  76. edhelas has left

  77. edhelas has joined

  78. Guus has left

  79. stefandxm has left

  80. stefandxm has joined

  81. Guus has left

  82. daniel has left

  83. daniel has left

  84. tim@boese-ban.de has joined

  85. daniel has left

  86. stefandxm has left

  87. ralphm has left

  88. daniel has left

  89. daniel has left

  90. daniel has left

  91. mimi89999 has joined

  92. tim@boese-ban.de has left

  93. mimi89999


  94. daniel has left

  95. zinid has left

  96. nyco has left

  97. tim@boese-ban.de has joined

  98. zinid has joined

  99. andrey.g has left

  100. uc has left

  101. tim@boese-ban.de has joined

  102. tim@boese-ban.de has joined

  103. intosi has joined

  104. tim@boese-ban.de has joined

  105. tim@boese-ban.de has joined

  106. zinid has left

  107. uc has left

  108. daniel has left

  109. emxp has left

  110. tim@boese-ban.de has joined

  111. tim@boese-ban.de has joined

  112. tux has left

  113. tim@boese-ban.de has left

  114. tim@boese-ban.de has joined

  115. stefandxm has joined

  116. emxp has joined

  117. jubalh has joined

  118. sonny has joined

  119. goffi has joined

  120. daniel has left

  121. la|r|ma has joined

  122. lskdjf has joined

  123. mathieui

    just asking, but there’s no way for a client to delete a message from a mam archive?

  124. Zash


  125. Zash

    Not in MAM

  126. Zash

    Separate specification may define that

  127. mathieui

    That’s what I was thinking as well

  128. Zash

    That Prosody fork, I forget the name, had something like that IIRC

  129. tim@boese-ban.de has joined

  130. mathieui

    I was checking if there was something like that in urn:mam:tmp which was removed later, but it doesn’t appear to be so

  131. tim@boese-ban.de has joined

  132. mathieui

    a coworker came to me because a client asked him to remove a message from the archive on an ejabberd server with mam:tmp

  133. mathieui

    so I had to check

  134. zinid

    the database schema in ejabberd doesn't depend on mam version, iirc

  135. Kev

    Yeah, we have to support that in M-Link, so things in the archive can be removed afterwards.

  136. Kev

    I imagine it'd be a fairly common enterprise etc. requirement.

  137. goffi has left

  138. Zash

    I'd imagine the opposite

  139. Ge0rG

    Maybe there is a separate archive that the data gets moved into?

  140. Zash

    Altho archiving and eg compliance logging doesn't have to be the same thing

  141. goffi has joined

  142. Kev

    (I note it's not the user who's able to do this, it's a sysadmin)

  143. Kev

    (And it leaves a tombstone)

  144. zinid

    any IM client (whatsapp, viber) has a function of deleting messages

  145. Zash

    Kev: Does it have custom protocol or some ad-hoc command?

  146. zinid

    you can even delete a message on remote end as well ;)

  147. Kev

    I forget how we do it, TBH. Adhoc, I expect.

  148. Zash

    You can send a message correction that changes it to an empty message or tombstone

  149. zinid


  150. Ge0rG

    I think yaxim will ignore a body-less LMC.

  151. fp-tester has left

  152. Ge0rG

    and body-less in that context also includes messages with an empty body

  153. zinid

    can I using LMC "erase" arbitrary message, or only the last one?

  154. fp-tester has joined

  155. Zash


  156. Ge0rG

    zinid: the XEP says you may only edit the last message, but I would consider it more practical to allow editing of the last N with N maybe around 20.

  157. Ge0rG

    Hm. The first time I proposed rolling back Carbons and Resource Locking was in 2015.

  158. zinid

    I think LMC is better (if it supports arbitrary deletion)

  159. zinid

    in this case you can design database easily (e.g. append only)

  160. Ge0rG

    zinid: send a mail to standards@ and propose a change.

  161. Ge0rG

    Kev: you suggested I write a thought-a-day series about the brokenness of current XMPP. If that was a serious proposal, what do you think would be the best venue to place that series?

  162. Kev

    It was semi-serious. I'm not 100% sure it's the best thing, but it seems like it might work. I was pondering a mail to standards@.

  163. Ge0rG

    Kev: I'm very interested in following through on that, in a form that's most acceptable to XSF members. I'm flexible regarding the form and the place to post, and personally I'd probably write a (very long) blog post instead.

  164. Kev

    I'm concerned that a very long blog post is likely to get TL;DRd.

  165. Kev

    (including by me)

  166. Ge0rG

    Because it allows to provide coherent arguments, has better markup and is not XSF-branded.

  167. Kev

    But give it a go :)

  168. Ge0rG

    Kev: what about a slide deck?

  169. Kev

    Oh, that has potential, including for if we do a high-bandwidth meeting to deal withit.

  170. Kev

    See what people-other-than-Kev think.

  171. Ge0rG

    people-other-then-Kev: I'd like to prepare a list of things that are currently broken in XMPP. What would be the best place for you to read it? standards@? my blog? XSF blog? a slide deck?

  172. jonasw

    I don’t care :)

  173. Ge0rG

    jonasw: as in "won't read it anyway" or as in "will red it either way"?

  174. jonasw

    the latter

  175. pep.

    Ge0rG, zinid, re LMC/deleting messages, that would only be true in a more-or-less controller context though, most client don't support LMC in semi-anon MUCs, and even when they do it would still be duplicated in the history

  176. zinid

    pep.: but you still "remove" it in your archive, which is the major goal

  177. Kev

    I'm keen it's not the XSF blog, FWIW.

  178. Ge0rG

    Kev: I just mentioned it for completeness sake. It was not really serious.

  179. pep.

    zinid, technically you don't remove it right? You just put a new message in front

  180. Guus

    Ge0rG: who's the intended audience?

  181. Ge0rG

    Guus: XSF members and people who implement MAM, Carbons, mobile clients etc.

  182. Ge0rG

    Guus: essentially everyone contributing to "modern" XMPP

  183. lumi has joined

  184. Guus

    then the mailinglist seems appropriate

  185. Zash

    The jdev@ list?

  186. Guus

    members -> members, impelmentors -> jdev

  187. Ge0rG

    Guus: see above, a coherent presentation will lack formatting and be tl;dr for most.

  188. Guus

    pick your audience :)

  189. Guus

    Ge0rG: the more reason to pick your audience carefully.

  190. zinid

    pep.: yes, but this is kinda normal, your "delete command" appears as "delete marker" in the database, so the original messages becomes a tombstone

  191. zinid

    pep.: such approach is used in some distributed databases for example

  192. zinid

    in blockchains also

  193. Ge0rG

    dwd: (moving over from jdev@) I'd like to make a talk, but can't guarantee to be present.

  194. Kev

    I think this is standards@, not jdev.

  195. dwd

    Kev, MUC, not list.

  196. dwd

    Ge0rG, If you're not present, the talk will be less effective indeed.

  197. pep.

    zinid, so it wouldn't just be a simple "empty message", it would be more than that and the db (and MAM?) would react to this as well?

  198. Ge0rG

    dwd: right. The problem I'm trying to solve now is that the challenge is very complex, and most people lack the time.

  199. Kev

    dwd: Guus suggested mailing to the jdev list. I don't think that's the right venue.

  200. Ge0rG

    dwd: Kev suggested to make a series of one-thought-a-day posts to standards@, but I'm not sure I can split up the problem appropriately.

  201. dwd

    Ge0rG, I don't know... I think if you chop up each issue, explain What it is, Why it matters, Who needs to do the next step, and What they need to do, you'd find which issues you can get traction on quite quickly.

  202. Kev


  203. dwd

    Ge0rG, If you can't chop it up into smaller issues, then I genuinely think it's a lost cause. It becomes "EVERYTHING IS BORKEN, FIX IT PLS".

  204. Guus

    Kev: I suggested that he'd pick an audience, and suggested that if that was primarily (client/server) developers, he'd pick jdev.

  205. zinid

    pep.: db will not react, this goes to client: when it sees the "delete marker", it remembers it and when it matches a message it ignores the message (and/or deletes in local history)

  206. Ge0rG

    Guus: I think that standards@ would be the most appropriate place.

  207. Guus

    then go for that :)

  208. Ge0rG

    at least if the form is "mail(s) to a ML"

  209. pep.

    zinid, that doesn't work in semi-MUC for most clients

  210. zinid

    pep.: I know

  211. zinid

    but current message correction doesn't work in my Tkabber for exmaple :)

  212. zinid


  213. Guus

    Ge0rG: if it's really, really long, but structured, perhaps do this on the wiki?

  214. Zash

    If you are going to have mutable history, then MAM might not be what you want

  215. zinid

    pep.: you see, if you want to synchronize deletion with all resources (which can be offline at the moment), how will you do that?

  216. pep.

    No idea :/

  217. Ge0rG

    Okay folks, thanks for the feedback. I'll try to structure my thoughts first, then see how I can split them up.

  218. pep.

    I tend not to worry about deletion because I think it's just not possible

  219. vanitasvitae has left

  220. zinid

    right, that's not an easy way, people inventing tombstones and dotted vectors and stuff like that

  221. jonasw

    deleting a message via LMC in MAM sounds like a terrible idea to me. this leads to inconsistent state between clients, because they might not re-sync old entries.

  222. zinid

    jonasw: disagree

  223. jonasw

    hm, you’ll have that anyways, no matter how you delete

  224. jonasw

    but something feels off about that approach.

  225. zinid

    if you keep a delete marker you can synchronize easily

  226. zinid

    damn, this is done in almost every key-value store

  227. zinid

    but this is harder for clients to implement...

  228. vanitasvitae has joined

  229. Zash

    Prosody MAM / archive code is mostly modeled to assume an append-only ordered list of messages

  230. zinid

    Zash: just like twitter btw :)

  231. zinid

    it's normal practice in high-load

  232. Zash

    Altho it's actually an ordered key-value thing, but the key-value-ness doesn't do very much

  233. zinid

    ejabberd uses SQL, so I don't care in fact, I'm just thinking that it would be great to have append-only for some usages

  234. jonasw

    LMC of messages before your last join are forbidden (via SHOULD) in the LMC XEP (0308)

  235. pep.

    jonasw, even if non-anonymous MUC?

  236. jonasw

    the XEP does not distinguish

  237. daniel has left

  238. daniel has joined

  239. Zash

    MUC doesn't tell you if historic messages are from the same senders as those currently present.

  240. Zash

    MUC-MAM might tho, I think

  241. andrey.g has joined

  242. andrey.g has left

  243. Ge0rG

    What's the current status of offline messages when a MAM-enabled client connects?

  244. andrey.g has joined

  245. andrey.g has left

  246. Ge0rG

    Will they be dumped to the client after initial presence, either way?

  247. andrey.g has joined

  248. Zash

    Add that to the list of things we should figure out how they should interact

  249. andrey.g has left

  250. zinid

    Ge0rG: you can disable them using flexible offline message retrieval

  251. Zash

    zinid: xep 13?

  252. zinid


  253. Zash

    You implement that?

  254. zinid


  255. andrey.g has joined

  256. andrey.g has left

  257. zinid

    we can probably recommend bare minimum implementation for servers

  258. Ge0rG

    zinid: are there any clients making use of it?

  259. andrey.g has joined

  260. andrey.g has left

  261. zinid

    Ge0rG: only ProcessOne customer's clients

  262. Ge0rG


  263. andrey.g has joined

  264. andrey.g has left

  265. zinid

    yes, we recommend doing this :D

  266. andrey.g has joined

  267. andrey.g has left

  268. zinid

    because there is no other standard way

  269. zinid

    but of course XSF can invent something :)

  270. Ge0rG

    The <purge/> command is prone to race conditions. Yay.

  271. andrey.g has joined

  272. andrey.g has left

  273. andrey.g has joined

  274. andrey.g has left

  275. andrey.g has joined

  276. Kev

    Ge0rG: And bind2 disables them.

  277. andrey.g has left

  278. andrey.g has joined

  279. andrey.g has left

  280. andrey.g has joined

  281. andrey.g has left

  282. andrey.g has joined

  283. andrey.g has left

  284. Ge0rG

    Kev: I hope we can make bind2 part of the solution to the problems I'm outlining.

  285. valo has left

  286. andrey.g has joined

  287. andrey.g has left

  288. andrey.g has joined

  289. andrey.g has left

  290. valo has joined

  291. andrey.g has joined

  292. andrey.g has left

  293. andrey.g has joined

  294. andrey.g has left

  295. andrey.g has joined

  296. andrey.g has left

  297. andrey.g has joined

  298. andrey.g has left

  299. andrey.g has joined

  300. andrey.g has left

  301. andrey.g has joined

  302. andrey.g has left

  303. andrey.g has joined

  304. andrey.g has left

  305. andrey.g has joined

  306. zinid

    Ge0rG: yes, races are possible, but not fatal, the server will not send you new messages anyway and you receive them via MAM later (so you don't lose them)

  307. andrey.g has left

  308. andrey.g has joined

  309. andrey.g has left

  310. Yagiza has left

  311. nyco has left

  312. lskdjf has left

  313. lskdjf has left

  314. Kev

    Ge0rG: Yes, or something like it (e.g. Dave's 'wrap bind2 up in sasl2' proposal).

  315. la|r|ma has joined

  316. zinid

    xmpp2.0 is a better choice than bind2, sasl2 and others :)

  317. andrey.g has joined

  318. andrey.g has left

  319. andrey.g has joined

  320. andrey.g has left

  321. andrey.g has joined

  322. andrey.g has left

  323. Zash

    Is xmpp2 a concrete thing yet?

  324. Zash

    Or is it just the concept of "lets re-do all the things from scratch"?

  325. andrey.g has joined

  326. andrey.g has left

  327. zinid

    not concrete of course ;)

  328. jonasw

    there’s https://wiki.xmpp.org/web/XMPP_2.0

  329. zinid

    Ge0rG is making it concrete :D

  330. sonny has joined

  331. Kev

    Zash: I think I'm explicitly trying *not* to redo everything from scratch.

  332. Guus

    Kev: that'd make for a good disclaimer on that page

  333. Guus

    on top

  334. Guus


  335. Guus

    in <blink>

  336. zinid


  337. zinid


  338. tim@boese-ban.de has joined

  339. Zash

    Is there anything on that page that's actually breaking compat enough to warrant a 2.0?

  340. Zash

    I mean, I imagine things like getting rid of 'jabber:client' and 'jabber:server' etc, and having a single unified namespace.

  341. Ge0rG

    Kev: I'm trying to redo from scratch the minimum amount of things so we can fix up our shit already.

  342. Ge0rG

    Zash: maybe it's only XMPP-IM 2.0

  343. Ge0rG

    my goal is not to break everything but to fix everything :P

  344. daniel has left

  345. daniel has joined

  346. nyco has left

  347. zinid

    bind and sasl are defined in rfc6120, so this cannot be solved inside xmpp-im solely (unless we accept bind2 and sasl2)

  348. goffi has left

  349. Ge0rG

    zinid: bind2 can be a new XEP, without breaking anything actually.

  350. Ge0rG

    Redoing the message routing is much more tricky.

  351. jonasw

    Zash, I chose the name for that wiki page, and initially it wasn’t clear to me if we might have to override some ruling from the RFCs, basically warranting a 2.0

  352. Zash

    If you do things in the context of a negotiable stream feature, then I'm not sure I think that should be called XMPP 2.0

  353. jonasw

    Zash, that’s just a name anyways

  354. jonasw

    let’s call it a working title :)

  355. Ge0rG

    The name is the most important thing about a project!

  356. Ge0rG

    What about Session 2.0?

  357. Zash

    Ge0rG: I think you mean the logo, closely followed by the fancy website on a cool domain

  358. Guus

    The color is.

  359. Zash

    There's that old <session/> stream feature that's basically a noop everywhere I know

  360. zinid

    Ge0rG: there are other problems beyond message routing

  361. zinid

    Ge0rG: rosters, presences, all this shit is not modern anymore

  362. Zash


  363. jonasw

    Ge0rG, Session 2.0 may indeed be a reasonable name

  364. zinid

    Zash: popular IMs don't even have presences, there is no point in them when everybody is online almost always

  365. andrey.g has joined

  366. vanitasvitae has joined

  367. Zash

    I don't think any of that should be removed, but I'd like message routing to be detached from presence.

  368. jere has joined

  369. Zash

    Just because "popular IMs" don't show something front and center anymore doesn't mean it doesn't have its uses

  370. Ge0rG

    zinid: there is even a business use case for presence: synchronized DND

  371. zinid

    I didn't say it's useless, I said "not modern", meaning not used in popular IMs

  372. Kev

    I think lots of them have presence.

  373. Kev

    Slack, Discord, Whatsapp, Facebook all have presence.

  374. lumi has joined

  375. Zash

    And I'm not going to listen to arguments that boil down to "because popularity", if I cared about that I wouldn't be here.

  376. Ge0rG

    There is real value in presence, and that's actually something that works pretty well on mobile, outside of initial presence flood from your roster when you connect.

  377. edhelas

    you have two kind of presences usages in the clients, manual (set by the user) or automatic (set by the client itself)

  378. zinid

    yeah, but it seems like they transmit only "chat" status

  379. daniel

    zinid: do you happen to know who - if any - from the beam project is going to the mentor summit?

  380. zinid

    i.e. when I open an app, I become available, when I close the app I become unavailable

  381. zinid

    daniel: /me and Holger

  382. Holger

    zinid: I'm not going to the summit :-)

  383. zinid

    this is regarding ejabberd projects, I cannot say about other BEAM projects

  384. Tobias has left

  385. zinid


  386. zinid


  387. Holger

    I think Mickaël asked on the list and got no response.

  388. zinid

    I read it wrong way

  389. Holger

    So maybe nobody's going.

  390. tim@boese-ban.de has joined

  391. daniel

    zinid: but you are coming, right?

  392. sonny has joined

  393. zinid

    no, sorry for confusion

  394. zinid

    I cannot leave russia, lol

  395. daniel

    That's too bad. Otherwise we would have had 3 xmpp related projects at the summit

  396. zinid

    maybe Mickael can go?

  397. zinid

    or Jerome? Chris?

  398. zinid

    but they are not mentors...

  399. Holger

    Trying to find his email.

  400. daniel

    If you haven't decided yet (and registered) then it's probably too late

  401. edhelas

    are we talking about the FOSDEM summit here ?

  402. daniel

    But they don't have to be mentors

  403. daniel

    edhelas: gsoc

  404. Holger

    zinid: Ah got it. No response indeed.

  405. edhelas

    oh ok

  406. zinid

    Holger: I don't even remember his mail

  407. daniel

    Have you never sent people to the summit?

  408. daniel

    It's a free trip to the US

  409. Holger

    zinid: It was on one of the 1,000 GSoC-related lists, maybe he forgot to add you to that one :-)

  410. Alex has joined

  411. daniel

    And each time you can roll the gitmo dice

  412. zinid

    no idea, I'm really not into this summit stuff, Mickael is usually managing this

  413. Holger

    daniel: Last year someone from some other BEAM project went.

  414. Holger

    zinid: gsoc-mentors@process-one.net on Tue, 19 Sep 2017 09:25:38 +0200.

  415. zinid

    Holger: I'm not subscribed ;)

  416. Holger


  417. zinid

    yeah, I'm a terrible mentor, I said that :)

  418. test has joined

  419. test has left

  420. winfried has joined

  421. zinid

    I have a note: XMPP 2.0 Session Initiation The client and server must coordinate the required information for a sync as soon as possible: Authenticate Client sends a bind2 request containing: stream resumption id (optional, to faciliate Stream Resumption) last-known MAM message-id (optional, to achieve full synchronization) MAM request with a time-delta (optional, alternative to message-id if only the history of the last N time units is needed) initial presence (maybe?) MUCs to join (maybe?) The server automagically figures out whether to do a stream resumption or a MAM sync and provides according data to the client, generates presence broadcast accordingly

  422. zinid

    I think we're reinventing Matrix approach here in fact

  423. test has joined

  424. zinid

    not that it's bad

  425. goffi has joined

  426. goffi has left

  427. goffi has joined

  428. zinid

    but what I see here is actually database synchronization between a server and a client

  429. Ge0rG

    zinid: I think it's good to treat session setup as a way to tell the client everything that changed since the last connect.

  430. test has left

  431. Ge0rG

    zinid: exactly, xmpp based database synchronization.

  432. edhelas has left

  433. zinid

    Ge0rG: yes, but it looks overcomplicated, in normal situation you just need to send a point from where to download

  434. edhelas has joined

  435. edhelas has left

  436. edhelas has joined

  437. zinid

    and I also think MUCs and one-to-one chats should not be treated differently

  438. zinid

    like in matrix, hehe

  439. sonny has joined

  440. zinid

    not sure why we need stream resumption, the messages are in MAM already

  441. zinid

    seems redundant as well

  442. edhelas

    zinid, don't forget the Pubsub/PEP synchronisation as well

  443. edhelas

    that's wht we were looking into https://xmpp.org/extensions/xep-0312.html

  444. Ge0rG

    zinid: because session setup is much more expensive than resumption, and you will lose outgoing messages without the latter

  445. edhelas

    when I'm loggin in I'm spammed by hundreds of PEP/pubsub notifications for things that I already had before

  446. sonny has joined

  447. zinid

    edhelas: well my idea is to have a "routing block", it can be a room or one-to-one chat or a pubsub-eventer where you can subscribe and unsubscribe, that's it

  448. Guus has left

  449. zinid

    edhelas: you're spammed because the desing is shit :P

  450. edhelas

    the design, or the implementation :p ?

  451. Ge0rG

    zinid: I'm not a fan of MUC MAM, but I try not to reinvent everything.

  452. Ge0rG

    Maybe it's a good idea in the grand scheme to have all MUCs synchronized to all devices by default.

  453. Alex

    Announcement : Board & Council elections 2017 https://wiki.xmpp.org/web/Board_and_Council_Elections_2017

  454. jonasw

    Alex, nice work :)

  455. la|r|ma has left

  456. la|r|ma has joined

  457. goffi

    Alex: s/2014/2017/

  458. Alex

    fixed :-)

  459. goffi


  460. Alex

    now you can add your names :-)

  461. SouL


  462. Alex

    or recruit the people who you think will do a great job in those roles

  463. tim@boese-ban.de has joined

  464. Guus

    Can we simply add those? 😈

  465. Ge0rG

    Alex: yay!

  466. Ge0rG

    It would be interesting to see "nominations"

  467. daniel has left

  468. daniel has joined

  469. Guus

    Likely: Boardy McBoardface and possibly all guys from Matrix.

  470. daniel has left

  471. daniel has joined

  472. Guus has left

  473. vanitasvitae has left

  474. jubalh has joined

  475. jjrh has left

  476. Guus has left

  477. jonasw

    looking forward to see who runs for board and council.

  478. Ge0rG

    I'd elect Boardy McBoardface. For Council.

  479. dwd

    A vote for Boardy McBoardface is actually a vote for David Attenborough, though.

  480. jonasw

    how that?

  481. vanitasvitae has left

  482. Ge0rG

    Maybe because of https://www.change.org/p/jo-johnson-sir-david-attenborough-to-change-his-name-to-boaty-mcboatface

  483. uc has joined

  484. Zash

    David McDavidface?

  485. Ge0rG

    Darth Zash.

  486. Guus has left

  487. jere has left

  488. jere has joined

  489. vanitasvitae has left

  490. vanitasvitae has left

  491. Guus has left

  492. Guus has left

  493. winfried has joined

  494. lumi has joined

  495. jjrh has left

  496. vanitasvitae has joined

  497. ralphm has left

  498. jjrh has left

  499. daniel has left

  500. ralphm has left

  501. Guus has left

  502. uc has joined

  503. daniel has left

  504. jjrh has left

  505. daniel has left

  506. jjrh has left

  507. uc has joined

  508. edhelas has left

  509. edhelas has joined

  510. uc has joined

  511. emxp has left

  512. emxp has joined

  513. goffi has left

  514. jubalh has joined

  515. Yagiza has joined

  516. jabberatdemo has joined

  517. uc has joined

  518. waqas has joined

  519. Valerian has joined

  520. daniel has left

  521. daniel has left

  522. tim@boese-ban.de has left

  523. jabberatdemo has left

  524. intosi has left

  525. ralphm has left

  526. Guus has left

  527. jere has joined

  528. jere has joined

  529. uc has joined

  530. intosi has joined

  531. andrey.g has left

  532. uc has joined

  533. jubalh has joined

  534. jubalh has joined

  535. lovetox has joined

  536. uc has joined

  537. andrey.g has joined

  538. andrey.g has left

  539. jcbrand has joined

  540. andrey.g has joined

  541. andrey.g has left

  542. andrey.g has joined

  543. andrey.g has left

  544. andrey.g has joined

  545. andrey.g has left

  546. jcbrand has left

  547. andrey.g has joined

  548. andrey.g has left

  549. winfried has joined

  550. uc has joined

  551. ralphm has left

  552. uc has joined

  553. tux has joined

  554. andrey.g has joined

  555. andrey.g has left

  556. jubalh has joined

  557. andrey.g has joined

  558. andrey.g has left

  559. andrey.g has joined

  560. andrey.g has left

  561. tux has joined

  562. andrey.g has joined

  563. andrey.g has left

  564. andrey.g has joined

  565. andrey.g has left

  566. uc has joined

  567. andrey.g has joined

  568. andrey.g has left

  569. andrey.g has joined

  570. andrey.g has left

  571. andrey.g has joined

  572. andrey.g has left

  573. andrey.g has joined

  574. andrey.g has left

  575. andrey.g has joined

  576. andrey.g has left

  577. andrey.g has joined

  578. andrey.g has left

  579. andrey.g has joined

  580. andrey.g has left

  581. andrey.g has joined

  582. andrey.g has left

  583. andrey.g has joined

  584. andrey.g has left

  585. andrey.g has joined

  586. andrey.g has left

  587. andrey.g has joined

  588. andrey.g has left

  589. andrey.g has joined

  590. andrey.g has left

  591. winfried has joined

  592. andrey.g has joined

  593. andrey.g has left

  594. andrey.g has joined

  595. andrey.g has left

  596. uc has joined

  597. intosi has left

  598. uc has joined

  599. peter has joined

  600. andrey.g has joined

  601. andrey.g has left

  602. andrey.g has joined

  603. andrey.g has left

  604. andrey.g has joined

  605. andrey.g has left

  606. andrey.g has joined

  607. andrey.g has left

  608. uc has joined

  609. zinid has left

  610. winfried has joined

  611. winfried has joined

  612. ralphm has joined

  613. uc has joined

  614. Wiktor has joined

  615. valo has left

  616. Guus has left

  617. winfried has left

  618. valo has joined

  619. waqas has left

  620. waqas has joined

  621. winfried has joined

  622. ralphm has left

  623. stefandxm has left

  624. stefandxm has joined

  625. Guus has left

  626. waqas has left

  627. la|r|ma has joined

  628. Valerian has left

  629. Valerian has joined

  630. winfried has left

  631. jjrh has left

  632. mhterres has joined

  633. Ge0rG

    dwd, Kev: so I'm trying out a new presentation form: https://op-co.de/tmp/whats-wrong-with-xmpp-2017.pdf

  634. mhterres has left

  635. jjrh has left

  636. edhelas

    when is this conference planned ?

  637. Ge0rG

    edhelas: this is the slide deck for a fictive conference.

  638. emxp has left

  639. emxp has joined

  640. andrey.g has joined

  641. andrey.g has left

  642. andrey.g has joined

  643. andrey.g has left

  644. andrey.g has joined

  645. andrey.g has left

  646. andrey.g has joined

  647. zinid

    Ge0rG: nice list ;)

  648. andrey.g has left

  649. andrey.g has joined

  650. andrey.g has left

  651. jjrh has left

  652. sonny has joined

  653. Ge0rG

    zinid: I knew you'd like it.

  654. mathieui

    Ge0rG, "MAM + MUC = madness" why?

  655. Valerian has left

  656. Ge0rG

    mathieui: because you have to query individual MUCs for their archives, there are different incompatible versions etc.

  657. sonny has joined

  658. stefandxm has left

  659. zinid

    Ge0rG: but isn't this a good idea? to query only what you need, e.g. when you login you receive a list of mucs with unread messages number, you don't need to query them all, only when a user opens the chat window/tab

  660. mathieui

    which reminds me I have to patch mod_mam_muc at some point too

  661. Zash


  662. mathieui

    Zash, muc archives are forever

  663. mathieui

    which is bad

  664. mathieui

    and also open to anyone, even someone not in the room

  665. mathieui

    so you can scrape remotely any public MUC for its whole lifetime

  666. Ge0rG

    zinid: maybe. Depends on whether you want a full-sync client or on-demand sync

  667. Zash

    mathieui: Pretty sure it respects members-onlyness

  668. mathieui

    Zash, yes, it does

  669. tim@boese-ban.de has joined

  670. Ge0rG has joined

  671. mathieui

    for members-only rooms, for which it indeed works like that

  672. Zash

    mathieui: I've considered making it optionally restrict access to eg members only, even in public rooms.

  673. mathieui

    the best way would be a muc configuration toggle

  674. peter has left

  675. jjrh has left

  676. peter has joined

  677. Guus has left

  678. Ge0rG

    See, madness!

  679. daniel has left

  680. Valerian has joined

  681. jjrh has left

  682. jjrh has left

  683. peter has left

  684. jjrh has left

  685. Guus has left

  686. daniel has left

  687. daniel has left

  688. daniel has joined

  689. winfried has joined

  690. lumi has left

  691. uc has joined

  692. jubalh has joined

  693. uc has joined

  694. Guus has left

  695. Tobias has left

  696. Yagiza has left

  697. tim@boese-ban.de has joined

  698. Ge0rG has joined

  699. Ge0rG

    That ejabberd MSN bug is really bugging me.

  700. Ge0rG

    Oh, it's different now.

  701. jjrh has left

  702. la|r|ma has left

  703. la|r|ma has joined

  704. la|r|ma has joined

  705. stefandxm has joined

  706. Guus has left

  707. lskdjf has joined

  708. lskdjf has joined

  709. jere has joined

  710. daniel has left

  711. daniel has joined

  712. Guus has left

  713. ralphm has left

  714. Valerian has left

  715. Valerian has joined

  716. mimi89999 has joined

  717. Guus has left

  718. mimi89999 has left

  719. stefandxm has left

  720. Guus has left

  721. Guus has left

  722. jonasw

    I see what you did there.

  723. Ge0rG

    I didn't do anything!

  724. andrey.g has joined

  725. andrey.g has left

  726. Guus has left

  727. andrey.g has joined

  728. andrey.g has left

  729. andrey.g has joined

  730. andrey.g has left

  731. andrey.g has joined

  732. andrey.g has left

  733. andrey.g has joined

  734. andrey.g has left

  735. andrey.g has joined

  736. andrey.g has left

  737. Valerian has left

  738. Guus has left

  739. moparisthebest has joined

  740. tux has joined

  741. Valerian has joined

  742. tux has joined

  743. uc has joined

  744. jjrh has left

  745. uc has joined

  746. jubalh has joined

  747. ralphm has left

  748. lumi has joined

  749. uc has joined

  750. vanitasvitae has left

  751. jubalh has left

  752. Valerian has left

  753. tux has joined

  754. Valerian has joined

  755. uc has joined

  756. Valerian has left

  757. Valerian has joined

  758. jjrh has left

  759. goffi has joined

  760. la|r|ma has left

  761. la|r|ma has joined

  762. tim@boese-ban.de has left

  763. uc has joined

  764. mimi89999 has left

  765. tux has joined

  766. stefandxm has joined

  767. andrey.g has joined

  768. andrey.g has left

  769. andrey.g has joined

  770. andrey.g has left

  771. andrey.g has joined

  772. andrey.g has left

  773. andrey.g has joined

  774. andrey.g has left

  775. jonasw

    can we re-trigger a website build to update https://xmpp.org/extensions/ ?

  776. jonasw

    (two new XEPs)

  777. andrey.g has joined

  778. andrey.g has left

  779. Valerian has left

  780. fp-tester has joined

  781. andrey.g has joined

  782. andrey.g has left

  783. Guus

    Kev, can you give me that privilege in hub.docker.com please?

  784. andrey.g has joined

  785. andrey.g has left

  786. SamWhited

    jonasw: Do you mean on Docker Hub or on EOS? It will happen automatically after a while I think; pretty sure Kev put it on a cron job.

  787. SamWhited

    I can trigger a rebuild on Docker Hub if that's all you need (I think?)

  788. Guus

    I put it in a cronjob

  789. Guus

    Sam, yes please

  790. Guus

    the cronjob will only check for a new docker image

  791. SamWhited

    oh, sorry, I lied, I don't have my credentials on this machine, sorry

  792. tim@boese-ban.de has joined

  793. andrey.g has joined

  794. andrey.g has left

  795. andrey.g has joined

  796. stefandxm has left

  797. andrey.g has left

  798. andrey.g has joined

  799. andrey.g has joined

  800. andrey.g has left

  801. andrey.g has joined

  802. Guus

    jonasw: find a typo, submit a PR, I'll merge :D

  803. ralphm has joined

  804. zinid has left

  805. andrey.g has joined

  806. andrey.g has left

  807. Wiktor has joined

  808. jcbrand has joined

  809. jcbrand has left

  810. stefandxm has joined

  811. vanitasvitae has left

  812. jere has joined

  813. moparisthebest

    Guus, add or remove a space? :P

  814. Zash has left

  815. Valerian has joined

  816. dropcash77 has joined

  817. emxp has joined

  818. emxp has joined

  819. daniel has left

  820. mimi89999 has left

  821. dropcash77 has left

  822. dropcash77 has joined

  823. dropcash77 has left

  824. jubalh has joined

  825. moparisthebest has joined

  826. jubalh has left

  827. stefandxm has left

  828. daniel has left

  829. goffi has left

  830. jere has joined

  831. jere has left

  832. jere has joined

  833. stefandxm has joined

  834. ralphm has joined

  835. waqas has joined

  836. jubalh has joined

  837. jere has joined

  838. jere has joined

  839. stefandxm has left

  840. moparisthebest has joined

  841. Alex has left

  842. ralphm has left

  843. jubalh has joined

  844. Alex has joined

  845. moparisthebest has joined

  846. jere has left

  847. jere has joined

  848. stefandxm has joined

  849. lovetox has left

  850. Guus has left

  851. peter has joined

  852. ralphm has joined

  853. daniel has left

  854. daniel has left

  855. Valerian has left

  856. lumi has left

  857. lumi has joined

  858. Valerian has joined

  859. tim@boese-ban.de has joined

  860. daniel has left

  861. daniel has left

  862. Ge0rG has left

  863. fp-tester has joined

  864. valo has left

  865. la|r|ma has left

  866. la|r|ma has joined

  867. stefandxm has left

  868. Alex has left

  869. fp-tester has left

  870. fp-tester has joined

  871. Guus has left

  872. Valerian has left

  873. Alex has joined

  874. Alex has left

  875. peter has left

  876. Guus has left

  877. sonny has left

  878. sonny has joined

  879. SamWhited has left

  880. emxp has left

  881. Guus has left

  882. jjrh has left

  883. Valerian has joined

  884. jjrh has left

  885. Guus has left

  886. Alex has joined