XMPP Council - 2012-04-25


  1. stpeter wanders in

  2. Kev

    Right, that's 16:00.

  3. Kev

    How're we doing for people being here?

  4. linuxwolf

    /whew

  5. Kev

    1) Roll call.

  6. linuxwolf

    present … barely

  7. MattJ

    linuxwolf, here?

  8. MattJ

    Heh

  9. MattJ

    I'm here

  10. ralphm

    hi

  11. Kev

    Tobias: ?

  12. Kev

    Maybe too busy with http://swift.im/hackathon/

  13. stpeter

    :)

  14. Kev

    2) Carbons/MAMs.

  15. MattJ

    linuxwolf, hello

  16. stpeter

    I have yet to think about MAM and Carbons

  17. MattJ

    Did you read my email about the MAM + Carbons overlap?

  18. stpeter

    I did :)

  19. Kev

    My thoughts on this are roughly:

  20. linuxwolf goes back to email quickly

  21. stpeter

    not sure about lw

  22. linuxwolf

    ok, caught up

  23. 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.

  24. Tobias

    hi

  25. MattJ

    Tobias, lag worse than waqas :)

  26. stpeter

    Kev: on the face of it, that seems sensible

  27. linuxwolf

    assuming there's one source for generating the IDs

  28. MattJ

    Right

  29. stpeter

    yes

  30. linuxwolf

    which means messages get munged

  31. linuxwolf

    but that's not all that horrible

  32. Kev

    linuxwolf: Right. If you're talking about MAM on remote services (such as MUCs) then you need to query those independently.

  33. linuxwolf

    well, munged is probably too strong a word

  34. 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

  35. stpeter

    let's ask Jer why he didn't include message IDs back in 1999 :)

  36. Kev

    linuxwolf: You mean that all messages get an <archived-by/> element?

  37. stpeter

    MattJ: yes

  38. Kev

    MattJ: Although presumably it only needs you to have mod_stanza_id and for both the other mods to use that?

  39. linuxwolf

    Kev: I'm not sure

  40. linuxwolf

    at the very least, the 'id' attribute will be changed

  41. Kev

    linuxwolf: I'm not talking about using the stanza id.

  42. Kev

    That's between the sender and the receiver.

  43. Kev

    I mean we have <archived by="myserver" id="ouaur.uh"/> injected.

  44. Kev

    So you can perform queries against MAM using the right id.

  45. linuxwolf

    sure

  46. linuxwolf

    ok

  47. linuxwolf ponders how this works with e2e

  48. stpeter

    heh

  49. stpeter

    well

  50. MattJ

    or how Carbons works with e2e for that matter

  51. linuxwolf

    I don't think it's actually a problem ...

  52. Kev

    linuxwolf: e2e needs to deal with the stanzas being modified inflight :)

  53. stpeter

    if you recall, XEP-0136 had all sorts of interesting features for encrypting the messages before pushing them to the archive

  54. MattJ

    Prosody will do things like add a <delay> for messages that have been held by 198

  55. linuxwolf

    the e2e specs allow for the container to be heavily modified today, so I don't think there's an issue

  56. MattJ

    so stanzas already get modified en route

  57. Kev

    linuxwolf: Then we're laughing.

  58. linuxwolf

    but getting the keys again can be tricky

  59. Kev

    linuxwolf: Oh, I see what you mean.

  60. MattJ

    I don't

  61. Kev

    MattJ: The encrypted messages get archived. How do you read them again?

  62. linuxwolf

    http://tools.ietf.org/html/draft-miller-xmpp-e2e

  63. MattJ

    Kev, right... MAM basically hints at not archiving them

  64. linuxwolf

    that's one solution (-:

  65. MattJ

    Depending on the actual encryption method used, it may not be possible to read them after the fact

  66. Kev

    Probably even an acceptable solution.

  67. MattJ

    and it may not be desired to archive sensitive stuff anyway

  68. MattJ

    encrypted or not

  69. linuxwolf

    MattJ: possibly

  70. Kev

    So, as far as this discussion goes...

  71. Kev

    Does anyone see issue with the proposal above for getting carbons and MAM working together so clients can have complete history?

  72. MattJ

    I still have no idea how I'd implement it

  73. MattJ

    and from a protocol perspective it's not "perfect", but it's workable

  74. Kev

    Server devs are smart, that's why they get the big bucks.

  75. linuxwolf

    I can see it working if MAM depends on carbons, maybe

  76. stpeter

    modulo the e2e stuff, the approach you've outlined above seems workable

  77. MattJ

    Kev, yeah...

  78. linuxwolf

    there

  79. linuxwolf

    gah

  80. linuxwolf

    there's something else that's started to bother me wrt carbons

  81. MattJ

    linuxwolf, I don't think there should be a dependency - or maybe I don't understand what you mean

  82. ralphm

    well, I suppose some of us can attain implementors' experience for the next revision :-)

  83. stpeter

    :)

  84. linuxwolf

    MattJ: it might not, I need to think on it some more

  85. linuxwolf

    so, bothering me: blocking protocols (privacy, shim)

  86. MattJ

    Yeah

  87. linuxwolf

    the quick answer is to say don't use both

  88. linuxwolf

    but I think that's a little too naive

  89. Kev

    For the stupid amongst us, spell this out please.

  90. linuxwolf

    your Client1 has a privacy policy, and enables carbons

  91. linuxwolf

    your Client2 does not have a privacy policy, and enables carbons

  92. linuxwolf

    you message someone on Client2 that Client1 would block

  93. linuxwolf

    what happens with the carbons?

  94. MattJ

    That's why privacy lists is broken (one reason anyway)

  95. MattJ

    But simple blocking works fine

  96. stpeter nods to MattJ

  97. linuxwolf

    MattJ: I'll not dispute privacy lists are broken, and simple blocking works fine, but doesn't cover quite enough cases

  98. 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?

  99. linuxwolf

    Kev: outgoing or incoming

  100. Kev

    Incoming the situation's reasonably straightforward, I'd have thought. You blocked them, you shouldn't get their messages.

  101. Kev

    I agree that it wouldn't hurt to spell this out somewhere.

  102. linuxwolf

    now it's about the outgoing from the other client

  103. linuxwolf

    and how you end up with one side of a conversation

  104. linuxwolf

    assuming the server doesn't drop the carbons because the message went to a blocked recipient

  105. MattJ

    Notably with MAM you would always get them

  106. MattJ

    Because they come from the server's JID, there is no ambiguity

  107. linuxwolf

    I don't know that I agree with that statement

  108. linuxwolf

    presumably there's a reason you're blocking them

  109. stpeter notes that we haven't really thought about the interactions between privacy lists, SIFT, Carbons, and MAM

  110. 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.

  111. linuxwolf

    just because the container is addressed from the server doesn't mean I won't be offended at seeing the message

  112. Tobias

    hi

  113. 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

  114. linuxwolf

    Kev: well, I'm not sure what to spec (-:

  115. Kev

    Tobias: WB.

  116. Tobias

    my mobile connection was flanky

  117. MattJ

    linuxwolf, well I'm not saying that you won't be offended, just that's what will undoubtedly happen

  118. linuxwolf

    MattJ: and I'm not sure that's actually desirable behavior

  119. ralphm is tempted to repeat his previous statement

  120. linuxwolf

    I could have blocked them because they like to spam me with "CAT FACTS"

  121. linuxwolf

    but now I get them because I retrieved MAM?

  122. MattJ

    linuxwolf, yep, well MAM explicitly declares an interest in all your history

  123. linuxwolf

    it might be these things that wrap other things will need to look deeper

  124. MattJ

    Though you can filter to a single JID

  125. ralphm

    agreeing with stpeter, what about having people starting to hack on this

  126. 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.

  127. MattJ

    ralphm, people have started to hack on this, we have client and server implementations of carbons and MAM already

  128. Kev

    +sp

  129. linuxwolf

    MattJ: so now I have to manually apply my privacy policies in multiple places?

  130. Zash

    What?!

  131. ralphm

    MattJ: I meant the combination, that you apparently don't know how to do yet.

  132. stpeter

    I wonder how much cleaner this all gets if we deprecate privacy lists

  133. MattJ

    linuxwolf, I'm not saying you have to do anything - I'm just saying what will happen :)

  134. linuxwolf

    stpeter: it might get clearer

  135. 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

  136. 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

  137. MattJ

    stpeter, well I'm hoping to go in that direction

  138. MattJ

    mod_privacy in Prosody is so complicated because of corner-cases like this

  139. MattJ

    That was me reconnecting with XEP-0198 :)

  140. linuxwolf

    nice (-:

  141. linuxwolf

    for MAM+blocking, this might not be a real problem

  142. Kev

    stpeter: I'd love to get rid of it.

  143. Kev

    So, anyway.

  144. Kev

    We're approaching 30mins.

  145. linuxwolf

    for carbons+blocking, I've run into some undesirables

  146. Kev

    I suggest someone produces a strawman that we then discuss.

  147. MattJ

    linuxwolf, the fact is there's no way you can stretch privacy lists or blocking into looking *inside* messages

  148. linuxwolf

    MattJ: isn't there? (-:

  149. MattJ

    Maybe <forward> gets you slightly there

  150. MattJ

    But I'll regret publishing that spec if it does :P

  151. linuxwolf

    that's what I was thinking

  152. Kev

    3) Date of next meeting.

  153. linuxwolf

    maybe you need to start regretting then (-:

  154. Kev

    Fortnight now?

  155. ralphm

    wfm

  156. MattJ

    Kev, +1

  157. linuxwolf looks at calendar

  158. linuxwolf

    2012-05-09 works for me

  159. Tobias

    +1

  160. stpeter

    wfm

  161. Kev

    4) AOB?

  162. MattJ

    As long as it's a Wednesday and 1500 UTC I'm fine

  163. MattJ

    None here

  164. linuxwolf

    no

  165. stpeter

    no AOB here

  166. Tobias

    no

  167. Kev

    Righty, we're just over time, on agenda with no actions. Jolly good.

  168. Kev

    Thanks all.

  169. Kev bangs the gavel.

  170. stpeter

    calendar updated, time to head into the office, bbiab

  171. Zash

    And now I've read up till the present

  172. Zash

    MattJ: I poked with priorities so that if MAM stamps an <archived/>, it'll be in any carbon'd message.

  173. MattJ

    Zash, nice

  174. MattJ

    that's one problem solved then

  175. Zash

    Altho, should the <arhived/> be stamped before or after the acual storing fo the message?

  176. linuxwolf

    probably after

  177. MattJ

    The tense of the verb suggests that :)

  178. linuxwolf

    you'd want to try and keep it pristine (-:

  179. Zash

    One of the things you'll want to describe more closely if you add it back then :)

  180. MattJ

    Well what does it matter?

  181. Florob

    I think it should be in the middle

  182. MattJ

    and a bit to the right

  183. MattJ

    and sky blue

  184. Zash

    <message><carbons:recv/><forward><message><arhived/></message></forward></message> <message><mam:result/><forward><message><archived (redundant?)/></message/></forward></message>

  185. MattJ

    Ah, I see what you mean

  186. MattJ

    Yes, that's how the original spec had it - but now we have mam:result I think it shouldn't be stored