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