MattJDid you read my email about the MAM + Carbons overlap?
stpeterI did :)
KevMy thoughts on this are roughly:
linuxwolfgoes back to email quickly
stpeternot sure about lw
linuxwolfok, caught up
Kev1) 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
MattJTobias, lag worse than waqas :)
stpeterKev: on the face of it, that seems sensible
linuxwolfassuming there's one source for generating the IDs
linuxwolfwhich means messages get munged
linuxwolfbut that's not all that horrible
Kevlinuxwolf: Right. If you're talking about MAM on remote services (such as MUCs) then you need to query those independently.
linuxwolfwell, munged is probably too strong a word
MattJIt 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
stpeterlet's ask Jer why he didn't include message IDs back in 1999 :)
Kevlinuxwolf: You mean that all messages get an <archived-by/> element?
KevMattJ: Although presumably it only needs you to have mod_stanza_id and for both the other mods to use that?
linuxwolfKev: I'm not sure
linuxwolfat the very least, the 'id' attribute will be changed
Kevlinuxwolf: I'm not talking about using the stanza id.
KevThat's between the sender and the receiver.
KevI mean we have <archived by="myserver" id="ouaur.uh"/> injected.
KevSo you can perform queries against MAM using the right id.
linuxwolfponders how this works with e2e
MattJor how Carbons works with e2e for that matter
linuxwolfI don't think it's actually a problem ...
Kevlinuxwolf: e2e needs to deal with the stanzas being modified inflight :)
stpeterif you recall, XEP-0136 had all sorts of interesting features for encrypting the messages before pushing them to the archive
MattJProsody will do things like add a <delay> for messages that have been held by 198
linuxwolfthe e2e specs allow for the container to be heavily modified today, so I don't think there's an issue
MattJso stanzas already get modified en route
Kevlinuxwolf: Then we're laughing.
linuxwolfbut getting the keys again can be tricky
Kevlinuxwolf: Oh, I see what you mean.
KevMattJ: The encrypted messages get archived. How do you read them again?
linuxwolfthe quick answer is to say don't use both
linuxwolfbut I think that's a little too naive
KevFor the stupid amongst us, spell this out please.
linuxwolfyou message someone on Client2 that Client1 would block
linuxwolfwhat happens with the carbons?
MattJThat's why privacy lists is broken (one reason anyway)
MattJBut simple blocking works fine
stpeternods to MattJ
linuxwolfMattJ: I'll not dispute privacy lists are broken, and simple blocking works fine, but doesn't cover quite enough cases
KevSo 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?
linuxwolfKev: outgoing or incoming
KevIncoming the situation's reasonably straightforward, I'd have thought. You blocked them, you shouldn't get their messages.
KevI agree that it wouldn't hurt to spell this out somewhere.
linuxwolfnow it's about the outgoing from the other client
linuxwolfand how you end up with one side of a conversation
linuxwolfassuming the server doesn't drop the carbons because the message went to a blocked recipient
MattJNotably with MAM you would always get them
MattJBecause they come from the server's JID, there is no ambiguity
linuxwolfI don't know that I agree with that statement
linuxwolfpresumably there's a reason you're blocking them
stpeternotes that we haven't really thought about the interactions between privacy lists, SIFT, Carbons, and MAM
Kevlinuxwolf: I'm not sure there's a right and a wrong behaviour here - we just pick something not obviously broken and spec it.
linuxwolfjust because the container is addressed from the server doesn't mean I won't be offended at seeing the message
MattJlinuxwolf, 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
linuxwolfKev: well, I'm not sure what to spec (-:
Tobiasmy mobile connection was flanky
MattJlinuxwolf, well I'm not saying that you won't be offended, just that's what will undoubtedly happen
linuxwolfMattJ: and I'm not sure that's actually desirable behavior
ralphmis tempted to repeat his previous statement
linuxwolfI could have blocked them because they like to spam me with "CAT FACTS"
linuxwolfbut now I get them because I retrieved MAM?
MattJlinuxwolf, yep, well MAM explicitly declares an interest in all your history
linuxwolfit might be these things that wrap other things will need to look deeper
MattJThough you can filter to a single JID
ralphmagreeing with stpeter, what about having people starting to hack on this
KevMattJ: Yes, but surely if you say "block all stanzas from this user", they shouldn't get as far as MAM to be later retreived.
MattJralphm, people have started to hack on this, we have client and server implementations of carbons and MAM already
linuxwolfMattJ: so now I have to manually apply my privacy policies in multiple places?
ralphmMattJ: I meant the combination, that you apparently don't know how to do yet.
stpeterI wonder how much cleaner this all gets if we deprecate privacy lists
MattJlinuxwolf, I'm not saying you have to do anything - I'm just saying what will happen :)
linuxwolfstpeter: it might get clearer
linuxwolfMattJ: and I'm trying to say that might be considered a bug by most others not as close to things as we are
stpeterI'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
MattJstpeter, well I'm hoping to go in that direction
MattJmod_privacy in Prosody is so complicated because of corner-cases like this
MattJThat was me reconnecting with XEP-0198 :)
linuxwolffor MAM+blocking, this might not be a real problem
Kevstpeter: I'd love to get rid of it.
KevWe're approaching 30mins.
linuxwolffor carbons+blocking, I've run into some undesirables
KevI suggest someone produces a strawman that we then discuss.
MattJlinuxwolf, the fact is there's no way you can stretch privacy lists or blocking into looking *inside* messages
linuxwolfMattJ: isn't there? (-:
MattJMaybe <forward> gets you slightly there
MattJBut I'll regret publishing that spec if it does :P
linuxwolfthat's what I was thinking
Kev3) Date of next meeting.
linuxwolfmaybe you need to start regretting then (-:
linuxwolflooks at calendar
linuxwolf2012-05-09 works for me
MattJAs long as it's a Wednesday and 1500 UTC I'm fine
stpeterno AOB here
KevRighty, we're just over time, on agenda with no actions. Jolly good.
Kevbangs the gavel.
stpetercalendar updated, time to head into the office, bbiab
ZashAnd now I've read up till the present
ZashMattJ: I poked with priorities so that if MAM stamps an <archived/>, it'll be in any carbon'd message.
MattJthat's one problem solved then
ZashAltho, should the <arhived/> be stamped before or after the acual storing fo the message?
MattJThe tense of the verb suggests that :)
linuxwolfyou'd want to try and keep it pristine (-:
ZashOne of the things you'll want to describe more closely if you add it back then :)