XSF Discussion - 2019-08-13


  1. madhur.garg has left

  2. pdurbin has left

  3. madhur.garg has joined

  4. madhur.garg has left

  5. madhur.garg has joined

  6. madhur.garg has left

  7. madhur.garg has joined

  8. madhur.garg has left

  9. karoshi has left

  10. madhur.garg has joined

  11. madhur.garg has left

  12. madhur.garg has joined

  13. madhur.garg has left

  14. madhur.garg has joined

  15. madhur.garg has left

  16. madhur.garg has joined

  17. madhur.garg has left

  18. madhur.garg has joined

  19. madhur.garg has left

  20. madhur.garg has joined

  21. madhur.garg has left

  22. valo has joined

  23. madhur.garg has joined

  24. madhur.garg has left

  25. madhur.garg has joined

  26. madhur.garg has left

  27. madhur.garg has joined

  28. madhur.garg has left

  29. madhur.garg has joined

  30. madhur.garg has left

  31. madhur.garg has joined

  32. madhur.garg has left

  33. madhur.garg has joined

  34. madhur.garg has left

  35. madhur.garg has joined

  36. madhur.garg has left

  37. madhur.garg has joined

  38. madhur.garg has left

  39. madhur.garg has joined

  40. madhur.garg has left

  41. madhur.garg has joined

  42. madhur.garg has left

  43. madhur.garg has joined

  44. madhur.garg has left

  45. madhur.garg has joined

  46. madhur.garg has left

  47. madhur.garg has joined

  48. madhur.garg has left

  49. madhur.garg has joined

  50. madhur.garg has left

  51. madhur.garg has joined

  52. madhur.garg has left

  53. madhur.garg has joined

  54. lumi has left

  55. pdurbin has joined

  56. neshtaxmpp has left

  57. neshtaxmpp has joined

  58. pdurbin has left

  59. pdurbin has joined

  60. adityaborikar has joined

  61. adityaborikar has left

  62. adityaborikar has joined

  63. Yagiza has joined

  64. neshtaxmpp has left

  65. neshtaxmpp has joined

  66. neshtaxmpp has left

  67. neshtaxmpp has joined

  68. pdurbin has left

  69. LNJ has left

  70. LNJ has joined

  71. adityaborikar has left

  72. Tobias has joined

  73. jubalh has joined

  74. adityaborikar has joined

  75. andy has joined

  76. Nekit has joined

  77. andy has left

  78. sezuan has joined

  79. sezuan has left

  80. sezuan has joined

  81. sezuan has left

  82. sezuan has joined

  83. karoshi has joined

  84. sezuan has left

  85. sezuan has joined

  86. sezuan has left

  87. sezuan has joined

  88. sezuan has left

  89. sezuan has joined

  90. sezuan has left

  91. sezuan has joined

  92. sezuan has left

  93. sezuan has joined

  94. sezuan has left

  95. sezuan has joined

  96. sezuan has left

  97. sezuan has joined

  98. sezuan has left

  99. sezuan has joined

  100. jubalh has left

  101. j.r has joined

  102. pdurbin has joined

  103. rion has left

  104. rion has joined

  105. goffi has joined

  106. wurstsalat has joined

  107. sezuan has left

  108. jcbrand has joined

  109. pdurbin has left

  110. j.r has left

  111. andy has joined

  112. j.r has joined

  113. j.r has left

  114. larma has left

  115. SaltyBones has left

  116. j.r has joined

  117. larma has joined

  118. sezuan has joined

  119. Mikaela has joined

  120. COM8 has joined

  121. COM8 has left

  122. COM8 has joined

  123. COM8 has left

  124. COM8 has joined

  125. COM8 has left

  126. COM8 has joined

  127. COM8 has left

  128. pdurbin has joined

  129. LNJ has left

  130. LNJ has joined

  131. rion has left

  132. rion has joined

  133. pdurbin has left

  134. nyco has joined

  135. Mikaela has left

  136. Mikaela has joined

  137. nyco has left

  138. rion has left

  139. rion has joined

  140. remko has joined

  141. andy has left

  142. andy has joined

  143. lskdjf has joined

  144. COM8 has joined

  145. Daniel has left

  146. Daniel has joined

  147. COM8 has left

  148. alameyo has left

  149. Guus has left

  150. Guus has joined

  151. alameyo has joined

  152. valo has left

  153. valo has joined

  154. andy has left

  155. andy has joined

  156. COM8 has joined

  157. COM8 has left

  158. COM8 has joined

  159. COM8 has left

  160. Guus has left

  161. Guus has joined

  162. alameyo has left

  163. alameyo has joined

  164. Dele (Mobile) has joined

  165. Dele (Mobile) has left

  166. alameyo has left

  167. Nekit has left

  168. pdurbin has joined

  169. mr.fister has left

  170. mr.fister has joined

  171. Nekit has joined

  172. pdurbin has left

  173. lumi has joined

  174. COM8 has joined

  175. COM8 has left

  176. debacle has joined

  177. COM8 has joined

  178. COM8 has left

  179. adityaborikar has left

  180. adityaborikar has joined

  181. COM8 has joined

  182. COM8 has left

  183. alameyo has joined

  184. alameyo has left

  185. alameyo has joined

  186. alameyo has left

  187. alameyo has joined

  188. alameyo has left

  189. alameyo has joined

  190. alameyo has left

  191. COM8 has joined

  192. COM8 has left

  193. pdurbin has joined

  194. alameyo has joined

  195. COM8 has joined

  196. COM8 has left

  197. pdurbin has left

  198. karoshi has left

  199. COM8 has joined

  200. COM8 has left

  201. Zash has left

  202. Zash has joined

  203. karoshi has joined

  204. matlag has left

  205. matlag has joined

  206. Zash has left

  207. Zash has joined

  208. murabito has left

  209. Daniel has left

  210. Daniel has joined

  211. Ge0rG

    pep.: what's the rationale for https://github.com/xsf/xeps/pull/805

  212. adityaborikar has left

  213. adityaborikar has joined

  214. Daniel has left

  215. Daniel has joined

  216. Zash has left

  217. karoshi has left

  218. karoshi has joined

  219. murabito has joined

  220. Zash has joined

  221. pdurbin has joined

  222. Nekit has left

  223. ralphm

    Ge0rG: the idea was as follows:

  224. pdurbin has left

  225. ralphm

    The way you discover support for RSM now, you can't tell if it is the pubsub service that supports RSM or Disco Items requests.

  226. Ge0rG

    Yes.

  227. Ge0rG

    Ah, and `pubsub#rsm` is to tell that this is RSM on top of pubsub.

  228. jonasโ€™

    exactly

  229. Syndace has left

  230. Ge0rG

    so the other one will be `http://jabber.org/protocol/disco#items#rsm`

  231. Ge0rG

    and then `http://jabber.org/protocol/disco#items#rsm#order_by`?

  232. ralphm

    XEP-0059 explicitly writes: โ€œNote: Even if a responding entity understands the result set management protocol, its support for result set management in the context of any given "using protocol" is OPTIONAL (e.g., an implementation could support it in the context of the 'jabber:iq:search' namespace but not in the context of the 'http://jabber.org/protocol/disco#items' namespace). Currently the only way for a requesting entity to determine if a responding entity supports result set management in the context of a given "using protocol" is to include result set management extensions in its request. If the responding entity does not include result set management extensions in its response, then the requesting entity SHOULD NOT include such extensions in future requests wrapped by the "using protocol" namespace.โ€

  233. Ge0rG

    So that section should be rewritten in terms of adding a `${otherprotocol}#rsm` feature.

  234. ralphm

    So there was a bit of discussion on how to attempt to fix this, and providing an explicit disco feature for RSM-within-pubsub was the easiest I could come up with.

  235. ralphm

    Other suggestions included subfeatures.

  236. Ge0rG

    ralphm: Yes, I was aware of that one, at least ;)

  237. Syndace has joined

  238. ralphm

    I think that'd be overengineering.

  239. ralphm

    I am also not sure if the current suboptimal way of discovering support by a "using protocol" is much of an issue in practice.

  240. Nekit has joined

  241. Ge0rG

    Technically, the proposed syntax is also a kind of sub-feature, but without an explicit structure.

  242. Ge0rG

    I have no idea of that.

  243. ralphm

    Ge0rG: indeed, less invasive.

  244. Ge0rG

    There is probably a break-even point on the required bytes somewhere.

  245. Ge0rG

    But the overhead of introducing actual sub-features in the XML schema dwarfs it all

  246. ralphm

    Well, I'd be more concerned in complexity.

  247. madhur.garg has left

  248. Ge0rG

    complexity is part of that overhead.

  249. ralphm

    yes

  250. ralphm

    I meant compared to byte-count.

  251. ralphm

    The PR mentions MAM vs. PubSub. That might be a better contrast.

  252. Zash

    MAM requires RSM tho, so RSM support would be implied

  253. ralphm

    Especially for MIX. Although MAM requires RSM.

  254. Ge0rG

    with MIX you end up having disco#items again.

  255. ralphm

    Right, so having http://jabber.org/protocol/disco#rsm and http://jabber.org/protocol/pubsub#rsm might be good enough here.

  256. Ge0rG

    http://jabber.org/protocol/disco#items#rsm

  257. ralphm

    Well, I'd do my suggestion.

  258. j.r has left

  259. j.r has joined

  260. ralphm

    It doesn't make any sense for info anyway.

  261. ralphm

    Also, having # show up twice is not great, IMO.

  262. Zash

    #items+rsm ? ๐Ÿ™‚

  263. ralphm

    In any case it is a bit of an optimization. I think collection nodes are rare in practice, so retrieving items from the root node is as well.

  264. ralphm

    And if you retrieve a node's info you could still see the rsm feature on it, maybe.

  265. ralphm

    Also, if you just try it, then you can cache that support.

  266. Nekit has left

  267. Nekit has joined

  268. ralphm

    (hence my original question of it actually being needed)

  269. Zash

    Hmmmm, I think someone mentioned having the server send caps hash of known local services, components etc at some early point. Did something come of that?

  270. Ge0rG

    I'd also prefer a "+" over a "#"

  271. Ge0rG

    but if this isn't bikeshedding, then nothing is.

  272. Kev

    โž• maybe?

  273. Kev

    :p

  274. Ge0rG

    Kev: there are very very many Emoji where you are coming from.

  275. madhur.garg has joined

  276. Zash

    It hints more at the combination than #, but yeah, the bike shed should be painted $(shuf -n 1 < colors.txt)

  277. Guus

    et tu brute

  278. Kev reacts to Ge0rG's message > Kev: there are very very many Emoji where you are coming from. with a ๐Ÿ˜ฎ

  279. j.r has left

  280. Ge0rG

    Kev: I'm not sure why you think you are funny.

  281. Kev

    It's not meant to be funny.

  282. ralphm

    I'm sticking with my suggestions for consistency with existing features for the respective protocols.

  283. Kev

    I'm hoping over time it'll piss everyone off enough that they decide fallback is a bad idea.

  284. ralphm

    Kev: can you send another one?

  285. Ge0rG

    Kev: in that case you should use a realistic fallback

  286. valo has left

  287. Ge0rG

    Kev: but I suppose you aren't because then people, including you, might realize that it's useful after all.

  288. Zash

    Wait, fallback? What context did I miss?

  289. ralphm

    Fallback for reactions.

  290. Ge0rG

    Kev: I've also had a nice chat with the authors of Reactions last weekend, and they were very sad because of the unclear perspectives for "a way to reference messages". As they understood Sam, he disagrees with attach-to being usable for reactions, because reactions are combining multiple reactions from different people, which attach-to isn't meant to do. References obviously isn't fit for the use case and it will take an unknown time to make it fit, and even if they use attach-to now, having to migrate from attach-to to some other official message-referencing scheme in a timeframe of the next five years doesn't look very attractive compared to implementing the custom reactions reference scheme now and to migrate from it to whatever Council will make The Right Thing Some Day In The Future.

  291. Ge0rG

    I hope that this was an accurate summary.

  292. Kev

    Well, I did offer to write some prose, back when I had a few more cycles, but the offer was ignored AFAICR.

  293. Ge0rG

    Kev: this is a very generic statement. Are you speaking of your message in the Message Reactions thread on standards?

  294. ralphm

    I still have to read the whole thread (vacation), but had assumed it would be related to References.

  295. Ge0rG

    ralphm: it is.

  296. valo has joined

  297. ralphm

    Ge0rG: but doesn't use the References protocol, right?

  298. Ge0rG

    I think that semantically, Reactions are very much attach-to, and Receipts are more-or-less attach-to, and LMC are not attach-to at all.

  299. Ge0rG

    ralphm: because there is no References protocol to... you know... reference messages.

  300. ralphm

    If you say that XEP-0372 needs work, then I agree.

  301. Ge0rG

    ralphm: I think that it's too ambitious to ever become useful.

  302. ralphm

    Other issues are handling these various things in archives and summary counts, as also discussed at the summit.

  303. adityaborikar has left

  304. adityaborikar has joined

  305. ralphm

    Ge0rG: if we want to figure out how to do Slack-style reactions, people references, URL references (including retreive and display a card?), edits, as well as receipts, then it makes sense to compare all of them.

  306. Ge0rG

    it would be awesome if the XSF had some kind of "General Direction of the Protocol Development" whitepaper

  307. wurstsalat has left

  308. wurstsalat has joined

  309. Ge0rG

    ralphm: but does it make sense to use the same mechanism for all of them?

  310. Ge0rG

    and if it does, who is going to define that mechanism, and when?

  311. Ge0rG

    and what do we do with proto-XEPs that need some kind of referencing mechanism until we got that sorted out?

  312. ralphm

    Well, I am offering to help make a consistent proposal. It would be good to have one or two people join me, similar to how, e.g., pubsub was hashed out eventually.

  313. Zash

    Ge0rG, like a vision statement?

  314. Ge0rG

    Zash: yes!

  315. ralphm

    Ge0rG: to me, you should accept proto XEPs in the usual sense of 'yeah, we need something like this'.

  316. Ge0rG

    Zash: a very high-level one, with things like "Thin clients, smart servers", and a low-level one, with things like "use 0372 if you want to reference one message from another"

  317. ralphm

    There's been some discussion on having an XSF Roadmap. Having this on it would make sense, but I think defining a Roadmap should be a concerted effort between Board and Council.

  318. Zash

    Ge0rG, a high level vision statement and a low level compliance suite?

  319. Ge0rG

    Zash: the compliance suite is for those who implement, not for those who write XEPs

  320. Ge0rG

    a low-level technical design vision for XEP authors

  321. Ge0rG

    ralphm: yes.

  322. ralphm

    Other approaches previously have been setting up SIGs, where the goal was something like "figure out Jingle".

  323. Zash

    https://xmpp.org/extensions/xep-0134.html and https://xmpp.org/extensions/xep-0143.html exist

  324. rion has left

  325. Ge0rG

    ralphm: I fully agree that we need a concerted effort from Board and Council.

  326. Ge0rG

    Zash: 0134 is kind of the high-level vision statement.

  327. ralphm

    I think those XEPs are great, but they don't give direction on what kind of features we'd like to see developed.

  328. ralphm

    Just when you are, how to go about it.

  329. ralphm

    And has been a bit of a rough spot forever. We've usually acted on stuff being submitted. Council generally doesn't *drive* protocol development.

  330. Zash

    Yeah, a coherent vision for the future would be nice

  331. Nekit has left

  332. Zash

    Tricky to do in a understaffed volonteer organization tho

  333. ralphm

    Indeed.

  334. Nekit has joined

  335. ralphm

    And this is not unique to the XSF.

  336. Zash

    Maybe not quite the thing a standards org does

  337. ralphm

    This is why the IETF has WGs, W3C caused WHATWG, etc.

  338. j.r has joined

  339. ralphm

    I see many areas that would need benefit from a concerted effort, probably initially by a small set of people: richer messaging (as above), voice/video calling in dynamic multi-client situations (read mobile clients going to sleep), MIX.

  340. ralphm

    -need

  341. Kev

    re: references, there's two types of references, both of which were meant to be in the References XEP. There's where you make a message reference a thing, and where you reference a message to add additional data. It still kinda makes sense to me to have them together, but it is not a hill for me to die on at all to split the two things out.

  342. Kev

    Other than that the name is misleading, I don't see why 367 couldn't solve the second case generically - reactions, corrections, etc.

  343. Kev

    And one of the things that 367 might do is to attach a Reference, so e.g. a server could annotate a message to say "This message is about This Thing (e.g. a server prefetching image URLs for previewing)"

  344. ralphm

    Nod

  345. ralphm

    That also helps with the goal of composition

  346. Kev

    And archive cleverness.

  347. ralphm

    Yes

  348. j.r has left

  349. ralphm

    Then we should also have mims depend on that instead of references, maybe.

  350. Kev

    mims?

  351. ralphm

    Sims

  352. ralphm

    XEP-0385

  353. Ge0rG

    Kev: one issue with 0367 is that conceptually, we'd have to stuff the payload inside of the attach-to element, not side by side with it. Otherwise, you can't distinguish which reference is which in a corrected reaction

  354. ralphm

    Huh?

  355. Kev

    Ge0rG: I would expect that the thing that's being attached/updated with would be inside the attach-to (although possibly updating 367 to not call it attach-to would make sense).

  356. Kev

    Although for un-reacting, I think pushing an unattach type thing makes much more sense than correcting.

  357. ralphm

    Slightly relatedly, I eventually want more broad edits, not just last message

  358. Kev

    ralphm: Indeed.

  359. Ge0rG

    Kev: if you unattach a message, it becomes stand alone? That doesn't make much sense

  360. Ge0rG

    At least not for reactions

  361. Kev

    No, it negates the reaction.

  362. ralphm

    I think you'd want some generic retraction indicator

  363. Ge0rG

    ralphm: I've always wondered who added that pointless restriction to the XEP ๐Ÿ˜‰

  364. Kev

    <attach-to id><reaction>๐Ÿ’ฏ</></> <unattach id><reaction>๐Ÿ’ฏ</></>

  365. ralphm

    So a message that has unattach is treated as no longer valid at all?

  366. Ge0rG

    Wait, that would be a delta protocol on a sub message base. Can we please avoid that?

  367. Kev

    Ge0rG: We'll have that anyway.

  368. Kev

    ralphm: The message containing <unnattach>'s only purpose would be to undo a previous attach.

  369. Ge0rG

    Kev: but you don't want to undo the attaching, you want to remove the payload.

  370. j.r has joined

  371. Kev

    s/unattach/remove-attachment/, then. The stanza name isn't particularly important to me.

  372. Ge0rG

    Which is much like replacing the old payload with a new, empty, one.

  373. Ge0rG

    You could technically use LMC to remove a message by updating it with an empty one.

  374. Kev

    Well, this is attaching things to a stanza, it's not updating the stanza per say. So I think unattaching makes sense, but I don't think arguing semantics of the English is particularly useful.

  375. Ge0rG

    Kev: stanza names end up defining the semantics of the protocol.

  376. Kev

    Ge0rG: Yes, that's what I'd like to avoid.

  377. Kev

    (Using LMC for references)

  378. adityaborikar has left

  379. Ge0rG

    For reactions?

  380. Ge0rG

    Kev [17:33]: > Ge0rG: Yes, that's what I'd like to avoid. The question is, why?

  381. Kev

    Because it requires tracking not just the data, but also the transport of the data, which is just another layer of indirection we're not going to want in the archive.

  382. Kev

    And similarly, it means that on the sender side we have to track how we sent out each datum, rather than just the data that were sent.

  383. Kev

    (And track that across clients)

  384. wurstsalat has left

  385. Ge0rG

    Kev: so you are saying, we should be able to change a reaction to a message without knowing the ID of the previous reaction, if any?

  386. wurstsalat has joined

  387. Kev

    Yes.

  388. Ge0rG

    our archive and everything around our transport is designed around individual messages. I'm not sure we want to change _that_

  389. Ge0rG

    Kev: this is what the current reactions XEP already covers.

  390. Ge0rG

    proto-XEP, of course.

  391. Kev

    It's 367 (or whatever we use as the wrapper) that needs it.

  392. Ge0rG

    But how are you going to resolve that with non-attached messages?

  393. wurstsalat has left

  394. wurstsalat has joined

  395. Ge0rG

    It's obvious for "This is a change of the reaction to message X" vs. "This is a correction of reaction Y (which was attached to X, but I don't need to say)"

  396. Ge0rG

    What if you want to attach multiple different things to X?

  397. adityaborikar has joined

  398. Ge0rG

    How do I know which one you unattach. Are you saying that I need to compare all the payloads and remove the closest match?

  399. pdurbin has joined

  400. Kev

    Well, compare the exact match, yes.

  401. Ge0rG

    How is that a better design than comparing the UUID of the last attachment?

  402. Ge0rG

    What if your unattach removes a payload that I haven't yet seen being added, and the add comes later from MAM?

  403. sezuan has left

  404. Kev

    You'd be able to ignore the unattach for anything you're not rendering, and when you get the message from the archive you'd also get the attachment summary.

  405. Ge0rG

    so you are speaking about a forklift protocol upgrade

  406. Ge0rG

    (I'm just trying to understand the rationale here)

  407. Ge0rG

    I mean, our messages and their related things become more and more of an implicit DAG with different kinds of edges.

  408. Ge0rG

    But I can't see how referencing earlier content by its content is going to help.

  409. Ge0rG

    I'm all in for making the DAG relationships all explicit and based on the same foundation.

  410. Ge0rG

    And then we have message threads, which are also a DAG, which is maybe strictly orthogonal ;)

  411. Lance has joined

  412. Ge0rG

    Is there even such a thing like orthogonality between DAGs?

  413. Kev

    I'm not sure threads are orthogonal.

  414. Kev

    I was thinking about this yesterday(?), and maybe they're just references.

  415. Ge0rG

    Maybe.

  416. Kev

    Or attachments :)

  417. lovetox has joined

  418. Ge0rG

    Ever used Microsoft Teams?

  419. Kev

    I think they're definitely not <thread/>, at least.

  420. Kev

    I haven't, similar to Slack/Discord?

  421. Ge0rG

    Kind of, but it's very slow, and it has explicit thread rendering, and the UX for threads isn't actually too bad, because there is an input box under _each_ message, and then what you type is rendered in that place of the thread

  422. Ge0rG

    no idea if threads are also reordered by recentness.

  423. Nekit has left

  424. Nekit has joined

  425. Ge0rG

    Because the other parts of it were so unbearable that I dropped it almost immediately.

  426. Kev

    Different from Slack then, with Slack (last I tried), you kinda promote a message into a thread.

  427. Ge0rG

    The thread UX of Slack is just horrible.

  428. Ge0rG

    Nobody I've met was actually using it.

  429. Ge0rG

    Anyway, back to our DAGs.

  430. Kev

    It's still useful, but you have to suffer through it rather than it supporting you.

  431. MattJ

    Let me introduce you to places that not only use it, but enforce it

  432. MattJ

    (or try to)

  433. Kev

    Please don't.

  434. Ge0rG

    If a thread is a DAG, and all the non-text things that belong to a message (receipts, reactions, etc) are a DAG, does it really make sense to merge those DAGs?

  435. Ge0rG

    in other words: if you fetch a message from MAM, do you want the whole thread, with all reactions? only the parent branch? nothing?

  436. Kev

    I'm not sure that I necessarily buy that threads are necessarily a(n unspecialised) DAG.

  437. Kev

    But that aside, the fetching from MAM+ does make using the same mechanism for threads and other attachments potentially sticky.

  438. Ge0rG

    Kev: how would you model threads?

  439. pdurbin has left

  440. Ge0rG

    (this whole discussion is probably moot anyway, because nobody wants threads)

  441. Ge0rG

    Kev: "potentially sticky"?

  442. Kev

    Probably a bad idea.

  443. ralphm

    One might want to do a MAM query on a specific thread. Otherwise I'd just threat it as just another attribute.

  444. Ge0rG

    so now we need a new edge attribute "should be included in MAM+ responses"

  445. Ge0rG

    or maybe two: "parent should be included in MAM+ responses" and "child should be included in MAM+ responses"

  446. Zash

    This hurts my brain.

  447. Ge0rG

    because an emoji reaction should obviously be returned when you query for the parent message.

  448. ralphm

    Zash: this stuff is not easy

  449. Ge0rG

    "sacrifice a child to proceed fetching MAM"

  450. Zash

    Infinite whiteboard required

  451. Ge0rG

    Zash: the infinite whiteboard is a DAG

  452. Ge0rG

    unless you draw circles.

  453. Kev

    The reactions aren't really a DAG, though.

  454. ralphm

    Ge0rG: well, at FOSDEM we discussed having summaries (counts) and having reactions as a dimension

  455. Zash

    11-dimentional whiteboard for drawing DAGs

  456. Kev

    As ralphm says.

  457. Zash

    Array of map of array of maps in seven dimentions?

  458. Ge0rG

    ralphm: I vaguely remember that, yeah.

  459. Ge0rG

    Kev: if you allow changing reactions, they become a DAG

  460. Ge0rG

    Kev: you might remember my fierce argumentation for allowing LMC to work on a DAG and not as a star.

  461. ralphm

    Why not have edits as a dimension, too?

  462. wojtek has joined

  463. Kev

    Sadly, I need to concentrate on work for a bit.

  464. Ge0rG

    ralphm: ideally, edits should be a one-dimensional linked list.

  465. wojtek has left

  466. ralphm

    I think a MAM archive will eventually need a few dimensions: edits, reactions, other attachments. And then there are summaries. And something we haven't really touched upon yet today: read/received per group participant.

  467. ralphm

    I.e. if you want to have a feature set that is similar to Slack and Whatsapp.

  468. ralphm

    Kev: maybe we should schedule a time to pick this up?

  469. Kev

    Happy to, but I don't have cycles at this minute.

  470. Kev

    I spent more than I probably should have, already.

  471. ralphm

    Zash: dizzy yet?

  472. Yagiza has left

  473. Zash wandered away to make food

  474. Lance has left

  475. j.r has left

  476. rion has joined

  477. j.r has joined

  478. Nekit has left

  479. Nekit has joined

  480. Wojtek has joined

  481. Wojtek has left

  482. alameyo has left

  483. j.r has left

  484. Nekit has left

  485. Chobbes has joined

  486. pdurbin has joined

  487. Chobbes has left

  488. sezuan has joined

  489. pdurbin has left

  490. j.r has joined

  491. UsL has left

  492. Mikaela has left

  493. Mikaela has joined

  494. Mikaela has left

  495. Mikaela has joined

  496. Mikaela has left

  497. Mikaela has joined

  498. valo has left

  499. UsL has joined

  500. Mikaela has left

  501. Mikaela has joined

  502. Mikaela has left

  503. Mikaela has joined

  504. Mikaela has left

  505. valo has joined

  506. Mikaela has joined

  507. Mikaela has left

  508. Mikaela has joined

  509. j.r has left

  510. Mikaela has left

  511. eve has left

  512. Mikaela has joined

  513. Mikaela has left

  514. Mikaela has joined

  515. Mikaela has left

  516. Mikaela has joined

  517. Mikaela has left

  518. Mikaela has joined

  519. wurstsalat has left

  520. Allo has left

  521. Allo has joined

  522. xalek has left

  523. xalek has joined

  524. eve has joined

  525. Wojtek has joined

  526. wurstsalat has joined

  527. adityaborikar has left

  528. adityaborikar has joined

  529. eve has left

  530. eve has joined

  531. j.r has joined

  532. Wojtek has left

  533. david has left

  534. valo has left

  535. sezuan has left

  536. wojtek has joined

  537. Daniel has left

  538. Daniel has joined

  539. Nekit has joined

  540. valo has joined

  541. Daniel has left

  542. Daniel has joined

  543. LNJ has left

  544. LNJ has joined

  545. pdurbin has joined

  546. Tobias has left

  547. david has joined

  548. pdurbin has left

  549. j.r has left

  550. j.r has joined

  551. j.r has left

  552. j.r has joined

  553. Nekit has left

  554. Nekit has joined

  555. andy has left

  556. remko has left

  557. pep.

    > ralphm> In any case it is a bit of an optimization. I think collection nodes are rare in practice, so retrieving items from the root node is as well. Apparently you're not doing pubsub enough

  558. pep.

    Hah, I read "collecting"

  559. pep.

    > Ge0rG> a very high-level one, with things like "Thin clients, smart servers", and a low-level one, with things like "use 0372 if you want to reference one message from another" Careful about the e2ee triad

  560. wojtek has left

  561. ralphm

    pep.: so I can ignore your remark?

  562. pep.

    Kev: the thing with 367 is that what council is trying to turn it into is not what the author intended for it, as I understand it. It'd be great to have a statement from him + change in the XEP, or council saying "fk it, we're taking over" or sth

  563. alameyo has joined

  564. pep.

    ralphm: depends, do you think you're doing enough pubsub already? :p

  565. ralphm

    Apart from being one of the authors of the spec and having things like ikDisplay? Probably not.

  566. ralphm

    pep.: And as for XEP-0367, I understand that issue, but this can go two ways: the consensus is to change the spec to address various concerns as raised today, or someone introduces another, similar spec that comes closer. The problem is that there are so many things coming together here that something has to give.

  567. ralphm

    Maybe I should write an email with the various topics we touched upon today.

  568. pep.

    Do we not already have 32 avatar xeps and 42 bookmark xeps?

  569. pep.

    With conversion xeps

  570. pep.

    I'm sure one more reference xep wouldn't harm

  571. ralphm

    We also had 3 or 4 pubsub specs, 3 service discovery specs, various session initiation approaches.

  572. pep.

    Sure, we can get rid of those that are no use later on

  573. ralphm

    Eventually rough consensus and running code prevails.

  574. ralphm

    And this particular problem domain is hard.

  575. ralphm

    The individual parts might look easy, and hopefully the protocols are going to be simple and composable.

  576. pep.

    In the meantime I think we should give some slack to the reaction protoXEP

  577. pep.

    That's something that they need and they're not gonna wait that we grow rainbows and references XEPs

  578. ralphm

    As I said, I need to read the entire thread still, but the concept of reactions was discussed at the Summit and if I was on council I'd vote for accepting.

  579. ralphm

    And then mold things properly.

  580. pep.

    Yeah

  581. ralphm

    I'm not sure who 'they' are and how their needs need to be addressed, but yeah, standards bodies are not necessarily fast.

  582. valo has left

  583. ralphm

    Most importantly because this is volunteer work and/or work priorities might not align.

  584. j.r has left

  585. pep.

    It very much aligns when somebody has an agenda. We should just try to nerdsnipe the right people

  586. ralphm

    I haven't even heard of the authors and the domain of their collective contact addresses (which is a concern the editors should look into), doesn't yield a website.

  587. pep.

    Haven't heard of the authors?

  588. pep.

    Have you used dino?

  589. ralphm

    No

  590. pep.

    Here you go

  591. ralphm

    It is entirely possible I missed something.

  592. ralphm

    But how should I know that these people are associated with that project?

  593. ralphm

    What is larma.de, for example? I did try to find out, you know?

  594. pep.

    Dunno, I meet them on a regular basis (conferences)

  595. Guus has left

  596. ralphm

    I should attend one, indeed, and meet them.

  597. larma

    Next years summit?

  598. Nekit has left

  599. ralphm

    At least. Did you sign up already?

  600. j.r has joined

  601. larma

    Not yet, but plan to (have to check with work stuff first)

  602. ralphm

    But maybe earlier. .nl isn't that far from .de.

  603. LNJ has left

  604. larma

    I still have CCCamp, Stockholm Sprint and C3 on my list of conferences for this year ๐Ÿ™‚

  605. ralphm

    Gotta sleep now, but will attempt to catch up tomorrow.

  606. Daniel

    i can imagine us doing another sprint in between sweden and ccc though

  607. Daniel

    maybe around november like last year

  608. ralphm

    Maybe Guus, intosi, and I should set something up in the Eindhoven region.

  609. karoshi has left

  610. j.r has left

  611. j.r has joined

  612. fippo has left

  613. lovetox has left

  614. goffi has left

  615. lumi has left

  616. arc has left

  617. Mikaela has left

  618. Mikaela has joined

  619. UsL has left

  620. UsL has joined

  621. pdurbin has joined

  622. mimi89999 has left

  623. mimi89999 has joined

  624. jcbrand has left