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