XMPP Council - 2012-04-25

Right, that's 16:00.

How're we doing for people being here?

/whew

1) Roll call.

present … barely

linuxwolf, here?

Heh

I'm here

hi

Tobias: ?

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

:)

2) Carbons/MAMs.

linuxwolf, hello

I have yet to think about MAM and Carbons

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

I did :)

My thoughts on this are roughly:

not sure about lw

ok, caught up

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.

hi

Tobias, lag worse than waqas :)

Kev: on the face of it, that seems sensible

assuming there's one source for generating the IDs

Right

yes

which means messages get munged

but that's not all that horrible

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

well, munged is probably too strong a word

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

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

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

MattJ: yes

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

Kev: I'm not sure

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

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

That's between the sender and the receiver.

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

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

sure

ok

heh

well

or how Carbons works with e2e for that matter

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

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

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

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

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

so stanzas already get modified en route

linuxwolf: Then we're laughing.

but getting the keys again can be tricky

linuxwolf: Oh, I see what you mean.

I don't

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

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

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

that's one solution (-:

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

Probably even an acceptable solution.

and it may not be desired to archive sensitive stuff anyway

encrypted or not

MattJ: possibly

So, as far as this discussion goes...

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

I still have no idea how I'd implement it

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

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

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

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

Kev, yeah...

there

gah

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

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

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

:)

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

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

Yeah

the quick answer is to say don't use both

but I think that's a little too naive

For the stupid amongst us, spell this out please.

your Client1 has a privacy policy, and enables carbons

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

you message someone on Client2 that Client1 would block

what happens with the carbons?

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

But simple blocking works fine

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

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?

Kev: outgoing or incoming

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

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

now it's about the outgoing from the other client

and how you end up with one side of a conversation

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

Notably with MAM you would always get them

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

I don't know that I agree with that statement

presumably there's a reason you're blocking them

linuxwolf: I'm not sure there's a right and a wrong behaviour here - we just pick something not obviously broken and spec it.

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

hi

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

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

Tobias: WB.

my mobile connection was flanky

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

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

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

but now I get them because I retrieved MAM?

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

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

Though you can filter to a single JID

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

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.

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

+sp

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

What?!

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

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

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

stpeter: it might get clearer

MattJ: and I'm trying to say that might be considered a bug by most others not as close to things as we are

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

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

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

That was me reconnecting with XEP-0198 :)

nice (-:

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

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

So, anyway.

We're approaching 30mins.

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

I suggest someone produces a strawman that we then discuss.

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

MattJ: isn't there? (-:

Maybe <forward> gets you slightly there

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

that's what I was thinking

3) Date of next meeting.

maybe you need to start regretting then (-:

Fortnight now?

wfm

Kev, +1

2012-05-09 works for me

+1

wfm

4) AOB?

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

None here

no

no AOB here

no

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

Thanks all.

calendar updated, time to head into the office, bbiab

And now I've read up till the present

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

Zash, nice

that's one problem solved then

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

probably after

The tense of the verb suggests that :)

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

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

Well what does it matter?

I think it should be in the middle

and a bit to the right

and sky blue

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

Ah, I see what you mean

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