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


  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.


  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.


  177. Ge0rG

    MIX has the additional problem that there is no plan for recovering from s2s outages.

  178. pep.


  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


  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.


  236. jonas’

    joking aside, will do

  237. jonas’


  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.


  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


  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


  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.


  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


  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 removed by Zash


  429. clinton has left

  430. clinton has joined

  431. clinton has left

  432. eta

    ah, that is porn

  433. edhelas

    yes, but uploaded using HTTP Upload !

  434. eta

    yeah, which meant I clicked on it

  435. eta

    and now it's on my screen and I can't delete it

  436. eta

    thanks dino

  437. pep.

    quick quick send new messages

  438. Zash

    Message Moderation to the rescue?

  439. dwd

    Scrolling, scrolling, scrolling.

  440. vanitasvitae

    luckily I waited before clicking

  441. dwd

    Get them wagons rolling.

  442. edhelas

    got a nice preview on Movim :D

  443. vanitasvitae

    but yeah, deleting images in dino would be nice

  444. pep.

    Zash, I think allowing a user to stop displaying a picture would be nice nonetheless :/

  445. eta makes more noise

  446. Ge0rG

    Some clients will just auto load images

  447. eta

    vanitasvitae, indeed

  448. edhelas

    actually it's the best way to wake up a channel it seems 🤔

  449. eta


  450. eta

    yay, it's off the screen now

  451. pep.

    Good, now we can go back to sleep

  452. Zash

    Pretty sure I enabled moderation here, so you can go in and delete it from the archives even

  453. edhelas

    pfieuw, now let's go back to normal

  454. dwd

    At least we're considered a worthwhile audience for porn spam.

  455. Ge0rG

    You can't solve social problems with technical means. If you block images, they'll send ASCII porn. Or illegal text content.

  456. eta

    Zash, but isn't it just converse that does that

  457. edhelas

    only XEP pr0n is allowed here, I like reading 0060 for example

  458. eta

    that's the good stuff

  459. vanitasvitae

    guys, follow my OnlyXEPs account!

  460. Ge0rG

    edhelas: you pervert!

  461. edhelas

    yeah, I love those Romeo & Juliet stories

  462. 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

  463. vanitasvitae

    pep., thanks for the heads up

  464. Lance has joined

  465. krauq has left

  466. krauq has joined

  467. neshtaxmpp has left

  468. Lance has left

  469. JustLikeThat has joined

  470. JustLikeThat has left

  471. JustLikeThat has joined

  472. DebXWoody has left

  473. Lance has joined

  474. JustLikeThat

    I have a proposal 🙂

  475. JustLikeThat removed by Zash


  476. mdosch

    Porn again? This time moving pictures?

  477. JustLikeThat has left

  478. mukt2 has joined

  479. adityaborikar has left

  480. adityaborikar has joined

  481. arc has left

  482. arc has joined

  483. Lance has left

  484. mukt2 has left

  485. arc has left

  486. arc has joined

  487. Guus


  488. Guus

    Better moderating support in clients is going to become more desirable.

  489. Guus

    EG: make a room temporarily moderated, hand out voice, stuff like that.

  490. Lance has joined

  491. Zash

    and XEP-0425

  492. slouchy6 has left

  493. arc has left

  494. arc has joined

  495. slouchy6 has joined

  496. Lance has left

  497. Lance has joined

  498. a moderator removed a message


  499. Observer has joined

  500. a moderator removed a message


  501. CognitiveDissonance has joined

  502. CognitiveDissonance

    Hi all

  503. CognitiveDissonance

    I was wondering, what is the *fundamental* difference between XMPP and Matrix?

  504. MattJ

    Great question :)

  505. Daniel

    Fundamental from an end user experience probably not

  506. adityaborikar has left

  507. adityaborikar has joined

  508. MattJ

    I think the fundamental difference is that XMPP is based on routing stuff, and Matrix is based on distributing stuff

  509. CognitiveDissonance

    Like design principles, target use-cases, future roadmap etc..

  510. 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)

  511. CognitiveDissonance

    Ah, routing vs distributing seems like a core difference.

  512. CognitiveDissonance

    Also, is matrix completely web-based?

  513. eta

    this is why Matrix servers need more resources to run; because they spend a lot of energy doing this replication algorithm

  514. Daniel

    Define web based.

  515. eta

    whereas XMPP messages are simple and easy to route

  516. CognitiveDissonance

    Daniel http

  517. Daniel

    Yes it uses http.

  518. Kev

    > easy to route /me giggles

  519. CognitiveDissonance

    Daniel What about xmpp?

  520. moparisthebest

    but if "http" is your criteria then XMPP is also web-based

  521. Daniel

    c2s *can* be http

  522. moparisthebest

    because it can be used over http

  523. Daniel

    s2s is tcp

  524. Daniel

    or at least we haven’t speced out a way to use s2s over http

  525. Daniel

    i guess we could

  526. paul has left

  527. jonas’

    why tho

  528. CognitiveDissonance

    So in terms of design principles like modularity, simplicity and extensibility, what is the diff b/w them?

  529. Zash has left

  530. Zash has joined

  531. CognitiveDissonance

    Daniel Hmm, I always seen only xmpp://foo and not http://foo, for c2s

  532. Daniel

    jonas’, well I was just answering a question.

  533. 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

  534. Daniel

    but you might want to run servers behind more restrictives firewalls

  535. Daniel

    on your raspi or something

  536. MattJ

    Running servers in the browser has been discussed in certain server projects before

  537. andrey.g has joined

  538. CognitiveDissonance

    Daniel: I see.

  539. CognitiveDissonance

    moparisthebest Point.

  540. CognitiveDissonance

    * good point

  541. eta

    CognitiveDissonance, so natively XMPP uses a TCP socket, but the BOSH (bidirectional streams over synchronous HTTP) extension lets you use it over HTTP

  542. CognitiveDissonance

    Sp matrix is a monolithic system right?

  543. eta

    (almost all popular servers expose that as an option for web clients)

  544. moparisthebest

    eta, CognitiveDissonance also websockets

  545. eta

    yep, that too

  546. Observer has left

  547. moparisthebest

    I expect *very soon (tm)* xmpp c2s and s2s to start working over QUIC as well

  548. CognitiveDissonance

    eta Daniel Ah BOSH makes sense. Btw, xmpp server doesn't *require* web server right? matrix seems to rely on web server.

  549. eta

    CognitiveDissonance, not at all!

  550. adityaborikar has left

  551. adityaborikar has joined

  552. eta

    you might want one for HTTP file uploading (XEP-0363), but it isn't a hard requirement

  553. CognitiveDissonance

    I see.

  554. Tobias has left

  555. CognitiveDissonance

    Also, in DNS records, I notices xmpp has only SRV records, where matrix has only A records.

  556. eta

    that's because matrix uses /.well-known

  557. jonas’

    CognitiveDissonance, you need A/AAAA records for SRV to make sense

  558. moparisthebest

    XMPP also has TXT records for some connection methods...

  559. CognitiveDissonance

    boon or a bane?

  560. Zash

    Matrix uses SRV too

  561. Tobias has joined

  562. moparisthebest

    again I expect *very soon (tm)* XMPP to start using http-svc/srv2 records or whatever the latest name for those are

  563. Zash

    moparisthebest: don't you dare!

  564. moparisthebest

    Zash, required for sni+alpn encryption!

  565. Zash


  566. moparisthebest

    (plus other things etc)

  567. Zash

    Do not want

  568. CognitiveDissonance

    i am scared of http and web tech stuff.

  569. moparisthebest

    that's the best thing about XMPP, even if you don't want it I can still have it and vice versa :D

  570. CognitiveDissonance

    Too many security issues

  571. moparisthebest

    CognitiveDissonance, to be fair that's just "computers"

  572. dwd

    CognitiveDissonance, To be cleat, Matrix need not suffer from those since it's not like it runs in the browser.

  573. dwd

    CognitiveDissonance, To be clear, Matrix need not suffer from those since it's not like it runs in the browser.

  574. Lance has left

  575. 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.

  576. jonas’


  577. CognitiveDissonance

    dwd hmm, AFAIK, even riot/element desktop client is a web stuff via electron.

  578. dwd

    CognitiveDissonance, Sure, the implementation of the clients is all web tech. But in principle it need not be.

  579. CognitiveDissonance

    dwd. I see. I have seem in wikipedia that xmpp is a text-based protocol like IRC. what does mean?

  580. dwd

    CognitiveDissonance, There are, I think, Electron-ish clients in the XMPP world. Certainly browser based ones.

  581. jonas’

    CognitiveDissonance, it means that some bytes are not allowed in the streams

  582. jonas’

    doesn’t matter in practice

  583. dwd

    CognitiveDissonance, XMPP operates by exchanging XML fragments over TCP, not text. Matrix operates by exchanging bits of JSON over HTTP.

  584. moparisthebest

    IRC operates by exchanging bytes over TCP, better hope you guess the encoding correctly!

  585. dwd

    (Favourite thing about IRC is that the case-folding for usernames is based on whatever keyboard layout the developer happened to be using).

  586. CognitiveDissonance

    I was confused about "text-based". XML is not a plain text?

  587. jonas’

    (dwd, wasn’t it the swedish 8-bit latin encoding thing?)

  588. Zash

    jonas’: finnish

  589. jonas’

    CognitiveDissonance, it is as much plain text as JSON is

  590. jonas’

    Zash, ah, right

  591. dwd

    CognitiveDissonance, It's generally textual in nature, but it's not plain text as such.

  592. jonas’

    (I mixed that up with mysql, that was swedish)

  593. moparisthebest

    if anything XMPP/XML and Matrix/JSON are much more "text-based" than IRC because the encoding is actually defined

  594. CognitiveDissonance

    dwd: Ah, I am getting the fundamental difference now.

  595. xecks has left

  596. CognitiveDissonance

    Matrix exchanges JSON over http and XMPP exchanges XML over tcp.

  597. jonas’

    (over http over tcp/whatever atrocity google thinks of)

  598. CognitiveDissonance

    If I put a VS (versus) in between ....

  599. moparisthebest

    mainly yes, but more generically XMPP exchanges XML over (a stream)

  600. 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.

  601. moparisthebest

    it's mostly TCP but it can be Websocket or a BOSH session today

  602. moparisthebest

    QUIC or whatever else tommorow

  603. eevvoor has left

  604. dwd

    moparisthebest, In fairness, plain TCP is rare since we're always using TLS.

  605. moparisthebest

    right I didn't mean *plain* TCP but good clarification

  606. CognitiveDissonance

    http is stateless and tct is stateful?

  607. Wojtek has joined

  608. dwd

    CognitiveDissonance, Broadly meaningless. Matrix has state in its sessions.

  609. CognitiveDissonance

    I see.

  610. antranigv has left

  611. eevvoor has joined

  612. 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.

  613. antranigv has joined

  614. raghavgururajan considers xmpp like emacs. extend and extend and extend

  615. moparisthebest

    "HTTP runs over TCP anyway" eh not so much anymore, http up to 2 does, http 3 does not

  616. moparisthebest

    in a similar way that future XMPP won't have to :)

  617. CognitiveDissonance


  618. CognitiveDissonance

    http is application layer right? it requires tcp?

  619. moparisthebest

    http3 runs over QUIC which is like TLS but over UDP

  620. CognitiveDissonance


  621. moparisthebest


  622. Alex has left

  623. alameyo has left

  624. alameyo has joined

  625. CognitiveDissonance


  626. jonas’

    (good thing we didn’t have DTLS…)

  627. moparisthebest

    https://en.wikipedia.org/wiki/HTTP/3 etc

  628. 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.

  629. Alex has joined

  630. CognitiveDissonance

    Thank you all folks!!!

  631. CognitiveDissonance

    I appreciate it.

  632. moparisthebest

    jonas’, DTLS is quite different than QUIC

  633. jonas’

    moparisthebest, I don’t care

  634. dwd

    I mean, finding a client or server that does XMPP and nothing else is *hard*.

  635. alameyo has left

  636. alameyo has joined

  637. moparisthebest

    it's akin to UDP vs TCP, you can't just drop-in replace one with the other, different use cases

  638. Kev

    You mean RFC 6120 only? Impossible, I suspect.

  639. dwd

    Kev, I was thinking 6120+6121, which is in principle possible.

  640. raghavgururajan

    dwd: That is actually. Start minimal and extend. Keeps things simple and modular.

  641. 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.

  642. raghavgururajan

    *actually good

  643. antranigv has left

  644. moparisthebest

    try finding a browser that just does http

  645. dwd

    moparisthebest, Ooooh, I'm going to use that next time someone does the "Too many XEPS!!!111" argument with me.

  646. Zash

    HTTP has too many RFCs!

  647. Syndace has left

  648. Syndace has joined

  649. 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?

  650. neshtaxmpp has joined

  651. dwd

    Broadly, yes - I don't know how else we could have built it but start with a common base and add bits.

  652. CognitiveDissonance

    raghavgururajan I was looking for that difference in xmpp and matrix.

  653. lovetox has joined

  654. 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?

  655. moparisthebest

    matrix starts with the whole shebang and then you are stuck with it

  656. CognitiveDissonance

    Oh hey lovetox is here. I love gajim.

  657. moparisthebest

    and that brings things like "sorry our main server is so slow please move to another server"

  658. CognitiveDissonance

    gotta go though

  659. CognitiveDissonance has left

  660. 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.

  661. antranigv has joined

  662. 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/

  663. Kev

    That does *heavily* depend on your traffic model, mind.

  664. 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.

  665. Lance has joined

  666. moparisthebest

    sure it's just nice to know it *can*

  667. xecks has joined

  668. 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.

  669. Kev

    Or one line of Perl.

  670. 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

  671. Zash

    or one looooooooong line of sed ;)

  672. 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

  673. rion has joined

  674. 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.

  675. antranigv has left

  676. antranigv has joined

  677. raghavgururajan whispers LISP

  678. moparisthebest

    (that was a jab at matrix by the way)

  679. raghavgururajan


  680. alameyo has left

  681. alameyo has joined

  682. raghavgururajan

    *ignore the ?

  683. antranigv has left

  684. 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

  685. Kev

    They have a much less complex ecosystem than we have.

  686. Kev

    And that page is already looking pretty complex.

  687. Zash

    Kev: ORLY?

  688. Kev


  689. Kev

    I really need to fix that bug.

  690. 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

  691. 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.

  692. Zash


  693. Zash

    Kev: Oh boy, let me tell you about Grid, the Matrix (protocol) fork (IIRC).

  694. Kev

    So I'm just wrong. Fair enough.

  695. Zash

    Kev: But yeah. It's probably comparable to back when Jabber Inc was a thing.

  696. Kev

    Jabber Inc was never the JSF, though.

  697. Zash

    Similar but different 🤷

  698. Kev


  699. werdan has joined

  700. paul has joined

  701. neshtaxmpp has left

  702. Steve Kille has left

  703. xecks has left

  704. Steve Kille has joined

  705. Lance has left

  706. xecks has joined

  707. krauq has left

  708. krauq has joined

  709. neshtaxmpp has joined

  710. 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.

  711. MattJ

    Er, wrong chat but not I guess

  712. matkor has left

  713. Zash

    Sure would be nice to have that nicer clients.html

  714. Kev

    Be nice to have nicer clients first :D

  715. 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)

  716. wurstsalat

    Zash, very much +1

  717. matkor has joined

  718. 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?

  719. Kev

    I've no idea which room this is referring to.

  720. Kev

    But it is certainly true that XMPP clients on Mac tend to be precompiled.

  721. Zash

    Kev: IETF list

  722. dwd

    Kev, MattJ's quote is from a mail by Ted Lemon on ietf-disgust

  723. Kev

    Ah, ta.

  724. Andrzej

    BeagleIM is for macOS and is distributed in binary form but if you wish you can compile it yourself

  725. eta

    Zash, wait, what do you know about grid

  726. Zash


  727. 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.

  728. Zash

    eta: I know someone wrote a long rant about how insecure Matrix is, then went on to make their own fork of it.

  729. jonas’

    dwd, typo? :D

  730. eta

    Zash, yeah, Max

  731. sonny has left

  732. sonny has joined

  733. Lance has joined

  734. pasdesushi has joined

  735. sonny has left

  736. Half-Shot has left

  737. uhoreg has left

  738. Rixon 👁🗨 has left

  739. neshtaxmpp has left

  740. Half-Shot has joined

  741. Rixon 👁🗨 has joined

  742. uhoreg has joined

  743. sonny has joined

  744. andrey.g has left

  745. sonny has left

  746. sonny has joined

  747. floretta has left

  748. DebXWoody has joined

  749. sonny has left

  750. neshtaxmpp has joined

  751. winfried has left

  752. winfried has joined

  753. sonny has joined

  754. sonny has left

  755. floretta has joined

  756. mukt2 has joined

  757. DebXWoody has left

  758. pasdesushi has left

  759. sonny has joined

  760. mukt2 has left

  761. mukt2 has joined

  762. arc has left

  763. arc has joined

  764. sonny has left

  765. sonny has joined

  766. sonny has left

  767. krauq has left

  768. krauq has joined

  769. DebXWoody has joined

  770. j.r has left

  771. mukt2 has left

  772. neshtaxmpp has left

  773. j.r has joined

  774. moparisthebest

    hrm since when was XMPP considered part of the #Fediverse ?

  775. Zash

    https://the-federation.info/ lists XMPP, ergo XMPP is part of the Fediverse.

  776. moparisthebest

    yep that's where I noticed

  777. Zash

    Now proceed to accept this circular logic as truth. Thank you!

  778. moparisthebest

    I thought Fediverse was just ActivityPub based stuff TIL

  779. Zash

    I thought it dated back to OStatus, but I'm not so sure.

  780. xecks has left

  781. xecks has joined

  782. krauq has left

  783. krauq has joined

  784. sonny has joined

  785. adityaborikar has left

  786. Andrzej has left

  787. j.r has left

  788. sonny has left

  789. Nano4BeingYou has joined

  790. neshtaxmpp has joined

  791. pasdesushi has joined

  792. debacle has left

  793. Andrzej has joined

  794. antranigv has joined

  795. arc has left

  796. arc has joined

  797. pasdesushi has left

  798. lovetox has left

  799. j.r has joined

  800. sonny has joined

  801. Nekit has left

  802. Nekit has joined

  803. pasdesushi has joined

  804. sonny has left

  805. sonny has joined

  806. pasdesushi has left

  807. vanitasvitae

    I think it depends how you define the Fediverse

  808. vanitasvitae

    Diaspora is also considered part of it and doesn't do AP either

  809. vanitasvitae

    So XMPP fits the definition of being federated and being able to do social networking

  810. Zash

    Is Email part of the Fediverse? :D

  811. moparisthebest

    if XMPP is then I'd have to argue SMTP is too

  812. sonny has left

  813. debacle has joined

  814. rion has left

  815. antranigv has left

  816. sonny has joined

  817. sonny has left

  818. neshtaxmpp has left

  819. lovetox has joined

  820. Shell

    there is social networking stuff built on XMPP, it's probably fediverse

  821. dwd

    moparisthebest, EMail used to be before Google took it over...

  822. sonny has joined

  823. sonny has left

  824. andrey.g has joined

  825. Andrzej has left

  826. pasdesushi has joined

  827. pasdesushi has left

  828. pasdesushi has joined

  829. pasdesushi has left

  830. lovetox has left

  831. andrey.g has left

  832. arc has left

  833. arc has joined

  834. pasdesushi has joined

  835. Andrzej has joined

  836. mukt2 has joined

  837. pasdesushi has left

  838. pasdesushi has joined

  839. j.r has left

  840. j.r has joined

  841. pasdesushi has left

  842. pasdesushi has joined

  843. DebXWoody has left

  844. pasdesushi has left

  845. krauq has left

  846. mukt2 has left

  847. kuvoh has joined

  848. Andrzej has left

  849. krauq has joined

  850. sonny has joined

  851. kuvoh has left

  852. Yagiza has left

  853. Andrzej has joined

  854. Wojtek has left

  855. Wojtek has joined

  856. Nano4BeingYou has left

  857. raghavgururajan

    Zash: Is there a homepage for Grid?

  858. raghavgururajan could find via searx

  859. sonny has left

  860. Alex has left

  861. raghavgururajan

    moparisthebest: Yes, SMTP and XMPP are fedearted protocols.

  862. moparisthebest

    yea I knew that, just not that every federated protocol was considered part of the "fediverse"

  863. Andrzej has left

  864. sonny has joined

  865. karoshi has left

  866. antranigv has joined

  867. dwd

    Please tell me they have usenet in there.

  868. Zash

    usenet distributed, not federated!!!!!!!eleven

  869. karoshi has joined

  870. sonny has left

  871. antranigv has left

  872. moparisthebest

    a ton I've never heard of but no usenet https://the-federation.info/#protocols

  873. pasdesushi has joined

  874. pasdesushi has left

  875. pasdesushi has joined

  876. moparisthebest

    zot? dfrn? all have more servers than the pitiful 53 XMPP servers and the 1 SMTP server

  877. moparisthebest

    strangely, not gmail.com

  878. dwd

    Zash, I don't think it described itself as federated - but nor did email.

  879. Zash

    possibly relevant xkcd https://xkcd.com/802/

  880. dwd

    Zash, But you can post a message to any NNTP server and it ends up on all of them somehow, right?

  881. Zash

    dwd: Just like Matrix!

  882. 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

  883. sonny has joined

  884. pasdesushi has left

  885. Maranda

    To me it looks like a "much spinning" site

  886. sonny has left

  887. Andrzej has joined

  888. Zash

    Maranda: https://www.youtube.com/watch?v=ldK1gQSSTSo

  889. Maranda


  890. Mikaela has left

  891. Maranda has left

  892. jcbrand has left

  893. Maranda has joined

  894. adityaborikar has joined

  895. pasis has left

  896. Kev

    dwd: You know I'm interested in MAM-FC too ;)

  897. Zash

    dwd, Kev: Have you seen https://gist.github.com/mar-v-in/8a9a578d2137a0196744a32abf6aa0eb/ ?

  898. Kev

    If that's the same as the old mailing list post that suggested we must not know what we're talking about, yes.

  899. Zash

    I don't know about that

  900. 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.

  901. Kev

    I might misremember, or it might be a different post. Will see if I can read it tomorr.w

  902. Andrzej has left

  903. arc has left

  904. arc has joined

  905. sonny has joined

  906. arc has left

  907. arc has joined

  908. sonny has left

  909. mukt2 has joined

  910. arc has left

  911. arc has joined

  912. pasdesushi has joined

  913. werdan has left

  914. LNJ has left

  915. arc has left

  916. arc has joined

  917. pasdesushi has left

  918. alameyo has left

  919. alameyo has joined

  920. dwd

    No, this one just says it's badly written, and was proibably written solely to prove him wrong.

  921. pasdesushi has joined

  922. pasdesushi has left

  923. 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.

  924. sonny has joined

  925. karoshi has left

  926. sonny has left

  927. sonny has joined

  928. arc has left

  929. xecks has left

  930. Andrzej has joined

  931. Andrzej has left

  932. debacle has left

  933. j.r has left

  934. j.r has joined

  935. arc has joined

  936. Andrzej has joined

  937. alameyo has left

  938. alameyo has joined

  939. 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.

  940. paul has left

  941. deuill has joined

  942. adityaborikar has left

  943. moparisthebest

    Kev: speaking of misunderstandings another reminder for the xep-0001 update :)

  944. Zash has left

  945. Zash has joined

  946. Zash has left

  947. Zash has joined

  948. Zash has left

  949. eevvoor has left

  950. deuill has left

  951. winfried has left

  952. winfried has joined

  953. Zash has joined

  954. Andrzej has left

  955. mimi89999 has left

  956. mimi89999 has joined

  957. j.r has left

  958. j.r has joined

  959. Andrzej has joined

  960. j.r has left

  961. j.r has joined

  962. papatutuwawa has left

  963. papatutuwawa has joined

  964. adityaborikar has joined

  965. arc has left

  966. arc has joined

  967. Wojtek has left