XMPP Council - 2012-04-25

09:52:49 Tobias has joined
13:13:43 Tobias has left
14:01:23 linuxwolf has joined
14:43:29 MattJ has joined
14:43:35 Tobias has joined
14:59:43 stpeter has joined
15:00:04 ralphm has joined
15:00:56 stpeter wanders in
15:02:31 Kev Right, that's 16:00.
15:02:39 Kev How're we doing for people being here?
15:02:40 linuxwolf /whew
15:02:42 Kev 1) Roll call.
15:02:49 linuxwolf present … barely
15:02:49 MattJ linuxwolf, here?
15:02:52 MattJ Heh
15:02:55 MattJ I'm here
15:02:57 ralphm hi
15:03:07 Kev Tobias: ?
15:04:58 Kev Maybe too busy with http://swift.im/hackathon/
15:05:09 stpeter :)
15:05:10 Kev 2) Carbons/MAMs.
15:05:52 MattJ linuxwolf, hello
15:06:09 stpeter I have yet to think about MAM and Carbons
15:06:16 MattJ Did you read my email about the MAM + Carbons overlap?
15:06:25 stpeter I did :)
15:06:26 Kev My thoughts on this are roughly:
15:06:27 linuxwolf goes back to email quickly
15:06:27 stpeter not sure about lw
15:08:09 linuxwolf ok, caught up
15:08:16 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.
15:08:29 Tobias hi
15:08:41 MattJ Tobias, lag worse than waqas :)
15:09:26 stpeter Kev: on the face of it, that seems sensible
15:09:40 linuxwolf assuming there's one source for generating the IDs
15:09:41 Tobias has left
15:09:47 MattJ Right
15:09:49 stpeter yes
15:09:51 linuxwolf which means messages get munged
15:10:07 linuxwolf but that's not all that horrible
15:10:10 Kev linuxwolf: Right. If you're talking about MAM on remote services (such as MUCs) then you need to query those independently.
15:10:12 linuxwolf well, munged is probably too strong a word
15:10:21 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
15:10:23 stpeter let's ask Jer why he didn't include message IDs back in 1999 :)
15:10:24 Kev linuxwolf: You mean that all messages get an <archived-by/> element?
15:10:32 stpeter MattJ: yes
15:10:48 Kev MattJ: Although presumably it only needs you to have mod_stanza_id and for both the other mods to use that?
15:10:48 linuxwolf Kev: I'm not sure
15:11:08 linuxwolf at the very least, the 'id' attribute will be changed
15:11:28 Kev linuxwolf: I'm not talking about using the stanza id.
15:11:43 Kev That's between the sender and the receiver.
15:12:00 Kev I mean we have <archived by="myserver" id="ouaur.uh"/> injected.
15:12:11 Kev So you can perform queries against MAM using the right id.
15:12:28 linuxwolf sure
15:12:30 linuxwolf ok
15:12:53 linuxwolf ponders how this works with e2e
15:12:58 stpeter heh
15:13:11 stpeter well
15:13:15 MattJ or how Carbons works with e2e for that matter
15:13:17 linuxwolf I don't think it's actually a problem ...
15:13:33 Kev linuxwolf: e2e needs to deal with the stanzas being modified inflight :)
15:13:43 stpeter if you recall, XEP-0136 had all sorts of interesting features for encrypting the messages before pushing them to the archive
15:14:03 MattJ Prosody will do things like add a <delay> for messages that have been held by 198
15:14:12 linuxwolf the e2e specs allow for the container to be heavily modified today, so I don't think there's an issue
15:14:13 MattJ so stanzas already get modified en route
15:14:20 Kev linuxwolf: Then we're laughing.
15:14:23 linuxwolf but getting the keys again can be tricky
15:14:34 Kev linuxwolf: Oh, I see what you mean.
15:14:38 MattJ I don't
15:14:49 Kev MattJ: The encrypted messages get archived. How do you read them again?
15:14:53 linuxwolf http://tools.ietf.org/html/draft-miller-xmpp-e2e
15:15:09 MattJ Kev, right... MAM basically hints at not archiving them
15:15:20 linuxwolf that's one solution (-:
15:15:31 MattJ Depending on the actual encryption method used, it may not be possible to read them after the fact
15:15:32 Kev Probably even an acceptable solution.
15:15:40 MattJ and it may not be desired to archive sensitive stuff anyway
15:15:47 MattJ encrypted or not
15:16:00 linuxwolf MattJ: possibly
15:16:14 Kev So, as far as this discussion goes...
15:16:32 Kev Does anyone see issue with the proposal above for getting carbons and MAM working together so clients can have complete history?
15:16:46 MattJ I still have no idea how I'd implement it
15:16:59 MattJ and from a protocol perspective it's not "perfect", but it's workable
15:17:02 Kev Server devs are smart, that's why they get the big bucks.
15:17:03 linuxwolf I can see it working if MAM depends on carbons, maybe
15:17:03 stpeter modulo the e2e stuff, the approach you've outlined above seems workable
15:17:10 MattJ Kev, yeah...
15:17:28 linuxwolf there
15:17:30 linuxwolf gah
15:17:47 linuxwolf there's something else that's started to bother me wrt carbons
15:17:56 MattJ linuxwolf, I don't think there should be a dependency - or maybe I don't understand what you mean
15:18:21 ralphm well, I suppose some of us can attain implementors' experience for the next revision :-)
15:18:46 stpeter :)
15:19:16 linuxwolf MattJ: it might not, I need to think on it some more
15:19:40 linuxwolf so, bothering me: blocking protocols (privacy, shim)
15:19:47 MattJ Yeah
15:19:56 linuxwolf the quick answer is to say don't use both
15:20:01 linuxwolf but I think that's a little too naive
15:20:11 Kev For the stupid amongst us, spell this out please.
15:20:37 linuxwolf your Client1 has a privacy policy, and enables carbons
15:20:52 linuxwolf your Client2 does not have a privacy policy, and enables carbons
15:21:01 linuxwolf you message someone on Client2 that Client1 would block
15:21:27 linuxwolf what happens with the carbons?
15:21:27 MattJ That's why privacy lists is broken (one reason anyway)
15:21:35 MattJ But simple blocking works fine
15:22:09 stpeter nods to MattJ
15:22:13 linuxwolf MattJ: I'll not dispute privacy lists are broken, and simple blocking works fine, but doesn't cover quite enough cases
15:22:16 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?
15:22:43 linuxwolf Kev: outgoing or incoming
15:23:21 Kev Incoming the situation's reasonably straightforward, I'd have thought. You blocked them, you shouldn't get their messages.
15:23:31 Kev I agree that it wouldn't hurt to spell this out somewhere.
15:24:04 linuxwolf now it's about the outgoing from the other client
15:24:10 linuxwolf and how you end up with one side of a conversation
15:24:26 linuxwolf assuming the server doesn't drop the carbons because the message went to a blocked recipient
15:24:32 MattJ Notably with MAM you would always get them
15:24:43 MattJ Because they come from the server's JID, there is no ambiguity
15:25:09 linuxwolf I don't know that I agree with that statement
15:25:16 linuxwolf presumably there's a reason you're blocking them
15:25:22 stpeter notes that we haven't really thought about the interactions between privacy lists, SIFT, Carbons, and MAM
15:25:23 Tobias has joined
15:25:31 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.
15:25:44 linuxwolf just because the container is addressed from the server doesn't mean I won't be offended at seeing the message
15:25:48 Tobias hi
15:25:49 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
15:25:53 linuxwolf Kev: well, I'm not sure what to spec (-:
15:25:54 Kev Tobias: WB.
15:26:06 Tobias my mobile connection was flanky
15:26:08 MattJ linuxwolf, well I'm not saying that you won't be offended, just that's what will undoubtedly happen
15:26:23 linuxwolf MattJ: and I'm not sure that's actually desirable behavior
15:26:35 ralphm is tempted to repeat his previous statement
15:26:43 linuxwolf I could have blocked them because they like to spam me with "CAT FACTS"
15:26:51 linuxwolf but now I get them because I retrieved MAM?
15:27:25 MattJ linuxwolf, yep, well MAM explicitly declares an interest in all your history
15:27:30 linuxwolf it might be these things that wrap other things will need to look deeper
15:27:34 MattJ Though you can filter to a single JID
15:27:39 ralphm agreeing with stpeter, what about having people starting to hack on this
15:27:57 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.
15:27:59 MattJ ralphm, people have started to hack on this, we have client and server implementations of carbons and MAM already
15:28:00 Kev +sp
15:28:06 linuxwolf MattJ: so now I have to manually apply my privacy policies in multiple places?
15:28:19 Zash has joined
15:28:22 Zash What?!
15:28:31 ralphm MattJ: I meant the combination, that you apparently don't know how to do yet.
15:28:35 stpeter I wonder how much cleaner this all gets if we deprecate privacy lists
15:28:51 MattJ linuxwolf, I'm not saying you have to do anything - I'm just saying what will happen :)
15:28:53 linuxwolf stpeter: it might get clearer
15:28:58 Florob has joined
15:29:27 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
15:29:41 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
15:29:45 MattJ stpeter, well I'm hoping to go in that direction
15:29:45 MattJ mod_privacy in Prosody is so complicated because of corner-cases like this
15:30:00 MattJ That was me reconnecting with XEP-0198 :)
15:30:11 linuxwolf nice (-:
15:30:30 linuxwolf for MAM+blocking, this might not be a real problem
15:30:31 Kev stpeter: I'd love to get rid of it.
15:30:36 Kev So, anyway.
15:30:39 Kev We're approaching 30mins.
15:30:40 linuxwolf for carbons+blocking, I've run into some undesirables
15:31:01 Kev I suggest someone produces a strawman that we then discuss.
15:31:17 MattJ linuxwolf, the fact is there's no way you can stretch privacy lists or blocking into looking *inside* messages
15:31:31 linuxwolf MattJ: isn't there? (-:
15:31:33 MattJ Maybe <forward> gets you slightly there
15:31:40 MattJ But I'll regret publishing that spec if it does :P
15:31:42 linuxwolf that's what I was thinking
15:31:51 Kev 3) Date of next meeting.
15:31:53 linuxwolf maybe you need to start regretting then (-:
15:31:54 Kev Fortnight now?
15:32:02 ralphm wfm
15:32:02 MattJ Kev, +1
15:32:04 linuxwolf looks at calendar
15:32:29 linuxwolf 2012-05-09 works for me
15:32:35 Tobias +1
15:32:39 stpeter wfm
15:32:40 Kev 4) AOB?
15:32:46 MattJ As long as it's a Wednesday and 1500 UTC I'm fine
15:33:03 MattJ None here
15:33:05 linuxwolf no
15:33:06 stpeter no AOB here
15:33:08 Tobias no
15:33:25 Kev Righty, we're just over time, on agenda with no actions. Jolly good.
15:33:27 Kev Thanks all.
15:33:30 Kev bangs the gavel.
15:35:15 stpeter calendar updated, time to head into the office, bbiab
15:36:27 stpeter has left
15:38:51 ralphm has left
15:40:16 Zash And now I've read up till the present
15:41:44 Zash MattJ: I poked with priorities so that if MAM stamps an <archived/>, it'll be in any carbon'd message.
15:42:51 MattJ Zash, nice
15:43:01 MattJ that's one problem solved then
15:43:56 Zash Altho, should the <arhived/> be stamped before or after the acual storing fo the message?
15:44:15 linuxwolf probably after
15:44:26 MattJ The tense of the verb suggests that :)
15:44:27 linuxwolf you'd want to try and keep it pristine (-:
15:45:14 Zash One of the things you'll want to describe more closely if you add it back then :)
15:45:46 MattJ Well what does it matter?
15:46:46 Florob I think it should be in the middle
15:47:13 MattJ and a bit to the right
15:47:25 MattJ and sky blue
15:49:48 Zash <message><carbons:recv/><forward><message><arhived/></message></forward></message> <message><mam:result/><forward><message><archived (redundant?)/></message/></forward></message>
15:51:04 linuxwolf has left
15:52:46 linuxwolf has joined
16:02:03 Zash has left
16:02:34 Kev has left
16:02:51 MattJ Ah, I see what you mean
16:03:24 MattJ Yes, that's how the original spec had it - but now we have mam:result I think it shouldn't be stored
16:08:42 Kev has joined
16:36:52 Tobias has left
16:52:36 linuxwolf has left
16:53:57 Tobias has joined
17:02:37 Florob has left
17:18:11 linuxwolf has joined
17:38:43 Zash has joined
19:55:53 linuxwolf has left
20:00:19 linuxwolf has joined
20:42:00 linuxwolf has left
20:44:19 linuxwolf has joined
20:50:16 Tobias has joined
20:59:56 stpeter has joined
21:01:33 linuxwolf has left
21:08:54 Tobias has joined
22:11:04 linuxwolf has joined
22:32:10 stpeter has left
22:48:39 Tobias has left
22:48:40 Tobias has joined
22:48:40 Tobias has left
22:48:42 Tobias has joined
22:48:42 Tobias has left
22:48:44 Tobias has joined
22:48:44 Tobias has left
22:48:46 Tobias has joined
22:48:46 Tobias has left
22:48:49 Tobias has joined
22:48:49 Tobias has left
22:48:52 Tobias has joined
22:48:52 Tobias has left
22:48:54 Tobias has joined
22:48:54 Tobias has left
22:48:55 Tobias has joined
22:48:56 Tobias has left
22:48:57 Tobias has joined
22:48:57 Tobias has left
22:48:59 Tobias has joined
22:48:59 Tobias has left
22:49:01 Tobias has joined
22:49:01 Tobias has left
22:49:03 Tobias has joined
22:49:03 Tobias has left
22:49:05 Tobias has joined
22:49:05 Tobias has left
22:49:07 Tobias has joined
22:49:07 Tobias has left
22:49:09 Tobias has joined
22:49:09 Tobias has left
22:49:37 Tobias has joined
22:50:38 Tobias has left
23:12:54 Zash has left
23:27:45 linuxwolf has left