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