XMPP Council - 2012-04-25


  1. Tobias has joined
  2. Tobias has left
  3. linuxwolf has joined
  4. MattJ has joined
  5. Tobias has joined
  6. stpeter has joined
  7. ralphm has joined
  8. stpeter wanders in
  9. Kev Right, that's 16:00.
  10. Kev How're we doing for people being here?
  11. linuxwolf /whew
  12. Kev 1) Roll call.
  13. linuxwolf present … barely
  14. MattJ linuxwolf, here?
  15. MattJ Heh
  16. MattJ I'm here
  17. ralphm hi
  18. Kev Tobias: ?
  19. Kev Maybe too busy with http://swift.im/hackathon/
  20. stpeter :)
  21. Kev 2) Carbons/MAMs.
  22. MattJ linuxwolf, hello
  23. stpeter I have yet to think about MAM and Carbons
  24. MattJ Did you read my email about the MAM + Carbons overlap?
  25. stpeter I did :)
  26. Kev My thoughts on this are roughly:
  27. linuxwolf goes back to email quickly
  28. stpeter not sure about lw
  29. linuxwolf ok, caught up
  30. Kev 1) You log in, you use MAM to get up to speed, using MAM IDs. 2) You use carbons, where the IDs will match the MAM ones 3) You log everything with an ID to local history cache 4) You log out. You now have a local cache of everything apart from any messages that you sent that don't yet have a reply. 5) You log in again, rinse and repeat. This will involve receiving any messages you sent but didn't get replies to in the previous session. This is likely to be not much in the way of duplicate data 6) ? 7) Profit.
  31. Tobias hi
  32. MattJ Tobias, lag worse than waqas :)
  33. stpeter Kev: on the face of it, that seems sensible
  34. linuxwolf assuming there's one source for generating the IDs
  35. Tobias has left
  36. MattJ Right
  37. stpeter yes
  38. linuxwolf which means messages get munged
  39. linuxwolf but that's not all that horrible
  40. Kev linuxwolf: Right. If you're talking about MAM on remote services (such as MUCs) then you need to query those independently.
  41. linuxwolf well, munged is probably too strong a word
  42. MattJ It complicates the server side, in Prosody at least, for mod_mam to be figuring out what mod_carbons is sending and injecting the right message IDs
  43. stpeter let's ask Jer why he didn't include message IDs back in 1999 :)
  44. Kev linuxwolf: You mean that all messages get an <archived-by/> element?
  45. stpeter MattJ: yes
  46. Kev MattJ: Although presumably it only needs you to have mod_stanza_id and for both the other mods to use that?
  47. linuxwolf Kev: I'm not sure
  48. linuxwolf at the very least, the 'id' attribute will be changed
  49. Kev linuxwolf: I'm not talking about using the stanza id.
  50. Kev That's between the sender and the receiver.
  51. Kev I mean we have <archived by="myserver" id="ouaur.uh"/> injected.
  52. Kev So you can perform queries against MAM using the right id.
  53. linuxwolf sure
  54. linuxwolf ok
  55. linuxwolf ponders how this works with e2e
  56. stpeter heh
  57. stpeter well
  58. MattJ or how Carbons works with e2e for that matter
  59. linuxwolf I don't think it's actually a problem ...
  60. Kev linuxwolf: e2e needs to deal with the stanzas being modified inflight :)
  61. stpeter if you recall, XEP-0136 had all sorts of interesting features for encrypting the messages before pushing them to the archive
  62. MattJ Prosody will do things like add a <delay> for messages that have been held by 198
  63. linuxwolf the e2e specs allow for the container to be heavily modified today, so I don't think there's an issue
  64. MattJ so stanzas already get modified en route
  65. Kev linuxwolf: Then we're laughing.
  66. linuxwolf but getting the keys again can be tricky
  67. Kev linuxwolf: Oh, I see what you mean.
  68. MattJ I don't
  69. Kev MattJ: The encrypted messages get archived. How do you read them again?
  70. linuxwolf http://tools.ietf.org/html/draft-miller-xmpp-e2e
  71. MattJ Kev, right... MAM basically hints at not archiving them
  72. linuxwolf that's one solution (-:
  73. MattJ Depending on the actual encryption method used, it may not be possible to read them after the fact
  74. Kev Probably even an acceptable solution.
  75. MattJ and it may not be desired to archive sensitive stuff anyway
  76. MattJ encrypted or not
  77. linuxwolf MattJ: possibly
  78. Kev So, as far as this discussion goes...
  79. Kev Does anyone see issue with the proposal above for getting carbons and MAM working together so clients can have complete history?
  80. MattJ I still have no idea how I'd implement it
  81. MattJ and from a protocol perspective it's not "perfect", but it's workable
  82. Kev Server devs are smart, that's why they get the big bucks.
  83. linuxwolf I can see it working if MAM depends on carbons, maybe
  84. stpeter modulo the e2e stuff, the approach you've outlined above seems workable
  85. MattJ Kev, yeah...
  86. linuxwolf there
  87. linuxwolf gah
  88. linuxwolf there's something else that's started to bother me wrt carbons
  89. MattJ linuxwolf, I don't think there should be a dependency - or maybe I don't understand what you mean
  90. ralphm well, I suppose some of us can attain implementors' experience for the next revision :-)
  91. stpeter :)
  92. linuxwolf MattJ: it might not, I need to think on it some more
  93. linuxwolf so, bothering me: blocking protocols (privacy, shim)
  94. MattJ Yeah
  95. linuxwolf the quick answer is to say don't use both
  96. linuxwolf but I think that's a little too naive
  97. Kev For the stupid amongst us, spell this out please.
  98. linuxwolf your Client1 has a privacy policy, and enables carbons
  99. linuxwolf your Client2 does not have a privacy policy, and enables carbons
  100. linuxwolf you message someone on Client2 that Client1 would block
  101. linuxwolf what happens with the carbons?
  102. MattJ That's why privacy lists is broken (one reason anyway)
  103. MattJ But simple blocking works fine
  104. stpeter nods to MattJ
  105. linuxwolf MattJ: I'll not dispute privacy lists are broken, and simple blocking works fine, but doesn't cover quite enough cases
  106. Kev So you're sending messages with one client to someone who you don't allow outgoing messages to from another client, and you activated carbons on the second client?
  107. linuxwolf Kev: outgoing or incoming
  108. Kev Incoming the situation's reasonably straightforward, I'd have thought. You blocked them, you shouldn't get their messages.
  109. Kev I agree that it wouldn't hurt to spell this out somewhere.
  110. linuxwolf now it's about the outgoing from the other client
  111. linuxwolf and how you end up with one side of a conversation
  112. linuxwolf assuming the server doesn't drop the carbons because the message went to a blocked recipient
  113. MattJ Notably with MAM you would always get them
  114. MattJ Because they come from the server's JID, there is no ambiguity
  115. linuxwolf I don't know that I agree with that statement
  116. linuxwolf presumably there's a reason you're blocking them
  117. stpeter notes that we haven't really thought about the interactions between privacy lists, SIFT, Carbons, and MAM
  118. Tobias has joined
  119. Kev linuxwolf: I'm not sure there's a right and a wrong behaviour here - we just pick something not obviously broken and spec it.
  120. linuxwolf just because the container is addressed from the server doesn't mean I won't be offended at seeing the message
  121. Tobias hi
  122. MattJ linuxwolf, I'm quite certain there's no ambiguity... MAM *does* send from the server's JID, and unless that's blocked, you'll get them
  123. linuxwolf Kev: well, I'm not sure what to spec (-:
  124. Kev Tobias: WB.
  125. Tobias my mobile connection was flanky
  126. MattJ linuxwolf, well I'm not saying that you won't be offended, just that's what will undoubtedly happen
  127. linuxwolf MattJ: and I'm not sure that's actually desirable behavior
  128. ralphm is tempted to repeat his previous statement
  129. linuxwolf I could have blocked them because they like to spam me with "CAT FACTS"
  130. linuxwolf but now I get them because I retrieved MAM?
  131. MattJ linuxwolf, yep, well MAM explicitly declares an interest in all your history
  132. linuxwolf it might be these things that wrap other things will need to look deeper
  133. MattJ Though you can filter to a single JID
  134. ralphm agreeing with stpeter, what about having people starting to hack on this
  135. Kev MattJ: Yes, but surely if you say "block all stanzas from this user", they shouldn't get as far as MAM to be later retreived.
  136. MattJ ralphm, people have started to hack on this, we have client and server implementations of carbons and MAM already
  137. Kev +sp
  138. linuxwolf MattJ: so now I have to manually apply my privacy policies in multiple places?
  139. Zash has joined
  140. Zash What?!
  141. ralphm MattJ: I meant the combination, that you apparently don't know how to do yet.
  142. stpeter I wonder how much cleaner this all gets if we deprecate privacy lists
  143. MattJ linuxwolf, I'm not saying you have to do anything - I'm just saying what will happen :)
  144. linuxwolf stpeter: it might get clearer
  145. Florob has joined
  146. linuxwolf MattJ: and I'm trying to say that might be considered a bug by most others not as close to things as we are
  147. stpeter I'll note that we pushed privacy lists forward in order to meet a perceived requirement for publication of RFC 3921, but it seems that we misunderstood the requirement and all that was really required was something like XEP-0191
  148. MattJ stpeter, well I'm hoping to go in that direction
  149. MattJ mod_privacy in Prosody is so complicated because of corner-cases like this
  150. MattJ That was me reconnecting with XEP-0198 :)
  151. linuxwolf nice (-:
  152. linuxwolf for MAM+blocking, this might not be a real problem
  153. Kev stpeter: I'd love to get rid of it.
  154. Kev So, anyway.
  155. Kev We're approaching 30mins.
  156. linuxwolf for carbons+blocking, I've run into some undesirables
  157. Kev I suggest someone produces a strawman that we then discuss.
  158. MattJ linuxwolf, the fact is there's no way you can stretch privacy lists or blocking into looking *inside* messages
  159. linuxwolf MattJ: isn't there? (-:
  160. MattJ Maybe <forward> gets you slightly there
  161. MattJ But I'll regret publishing that spec if it does :P
  162. linuxwolf that's what I was thinking
  163. Kev 3) Date of next meeting.
  164. linuxwolf maybe you need to start regretting then (-:
  165. Kev Fortnight now?
  166. ralphm wfm
  167. MattJ Kev, +1
  168. linuxwolf looks at calendar
  169. linuxwolf 2012-05-09 works for me
  170. Tobias +1
  171. stpeter wfm
  172. Kev 4) AOB?
  173. MattJ As long as it's a Wednesday and 1500 UTC I'm fine
  174. MattJ None here
  175. linuxwolf no
  176. stpeter no AOB here
  177. Tobias no
  178. Kev Righty, we're just over time, on agenda with no actions. Jolly good.
  179. Kev Thanks all.
  180. Kev bangs the gavel.
  181. stpeter calendar updated, time to head into the office, bbiab
  182. stpeter has left
  183. ralphm has left
  184. Zash And now I've read up till the present
  185. Zash MattJ: I poked with priorities so that if MAM stamps an <archived/>, it'll be in any carbon'd message.
  186. MattJ Zash, nice
  187. MattJ that's one problem solved then
  188. Zash Altho, should the <arhived/> be stamped before or after the acual storing fo the message?
  189. linuxwolf probably after
  190. MattJ The tense of the verb suggests that :)
  191. linuxwolf you'd want to try and keep it pristine (-:
  192. Zash One of the things you'll want to describe more closely if you add it back then :)
  193. MattJ Well what does it matter?
  194. Florob I think it should be in the middle
  195. MattJ and a bit to the right
  196. MattJ and sky blue
  197. Zash <message><carbons:recv/><forward><message><arhived/></message></forward></message> <message><mam:result/><forward><message><archived (redundant?)/></message/></forward></message>
  198. linuxwolf has left
  199. linuxwolf has joined
  200. Zash has left
  201. Kev has left
  202. MattJ Ah, I see what you mean
  203. MattJ Yes, that's how the original spec had it - but now we have mam:result I think it shouldn't be stored
  204. Kev has joined
  205. Tobias has left
  206. linuxwolf has left
  207. Tobias has joined
  208. Florob has left
  209. linuxwolf has joined
  210. Zash has joined
  211. linuxwolf has left
  212. linuxwolf has joined
  213. linuxwolf has left
  214. linuxwolf has joined
  215. Tobias has joined
  216. stpeter has joined
  217. linuxwolf has left
  218. Tobias has joined
  219. linuxwolf has joined
  220. stpeter has left
  221. Tobias has left
  222. Tobias has joined
  223. Tobias has left
  224. Tobias has joined
  225. Tobias has left
  226. Tobias has joined
  227. Tobias has left
  228. Tobias has joined
  229. Tobias has left
  230. Tobias has joined
  231. Tobias has left
  232. Tobias has joined
  233. Tobias has left
  234. Tobias has joined
  235. Tobias has left
  236. Tobias has joined
  237. Tobias has left
  238. Tobias has joined
  239. Tobias has left
  240. Tobias has joined
  241. Tobias has left
  242. Tobias has joined
  243. Tobias has left
  244. Tobias has joined
  245. Tobias has left
  246. Tobias has joined
  247. Tobias has left
  248. Tobias has joined
  249. Tobias has left
  250. Tobias has joined
  251. Tobias has left
  252. Tobias has joined
  253. Tobias has left
  254. Zash has left
  255. linuxwolf has left