XSF logo XSF Discussion - 2019-03-11


  1. grumpy has left
  2. dos has joined
  3. vanitasvitae has left
  4. mrDoctorWho has joined
  5. karoshi has left
  6. debacle has left
  7. UsL has joined
  8. mrDoctorWho has left
  9. Lance has left
  10. rtq3 has joined
  11. rtq3 has left
  12. rtq3 has joined
  13. rtq3 has left
  14. rtq3 has joined
  15. Lance has joined
  16. ThibG has left
  17. Lance has left
  18. j.r has left
  19. j.r has joined
  20. contrapunctus has left
  21. contrapunctus has joined
  22. tux has left
  23. rtq3 has left
  24. ThibG has joined
  25. lumi has left
  26. alacer has joined
  27. mrDoctorWho has joined
  28. wurstsalat has left
  29. alacer has left
  30. alacer has joined
  31. tux has joined
  32. pep. has left
  33. moparisthebest has left
  34. moparisthebest has joined
  35. wurstsalat has joined
  36. contrapunctus has left
  37. contrapunctus has joined
  38. contrapunctus has left
  39. contrapunctus has joined
  40. contrapunctus has left
  41. contrapunctus has joined
  42. arc has left
  43. arc has joined
  44. arc has left
  45. arc has joined
  46. contrapunctus has left
  47. contrapunctus has joined
  48. Neustradamus has joined
  49. oli has left
  50. Maranda has joined
  51. Nekit has joined
  52. Maranda has left
  53. ThibG has left
  54. ThibG has joined
  55. blabla has joined
  56. contrapunctus has left
  57. contrapunctus has joined
  58. ThibG has left
  59. ThibG has joined
  60. rion has joined
  61. contrapunctus has left
  62. contrapunctus has joined
  63. contrapunctus has left
  64. contrapunctus has joined
  65. novnov has joined
  66. novnov has left
  67. novnov has joined
  68. novnov has left
  69. oli has joined
  70. contrapunctus has left
  71. contrapunctus has joined
  72. contrapunctus has left
  73. contrapunctus has joined
  74. lnj has joined
  75. contrapunctus has left
  76. contrapunctus has joined
  77. contrapunctus has left
  78. contrapunctus has joined
  79. contrapunctus has left
  80. contrapunctus has joined
  81. oli has left
  82. oli has joined
  83. oli has left
  84. oli has joined
  85. alacer has left
  86. alacer has joined
  87. rtq3 has joined
  88. andy has joined
  89. MattJ has joined
  90. contrapunctus has left
  91. contrapunctus has joined
  92. rtq3 has left
  93. rtq3 has joined
  94. alacer has left
  95. frainz has left
  96. frainz has joined
  97. yon has left
  98. rtq3 has left
  99. rtq3 has joined
  100. vaulor has joined
  101. alacer has joined
  102. karoshi has joined
  103. ralphm has left
  104. ralphm has joined
  105. yon has joined
  106. oli has left
  107. oli has joined
  108. 404.city has joined
  109. alacer has left
  110. ralphm has left
  111. ralphm has joined
  112. benpa has joined
  113. uhoreg has joined
  114. Half-Shot has joined
  115. Matthew has joined
  116. 404.city has left
  117. goffi has joined
  118. oli has left
  119. ralphm has left
  120. ralphm has joined
  121. oli has joined
  122. oli has left
  123. oli has joined
  124. Guus has left
  125. Guus has joined
  126. contrapunctus has left
  127. contrapunctus has joined
  128. Guus has left
  129. mimi89999 has joined
  130. Guus has joined
  131. rtq3 has left
  132. rtq3 has joined
  133. Kev has joined
  134. Andrew Nenakhov has left
  135. Andrew Nenakhov has joined
  136. wurstsalat has left
  137. wurstsalat has joined
  138. Steve Kille has left
  139. alacer has joined
  140. ralphm has left
  141. ralphm has joined
  142. Steve Kille has joined
  143. contrapunctus has left
  144. contrapunctus has joined
  145. Tobias has joined
  146. Holger has joined
  147. Andrew Nenakhov has left
  148. Andrew Nenakhov has joined
  149. oli has left
  150. contrapunctus has left
  151. contrapunctus has joined
  152. Guus has left
  153. Guus has joined
  154. oli has joined
  155. Guus has left
  156. larma has joined
  157. Guus has joined
  158. ralphm has left
  159. ralphm has joined
  160. j.r has left
  161. nyco has joined
  162. contrapunctus has left
  163. contrapunctus has joined
  164. Andrew Nenakhov has left
  165. Andrew Nenakhov has joined
  166. zinid jonas’, hey, I have sent you the protoXEP, I know you're busy, but maybe you will find some time to accept it for the upcoming agenda
  167. debacle has joined
  168. ralphm has left
  169. ralphm has joined
  170. contrapunctus has left
  171. contrapunctus has joined
  172. igoose has left
  173. igoose has joined
  174. alacer has left
  175. contrapunctus has left
  176. Kev has left
  177. contrapunctus has joined
  178. lskdjf has joined
  179. Kev has joined
  180. ralphm has left
  181. ralphm has joined
  182. jonas’ zinid, thanks for the hint
  183. contrapunctus has left
  184. contrapunctus has joined
  185. andrey.g has joined
  186. andrey.g has left
  187. contrapunctus has left
  188. contrapunctus has joined
  189. contrapunctus has left
  190. contrapunctus has joined
  191. contrapunctus has left
  192. contrapunctus has joined
  193. alacer has joined
  194. kokonoe has left
  195. kokonoe has joined
  196. andrey.g has joined
  197. rtq3 has left
  198. Guus has left
  199. Guus has joined
  200. Guus has left
  201. Kev has left
  202. rtq3 has joined
  203. wurstsalat has left
  204. rtq3 has left
  205. larma has left
  206. dele has joined
  207. dele has left
  208. debacle has left
  209. larma has joined
  210. Guus has joined
  211. Kev has joined
  212. alacer has left
  213. j.r has joined
  214. dwd has joined
  215. lorddavidiii has joined
  216. dwd lnj, Is qxmpp your project?
  217. 404.city has joined
  218. oli has left
  219. oli has joined
  220. oli has left
  221. oli has joined
  222. rtq3 has joined
  223. lnj dwd: not its not, but I'm contributing to it
  224. mark has left
  225. mark has joined
  226. Kev has left
  227. dwd lnj, Any idea if the example GUI does MIX at all? I saw the library does.
  228. kokonoe has left
  229. kokonoe has joined
  230. lumi has joined
  231. Zash has left
  232. zinid dwd, are you working at any XMPP projects nowadays?
  233. Kev has joined
  234. dwd zinid, Trying to. :-)
  235. dwd zinid, Both Threads Styling stuff (lots of gatewaying into other IM systems) and Metre. I should be doing Openfire too (although I'm not really sure they need my help right now).
  236. dwd zinid, Current Threads thing is a standalone MIX implementation that I'm then building on to do our gatewaying interface. Hoping to get the MIX bits out as OSS for people to play with.
  237. alacer has joined
  238. Zash has joined
  239. zinid dwd: okay
  240. zinid good to know someone is doing MIX
  241. rtq3 has left
  242. alacer has left
  243. j.r has left
  244. alacer has joined
  245. Guus dwd we just upgraded MINA, and you're wondering if we need your help? 🙂
  246. lnj dwd: I'm working on the MIX implementation in QXmpp, but it's not entirely finished and not all of my pull requests have been merged yet.
  247. lnj But all parsing / serialization of the main xep and xep 405 is working (in the unit tests).
  248. mark has left
  249. mark has joined
  250. dwd Guus, That's what I mean, you clearly don't!
  251. debacle has joined
  252. dwd lnj, Ah, OK. For my purposes, just a real client I can use for exploratory testing would be really helpful.
  253. mark has left
  254. alacer has left
  255. Guus dwd Imply what you want - we're still assigning all issues to you. 🙂
  256. kokonoe has left
  257. kokonoe has joined
  258. Link Mauve has joined
  259. Guus dwd We'd like to welcome you home. Kindly re-auto-join open_chat 🙂
  260. Yagiza has joined
  261. Zash Would you kindly
  262. Guus That'd be as if I'm giving him a choice. Nope. 🙂
  263. Guus We need our glorious leader back!
  264. Guus The fashion industry has stolen him from us!
  265. j.r has joined
  266. lumi has left
  267. Alex has joined
  268. Alex has left
  269. nyco has left
  270. Alex has joined
  271. Alex has left
  272. yon has left
  273. Alex has joined
  274. dwd So - if a XEP-0060 node supports XEP-0313, the archived items are the events sent out? What about retracts when notify is set to false - do these events which don't get sent get archived nonetheless?
  275. ralphm dwd: a retract is not an item, it is the removal of one, so I'm not sure if it is appropriate to store in MAM.
  276. dwd ralphm, What's in MAM then, if not events?
  277. ralphm I.e. if you request items from a pubsub node, you only get items, and if a previously existing item was retracted, it will not be included in the result.
  278. dwd ralphm, Oh, certainly. But if you ask for the Things from MAM, that wouldn't be items, but events? Or what?
  279. ralphm dwd: this is a good question. Either the MAM archive is a record of the notifications (even if they weren't sent?) or it is an archive of items.
  280. ralphm I kinda expected the latter, to be consistent with the pubsub items iq results.
  281. dwd ralphm, I thought it was a good questioin when I asked it.
  282. ralphm It is
  283. ralphm because we also have other notifications
  284. ralphm like node deletion
  285. dwd ralphm, Yes, this is true. Are those also events (as in {http://jabber.org/protocol/pubsub}event)?
  286. pep. has joined
  287. ralphm ``` <xs:element name='event'> <xs:complexType> <xs:choice> <xs:element ref='collection'/> <xs:element ref='configuration'/> <xs:element ref='delete'/> <xs:element ref='items'/> <xs:element ref='purge'/> <xs:element ref='subscription'/> </xs:choice> </xs:complexType> </xs:element> ```
  288. dwd Oh. Gosh. Lots of types I hadn't thought about.
  289. MattJ dwd, FWIW the pubsub stuff in MAM has never delighted me, for reasons like this. I've had a lot of feedback that it should at least be split out, but I haven't had time for that yet.
  290. ralphm And items can include 'item' or 'retract'.
  291. MattJ I don't really understand what it would be expected to return, but I suspect it would have to leave a tombstone for retracted items
  292. dwd MattJ, I would advocate splitting it out if it weren't for the minor point that there seems to be only one sentence of it...
  293. MattJ No, there is more: https://xmpp.org/extensions/xep-0313.html#business-storeret-pubsub-archives
  294. MattJ Oh right, that paragraph is a sentence
  295. MattJ No, two
  296. ralphm Since MIX critically depends on MAM and PubSub, this is something that requires a clear answer.
  297. ThibG has left
  298. ThibG has joined
  299. dwd MattJ, SO that looks as if it's saying that it's the events that are stored, but the only mandatory event is the 'item' event (for publicaiton).
  300. dwd MattJ, One assumes, therefore, that other events might be permissible. If one squints enough.
  301. dwd ralphm, This, incidentally, is why I'm asking the question.
  302. ralphm So really, events with <items><item/></items>
  303. ralphm but with retracted items excluded
  304. dwd ralphm, Yes. Sorry, it seems today everyone has to use very loose parsing on what I'm trying to say...
  305. dwd ralphm, No, it mentions no limitations, just a requirement to include the item publishes.
  306. ralphm MAM in turn also seems to kinda support the notion of messages being removed from an archive, without providing protocol for it.
  307. andy has left
  308. ralphm (section 3.2)
  309. MattJ It definitely doesn't support the notion of messages being *removed*
  310. dwd ralphm, Seems reasonable. I suspect there are a number of use-cases for siilently removing a message from the archive.
  311. ralphm MattJ: second paragraph
  312. dwd MattJ, Blame Kev?
  313. MattJ The second paragraph essentially explains that the entry is still there, but without a payload
  314. ralphm But, reading XEP-313's 5.1.3, I definitely read that as grafting the MAM protocol on top of a pubsub item store and faking it
  315. ralphm I.e. not actually requiring storing events, but constructing them as if sent to a subscriber, wrapped by the envelope.
  316. ralphm Also note that it doesn't allow multiple items in one message, which /is/ ok for actual event notifications.
  317. Maranda has joined
  318. Alex has left
  319. ralphm For what it is worth, I think this is fine.
  320. ralphm The only gap I see is that a client may not ever become aware of the retraction of an item.
  321. ralphm because if it happened to be offline when the notification got sent, and the item is 'emptied' (as MattJ suggests), there will not be a thing representing that deletion in the archive.
  322. ralphm However, on the other hand, the retract event *should* be in the user's own archive, assuming the model where the server manages the users subscription (PAM).
  323. ralphm And given that, it is sufficiently consistent to me.
  324. ralphm I.e. if you were not yet subscribed, retrieving the archive just lacks the retracted items, and is the consolidated state of things.
  325. ralphm (retrieving it from the pubsub node)
  326. ralphm dwd?
  327. dwd processes.
  328. Zash And where did the text about having to return item-not-found for unknown ids in RSM?
  329. Zash And where did the text about having to return item-not-found for unknown ids in RSM come from?
  330. dwd ralphm, No, I think that sucks a bit. Asking a remote source for MAM items should yield the same result as asking your local source filtering for the remote sender. I think.
  331. Guus Was there a DST switchover last weekend?
  332. MattJ US changed, yes
  333. Guus \o/ first time in ... ever ... that I learned about this _before_ being late for a meeting.
  334. intosi has left
  335. intosi has joined
  336. 404.city has left
  337. j.r has left
  338. ralphm dwd: why? The first in this case is the archive of the pubsub node, and the second is the archive of messages sent to you.
  339. ralphm Guus: make sure you tell Arc
  340. Guus arc ^^
  341. j.r has joined
  342. arc Lol
  343. arc It's a DST miracle
  344. dwd (In other news, I think I can make MIX without MIX-PAM work reasonably well, which might make it less of a forklift upgrade)
  345. Zash And EU chickened out of abolishing DST :(
  346. Tobias has left
  347. dwd Zash, It may be the only positive from Brexit.
  348. ralphm dwd: having MAM remember all the possible events sent to users for pubsub nodes is a bit terrible itself. E.g. it would need to record config changes.
  349. ralphm Not even sure about subscription approvals
  350. dwd ralphm, Well sure. But for items, at least, recording old versions of items and retractions seems reasonable.
  351. Guus Zash wait what?
  352. dwd ralphm, Otherwise what's the point of having the archive?
  353. ralphm dwd: why? The semantics of a publish request with the same item id, is that the previous item is obliterated and replaced with the new one.
  354. dwd ralphm, Besides which, it'd mean querying the MAM archive of the messages node of a MIX channel always gave you nothing. Boring.
  355. ralphm If you do an items request, you don't get that either.
  356. Zash Guus: The EU considered abolishing DST changes, but chickened out and didn't give any requirements and "every country could do whatever they want", so it seems nothing changes and we get the stupid DST headache twice a year.
  357. ralphm dwd: why would querying the mam archive of the messages node of a mix channel give you no items?
  358. Guus Zash fwiw, I thought that most countries would still go ahead and change it - although there might not be a uniform choice across Europe (and for those that do stop switching over, it's undecided if they'd go for summer, or winter time.
  359. ralphm dwd: even though the notifications are sent as regular <message/> stanzas with bodies, there's no reason the message archive for the node to not return 'proper' constructed events as with every node.
  360. dwd ralphm, Because it's explicitly defined to not store pubsub items.
  361. ralphm dwd: so that node is transient?
  362. dwd ralphm, See XEP-0369#4.7.2
  363. Zash Guus: So without coordination we might get a worse mess than now.
  364. Guus Zash perhaps
  365. dwd Zash, Same time for any switches that do happen, mind.
  366. Zash Don't most of the EU switch at the same time already?
  367. mark has joined
  368. ralphm dwd: wait, so in that section, which archive is being referred to? The archive of the messages node, or of the channel itself?
  369. dwd ralphm, It doesn't mention an archive there. But your proposal means that querying the archive for the MIX channel gives messages, whereas querying the archive of the messages node of the MIX channel doesn't.
  370. dwd Zash, They do, all, switch at the same time. The UK moved its changeover time, IIRC, by an hour, to match the rest of the EU.
  371. Zash And is mostly in the same timezone (except the uk and finland?)
  372. Zash And what's this about MIX and MAM?
  373. dwd Zash, And Portugal. Not sure about some of Eastern Europe either.
  374. dwd Zash, MIX, MAM, and '60.
  375. dwd Zash, But mostly, what's in a '60 MAM archive.
  376. Zash Don't you get all messages regardless of whether you have online resources?
  377. Zash .. to your account? So you could query them from there?
  378. Zash And without getting a copy per joined resource?
  379. Lance has joined
  380. ralphm dwd: well, I'm not sure if it a proposal, but it is one or the other. Either the messages node is persistent, but sends out notifications as regular messages instead of pubsub events, or it is not a real pubsub node, and subscribing to it just indicates the desire to get the non-event-but-bare-stanzas-with-payload messages.
  381. arc Zash no we get it four or more times a year because different parts of the world switch at different times
  382. Zash I meant within the EU tho
  383. ralphm In the latter case, maybe having the archive be at the channel level, not the nodes it contains. I'm not sure how that interacts with hypothetical 'root node' subscriptions and their MAM archive.
  384. mark has left
  385. mark has joined
  386. Maranda has left
  387. Lance has left
  388. Alex has joined
  389. arc Yea, that kind of thinking is problematic because it spreads. At a tech conferences here in the US, I keep hearing things like "xmpp? Don't they just use that in the EU?"
  390. MattJ No, they also use it in the UK
  391. ralphm Zash: I think you want to scroll back to http://logs.xmpp.org/xsf/2019-03-11#2019-03-11-fb946fc83908ade3
  392. ralphm arc: you could reply with 'Fortnite'.
  393. dwd MattJ, Another 18 days until that works.
  394. arc Adults don't understand fortnight
  395. dwd arc, Eve Online. Origin. NATO.
  396. dwd arc, Actually, your president doesn't understand NATO, at least. :-)
  397. ralphm arc: adults are overrated
  398. arc Not my president. He's only president for Nazis and rednecks
  399. ralphm dwd: what about my message earlier?
  400. dwd ralphm, FWIW, I wanted the messages node to hold all messages. But I lost that one. My solution was to have MAM flags which could "condense" the items, for example by eliding retractions and corrected messages. I've been toying with the idea of such things to flag messages which have been acknowledged by '184, etc.
  401. lovetox has joined
  402. dwd ralphm, But in any case, the MAM/MIX vs MAM/'60-on-messages-node is just a curiosity. Subscribing to the messages node with '60 syntax should/might give you a pubsub-syntax event stream of messages.
  403. ralphm I am happy for something that condenses archived messages in general, although keeping in mind the discussion on multiple dimensions as discussed with Kev on the Summit.
  404. mfoss has joined
  405. dwd ralphm, I don't remember the discussion being discussed.
  406. dwd ralphm, Did we discuss a discussion during the discussion?
  407. ralphm However, I strongly believe that MAM on PubSub nodes currently are defined as a protocol to the item archive, not the message archive, and this is just a choice. I don't think right now that it is a bad one.
  408. alacer has joined
  409. UsL has left
  410. ralphm To cover the weird semantics of the messages node sending out notifications is a non-XEP-0060 syntax is something we could encode in the node configuration.
  411. ralphm There is (some) precedent for this.
  412. Zash If it was an archive of events then you'd probably want a way to filter them for the data payloads
  413. mfoss has left
  414. ralphm I remember that when Twitter supported XMPP pubsub (yes, really), it sent out atom elements and bodies in the bare message instead of using the event structure.
  415. ralphm The goal was to make it easier for client devs to work with.
  416. Zash pubsub#include_body is pretty nice
  417. ralphm yes and no
  418. ralphm it would only cover the body
  419. Zash True
  420. ralphm But we could define something similar
  421. ralphm like
  422. Zash Including a picture would be neat in some cases actually.
  423. Alex has left
  424. ralphm a config item that represents 'bare notifications'
  425. Zash What do you mean by "bare"?
  426. ralphm Zash: a notification without the pubsub event wrapper
  427. Zash Wait did they send `<message><{atom}item>atom stuff</item><body>someone tweeted hello</body></message>` without the pubsub container?
  428. ralphm Zash: we are considering what notifications a user gets when subscribed to the messages node in a mix channel, right?
  429. ralphm So at some point we said we wanted 'regular' messages to be sent as 'regular' messages originating in the channels' JID
  430. ralphm However, you still have to subscribe to the 'messages' node.
  431. ralphm For all other nodes, you'd get notifications with the normal pubsub event wrapper.
  432. Zash I'm afraid I haven't managed to read the MIX specs yet.
  433. ralphm So if we want to change that for this purpose, you'd have to have a flag to represent this behaviour.
  434. Zash I remember discussions about that and thought containerless was the case already.
  435. ralphm Zash: yes, but implicit in the sense that if you just throw a pubsub service onto the jid representing a channel, it doesn't work that way.
  436. ralphm Zash: XEP-0369 now says something weird:
  437. ralphm “The Messages node is used to distribute messages. The Messages node is a transient node and so no PubSub items are held. Messages MUST go to the associated MAM archive and history is retrieved by use of MAM. Users subscribe to this node to indicate that messages from the channel are to be sent to them. Private Messages are not distributed by the Messages node. ”
  438. ralphm So this is not very clear on the details.
  439. zinid why isn't it clear?
  440. zinid I find it pretty clear
  441. zinid I implemented this part, didn't find caveates
  442. ralphm zinid: if the pubsub item 'messages' doesn't hold items, what MAM archive does this text refer to?
  443. ralphm pubsub node, I mean
  444. zinid I don't know, but that's how MIX designed
  445. zinid it's just weird
  446. ralphm zinid: so instead of saying 'it is weird', we are trying to properly define it.
  447. mimi89999 has left
  448. ralphm zinid
  449. ralphm I didn't say the intent wasn't clear
  450. kokonoe has left
  451. zinid I mean the sentence "as an instruction" is clear. we have tons of weirdness in our XEPs, I kinda don't pay attention already
  452. alacer has left
  453. zinid whatever
  454. mimi89999 has joined
  455. ralphm zinid: so to retrieve the MAM archive for the channel's messages, where does the client direct it? The channel JID? With or without a node?
  456. zinid ralphm, to channel jid, no need for any nodes
  457. dwd zinid, +1
  458. zinid this node is kinda "ephemeral"
  459. ralphm zinid: ok, I'll buy that, but that means that the 'messages' node is not really a pubsub node.
  460. dwd ralphm, We assume that directing XEP-0060 traffic to individual nodes gives you "classic" XEP-0060 stuff.
  461. ralphm dwd: sure, I'm happy with that
  462. ralphm but the text I quoted should be more explicit on this
  463. dwd ralphm, And FWIW, the "subscription" to nodes is fully mediated by the MIX channel itself, so it can do "special" subscriptions for the messages node if done through a join. WHich is what I'm doing right now.
  464. ralphm Because even if it is a transient node, subscribing to it would normally yield empty notifications like this: <message from='pubsub.shakespeare.lit' to='francisco@denmark.lit'> <event xmlns='http://jabber.org/protocol/pubsub#event'> <items node='elsinore/doorbell'/> </event> </message>
  465. ralphm dwd: maybe it would be better to say: there is no XEP-0060 style 'messages' node.
  466. dwd ralphm, Why empty?
  467. ralphm dwd: right, good point. At least without an item id.
  468. zinid > the "subscription" to nodes is fully mediated by the MIX channel itself dwd, and that's the most weird thing of MIX. Back then when we implemented pubsub in ejabberd it was supposed to be a simple front-end to a database, now we introduce some "mediation" layer and the code is just useless now
  469. dwd ralphm, You're showing '60 Ex 3, there, which is explicitly a transient node that *also* doesn't have payloads.
  470. zinid so the complexity now is how to design internal pubsub handlers to work above any "mediated" layer
  471. zinid including database or MIX
  472. dwd ralphm, Whereas if you look at Table 4, bottom right is what we're expecting if you subscribe directly to the messages node.
  473. ralphm Right, without item ids
  474. dwd zinid, Right - in my toy implementation, subscriptions internally are callable types (functor objects), and so MIX just uses a different callable type for join'ed message subscriptions.
  475. dwd ralphm, No, they just don't *have* to have message ids.
  476. dwd ralphm, Argh. Item ids.
  477. zinid dwd, sure, it's quite doable if you don't have a ton of code you need to redesign 🙂
  478. dwd ralphm, And probably wouldn't - there's a lot of complexity unspoken about whether the id on a message coming out from MIX is an item id in Pubsub terms or some new Event Id.
  479. dwd zinid, Yes, as well I know from looking at doing similar in Openfire etc.
  480. ralphm dwd: it'd be better to say: the messages node is special, no notifications, no archive, you just indicate you want normal message from the channel and *it* has an archive
  481. yon has joined
  482. dwd ralphm, I think it works anyway, doesn't it? We just need to say that asking for the MAM archive from the channel itself is a Different Thing.
  483. dwd ralphm, Noting, of course, that MIX implementations do nto have to offer very much (if any) classic XEP-0060 on the nodes within channels.
  484. ralphm And that you don't get notifications from the node itself
  485. ralphm Well, I definitely expect other nodes to be proper pubsub nodes
  486. ralphm With retract, purge, etc.
  487. Alex has joined
  488. ralphm Or at least all the normal mandatory stuff
  489. yon has left
  490. yvo has joined
  491. kokonoe has joined
  492. kokonoe has left
  493. Nekit has left
  494. kokonoe has joined
  495. Guus has left
  496. Guus has joined
  497. ThibG has left
  498. ThibG has joined
  499. Lance has joined
  500. yon has joined
  501. Guus has left
  502. Guus has joined
  503. Maranda has joined
  504. intosi has left
  505. lumi has joined
  506. UsL has joined
  507. Tobias has joined
  508. kokonoe has left
  509. kokonoe has joined
  510. zinid hey guys, any input on my last ranting on standards@ list?
  511. zinid https://mail.jabber.org/pipermail/standards/2019-March/035857.html
  512. zinid nobody read? nobody cares?
  513. Kev has left
  514. Guus has left
  515. Guus has joined
  516. moparisthebest I like the idea, haven't read the XEPs yet though
  517. Guus has left
  518. zinid nice to hear, thanks
  519. Zash I stopped reading at "it just sucks"
  520. zinid oh, sorry
  521. zinid yeah, I shouldn't have said that
  522. moparisthebest oh I agreed with that part :P
  523. zinid you're guys so fragile, I always forget 😀
  524. zinid whatever, scram sucks 😛
  525. moparisthebest hmm, so I like the whole "cert auth" part, I hate the centralized CA bit
  526. lskdjf has left
  527. moparisthebest is the only reason for that "spam prevention" ?
  528. lskdjf has joined
  529. zinid moparisthebest, no, also RELOAD requirement
  530. zinid that's Sybil protection
  531. zinid https://xmpp.org/extensions/xep-0415.html#enroll-auth
  532. zinid first part
  533. Ge0rG zinid: how do you protect from sybil attacks, again?
  534. zinid Ge0rG, by concentrating identities checks in a few single place, at CAs
  535. zinid note that for now we don't need the checks to be extremely severe, something like oauth to popular services or sms verification is enough so far
  536. Ge0rG why is a sybil attack even a problem at all?
  537. zinid Ge0rG, in p2p?
  538. zinid because you can polute routing
  539. Ge0rG in the CA thing.
  540. zinid aka Eclipse attack
  541. dwd has left
  542. dwd has joined
  543. zinid sybil attack is not a problem is CA, CAs are just centralized to prevent Sybil
  544. zinid *in
  545. moparisthebest idk, the CA looks like a total dealbreaker to me
  546. zinid moparisthebest, why?
  547. moparisthebest maybe that makes it vulnerable to a sybil attack but probably worth it
  548. zinid I recall you like DNS, but DNS is ICANN - same centralized stuff
  549. moparisthebest I don't know anyone or any organization I trust enough to run a CA
  550. Ge0rG zinid: but how is a CA supposed to prevent sybil attacks?
  551. dwd has left
  552. moparisthebest I only trust certificates as far as the public key anyway, hence why I like DNSSEC + DANE etc
  553. zinid Ge0rG, I wrote already: > note that for now we don't need the checks to be extremely severe, something like oauth to popular services or sms verification is enough so far
  554. zinid moparisthebest, but what's the difference?
  555. Ge0rG zinid: but that would mean that you essentially don't verify the identity of the XMPP entity but instead of whatever third-party service you use?
  556. Ge0rG (actually, "in addition to")
  557. zinid Ge0rG, you can verify the entity of course by asking to provide the passport 😀
  558. zinid without CAs you don't have even that: you cannot identify all your online contacts that way
  559. moparisthebest to clarify, I like the idea of identifying an XMPP *account* (not device, could be multiple devices) with a cryptographic key
  560. j.r has left
  561. moparisthebest I don't like the idea of a centralized CA approving that
  562. Ge0rG zinid: I still think that you are conflating multiple different problem domains. There is value in having an XMPP based CA hierarchy, and there is value in whatever sybil attack prevention mechanism you might require for RELOAD. But those are completely separate
  563. j.r has joined
  564. zinid Ge0rG, sure they are separate
  565. zinid but I don't solve separate problems
  566. zinid I separate a single meta problem
  567. moparisthebest zinid, if you are looking for "trust" then each domain should have it's own level of trust, which gets passed to it's users, imho
  568. zinid I'm not interested in our permanent bikeshedding with small problems without seeing a complete picture
  569. moparisthebest that keeps it federated
  570. zinid moparisthebest, it's possible to do and I outlined that in XEP-0416
  571. zinid but still Sybil resistance is a problem and you CANNOT address it without centralization, and clever people proved that
  572. moparisthebest then it shouldn't be addressed...
  573. zinid also, what's the point in federated accounts? why not roaming user profiles? we're moving that way in Moved for example
  574. moparisthebest as you pointed out it's already basically centralized and could be solved that way through DNS
  575. zinid so we just rely on CA instead of DNS, both are centralized
  576. moparisthebest if entire domains are trusted/not and excluded/not attackers already can't buy an unlimited number of those
  577. zinid moparisthebest, I can create 100500 accounts on another poorly maintained server and attack your server, what will you do?
  578. moparisthebest block that 1 server
  579. Steve Kille has left
  580. zinid oh great idea 🙂
  581. zinid to block other users on that server?
  582. moparisthebest no problem, they can use their crypto identity to move to another one :D
  583. dwd has joined
  584. zinid moparisthebest, how that?
  585. zinid where will they get the identity? how will they move?
  586. zinid from *abandoned* server
  587. zinid not to mention they will of course not move anywhere
  588. moparisthebest they generate the identity, all their contacts have that key, when they get a request from $new_account with that same identity, they know they've moved
  589. zinid and you will trust the identity signed by that rougue server?
  590. Lance has left
  591. moparisthebest it's not signed by anyone
  592. zinid moparisthebest, also, can you please outline your concerns with CAs?
  593. frainz has left
  594. zinid let's encrypt is bad?
  595. frainz has joined
  596. moparisthebest 1. assuming good intent and all that, commercial CAs get hacked/compromised all the time, what "XMPP CA" would even be as good?
  597. moparisthebest 2. I don't like assuming good intent, or being at the whim of anyone else
  598. zinid moparisthebest, and DNS servers are not hacked all the time?
  599. zinid and DNS assumes not intent?
  600. moparisthebest no? also there isn't a single source of truth DNS server
  601. oli has left
  602. zinid except root servers?
  603. zinid whatever, what you say is possible if every XMPP server maintains CA
  604. zinid tied to their domains
  605. zinid but it sucks
  606. zinid also, good luck create roaming profiles in such system: why would I trust identities signed by some server X?
  607. zinid it's even moot that CA and much easier to compromise
  608. zinid *than
  609. moparisthebest I don't think there should be CAs at all, only account keys, generated on an end device on account creation, sync'd to other devices
  610. zinid moparisthebest, and how will you verify those keys?
  611. moparisthebest manually, or PGP web-of-trust style ? :P
  612. zinid sigh
  613. zinid okay, have fun with it
  614. Alex has left
  615. dwd has left
  616. dwd has joined
  617. yon has left
  618. Guus has joined
  619. dwd has left
  620. Alex has joined
  621. debacle has left
  622. vanitasvitae has joined
  623. Wiktor has joined
  624. Alex has left
  625. yvo has left
  626. wurstsalat has joined
  627. Alex has joined
  628. Alex has left
  629. igoose has left
  630. arc has left
  631. arc has joined
  632. yon has joined
  633. kokonoe has left
  634. igoose has joined
  635. kokonoe has joined
  636. debacle has joined
  637. vanitasvitae has left
  638. Alex has joined
  639. Yagiza has left
  640. oli has joined
  641. mimi89999 has left
  642. dwd has joined
  643. j.r has left
  644. mimi89999 has joined
  645. j.r has joined
  646. Guus has left
  647. Alex has left
  648. Guus has joined
  649. waqas has joined
  650. vanitasvitae has joined
  651. lumi has left
  652. lumi has joined
  653. lumi has left
  654. lumi has joined
  655. Alex has joined
  656. yon has left
  657. Alex has left
  658. architekt has joined
  659. architekt has left
  660. arc has left
  661. Steve Kille has joined
  662. edhelas has joined
  663. nyco has joined
  664. arc has joined
  665. Alex has joined
  666. igoose has left
  667. igoose has joined
  668. Kev has joined
  669. igoose has left
  670. igoose has joined
  671. dwd has left
  672. dwd has joined
  673. dwd has left
  674. Tobias has left
  675. Guus has left
  676. Guus has joined
  677. Ge0rG has left
  678. arc has left
  679. arc has joined
  680. Ge0rG has joined
  681. lnj has left
  682. lumi has left
  683. lumi has joined
  684. lumi has left
  685. lumi has joined
  686. andrey.g has left
  687. Maranda has left
  688. andrey.g has joined
  689. ThibG has left
  690. ThibG has joined
  691. Lance has joined
  692. !xsf_Martin has joined
  693. dwd has joined
  694. dwd has left
  695. dwd has joined
  696. !xsf_Martin has left
  697. Alex has left
  698. !xsf_Martin has joined
  699. !xsf_Martin has left
  700. !xsf_Martin has joined
  701. !xsf_Martin has left
  702. !xsf_Martin has joined
  703. !xsf_Martin has left
  704. !xsf_Martin has joined
  705. !xsf_Martin has left
  706. !xsf_Martin has joined
  707. !xsf_Martin has left
  708. !xsf_Martin has joined
  709. !xsf_Martin has left
  710. !xsf_Martin has joined
  711. !xsf_Martin has left
  712. !xsf_Martin has joined
  713. !xsf_Martin has left
  714. !xsf_Martin has joined
  715. !xsf_Martin has left
  716. !xsf_Martin has joined
  717. !xsf_Martin has left
  718. !xsf_Martin has joined
  719. !xsf_Martin has left
  720. !xsf_Martin has joined
  721. !xsf_Martin has left
  722. !xsf_Martin has joined
  723. dwd has left
  724. yon has joined
  725. dwd has joined
  726. wurstsalat has left
  727. efrit has joined
  728. wurstsalat has joined
  729. Alex has joined
  730. Alex has left
  731. matlag has joined
  732. yon has left
  733. efrit has left
  734. nyco has left
  735. edhelas has left
  736. dwd has left
  737. dwd has joined
  738. dwd has left
  739. nyco has joined
  740. edhelas has joined
  741. dwd has joined
  742. dele has joined
  743. goffi has left
  744. dele has left
  745. yon has joined
  746. lumi has left
  747. lumi has joined
  748. andrey.g has left
  749. dwd has left
  750. dwd has joined
  751. andrey.g has joined
  752. dwd has left
  753. Guus has left
  754. Guus has joined
  755. Guus has left
  756. architekt has joined
  757. architekt has left
  758. mimi89999 has left
  759. mimi89999 has joined
  760. andrey.g has left
  761. Guus has joined
  762. dwd has joined
  763. Lance has left
  764. lovetox has left
  765. dwd has left
  766. dwd has joined
  767. dwd has left
  768. dwd has joined
  769. dele has joined
  770. dele has left
  771. dele has joined
  772. arc has left
  773. arc has joined