dwdFlorian, You called the meeting, so you get to chair it. :-)
Florianheh, ok
Florianlet me pull up the Wiki page at the same time
Florianlet's give it another 5 mins ... Ashley wanted to be here
Florianand Matt
Ashleyhas joined
dwdHey Ashley.
Ashleyhey there
Florianhey
Ashleyhow do we want to proceed?
FlorianI was thinking of splitting up the RFP into a few parts
Ashleymakes sense
Florian1. Technology
Florian2. Goals
Link Mauvehas joined
Ashleyshould we have a background section?
Florian3. What the XSF offers
KevJust a question ... have we ascertained that no-one has interest in doing this without the XSF paying for it?
Tobiashas joined
FlorianKev: we haven't, no.
Kev(I won't, so there's not an ulterior motive)
Florianhttp://piratepad.net/CMPIY1IvOm
FlorianI think the thing is, we basically mention in the RFP that the XSF is willing to pay
Florianat the XSF's discretion
Florianso people who apply can mention that they want X amount for it
KevK.
Florianand then we can decide if that's worth it, or see if we can find another amount that's mutually beneficial
waqashas joined
Floriando those 4 sections sound alright?
dwdKev, 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.
waqasFWIW, I for one was thinking of working on this before payment entered the discussion.
Jefhas joined
Florianwaqas: glad to hear :)
Kevdwd: Right - I'm just raising the issue in case someone is already motivated and the introduction of cash loses us motivation.
FlorianKev: I don't think offering cash would lose motivation
Florianbut yeah, should we go through the 4 sections?
Florianstarting with Background
KevOh, I think there are plenty of cases where it would, but that's OK.
KevYes.
dwdFlorian, SO the four are background, tech, goals, and what the XSF is offering?
Florianyup, I think that makes sense
Florianmaybe time-frame?
Florianhowever, I think that would fit into goals
dwdProbably.
dwdDoes anyone have a clear sense of what the time-frame needs to be?
dwdThat is, any existing constraints? (Like, if Mozilla have a clear deadline for getting BrowserID implemented and deployed, say).
akuckartzhas left
Ashleyi would assume this would line up with mozilla
FlorianI don't see a deadline on the page linked on piratepad
KevSo presumably we need something working far ahead of that.
waqasTwo 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).
Florianright
waqas(this was in response to Winfried Tilanus's email about risk to the XSF)
dwdRight - it occured to me you also probably need an HTTP based API somewhere for the sites to hit.
Floriandwd: BOSH?
dwdFlorian, No, I mean something the sites hit, not something the browser hits direct.
Florianbut let's stick with the background part for now
AshleyFlorian: i was just thinking we could take your board writeup as a background
Florianthe blogpost? sure
Ashleyyeah
Florianalright
Floriananything else for Background?
Florianelse let's move on to Technology :)
Medicshas joined
dwdFlorian, So the technology is pretty unconstrained from our poitn of view - we just want XMPP.
Florianright
Ashleythis may be a goal, but should be internet scale
FlorianI think that we should mention that authentication should happen in the "XMPP way"
KevWell, we want the identity bit of XMPP, while opening the door to using it for other mechanisms later.
Florianas well as federation would be required for this to work
Floriani.e. you can't log in on facebook.com with your Google ID if Facebook doesn't do S2S to google
Floriandoes that make sense?
ZashBut the current BrowserID is based on signing tokens with a private key you hold (which in turn is signed by your provider)
koskihas joined
Florianmaybe let's skip to Goals first
Florianand come back to technology
Florianthat way we know what we want to achieve :)
Florianone goal is obviously authentication
Ashleywould being able to leverage the XMPP channel for other uses post-authentication be a goal?
ZashThe SignIntoBrowser mentions bookmarks and contacts
FlorianAshley: I think so
dwdAshley, Yes, I think so too.
FlorianI think contacts
Florianas well as push
Floriani.e. notifications
Ashleyyes, notifications would be great
Florianfor bookmarks, that's data storage
Floriancan we do that somehow with PEP?
Floriani.e. do we want to offer a data storage option?
dwdFlorian, We've *got* a bookmarks spec. :-)
Zashand it mentions how to store it in PEP
Florianoh, right ... yeah :D
Florianok, so let me rephrase that ...
waqasThis does increase the scope of the project beyond BrowserID. Would Mozilla buy into that initially?
Floriando we want a data storage option, or "just" bookmark storage?
KevFlorian: Do we need to constrain it? Why not be open-ended and see what response the RFP gets?
Floriansure
Ashleywell, i think we're just talking about examples of post-auth capabilities over this channel
KevAshley: Very probably.
dwdwaqas, I don't think we want to paint ourselves into a corner that doesn't include post-auth stuff.
KevTo my mind what we want is:
waqasAlso: 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.
Kev1) Primary goal: Auth/identity
2) Secondary goals: taking advantage of other data stuff. Examples would include ...
Ashleyfwiw, i need to head out to schlep kids to soccer
KevAnd see what comes back to us.
dwdKev, Seems reasonable.
FlorianAshley: ok ... thanks for dropping by
FlorianKev: makes sense
Ashleysure, let me know what i can do to help after the fact
Kevwaqas: Yes. Although I don't think encrypting it is hard, assuming user-held keys of some description.
Ashleyhas left
waqasYep
Florianok, does that look alright for the goals?
KevSo it's a good point to include, but not a hard one to address.
KevFlorian: Happy for me to poke at the pp?
bearis late -sorry
Floriansure
Florianthat's what it's there for :)
MattJhas joined
bearbrowserID is a quarterly goal for mozilla to be used by all our public facing, needs login web sites
bearso that means by end of summer it will be all over moz products
Florianbear: thanks for the info :)
beartbird has beta code already for "chat" and that includes xmpp
bearand that beta is going to be releases this quarter also
Florianso I think we should have the RFP deadline for end of May
Florianand then get cracking
KevFlorian: OK, I've poked the pp.
FlorianKev: great :)
KevAgree/disagree/abort/fail.
dwdFlorian, Note that winfried said that if we want to get any funding off NLNet, that's also a June thing.
Florianright
KevI'll ask this just for the sake of it...are we now scrabbling to join a party we're too late to arrive at?
Kevi.e. is it feasible for us to have anything worthwhile in a timeframe that would influence the outcomes we care about?
beardo we want to be clear if this is a browserid client part or also the service part?
FlorianKev: I don't think it's too late, as we've got most of the technology already
Florianbut we need to get some fancy demos ready relatively quickly to gain attention / traction
bearbrowserid itself just became viable the last couple of months
bearthe code was baking internally at moz most of the winter
KevWell, 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.
dwdbear, I think we need both parts, don't we?
bearmoz *internally* is pushing for this
Kevs/Moz to ship this/ship this to Moz/
bearbut publicly it's now part of the privacy/persona push that they haven't (or are starting) to push
bearso we are just a bit ahead of the wave
beardwd - I agree
Florianyeah, we need both
Florianbut I think the service side exists
Florianas we're just using XMPP, people have Google Accounts
KevFlorian: Probably does, but saying we need both in the RFP makes it clear.
Florianah, right
dwdbear, 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.
MattJbear, but are we - as in, do we have time to develop proof-of-concepts, etc.?
KevIf the RFPs come back saying "We just use XMPP server as-is".
Kev+then that's great.
dwdbear, I have to say I prefer the latter. Otherwise the browserid.org service can monitor all the sign-ins...
bearyes - my hope/goal in this is that xmpp can be used as a site-side verifier
Florianah, dwd, you added Compatibility with BrowserID ...
bearmattj - I personally think we are. knowing how moz internals work, they are rarely on time with delivery goals
Floriando we want that, or do we want to define a "new" BrowserID?
Kevbear: Which is useful, thnks.
MattJbear, shocking :P
bearI would hate if this ends up being a NIH clone of BrowserID
dwdFlorian, We want a verifier that's compatible. I don't preclude *other* verifiers...
bearlikes how dwd said it
Florian:)
koski+1 what dwd said
dwdFlorian, 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.
bearI 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
Kev"XMPP implements browserid" - what does that mean?
dwdbear, You want browserid for signing to XMPP as well? A browserid SASL mech?
KevIn language we can put into the RFP :)
Florian:)
bearyes, but i'm trying not to influence the current enthusiasm or derail it
KevThis is a completely opposite problem I think, isn't it?
bearhaving never even tried to implement one, I don't know
KevI'm completely outside my comfort zone with webish stuff.
bearbut yes, I suspect it is
bearsmacks his own hand for even bringing it up
dwdwould note that a browserid SASL mech is pretty simple.
dwdBut yeah, different (opposite) problem.
KevAlthough has fun recursive effects.
KevI assert, signing into kev@... that I'm me using browserid, for which I assert I'm me using kevin@...
bearlaughs
Florianlol
Kev(Completely pointless as we could do this without browserid, but still ...:)
Florianok, do we have all the information we want in the PP?
dwdNot quite, hang on.
dwdbear, Is there anyone at Mozilla that would be able to publically work with the XSF (and the guys actually doing this coding)?
bearanyone on the browserid team - they are very open
waqasThat would be very useful
bear#identity channel on irc.mozilla.org
dwdCan't they use XMPP?!
bearirc is very much part of mozilla's dna
dwdwould like to design a retrovirus to recode that.
bearagree
Florianheh
bearnew ways of doing group communication have come and gone, but irc always remains
waqasGood thing no-one suggested IRC for BrowserID. Or did they?
dwdwaqas, Authenticate yourself using an unauthenticated network!
bearhell, if we could give them a browserid auth'd xmpp - irc gateway ...
KevBrowserID by nickserv. Sounds good to me.
waqasdwd, I'm sure it has been tried
dwdOK. FInal question...
dwdHow is the XSF going to decide who gets paid?
FlorianI think that's something the board should do
dwdI don't think the Board is qualified to do more than ratify decisions made by more technical people, to be honest.
Florianmaybe Board + Council?
bearwe should get the tech council to rank any contenders and if we have the enjoyable problem of having too many to pick...
KevI'm trying to think of better ways than relying on Council for this, but am struggling to think of something fair.
dwdThe Council could. Or the Board could pick a set of bodies to do the selection.
KevSome faux-Council chosen by Board is more contentious but probably also more reasonable.
beareach bounty item should have a clear spec - so that it's a simple checklist to see if they met the requirements
Floriandwd: that might be a possibility too ... as that would allow us to maybe get input from Mozilla people as well
dwdKev, I don't think we can reasonably achieve actual fairness.
Floriani.e. we can have someone from the Mozilla BrowserID team give his input on the projects
dwdFlorian, Good point, I'd not thought of that.
bearonce we get the rfp in place, I can definitely ask if one of them would like to help be a tech reviewer
Florianso, I'd say the Board should go out and find a group of maybe 5 people, comprising of Council / Board and "industry experts" :)
MattJand they need to not be people who might submit a proposal themselves (obviously)
FlorianI 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
FlorianMattJ: correct
dwdMattJ, I'm not sure that's needed. They can't be asking for cash, though they could be offering to do the work gratis.
Floriandwd: fair point
KevSure it is.
KevYou can't preclude someone else getting paid.
FlorianKev: huh?
KevMatt 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.
FlorianI think it is
Kev(As choosing your own project precludes someone else getting paid for theirs)
Florianright
Florianhence what Dave said makes sense
Florianthey can be on the judging panel if their project idea is not being compensated by the XSF
bearI think Kev is worried that a judge might pick their own gratis work to avoid the XSF from having to pay the bounty
bearor the appearance that is happening
Florianwell, the XSF will accept all gratis work
Kevbear: Not that, actually, but a) the appearance is horrid and b) There's more benefit to the winner here than just getting paid.
Florianor at least I think it should
dwdKev, Right, I suppose it's worth avoiding if possible.
Florianwe don't have a limited amount of slots for projects
KevIf 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.
bearyes, moz tends to hire folks who are good contributors
bear(as contractors or staff)
Florianhmm, ok
Florianso should we not allow that, or just prefer not to have that
KevFlorian: 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 :)
FlorianKev: right
KevI think we should avoid it.
Florianok
KevI don't think we have so many people on Board/Council who'll be putting their names down for this.
bearyes, when money is involved, we should be 110% clear of those kind of implications
Florian"Jury member can't submit a project."
beardo we want to even begin to say what OS licenses should be used?
Florianhmm
Kevbear: License of the XSF's choice, to be decided later.
bearthen we need to be clear that they are giving the XSF all rights to the code
KevWe're going to want something entirely permissive.
Florianright
Floriananyone want to add that to the Legal Mumbo Jumbo section?
KevI'd suggest two-clause BSD or MIT, although three-clause BSD is probably OK.
bearis a fan of MPLv2
bearbut I can how others may not be ;)
KevI'd like something more permissive than that if we're looking at stumping up money for this.
bearnods
FlorianI think that the way bear put it is fine
Florianthe XSF gets ownership as this can be seen as contract work
Floriani.e. we're paying people
Florianand the free work can be seen as donations
Florianso I think that makes sense and gives us freedom
bearwe may need to get peter to run this by whatever lawyer the xsf uses
Florianright
KevRight.
dwdI have to admit I don't care - in many respects I'd like to avoid assignment if at all possible.
Florianok, I think we have a good start though
dwdI think requiring a very liberal license is adequate.
beardwd - true, just avoiding some messy downstream issues if we say "xsf owns all" and then we assign it a BSD license
Florianbear: right
Florianok, I think we have a good start here
bearhmm, but I will defer to the lawyer because I can see a scenario where doing that opens us up to more grief
FlorianI'd say the next step is to write this up properly ...
Florianon the wiki
Florianany volunteers?
KevI'd prefer liberal license to assignment, FWIW, but hills, etc.
FlorianI'm happy to write the background / what xsf can offer and legal part
bearflips and joins dwd and kev
beardo we need to do more than just cut-n-paste this into a concept/outline page?
FlorianI think we should write this up
dwdbear, 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.
beardwd - understood, I changed my mind about it as I thought about it more than a few seconds
bearflorian - i'll start transfering it to the wiki
Florianalright
bearmost of it will be brought over the same, just will fill in some words
Florianas I said, I'm more than happy doing the texts for Background, what xsf offers and legal stuff
bearcool
Florianwould be great if some people could sit down and write up the 2 other parts
dwdAny volunteers?
bearlet me get this first draft on the wiki
Florianhttp://wiki.xmpp.org/web/BID-RFP
Floriananyone willing to write Technology / Goals?
KevI'm not offering to do anything for fear that I won't complete it.
bearboth of those are part of the etherpad - they just need filling out with more detail
dwdRight, I'll do some work over it.
Floriandwd: awesome, thanks :)
Florianso one last thing ... time?
Florianshould we say, all written up by wednesday?
Florianand then another meeting here?
dwdWe can do that, I think.
Florianalright ....
FlorianAOB?
dwdBut maybe arrange the meeting time on a list, to ensure we get everyone who wants to come here.
Floriandwd: sure
Florianalright, I think with 1h30m ... it's time to end :)
dwdFlorian, Thanks!
Florianthanks all!
FlorianI'll send a mail to the list later
Florianmembers, jdev, standards, jadmin
bearok, wiki now has the etherpad contents
Floriangreat!
Florianthanks bear
Florianthanks all !
FlorianNext meeting wednesday ... tbc
bearthanks
KevTa.
Florianhas left
koskihas left
Jefhas left
Jefhas joined
Jefhas left
Jefhas joined
Jefhas left
Jefhas joined
winfriedhas left
waqashas joined
Medicshas left
Tobiashas joined
JefYoung man, there's a place you can go
JefYoung man, there's a place you can go
JefYou can stay there and I'm sure you will find
Many ways to have a good time
JefIt's fun to stay at the X.S.F
JefIt's fun to stay at the X.S.F
JefThey have everything for young men to enjoy
JefThey have everything for young men to enjoy
dwdJef, I think you'll find that XMPP is a better acronym for YMCA parodies.
dwdOr IETF, or indeed any four letter acronym.
Jeflol
MiGri;)
KevEeee Tee Ell Aaay
bearin some ways I am glad I had no idea what he was referencing
XSF Discussion - 2012-05-05