XSF Discussion - 2012-05-05

BrowserID talks in 4 minutes :)

\o/

Florian, You called the meeting, so you get to chair it. :-)

heh, ok

let me pull up the Wiki page at the same time

let's give it another 5 mins ... Ashley wanted to be here

and Matt

Hey Ashley.

hey there

hey

how do we want to proceed?

I was thinking of splitting up the RFP into a few parts

makes sense

1. Technology

2. Goals

should we have a background section?

3. What the XSF offers

Just a question ... have we ascertained that no-one has interest in doing this without the XSF paying for it?

Kev: we haven't, no.

(I won't, so there's not an ulterior motive)

http://piratepad.net/CMPIY1IvOm

I think the thing is, we basically mention in the RFP that the XSF is willing to pay

at the XSF's discretion

so people who apply can mention that they want X amount for it

K.

and then we can decide if that's worth it, or see if we can find another amount that's mutually beneficial

do those 4 sections sound alright?

Kev, I do think we'll need to offer cash in some cases to get things done. In some cases, though, we might not need to - that's good too, of course.

FWIW, I for one was thinking of working on this before payment entered the discussion.

waqas: glad to hear :)

dwd: Right - I'm just raising the issue in case someone is already motivated and the introduction of cash loses us motivation.

Kev: I don't think offering cash would lose motivation

but yeah, should we go through the 4 sections?

starting with Background

Oh, I think there are plenty of cases where it would, but that's OK.

Yes.

Florian, SO the four are background, tech, goals, and what the XSF is offering?

yup, I think that makes sense

maybe time-frame?

however, I think that would fit into goals

Probably.

Does anyone have a clear sense of what the time-frame needs to be?

That is, any existing constraints? (Like, if Mozilla have a clear deadline for getting BrowserID implemented and deployed, say).

i would assume this would line up with mozilla

I don't see a deadline on the page linked on piratepad

https://wiki.mozilla.org/Identity/Features/Sign_into_the_browser

this says FF 15

So presumably we need something working far ahead of that.

Two points I'd like to raise: 1. BrowserID is browser neutral. If Mozilla ends up not integrating our work in Firefox, it would be useful to have it work regardless. A signon solution for XMPP would be valuable for the XMPP community in any case. 2. BroswerID allows a lot of freedom to the authenticating party. Captchas, oauth/facebook/twitter login could be tunneled over it without changing XMPP web apps (which happens to be a much requested feature).

right

(this was in response to Winfried Tilanus's email about risk to the XSF)

Right - it occured to me you also probably need an HTTP based API somewhere for the sites to hit.

dwd: BOSH?

Florian, No, I mean something the sites hit, not something the browser hits direct.

but let's stick with the background part for now

Florian: i was just thinking we could take your board writeup as a background

the blogpost? sure

yeah

alright

anything else for Background?

else let's move on to Technology :)

Florian, So the technology is pretty unconstrained from our poitn of view - we just want XMPP.

right

this may be a goal, but should be internet scale

I think that we should mention that authentication should happen in the "XMPP way"

Well, we want the identity bit of XMPP, while opening the door to using it for other mechanisms later.

as well as federation would be required for this to work

i.e. you can't log in on facebook.com with your Google ID if Facebook doesn't do S2S to google

does that make sense?

But the current BrowserID is based on signing tokens with a private key you hold (which in turn is signed by your provider)

maybe let's skip to Goals first

and come back to technology

that way we know what we want to achieve :)

one goal is obviously authentication

would being able to leverage the XMPP channel for other uses post-authentication be a goal?

The SignIntoBrowser mentions bookmarks and contacts

Ashley: I think so

Ashley, Yes, I think so too.

I think contacts

as well as push

i.e. notifications

yes, notifications would be great

for bookmarks, that's data storage

can we do that somehow with PEP?

i.e. do we want to offer a data storage option?

Florian, We've *got* a bookmarks spec. :-)

and it mentions how to store it in PEP

oh, right ... yeah :D

ok, so let me rephrase that ...

This does increase the scope of the project beyond BrowserID. Would Mozilla buy into that initially?

do we want a data storage option, or "just" bookmark storage?

Florian: Do we need to constrain it? Why not be open-ended and see what response the RFP gets?

sure

well, i think we're just talking about examples of post-auth capabilities over this channel

Ashley: Very probably.

waqas, I don't think we want to paint ourselves into a corner that doesn't include post-auth stuff.

To my mind what we want is:

Also: bookmarks storage. Readable by server admins. I'm not sure how well that would be received, as the existing Firefox bookmark sync stuff makes a point of advertising that it's always encrypted, and they can't see your data.

1) Primary goal: Auth/identity 2) Secondary goals: taking advantage of other data stuff. Examples would include ...

fwiw, i need to head out to schlep kids to soccer

And see what comes back to us.

Kev, Seems reasonable.

Ashley: ok ... thanks for dropping by

Kev: makes sense

sure, let me know what i can do to help after the fact

waqas: Yes. Although I don't think encrypting it is hard, assuming user-held keys of some description.

Yep

ok, does that look alright for the goals?

So it's a good point to include, but not a hard one to address.

Florian: Happy for me to poke at the pp?

sure

that's what it's there for :)

browserID is a quarterly goal for mozilla to be used by all our public facing, needs login web sites

so that means by end of summer it will be all over moz products

bear: thanks for the info :)

tbird has beta code already for "chat" and that includes xmpp

and that beta is going to be releases this quarter also

so I think we should have the RFP deadline for end of May

and then get cracking

Florian: OK, I've poked the pp.

Kev: great :)

Agree/disagree/abort/fail.

Florian, Note that winfried said that if we want to get any funding off NLNet, that's also a June thing.

right

I'll ask this just for the sake of it...are we now scrabbling to join a party we're too late to arrive at?

i.e. is it feasible for us to have anything worthwhile in a timeframe that would influence the outcomes we care about?

do we want to be clear if this is a browserid client part or also the service part?

Kev: I don't think it's too late, as we've got most of the technology already

but we need to get some fancy demos ready relatively quickly to gain attention / traction

browserid itself just became viable the last couple of months

the code was baking internally at moz most of the winter

Well, if Moz want to ship this by end June, and we have an RFP process that ends end May, that gives a month to evaluate RFPs, hire someone, get delivery and influence Moz.

bear, I think we need both parts, don't we?

moz *internally* is pushing for this

s/Moz to ship this/ship this to Moz/

but publicly it's now part of the privacy/persona push that they haven't (or are starting) to push

so we are just a bit ahead of the wave

dwd - I agree

yeah, we need both

but I think the service side exists

as we're just using XMPP, people have Google Accounts

Florian: Probably does, but saying we need both in the RFP makes it clear.

ah, right

bear, We also need to ensure that either the browserid site-side verification can "pass through" to a XMPP based system, or else that a site could hit a browserid verifier specific to that domain.

bear, but are we - as in, do we have time to develop proof-of-concepts, etc.?

If the RFPs come back saying "We just use XMPP server as-is".

+then that's great.

bear, I have to say I prefer the latter. Otherwise the browserid.org service can monitor all the sign-ins...

yes - my hope/goal in this is that xmpp can be used as a site-side verifier

ah, dwd, you added Compatibility with BrowserID ...

mattj - I personally think we are. knowing how moz internals work, they are rarely on time with delivery goals

do we want that, or do we want to define a "new" BrowserID?

bear: Which is useful, thnks.

bear, shocking :P

I would hate if this ends up being a NIH clone of BrowserID

Florian, We want a verifier that's compatible. I don't preclude *other* verifiers...

:)

+1 what dwd said

Florian, That is, we want a verifier that works - potentially - exactly how the existing POST to https://browserid.org/ works, but if there's an "XMPP way", that's also cool. An option here is to encode additional magicks into the Assertion that tell the site about verifier services to use.

I will admit that my bias is that xmpp implements browserid - it would help by adding another open source product that supports the tech which will help Mozilla push it

"XMPP implements browserid" - what does that mean?

bear, You want browserid for signing to XMPP as well? A browserid SASL mech?

In language we can put into the RFP :)

:)

yes, but i'm trying not to influence the current enthusiasm or derail it

This is a completely opposite problem I think, isn't it?

having never even tried to implement one, I don't know

I'm completely outside my comfort zone with webish stuff.

but yes, I suspect it is

But yeah, different (opposite) problem.

Although has fun recursive effects.

I assert, signing into kev@... that I'm me using browserid, for which I assert I'm me using kevin@...

lol

(Completely pointless as we could do this without browserid, but still ...:)

ok, do we have all the information we want in the PP?

Not quite, hang on.

bear, Is there anyone at Mozilla that would be able to publically work with the XSF (and the guys actually doing this coding)?

anyone on the browserid team - they are very open

That would be very useful

#identity channel on irc.mozilla.org

Can't they use XMPP?!

irc is very much part of mozilla's dna

agree

heh

new ways of doing group communication have come and gone, but irc always remains

Good thing no-one suggested IRC for BrowserID. Or did they?

waqas, Authenticate yourself using an unauthenticated network!

hell, if we could give them a browserid auth'd xmpp - irc gateway ...

BrowserID by nickserv. Sounds good to me.

dwd, I'm sure it has been tried

OK. FInal question...

How is the XSF going to decide who gets paid?

I think that's something the board should do

I don't think the Board is qualified to do more than ratify decisions made by more technical people, to be honest.

maybe Board + Council?

we should get the tech council to rank any contenders and if we have the enjoyable problem of having too many to pick...

I'm trying to think of better ways than relying on Council for this, but am struggling to think of something fair.

The Council could. Or the Board could pick a set of bodies to do the selection.

Some faux-Council chosen by Board is more contentious but probably also more reasonable.

each bounty item should have a clear spec - so that it's a simple checklist to see if they met the requirements

dwd: that might be a possibility too ... as that would allow us to maybe get input from Mozilla people as well

Kev, I don't think we can reasonably achieve actual fairness.

i.e. we can have someone from the Mozilla BrowserID team give his input on the projects

Florian, Good point, I'd not thought of that.

once we get the rfp in place, I can definitely ask if one of them would like to help be a tech reviewer

so, I'd say the Board should go out and find a group of maybe 5 people, comprising of Council / Board and "industry experts" :)

and they need to not be people who might submit a proposal themselves (obviously)

I think it's important to have at least 1 board and 1 council member on it though, as the aim is to push forward XMPP

MattJ: correct

MattJ, I'm not sure that's needed. They can't be asking for cash, though they could be offering to do the work gratis.

dwd: fair point

Sure it is.

You can't preclude someone else getting paid.

Kev: huh?

Matt suggested people judging the proposals shouldn't be people themselves submitting proposals. Dave said that was ok if the proposals weren't paid. I said it wasn't.

I think it is

(As choosing your own project precludes someone else getting paid for theirs)

right

hence what Dave said makes sense

they can be on the judging panel if their project idea is not being compensated by the XSF

I think Kev is worried that a judge might pick their own gratis work to avoid the XSF from having to pay the bounty

or the appearance that is happening

well, the XSF will accept all gratis work

bear: Not that, actually, but a) the appearance is horrid and b) There's more benefit to the winner here than just getting paid.

or at least I think it should

Kev, Right, I suppose it's worth avoiding if possible.

we don't have a limited amount of slots for projects

If a consultant got selected by the XSF to do this, the work went into Mozilla off the back of that, etc., that's a hell of an advert for that consultant. Worth more than the amount we would have paid, I suspect.

yes, moz tends to hire folks who are good contributors

(as contractors or staff)

hmm, ok

so should we not allow that, or just prefer not to have that

Florian: A bit like if it was left up to the Council Chair to select an official XMPP library - Swiften's available free, so it's fine for me to choose that :)

Kev: right

I think we should avoid it.

ok

I don't think we have so many people on Board/Council who'll be putting their names down for this.

yes, when money is involved, we should be 110% clear of those kind of implications

"Jury member can't submit a project."

do we want to even begin to say what OS licenses should be used?

hmm

bear: License of the XSF's choice, to be decided later.

then we need to be clear that they are giving the XSF all rights to the code

We're going to want something entirely permissive.

right

anyone want to add that to the Legal Mumbo Jumbo section?

I'd suggest two-clause BSD or MIT, although three-clause BSD is probably OK.

but I can how others may not be ;)

I'd like something more permissive than that if we're looking at stumping up money for this.

I think that the way bear put it is fine

the XSF gets ownership as this can be seen as contract work

i.e. we're paying people

and the free work can be seen as donations

so I think that makes sense and gives us freedom

we may need to get peter to run this by whatever lawyer the xsf uses

right

Right.

I have to admit I don't care - in many respects I'd like to avoid assignment if at all possible.

ok, I think we have a good start though

I think requiring a very liberal license is adequate.

dwd - true, just avoiding some messy downstream issues if we say "xsf owns all" and then we assign it a BSD license

bear: right

ok, I think we have a good start here

hmm, but I will defer to the lawyer because I can see a scenario where doing that opens us up to more grief

I'd say the next step is to write this up properly ...

on the wiki

any volunteers?

I'd prefer liberal license to assignment, FWIW, but hills, etc.

I'm happy to write the background / what xsf can offer and legal part

do we need to do more than just cut-n-paste this into a concept/outline page?

I think we should write this up

bear, My problem with assignment is that in the UK, for example, it requires a formal Statutory Instrument, whereas in Canada, you cannot enforce an assignment clause before the fact - it's just legally a bit of a minefield.

dwd - understood, I changed my mind about it as I thought about it more than a few seconds

florian - i'll start transfering it to the wiki

alright

most of it will be brought over the same, just will fill in some words

as I said, I'm more than happy doing the texts for Background, what xsf offers and legal stuff

cool

would be great if some people could sit down and write up the 2 other parts

Any volunteers?

let me get this first draft on the wiki

http://wiki.xmpp.org/web/BID-RFP

anyone willing to write Technology / Goals?

I'm not offering to do anything for fear that I won't complete it.

both of those are part of the etherpad - they just need filling out with more detail

Right, I'll do some work over it.

dwd: awesome, thanks :)

so one last thing ... time?

should we say, all written up by wednesday?

and then another meeting here?

We can do that, I think.

alright ....

AOB?

But maybe arrange the meeting time on a list, to ensure we get everyone who wants to come here.

dwd: sure

alright, I think with 1h30m ... it's time to end :)

Florian, Thanks!

thanks all!

I'll send a mail to the list later

members, jdev, standards, jadmin

ok, wiki now has the etherpad contents

great!

thanks bear

thanks all !

Next meeting wednesday ... tbc

thanks

Ta.

Young man, there's a place you can go

Young man, there's a place you can go

You can stay there and I'm sure you will find Many ways to have a good time

It's fun to stay at the X.S.F

It's fun to stay at the X.S.F

They have everything for young men to enjoy

They have everything for young men to enjoy

Jef, I think you'll find that XMPP is a better acronym for YMCA parodies.

Or IETF, or indeed any four letter acronym.

lol

;)

Eeee Tee Ell Aaay

in some ways I am glad I had no idea what he was referencing