XSF Discussion - 2020-10-06

  1. alameyo has left
  2. alameyo has joined
  3. mukt2 has left
  4. Andrzej has left
  5. Tobias has left
  6. mukt2 has joined
  7. krauq has left
  8. krauq has joined
  9. dwd has left
  10. alameyo has left
  11. alameyo has joined
  12. neshtaxmpp has left
  13. Lance has left
  14. andrey.g has left
  15. Andrzej has joined
  16. Lance has joined
  17. papatutuwawa has left
  18. papatutuwawa has joined
  19. j.r has left
  20. neshtaxmpp has joined
  21. Andrzej has left
  22. krauq has left
  23. krauq has joined
  24. alameyo has left
  25. alameyo has joined
  26. Lance has left
  27. adityaborikar has joined
  28. slouchy6 has joined
  29. peetah has left
  30. Lance has joined
  31. Yagiza has joined
  32. Andrzej has joined
  33. Lance has left
  34. mukt2 has left
  35. Andrzej has left
  36. Lance has joined
  37. Seve has joined
  38. Lance has left
  39. Shell has left
  40. DebXWoody has joined
  41. Lance has joined
  42. dwd has joined
  43. DebXWoody has left
  44. jcbrand has joined
  45. DebXWoody has joined
  46. Lance has left
  47. waqas has left
  48. DebXWoody has left
  49. Andrzej has joined
  50. Seve has left
  51. karoshi has joined
  52. werdan has joined
  53. LNJ has joined
  54. werdan has left
  55. Seve has joined
  56. emus has joined
  57. Tobias has joined
  58. sonny has left
  59. Andrzej has left
  60. sonny has joined
  61. sonny has left
  62. eevvoor has joined
  63. peetah has joined
  64. sonny has joined
  65. Andrzej has joined
  66. sonny has left
  67. floretta has left
  68. DebXWoody has joined
  69. Lance has joined
  70. Andrzej has left
  71. sonny has joined
  72. sonny has left
  73. sonny has joined
  74. Andrzej has joined
  75. Mikaela has joined
  76. sonny has left
  77. Lance has left
  78. sonny has joined
  79. sonny has left
  80. sonny has joined
  81. Lance has joined
  82. sonny has left
  83. sonny has joined
  84. LNJ has left
  85. LNJ has joined
  86. Lance has left
  87. sonny has left
  88. andrey.g has joined
  89. antranigv has joined
  90. antranigv has left
  91. antranigv has joined
  92. alameyo has left
  93. alameyo has joined
  94. disgyze has left
  95. LNJ has left
  96. LNJ has joined
  97. j.r has joined
  98. debacle has joined
  99. mdosch has left
  100. mdosch is watching 🏒 has left
  101. mdosch is watching 🏒 has joined
  102. mdosch has joined
  103. sonny has joined
  104. Andrzej has left
  105. andrey.g has left
  106. adityaborikar has left
  107. adityaborikar has joined
  108. Lance has joined
  109. Andrzej has joined
  110. sonny has left
  111. debacle has left
  112. Lance has left
  113. j.r has left
  114. j.r has joined
  115. Andrzej has left
  116. lskdjf has joined
  117. floretta has joined
  118. antranigv has left
  119. Andrzej has joined
  120. matkor has left
  121. matkor has joined
  122. deuill has joined
  123. Steve Kille has left
  124. deuill has left
  125. Steve Kille has joined
  126. pep. Can participants fetch MUC-registered nicknames of other participants?
  127. Daniel Will those appear in the member list?
  128. Daniel Admin/owner list
  129. Daniel That's probably way underspecified. But it would make sense
  130. Daniel Since prosody is the only implementation that even has registration ask MattJ?
  131. Ge0rG MattJ proposed to send all registered participants that are not an occupant with unavailable presence.
  132. pep. (one more place to fetch nicks yay)
  133. Ge0rG IMHO, sending a bunch of unavailable presence with a join shouldn't break anything
  134. Daniel Shouldn't...
  135. Daniel But yes that probably makes sense
  136. MattJ pep., "one more place" -> the idea was to consolidate them all into this one place (presence), so the client only has one mechanism to track occupants
  137. MattJ In my head I have a draft thing for MUC join flags to opt into things like this
  138. MattJ and also to filter messages, e.g. bots that only want to receive certain things or from certain occupants (and enforcing this server-side if necessary, so it becomes safe to add bots to a room without them logging your conversations)
  139. Daniel Uh. Like muc/sub
  140. Andrzej has left
  141. Ge0rG MattJ: also a flag to not send occupant presence and a roser-versioning-alike thing for the participants?
  142. floretta has left
  143. krauq has left
  144. neshtaxmpp has left
  145. debacle has joined
  146. krauq has joined
  147. neshtaxmpp has joined
  148. eevvoor has left
  149. pep. MattJ: there are other places where a client can fetch nicks / display name that a MUC doesn't have access to
  150. pep. right?
  151. MattJ pep., oh, sure
  152. MattJ Daniel, quite possibly, but I'd actually put this through as a XEP and hope to keep the changes simple enough that it gets adoped (if other server devs even care about improving MUC anymore, it's possible that they don't)
  153. MattJ Daniel, quite possibly, but I'd actually put this through as a XEP and hope to keep the changes simple enough that it gets adopted (if other server devs even care about improving MUC anymore, it's possible that they don't)
  154. Ge0rG I still think that improving MUC is worthwhile. MIX has become a significant engineering effort.
  155. Daniel Implementing it on the client side is probably easy
  156. Daniel but for me the biggest issue with MUC is reconnection/reliability
  157. Daniel before we can solve that it feels a little pointless to waste time and energy on other improvements
  158. Daniel but I understand that different people have different priorities
  159. Daniel and/or that work on one improvement doesn't block improvements on other fronts
  160. Ge0rG Daniel: did you make any progress on the per-MUC push registration?
  161. Daniel i even removed the code again
  162. Daniel because it was causing some weird edge case bugs
  163. Daniel where the server was maybe at fault
  164. Daniel and nobody had implemented it
  165. Ge0rG "weird edge case bugs" is the long form of "MUC"
  166. Daniel well i think it wasn’t even muc related. but a server announced push and muc on the primary domain and then it registered itself 100 times or something
  167. pep. What happened of 410 on s2s?
  168. Daniel I don’t recall the details. but i didn’t feel like fixing it or finding work arounds for it when it was dead code anyway
  169. pep. MattJ, any hint about my first questio nbtw
  170. pep. MattJ, any hint about my first question btw
  171. Daniel not on s2s but having your server do it?
  172. Daniel because 410 on s2s would just be regular ping, no?
  173. pep. yeah, servers doing "410"
  174. pep. Whatever it takes to keep the link on. Which is also gonna be a problem for MIX anyway
  175. Daniel didn’t eta want to come up with a thing
  176. pep. dunno
  177. Ge0rG MIX has the additional problem that there is no plan for recovering from s2s outages.
  178. pep. yeah
  179. Ge0rG MUC is self-healing, more or less, once you rejoin
  180. Daniel i've heard matrix has something for that
  181. Ge0rG MIX... good luck.
  182. Daniel well your joins/leaves are IQ based so you know if that was succesful
  183. Ge0rG We also have the same problem with MAM.
  184. Daniel and then you might just lose messages
  185. Ge0rG Because apparently, combining "give me everything I missed" and "enable live delivery" is a HARD problem
  186. MattJ pep., from example 131 in XEP-0045 it looks like the affiliation list includes the nick, so yeah
  187. pep. Ah, thanks. I missed it indeed
  188. Daniel MattJ, does prosody already include that?
  189. MattJ Yes
  190. sonny has joined
  191. MattJ Just found the test: https://hg.prosody.im/trunk/file/tip/spec/scansion/muc_register.scs#l397
  192. sonny has left
  193. sonny has joined
  194. eevvoor has joined
  195. sonny has left
  196. mukt2 has joined
  197. DebXWoody has left
  198. eevvoor has left
  199. eevvoor has joined
  200. Andrzej has joined
  201. mukt2 has left
  202. Andrzej has left
  203. Andrzej has joined
  204. sonny has joined
  205. sonny has left
  206. eevvoor has left
  207. floretta has joined
  208. sonny has joined
  209. antranigv has joined
  210. Lance has joined
  211. Andrzej has left
  212. eta Daniel: yeah I have half a protoxep about automatically reconnecting to MUCs that I never finished
  213. antranigv has left
  214. antranigv has joined
  215. Lance has left
  216. antranigv has left
  217. Shell has joined
  218. Tobias has left
  219. Tobias has joined
  220. antranigv has joined
  221. antranigv has left
  222. antranigv has joined
  223. pasis has joined
  224. adityaborikar has left
  225. adityaborikar has joined
  226. Lance has joined
  227. pasis Hi, I've refreshed library in libraries.json, but xmpp.org hasn't been synced. Could someone update xmpp.org? The library is libstrophe.
  228. DebXWoody has joined
  229. adityaborikar has left
  230. adityaborikar has joined
  231. Seve pasis: It was merged though, right? I think I did
  232. pasis yes, it's merged, just doesn't appear at xmpp.org
  233. pep. Yeah docker things probably need a push
  234. jonas’ they need a pull :-X
  235. pep. :P
  236. jonas’ joking aside, will do
  237. jonas’ updated
  238. Lance has left
  239. vanitasvitae btw. there are some stale PRs on xsf/xeps that are ready for processing by the editors, namely https://github.com/xsf/xeps/pull/923 and https://github.com/xsf/xeps/pull/932
  240. vanitasvitae pokes editors with a stick
  241. jonas’ vanitasvitae, ah, I missed your approval on those, as I was on vacation during that time
  242. jonas’ will tag them so that I process them later tonight
  243. jonas’ thanks for the ping
  244. vanitasvitae nice 🙂
  245. vanitasvitae thanks for being an editor ❤️
  246. alameyo has left
  247. alameyo has joined
  248. antranigv has left
  249. Andrzej has joined
  250. eevvoor has joined
  251. pep. and I didn't really help :x
  252. floretta has left
  253. pasis it works now, thanks :)
  254. adityaborikar has left
  255. adityaborikar has joined
  256. neshtaxmpp has left
  257. antranigv has joined
  258. antranigv has left
  259. adityaborikar has left
  260. adityaborikar has joined
  261. arc has joined
  262. arc has left
  263. arc has joined
  264. arc has left
  265. arc has joined
  266. adityaborikar has left
  267. adityaborikar has joined
  268. dwd (Reading up) eta, I keep meaning to explore your ideas around group chats in more detail. I think I've read half your series on your blog, but keep meaning to read the rest.
  269. eta dwd, I mean it does peter out near the end; the only useful thing in that series is the whole "sponsoring server" model
  270. eta (which you could implement with XEP-0045 today and a custom MUC component, and I indeed might one day)
  271. dwd eta, Ah, yes - you had a hybrid model between XMPP's single authority and IRC's model of every server has to be trusted?
  272. eta dwd, exactly -- you have a quorum of trusted servers that use some consensus algorithm (Raft / Paxos)
  273. eta which is less crazy than Matrix's "fully decentralized" model (which I don't see being viable
  274. eta which is less crazy than Matrix's "fully decentralized" model (which I don't see being viable)
  275. pep. (blog link?)
  276. dwd eta, There's some work around on partially trusted consensus algorithms, too. Kind of like BFT algorithms but each server might have different legitimate aims.
  277. eta pep., https://theta.eu.org/2019/10/10/nea-federation-design.html
  278. pep. thanks
  279. dwd eta, You definitely don't want Paxos, though. And even Raft has some problems if we assume byzantine fault tolerance and dynamic group membership is desirable, I think.
  280. krauq has left
  281. krauq has joined
  282. eta dwd, very potentially! I never really went anywhere with this; it was just an idea
  283. eta what could be interesting is just to piggyback of something like etcd, which already handles the distributed state
  284. dwd eta, Well, you could start with a simple Raft implementation, for exploratory purposes.
  285. eta nods
  286. Shell etcd is just a Raft implementation on top of a k/v store, isn't it?
  287. dwd eta, And I think you don't need to worry too much about formal consensus for most things, you can do elections and a tree-based fanout for messaging, for example.
  288. eta Shell, yeah
  289. eta dwd, yeah, I mean you only need consensus for things like the room member list
  290. Kev Am I misremembering Raft, or isn't it a leadership-election thing? So fails if you need to continue functioning in a split situation?
  291. dwd eta, ... maybe? I'm not sure that needs consensus until the point where a member is more than a mere passive observer.
  292. antranigv has joined
  293. eta dwd, no, sure
  294. eta I meant more bans/voiced users/etc
  295. antranigv has left
  296. dwd Kev, It might have leadership, but it survives partition. It is not, however, eventually-consistent, so an orphaned member ceases to be available.
  297. Kev That is, I believe, what I intended to express. The majority split functions, the minority split doesn't.
  298. eta Kev, the thing is you can just queue messages in the minority split until it rejoins
  299. Kev eta
  300. eta blinks
  301. Kev (Sorry, dev version of client)
  302. eta aha :)
  303. dwd Kev, But eventual consistency and message ordering are, I think, problematic, unless your UX makes things very clear. FMUC solves this, I think, by making that UX affordance possible.
  304. Kev eta: By 'messages' here do you mean <message/> or the log entries from Raft? If it's <message/> then there's lots of other modifications that could happen during a split that are hard to deal with, I think.
  305. eta Kev, <message/>
  306. pep. I don't know Raft nor Paxos. Why would a minority not continue working on its own? redo elections etc.?
  307. pep. Resources I can read?
  308. antranigv has joined
  309. eta pep., https://raft.github.io/
  310. Shell because the minority can't know that what it does is compatible with the state of the majority.
  311. Kev dwd: Yes. It's not even the message ordering that most worries me though, it's the other state changes, e.g. banning a user and making them an owner on different nodes (the old IRC netsplit op attacks are an extreme symptom of this).
  312. neshtaxmpp has joined
  313. dwd pep., Have a look at "CAP Theorum", as a good general start point.
  314. arc has left
  315. arc has joined
  316. antranigv has left
  317. antranigv has joined
  318. Kev pep: In order to win an election you need to have a majority vote. If you're in a minority split you can never have a majority vote. The leader is the Source Of Truth for the replication, with it being responsible for ordering the log messages. So if you had two leaders each claiming to be the Source Of Truth, bad things happen. At least from memory, I've not looked at Raft properly in a few years.
  319. antranigv has left
  320. dwd Kev, Broadly, this is true for almost every consensus algorithm that eschews eventual consistency.
  321. Kev Right.
  322. pep. Kev, right, your use of minority / majority "only" makes sense when you try to merge back :p
  323. pep. Thanks for the pointers
  324. eta Kev, I don't see how you can do split riding though
  325. dwd Kev, But also, I don't think the netsplit op attacks are possible if you don't have an eventual-consistency style.
  326. eta if you're in the minority partition, disallow all state changes
  327. dwd eta, Not just state. Message reordering can lead to some interesting problems.
  328. adityaborikar has left
  329. Kev Right. That (eta) obviously avoids the complications, at the cost of degraded service. But note that 'state' here includes message publishing.
  330. adityaborikar has joined
  331. dwd And when I say "interesting", I mean in the sense of people dying.
  332. eta ?!
  333. Ge0rG Just DAG everything?
  334. eta remembers dwd makes healthcare messaging software
  335. dwd eta, Not that context actually, but yes.
  336. eta wait, so explain how message reordering is problematic?
  337. krauq has left
  338. dwd "Is the patient breathing?" "Yes" "Have you checked for spinal injury?" "No". Rearrange for much fun.
  339. eta right, but you can't flip the yes and the no here
  340. eta assuming the asker and the responder have a netsplit between them
  341. eta because the behaviour in event of partition is to queue
  342. Zash eta: is your blog on planet ?
  343. dwd No, but if the "Yes" follows "spinal injury" people get pretty confused very quickly.
  344. eta Zash, don't think so
  345. krauq has joined
  346. Ge0rG eta: you can get nice reordering effects if there is a third party reading, and they have intermittent s2s issues
  347. Kev My (not exhaustive, but I've spent more time on this than one might like) experience of things-that-can-go-wrong in situations like this is that whenever I think "But at least X can't happen", something else that's equivalent to X ends up being able to happen.
  348. arc has left
  349. eta Kev, hah
  350. arc has joined
  351. dwd Ge0rG, As for DAG, that does deserve a special place in hell. People don't talk in DAGs, they talk linearly. The way to get DAGgy in conversations is to thread them and present a UX that then makes sense, and somehow encourage users to use that threading sanely.
  352. Kev dwd: Our conversation here is a DAG. It's just a very specialised case :)
  353. Kev ._._._._._._._.
  354. dwd Kev, Yes, yes. Have a sticker. :-)
  355. Ge0rG Kev: is it really? Each message is either a root or a reference to some earlier message.
  356. eta if you *really* cared about message ordering you could replicate messages in the raft log
  357. dwd Ge0rG, A linear graph is a proper subset of a DAG, I think he means.
  358. eta but that would add quite a deal of latency
  359. Kev dwd: Honestly, a decent sticker would brighten up my day Quite A Lot right now.
  360. pep. Some people want want ./·_./·_./·_. :x
  361. Ge0rG dwd: yes, that's what I conlcuded from the message as well. My point is that this conversation is not a linear graph.
  362. pep. Some people want ./·_./·_./·_. :x
  363. pep. And not a full dag
  364. Ge0rG pep.: is that morse code?
  365. Ge0rG drunk morse?
  366. dwd Ge0rG, Morse did drink a lot.
  367. Kev Ge0rG: I'm as surprised as the next person that my joke doesn't stand up to scrutiny.
  368. Ge0rG Kev: sorry
  369. dwd Kev, It's been rejected at peer review stage, but is still available as a pre=print, so I guess you win?
  370. Kev Academic journal peer review is a process I will be very happy not to go through again (on either side).
  371. Ge0rG I suppose normal people are not deep into partially ordered histories, right?
  372. sonny has left
  373. Kev Georg - if you mean that it's only the 'mission critical' (for want of a better term) situations where ordering matters, I think 'normal' people care about it too, it's just less bad when it goes wrong.
  374. pep. Ge0rG, it's supposed to represent a special shape of tree :p Dunno if that has a name
  375. pep. https://ppjet.bouah.net/tree-foo.png
  376. Ge0rG Kev: what I intend to say is this: if message history is implemented as an eventually consistent DAG, people won't be able to grasp the concept and draw the right conclusions regarding message ordering. Not in normal times and especially not during a crisis
  377. Kev Ah. Yes, I think a UI needs to de-DAG it in order for it to be reasonably understandable.
  378. dwd eta, Anyway, if you always send messages to the top of a conceptual routing tree, so a single leader elected for the purpose, but handle state changes through a consensus algorithm, then I think we're good. If you use a Byzantine fault tolerant algorithm, and use it sparingly, then I think you more or less get reasonable performance with highly resilient state - as long as you're not connected to a node which loses connectivity with the others in the consensus group.
  379. pep. (Basically meant to say some people want to be able to reply to a single message)
  380. dwd Kev, Or as pep. suggests (I think), Slack-style "threading".
  381. sonny has joined
  382. Ge0rG Are we talking about threading or about message history consistency?
  383. Kev I note that me saying that things like Raft don't solve all aspects of CAP (yes), doesn't mean that using Raft for MUCs (which are currently entirely SPoF) would be bad.
  384. dwd pep., FWIW, I wanted to do Slack-style threading by spawning off a new chatroom as a child of the containing conversation.
  385. pep. dwd, I hear that's how rocketchat worksss-ish?
  386. pep. I've never used it
  387. dwd Kev, Also the whole point of CAP is that you can't solve all aspects of it.
  388. Kev I wanted to do Slack-style threading by spawning off a new message node within the channel.
  389. Kev dwd: Yes, thus the "(yes)" to denote that I realised.
  390. dwd pep., I... don't know. I do know some people who do a lot with Rocketchat though.
  391. dwd Kev, Ah, I thought so, but then I worried about people misunderstanding, but then after writing my last I realised that anyone familiar with "CAP" would know anyway.
  392. dwd Sometimes I should just not write things. :-)
  393. dwd eta, Oh, and before I forget to mention it, the bit of your design I thought was interesting - and have now largely forgotten - was your approach to permissions at the group chat level, which seemed well thought through.
  394. Kev You are probably right that I'm not expressing things in an observer-considerate way.
  395. sonny has left
  396. sonny has joined
  397. Kev I've been thinking about ways to improve clustering within M-Link (and other things) recently, which is a very similar area, but with different requirements.
  398. dwd Yes - no need to conider Byzantine fault tolerance, but you probably so want to go the eventual consistency route for most things.
  399. Kev I hadn't realised it, but reading eta's article I'm starting to think I'm in the middle of re-inventing Matrix.
  400. dwd Kev, Thinking about the IRC netsplit attacks, were those entirely predicated on the combination of channels disappearing when nobody was in them (and thus being able to be recreated with different ownership) and a poor merge algorithm?
  401. eta dwd, yes
  402. Kev Yes.
  403. eta the fix was "improve the merge algorithm"
  404. Andrzej has left
  405. eta so the channel with the earliest creation timestamp wins
  406. Andrzej has joined
  407. Kev Well, that was one of the fixes. I've also seen (maybe not recently) disallowing channel creation during a split.
  408. Zash Oh glob not merge algorithms
  409. Kev You can't *not* have merge algorithms of some sort, if you want eventual consistency.
  410. Kev You may as well say "Oh glob, not eventual consistency", which would probably be quite fair, it's a lot more of a brainfuck to reason about than something like Raft.
  411. antranigv has joined
  412. eta decides people should just use single servers and avoid making a distributed system where possible
  413. dwd eta, We already have a distributed system in XMPP; we just have a fixed leader and all decisions are made by the leader. That's a valid solution to be problem; it's just that if you want to address the shortcomings (like the leader being a SPOF) then things get complicated.
  414. adityaborikar has left
  415. adityaborikar has joined
  416. dwd eta, Most notably, because our distributed system is a heterogeneous distributed system already.
  417. floretta has joined
  418. mukt2 has joined
  419. Lance has joined
  420. adityaborikar has left
  421. adityaborikar has joined
  422. Lance has left
  423. mukt2 has left
  424. raghavgururajan has joined
  425. clintoning has joined
  426. clintoning has left
  427. clinton has joined
  428. clinton has left
  429. clinton has joined
  430. clinton has left
  431. eta ah, that is porn
  432. edhelas yes, but uploaded using HTTP Upload !
  433. eta yeah, which meant I clicked on it
  434. eta and now it's on my screen and I can't delete it
  435. eta thanks dino
  436. pep. quick quick send new messages
  437. Zash Message Moderation to the rescue?
  438. dwd Scrolling, scrolling, scrolling.
  439. vanitasvitae luckily I waited before clicking
  440. dwd Get them wagons rolling.
  441. edhelas got a nice preview on Movim :D
  442. vanitasvitae but yeah, deleting images in dino would be nice
  443. pep. Zash, I think allowing a user to stop displaying a picture would be nice nonetheless :/
  444. eta makes more noise
  445. Ge0rG Some clients will just auto load images
  446. eta vanitasvitae, indeed
  447. edhelas actually it's the best way to wake up a channel it seems 🤔
  448. eta hahaha
  449. eta yay, it's off the screen now
  450. pep. Good, now we can go back to sleep
  451. Zash Pretty sure I enabled moderation here, so you can go in and delete it from the archives even
  452. edhelas pfieuw, now let's go back to normal
  453. dwd At least we're considered a worthwhile audience for porn spam.
  454. Ge0rG You can't solve social problems with technical means. If you block images, they'll send ASCII porn. Or illegal text content.
  455. eta Zash, but isn't it just converse that does that
  456. edhelas only XEP pr0n is allowed here, I like reading 0060 for example
  457. eta that's the good stuff
  458. vanitasvitae guys, follow my OnlyXEPs account!
  459. Ge0rG edhelas: you pervert!
  460. edhelas yeah, I love those Romeo & Juliet stories
  461. pep. While there is some activity in here: in 20 minutes we have a SCAM meeting in xmpp:scam@muc.xmpp.org?join and we're talking about Summit. Please join if you want to follow and/or have ideas on the organisation side of things
  462. vanitasvitae pep., thanks for the heads up
  463. Lance has joined
  464. krauq has left
  465. krauq has joined
  466. neshtaxmpp has left
  467. Lance has left
  468. JustLikeThat has joined
  469. JustLikeThat has left
  470. JustLikeThat has joined
  471. DebXWoody has left
  472. Lance has joined
  473. JustLikeThat I have a proposal 🙂
  474. mdosch Porn again? This time moving pictures?
  475. JustLikeThat has left
  476. mukt2 has joined
  477. adityaborikar has left
  478. adityaborikar has joined
  479. arc has left
  480. arc has joined
  481. Lance has left
  482. mukt2 has left
  483. arc has left
  484. arc has joined
  485. Guus Yes
  486. Guus Better moderating support in clients is going to become more desirable.
  487. Guus EG: make a room temporarily moderated, hand out voice, stuff like that.
  488. Lance has joined
  489. Zash and XEP-0425
  490. slouchy6 has left
  491. arc has left
  492. arc has joined
  493. slouchy6 has joined
  494. Lance has left
  495. Lance has joined
  496. Observer has joined
  497. CognitiveDissonance has joined
  498. CognitiveDissonance Hi all
  499. CognitiveDissonance I was wondering, what is the *fundamental* difference between XMPP and Matrix?
  500. MattJ Great question :)
  501. Daniel Fundamental from an end user experience probably not
  502. adityaborikar has left
  503. adityaborikar has joined
  504. MattJ I think the fundamental difference is that XMPP is based on routing stuff, and Matrix is based on distributing stuff
  505. CognitiveDissonance Like design principles, target use-cases, future roadmap etc..
  506. eta CognitiveDissonance, Matrix is fundamentally a database (a graph data structure that's replicated across servers; the spec defines how to replicate the structure), whereas XMPP is based on passing messages around (the spec defines how messages should be routed to different clients and optionally stored)
  507. CognitiveDissonance Ah, routing vs distributing seems like a core difference.
  508. CognitiveDissonance Also, is matrix completely web-based?
  509. eta this is why Matrix servers need more resources to run; because they spend a lot of energy doing this replication algorithm
  510. Daniel Define web based.
  511. eta whereas XMPP messages are simple and easy to route
  512. CognitiveDissonance Daniel http
  513. Daniel Yes it uses http.
  514. Kev > easy to route /me giggles
  515. CognitiveDissonance Daniel What about xmpp?
  516. moparisthebest but if "http" is your criteria then XMPP is also web-based
  517. Daniel c2s *can* be http
  518. moparisthebest because it can be used over http
  519. Daniel s2s is tcp
  520. Daniel or at least we haven’t speced out a way to use s2s over http
  521. Daniel i guess we could
  522. paul has left
  523. jonas’ why tho
  524. CognitiveDissonance So in terms of design principles like modularity, simplicity and extensibility, what is the diff b/w them?
  525. Zash has left
  526. Zash has joined
  527. CognitiveDissonance Daniel Hmm, I always seen only xmpp://foo and not http://foo, for c2s
  528. Daniel jonas’, well I was just answering a question.
  529. moparisthebest XMPP has proven to be very extensible based on continuing to work well 20+ years after it started, matrix on the other hand... they are asking users to migrate servers because they can't scale
  530. Daniel but you might want to run servers behind more restrictives firewalls
  531. Daniel on your raspi or something
  532. MattJ Running servers in the browser has been discussed in certain server projects before
  533. andrey.g has joined
  534. CognitiveDissonance Daniel: I see.
  535. CognitiveDissonance moparisthebest Point.
  536. CognitiveDissonance * good point
  537. eta CognitiveDissonance, so natively XMPP uses a TCP socket, but the BOSH (bidirectional streams over synchronous HTTP) extension lets you use it over HTTP
  538. CognitiveDissonance Sp matrix is a monolithic system right?
  539. eta (almost all popular servers expose that as an option for web clients)
  540. moparisthebest eta, CognitiveDissonance also websockets
  541. eta yep, that too
  542. Observer has left
  543. moparisthebest I expect *very soon (tm)* xmpp c2s and s2s to start working over QUIC as well
  544. CognitiveDissonance eta Daniel Ah BOSH makes sense. Btw, xmpp server doesn't *require* web server right? matrix seems to rely on web server.
  545. eta CognitiveDissonance, not at all!
  546. adityaborikar has left
  547. adityaborikar has joined
  548. eta you might want one for HTTP file uploading (XEP-0363), but it isn't a hard requirement
  549. CognitiveDissonance I see.
  550. Tobias has left
  551. CognitiveDissonance Also, in DNS records, I notices xmpp has only SRV records, where matrix has only A records.
  552. eta that's because matrix uses /.well-known
  553. jonas’ CognitiveDissonance, you need A/AAAA records for SRV to make sense
  554. moparisthebest XMPP also has TXT records for some connection methods...
  555. CognitiveDissonance boon or a bane?
  556. Zash Matrix uses SRV too
  557. Tobias has joined
  558. moparisthebest again I expect *very soon (tm)* XMPP to start using http-svc/srv2 records or whatever the latest name for those are
  559. Zash moparisthebest: don't you dare!
  560. moparisthebest Zash, required for sni+alpn encryption!
  562. moparisthebest (plus other things etc)
  563. Zash Do not want
  564. CognitiveDissonance i am scared of http and web tech stuff.
  565. moparisthebest that's the best thing about XMPP, even if you don't want it I can still have it and vice versa :D
  566. CognitiveDissonance Too many security issues
  567. moparisthebest CognitiveDissonance, to be fair that's just "computers"
  568. dwd CognitiveDissonance, To be cleat, Matrix need not suffer from those since it's not like it runs in the browser.
  569. dwd CognitiveDissonance, To be clear, Matrix need not suffer from those since it's not like it runs in the browser.
  570. Lance has left
  571. dwd CognitiveDissonance, It just uses HTTP and JSON as its substrate layer, like XMPP uses XML. And XML has its own set of amusing security issues.
  572. jonas’ "laugh"able!
  573. CognitiveDissonance dwd hmm, AFAIK, even riot/element desktop client is a web stuff via electron.
  574. dwd CognitiveDissonance, Sure, the implementation of the clients is all web tech. But in principle it need not be.
  575. CognitiveDissonance dwd. I see. I have seem in wikipedia that xmpp is a text-based protocol like IRC. what does mean?
  576. dwd CognitiveDissonance, There are, I think, Electron-ish clients in the XMPP world. Certainly browser based ones.
  577. jonas’ CognitiveDissonance, it means that some bytes are not allowed in the streams
  578. jonas’ doesn’t matter in practice
  579. dwd CognitiveDissonance, XMPP operates by exchanging XML fragments over TCP, not text. Matrix operates by exchanging bits of JSON over HTTP.
  580. moparisthebest IRC operates by exchanging bytes over TCP, better hope you guess the encoding correctly!
  581. dwd (Favourite thing about IRC is that the case-folding for usernames is based on whatever keyboard layout the developer happened to be using).
  582. CognitiveDissonance I was confused about "text-based". XML is not a plain text?
  583. jonas’ (dwd, wasn’t it the swedish 8-bit latin encoding thing?)
  584. Zash jonas’: finnish
  585. jonas’ CognitiveDissonance, it is as much plain text as JSON is
  586. jonas’ Zash, ah, right
  587. dwd CognitiveDissonance, It's generally textual in nature, but it's not plain text as such.
  588. jonas’ (I mixed that up with mysql, that was swedish)
  589. moparisthebest if anything XMPP/XML and Matrix/JSON are much more "text-based" than IRC because the encoding is actually defined
  590. CognitiveDissonance dwd: Ah, I am getting the fundamental difference now.
  591. xecks has left
  592. CognitiveDissonance Matrix exchanges JSON over http and XMPP exchanges XML over tcp.
  593. jonas’ (over http over tcp/whatever atrocity google thinks of)
  594. CognitiveDissonance If I put a VS (versus) in between ....
  595. moparisthebest mainly yes, but more generically XMPP exchanges XML over (a stream)
  596. dwd CognitiveDissonance, Well, possibly not. XML+TCP and JSON+HTTP aren't that different, really. The biggest gain XMPP gets from XML is actually the namespacing rules, which give us clear extensibility - but in principle you can transcode between the two with some rules. The much bigger difference between XMPP and Matrix is the fundamental model.
  597. moparisthebest it's mostly TCP but it can be Websocket or a BOSH session today
  598. moparisthebest QUIC or whatever else tommorow
  599. eevvoor has left
  600. dwd moparisthebest, In fairness, plain TCP is rare since we're always using TLS.
  601. moparisthebest right I didn't mean *plain* TCP but good clarification
  602. CognitiveDissonance http is stateless and tct is stateful?
  603. Wojtek has joined
  604. dwd CognitiveDissonance, Broadly meaningless. Matrix has state in its sessions.
  605. CognitiveDissonance I see.
  606. antranigv has left
  607. eevvoor has joined
  608. dwd CognitiveDissonance, I mean, IP is stateless and yet XMPP has state. TCP has state too. XMPP sessions can span multiple TCP sessions. So whether TCP happens to have state isn't important - and HTTP runs over TCP anyway.
  609. antranigv has joined
  610. raghavgururajan considers xmpp like emacs. extend and extend and extend
  611. moparisthebest "HTTP runs over TCP anyway" eh not so much anymore, http up to 2 does, http 3 does not
  612. moparisthebest in a similar way that future XMPP won't have to :)
  613. CognitiveDissonance what?
  614. CognitiveDissonance http is application layer right? it requires tcp?
  615. moparisthebest http3 runs over QUIC which is like TLS but over UDP
  616. CognitiveDissonance quic??
  617. moparisthebest https://en.wikipedia.org/wiki/QUIC
  618. Alex has left
  619. alameyo has left
  620. alameyo has joined
  621. CognitiveDissonance nice
  622. jonas’ (good thing we didn’t have DTLS…)
  623. moparisthebest https://en.wikipedia.org/wiki/HTTP/3 etc
  624. dwd Matthew Hodgson, of Matrix, once compared Matrix and XMPP as Mac vs Linux. I think perhaps iPhone versus Linux might be more apropos. Matrix gives you a bunch of stuff, and you get what you're given - though you can add more. XMPP gives you a low-level kernel, but almost everyone then gives you a distribution with a bunch of common software on top.
  625. Alex has joined
  626. CognitiveDissonance Thank you all folks!!!
  627. CognitiveDissonance I appreciate it.
  628. moparisthebest jonas’, DTLS is quite different than QUIC
  629. jonas’ moparisthebest, I don’t care
  630. dwd I mean, finding a client or server that does XMPP and nothing else is *hard*.
  631. alameyo has left
  632. alameyo has joined
  633. moparisthebest it's akin to UDP vs TCP, you can't just drop-in replace one with the other, different use cases
  634. Kev You mean RFC 6120 only? Impossible, I suspect.
  635. dwd Kev, I was thinking 6120+6121, which is in principle possible.
  636. raghavgururajan dwd: That is actually. Start minimal and extend. Keeps things simple and modular.
  637. Kev Sorry, I didn't mean it was technically impossible to do 6120 only (although I think it probably is, because you'd need to replace 6121 with something else for the routing rules), just that I would be amazed if there exists any such software. Although I'd be moderately surprised to find something doing 612[01] and nothing else, but not shocked.
  638. raghavgururajan *actually good
  639. antranigv has left
  640. moparisthebest try finding a browser that just does http
  641. dwd moparisthebest, Ooooh, I'm going to use that next time someone does the "Too many XEPS!!!111" argument with me.
  642. Zash HTTP has too many RFCs!
  643. Syndace has left
  644. Syndace has joined
  645. raghavgururajan To rewrite my message: What XMPP does is good. It starts minimal and then extends. It keep things simple and modular. Don't you all agree?
  646. neshtaxmpp has joined
  647. dwd Broadly, yes - I don't know how else we could have built it but start with a common base and add bits.
  648. CognitiveDissonance raghavgururajan I was looking for that difference in xmpp and matrix.
  649. lovetox has joined
  650. dwd Matrix can avoid this by essentially being an open source project with a protocol spec - I'm not sure that there's any well-used third-party implementations, are there?
  651. moparisthebest matrix starts with the whole shebang and then you are stuck with it
  652. CognitiveDissonance Oh hey lovetox is here. I love gajim.
  653. moparisthebest and that brings things like "sorry our main server is so slow please move to another server"
  654. CognitiveDissonance gotta go though
  655. CognitiveDissonance has left
  656. dwd But if there ends up being a bunch of independent implementations, then wholesale changes to the monolith spec are going to be much harder to arrange.
  657. antranigv has joined
  658. moparisthebest vs xmpp's "we handle 10million+ simultaneous connections and 600+ messages per second no problem" https://www.process-one.net/blog/ejabberd-nintendo-switch-npns/
  659. Kev That does *heavily* depend on your traffic model, mind.
  660. dwd moparisthebest, Yeah, but I kind of got bored with scaling. I like that we can, but I'm more interested in smaller scale stuff now - you can do a lot more interesting stuff.
  661. Lance has joined
  662. moparisthebest sure it's just nice to know it *can*
  663. xecks has joined
  664. dwd Right, sure. And it's another strength - you can pick a server built to do massive scaling, or one built for low-bandwidth, or write your own in about 2,000 lines of Python.
  665. Kev Or one line of Perl.
  666. raghavgururajan > dwd‎: But if there ends up being a bunch of independent implementations, then wholesale changes to the monolith spec are going to be much harder to arrange. +1
  667. Zash or one looooooooong line of sed ;)
  668. moparisthebest if you find yourself rewriting your server in another language in the hope it might be faster you've probably made a wrong turn design-wise
  669. rion has joined
  670. dwd moparisthebest, Oh, I think 2000 lines of Python will be slower. But I don't have to scale to 10 million users, so I have other criteria for success.
  671. antranigv has left
  672. antranigv has joined
  673. raghavgururajan whispers LISP
  674. moparisthebest (that was a jab at matrix by the way)
  675. raghavgururajan ?
  676. alameyo has left
  677. alameyo has joined
  678. raghavgururajan *ignore the ?
  679. antranigv has left
  680. moparisthebest wow I do have to give them props for this page https://matrix.org/docs/projects/try-matrix-now that's far superior to anything we have
  681. Kev They have a much less complex ecosystem than we have.
  682. Kev And that page is already looking pretty complex.
  683. Zash Kev: ORLY?
  684. Kev Z
  685. Kev I really need to fix that bug.
  686. moparisthebest really? if you only judged by https://xmpp.org/software/clients.html / https://xmpp.org/software/servers.html / https://xmpp.org/software/libraries.html you'd probably conclude we barely have an ecosystem at all
  687. Kev Zash: Unless I'm wrong (which is always possible), Matrix is led by Matrix. They don't have the complexities we do where our 'central org' (I don't have a better description) is community-run by competing projects etc.
  688. Zash http://screenshots.debian.net/packages?search=xmpp&show=with
  689. Zash Kev: Oh boy, let me tell you about Grid, the Matrix (protocol) fork (IIRC).
  690. Kev So I'm just wrong. Fair enough.
  691. Zash Kev: But yeah. It's probably comparable to back when Jabber Inc was a thing.
  692. Kev Jabber Inc was never the JSF, though.
  693. Zash Similar but different 🤷
  694. Kev Fair.
  695. werdan has joined
  696. paul has joined
  697. neshtaxmpp has left
  698. Steve Kille has left
  699. xecks has left
  700. Steve Kille has joined
  701. Lance has left
  702. xecks has joined
  703. krauq has left
  704. krauq has joined
  705. neshtaxmpp has joined
  706. MattJ > If I want to get a reliable xmpp client going on my Mac, I’m going to have to download and compile code, and I don’t actually know which code is the best bet, so chances are I’m going to have to download and compile multiple bits of code before I find one that works.
  707. MattJ Er, wrong chat but not I guess
  708. matkor has left
  709. Zash Sure would be nice to have that nicer clients.html
  710. Kev Be nice to have nicer clients first :D
  711. Kev (Yes, I know Swift hasn't had enough love in recent times. Working on that at the moment, although what form it'll take is up in the air)
  712. wurstsalat Zash, very much +1
  713. matkor has joined
  714. dwd I am right in thinking Ted Lemon's talking bollocks there, surely? I mean, the Mac desktop clients aren't pretty, but there's a few that exist and they're all in binary form right?
  715. Kev I've no idea which room this is referring to.
  716. Kev But it is certainly true that XMPP clients on Mac tend to be precompiled.
  717. Zash Kev: IETF list
  718. dwd Kev, MattJ's quote is from a mail by Ted Lemon on ietf-disgust
  719. Kev Ah, ta.
  720. Andrzej BeagleIM is for macOS and is distributed in binary form but if you wish you can compile it yourself
  721. eta Zash, wait, what do you know about grid
  722. Zash https://mailarchive.ietf.org/arch/msg/tools-discuss/21-hD287xlxBkskiWxPl5vX6f8I
  723. Kev I wonder at what point I unsubbed from ietf-disgust. I used to be subbed, but realise now I've not seen a mail for years, so I probably made a (rare) Good Life Choice at some point.
  724. Zash eta: I know someone wrote a long rant about how insecure Matrix is, then went on to make their own fork of it.
  725. jonas’ dwd, typo? :D
  726. eta Zash, yeah, Max
  727. sonny has left
  728. sonny has joined
  729. Lance has joined
  730. pasdesushi has joined
  731. sonny has left
  732. Half-Shot has left
  733. uhoreg has left
  734. Rixon 👁🗨 has left
  735. neshtaxmpp has left
  736. Half-Shot has joined
  737. Rixon 👁🗨 has joined
  738. uhoreg has joined
  739. sonny has joined
  740. andrey.g has left
  741. sonny has left
  742. sonny has joined
  743. floretta has left
  744. DebXWoody has joined
  745. sonny has left
  746. neshtaxmpp has joined
  747. winfried has left
  748. winfried has joined
  749. sonny has joined
  750. sonny has left
  751. floretta has joined
  752. mukt2 has joined
  753. DebXWoody has left
  754. pasdesushi has left
  755. sonny has joined
  756. mukt2 has left
  757. mukt2 has joined
  758. arc has left
  759. arc has joined
  760. sonny has left
  761. sonny has joined
  762. sonny has left
  763. krauq has left
  764. krauq has joined
  765. DebXWoody has joined
  766. j.r has left
  767. mukt2 has left
  768. neshtaxmpp has left
  769. j.r has joined
  770. moparisthebest hrm since when was XMPP considered part of the #Fediverse ?
  771. Zash https://the-federation.info/ lists XMPP, ergo XMPP is part of the Fediverse.
  772. moparisthebest yep that's where I noticed
  773. Zash Now proceed to accept this circular logic as truth. Thank you!
  774. moparisthebest I thought Fediverse was just ActivityPub based stuff TIL
  775. Zash I thought it dated back to OStatus, but I'm not so sure.
  776. xecks has left
  777. xecks has joined
  778. krauq has left
  779. krauq has joined
  780. sonny has joined
  781. adityaborikar has left
  782. Andrzej has left
  783. j.r has left
  784. sonny has left
  785. Nano4BeingYou has joined
  786. neshtaxmpp has joined
  787. pasdesushi has joined
  788. debacle has left
  789. Andrzej has joined
  790. antranigv has joined
  791. arc has left
  792. arc has joined
  793. pasdesushi has left
  794. lovetox has left
  795. j.r has joined
  796. sonny has joined
  797. Nekit has left
  798. Nekit has joined
  799. pasdesushi has joined
  800. sonny has left
  801. sonny has joined
  802. pasdesushi has left
  803. vanitasvitae I think it depends how you define the Fediverse
  804. vanitasvitae Diaspora is also considered part of it and doesn't do AP either
  805. vanitasvitae So XMPP fits the definition of being federated and being able to do social networking
  806. Zash Is Email part of the Fediverse? :D
  807. moparisthebest if XMPP is then I'd have to argue SMTP is too
  808. sonny has left
  809. debacle has joined
  810. rion has left
  811. antranigv has left
  812. sonny has joined
  813. sonny has left
  814. neshtaxmpp has left
  815. lovetox has joined
  816. Shell there is social networking stuff built on XMPP, it's probably fediverse
  817. dwd moparisthebest, EMail used to be before Google took it over...
  818. sonny has joined
  819. sonny has left
  820. andrey.g has joined
  821. Andrzej has left
  822. pasdesushi has joined
  823. pasdesushi has left
  824. pasdesushi has joined
  825. pasdesushi has left
  826. lovetox has left
  827. andrey.g has left
  828. arc has left
  829. arc has joined
  830. pasdesushi has joined
  831. Andrzej has joined
  832. mukt2 has joined
  833. pasdesushi has left
  834. pasdesushi has joined
  835. j.r has left
  836. j.r has joined
  837. pasdesushi has left
  838. pasdesushi has joined
  839. DebXWoody has left
  840. pasdesushi has left
  841. krauq has left
  842. mukt2 has left
  843. kuvoh has joined
  844. Andrzej has left
  845. krauq has joined
  846. sonny has joined
  847. kuvoh has left
  848. Yagiza has left
  849. Andrzej has joined
  850. Wojtek has left
  851. Wojtek has joined
  852. Nano4BeingYou has left
  853. raghavgururajan Zash: Is there a homepage for Grid?
  854. raghavgururajan could find via searx
  855. sonny has left
  856. Alex has left
  857. raghavgururajan moparisthebest: Yes, SMTP and XMPP are fedearted protocols.
  858. moparisthebest yea I knew that, just not that every federated protocol was considered part of the "fediverse"
  859. Andrzej has left
  860. sonny has joined
  861. karoshi has left
  862. antranigv has joined
  863. dwd Please tell me they have usenet in there.
  864. Zash usenet distributed, not federated!!!!!!!eleven
  865. karoshi has joined
  866. sonny has left
  867. antranigv has left
  868. moparisthebest a ton I've never heard of but no usenet https://the-federation.info/#protocols
  869. pasdesushi has joined
  870. pasdesushi has left
  871. pasdesushi has joined
  872. moparisthebest zot? dfrn? all have more servers than the pitiful 53 XMPP servers and the 1 SMTP server
  873. moparisthebest strangely, not gmail.com
  874. dwd Zash, I don't think it described itself as federated - but nor did email.
  875. Zash possibly relevant xkcd https://xkcd.com/802/
  876. dwd Zash, But you can post a message to any NNTP server and it ends up on all of them somehow, right?
  877. Zash dwd: Just like Matrix!
  878. Zash dwd: "usenet is distributed, not federerated" was what I meant to write, before my sleepy brain decided to change the sentence structure in the middle
  879. sonny has joined
  880. pasdesushi has left
  881. Maranda To me it looks like a "much spinning" site
  882. sonny has left
  883. Andrzej has joined
  884. Zash Maranda: https://www.youtube.com/watch?v=ldK1gQSSTSo
  885. Maranda 😂
  886. Mikaela has left
  887. Maranda has left
  888. jcbrand has left
  889. Maranda has joined
  890. adityaborikar has joined
  891. pasis has left
  892. Kev dwd: You know I'm interested in MAM-FC too ;)
  893. Zash dwd, Kev: Have you seen https://gist.github.com/mar-v-in/8a9a578d2137a0196744a32abf6aa0eb/ ?
  894. Kev If that's the same as the old mailing list post that suggested we must not know what we're talking about, yes.
  895. Zash I don't know about that
  896. Kev I thought there was some line in it about only understonding how we could have written it if we didn't understand the area.
  897. Kev I might misremember, or it might be a different post. Will see if I can read it tomorr.w
  898. Andrzej has left
  899. arc has left
  900. arc has joined
  901. sonny has joined
  902. arc has left
  903. arc has joined
  904. sonny has left
  905. mukt2 has joined
  906. arc has left
  907. arc has joined
  908. pasdesushi has joined
  909. werdan has left
  910. LNJ has left
  911. arc has left
  912. arc has joined
  913. pasdesushi has left
  914. alameyo has left
  915. alameyo has joined
  916. dwd No, this one just says it's badly written, and was proibably written solely to prove him wrong.
  917. pasdesushi has joined
  918. pasdesushi has left
  919. dwd In any case, *my* main problem with MAM-FC, currently - beyond it needing a lot of editing work - is that there's no way for a server to distinguish between a client updating its conversation view and a client paging through a conversation. RSM simply doesn't provide that, and the result is it gets a bit weird and broken, or else plain inefficient.
  920. sonny has joined
  921. karoshi has left
  922. sonny has left
  923. sonny has joined
  924. arc has left
  925. xecks has left
  926. Andrzej has joined
  927. Andrzej has left
  928. debacle has left
  929. j.r has left
  930. j.r has joined
  931. arc has joined
  932. Andrzej has joined
  933. alameyo has left
  934. alameyo has joined
  935. lskdjf dwd, in that gist there is a whole page of arguments on what the person thinks are issues with MAM-FC. It's not fair to pick out one sencence you didn't like to be able to say "whatever". It would be good to hear why you think that the issues raised in the gist (e.g. paragraph 3+4) aren't actually issues.
  936. paul has left
  937. deuill has joined
  938. adityaborikar has left
  939. moparisthebest Kev: speaking of misunderstandings another reminder for the xep-0001 update :)
  940. Zash has left
  941. Zash has joined
  942. Zash has left
  943. Zash has joined
  944. Zash has left
  945. eevvoor has left
  946. deuill has left
  947. winfried has left
  948. winfried has joined
  949. Zash has joined
  950. Andrzej has left
  951. mimi89999 has left
  952. mimi89999 has joined
  953. j.r has left
  954. j.r has joined
  955. Andrzej has joined
  956. j.r has left
  957. j.r has joined
  958. papatutuwawa has left
  959. papatutuwawa has joined
  960. adityaborikar has joined
  961. arc has left
  962. arc has joined
  963. Wojtek has left