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


  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


  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


  420. ralphm

    But we could define something similar

  421. ralphm


  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


  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


  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


  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


  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


  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


  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


  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