XSF Discussion - 2012-05-05

  1. Jef has joined

  2. waqas has joined

  3. Neustradamus has joined

  4. Neustradamus has left

  5. Neustradamus has left

  6. Neustradamus has joined

  7. waqas has joined

  8. Neustradamus has left

  9. Neustradamus has joined

  10. Jef has left

  11. Dan Siemon has joined

  12. Dan Siemon has left

  13. Jef has joined

  14. Jef has left

  15. Jef has joined

  16. Jef has left

  17. akuckartz@jabber.org has joined

  18. akuckartz has joined

  19. Zash has joined

  20. winfried has joined

  21. waqas has joined

  22. waqas has left

  23. Florian has joined

  24. Florian

    BrowserID talks in 4 minutes :)

  25. Zash


  26. dwd

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

  27. Florian

    heh, ok

  28. Florian

    let me pull up the Wiki page at the same time

  29. Florian

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

  30. Florian

    and Matt

  31. Ashley has joined

  32. dwd

    Hey Ashley.

  33. Ashley

    hey there

  34. Florian


  35. Ashley

    how do we want to proceed?

  36. Florian

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

  37. Ashley

    makes sense

  38. Florian

    1. Technology

  39. Florian

    2. Goals

  40. Link Mauve has joined

  41. Ashley

    should we have a background section?

  42. Florian

    3. What the XSF offers

  43. Kev

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

  44. Tobias has joined

  45. Florian

    Kev: we haven't, no.

  46. Kev

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

  47. Florian


  48. Florian

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

  49. Florian

    at the XSF's discretion

  50. Florian

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

  51. Kev


  52. Florian

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

  53. waqas has joined

  54. Florian

    do those 4 sections sound alright?

  55. dwd

    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.

  56. waqas

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

  57. Jef has joined

  58. Florian

    waqas: glad to hear :)

  59. Kev

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

  60. Florian

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

  61. Florian

    but yeah, should we go through the 4 sections?

  62. Florian

    starting with Background

  63. Kev

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

  64. Kev


  65. dwd

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

  66. Florian

    yup, I think that makes sense

  67. Florian

    maybe time-frame?

  68. Florian

    however, I think that would fit into goals

  69. dwd


  70. dwd

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

  71. dwd

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

  72. akuckartz has left

  73. Ashley

    i would assume this would line up with mozilla

  74. Florian

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

  75. Ashley


  76. Ashley

    this says FF 15

  77. Kev

    So presumably we need something working far ahead of that.

  78. waqas

    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).

  79. Florian


  80. waqas

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

  81. dwd

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

  82. Florian

    dwd: BOSH?

  83. dwd

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

  84. Florian

    but let's stick with the background part for now

  85. Ashley

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

  86. Florian

    the blogpost? sure

  87. Ashley


  88. Florian


  89. Florian

    anything else for Background?

  90. Florian

    else let's move on to Technology :)

  91. Medics has joined

  92. dwd

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

  93. Florian


  94. Ashley

    this may be a goal, but should be internet scale

  95. Florian

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

  96. Kev

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

  97. Florian

    as well as federation would be required for this to work

  98. Florian

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

  99. Florian

    does that make sense?

  100. Zash

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

  101. koski has joined

  102. Florian

    maybe let's skip to Goals first

  103. Florian

    and come back to technology

  104. Florian

    that way we know what we want to achieve :)

  105. Florian

    one goal is obviously authentication

  106. Ashley

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

  107. Zash

    The SignIntoBrowser mentions bookmarks and contacts

  108. Florian

    Ashley: I think so

  109. dwd

    Ashley, Yes, I think so too.

  110. Florian

    I think contacts

  111. Florian

    as well as push

  112. Florian

    i.e. notifications

  113. Ashley

    yes, notifications would be great

  114. Florian

    for bookmarks, that's data storage

  115. Florian

    can we do that somehow with PEP?

  116. Florian

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

  117. dwd

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

  118. Zash

    and it mentions how to store it in PEP

  119. Florian

    oh, right ... yeah :D

  120. Florian

    ok, so let me rephrase that ...

  121. waqas

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

  122. Florian

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

  123. Kev

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

  124. Florian


  125. Ashley

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

  126. Kev

    Ashley: Very probably.

  127. dwd

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

  128. Kev

    To my mind what we want is:

  129. waqas

    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.

  130. Kev

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

  131. Ashley

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

  132. Kev

    And see what comes back to us.

  133. dwd

    Kev, Seems reasonable.

  134. Florian

    Ashley: ok ... thanks for dropping by

  135. Florian

    Kev: makes sense

  136. Ashley

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

  137. Kev

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

  138. Ashley has left

  139. waqas


  140. Florian

    ok, does that look alright for the goals?

  141. Kev

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

  142. Kev

    Florian: Happy for me to poke at the pp?

  143. bear is late -sorry

  144. Florian


  145. Florian

    that's what it's there for :)

  146. MattJ has joined

  147. bear

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

  148. bear

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

  149. Florian

    bear: thanks for the info :)

  150. bear

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

  151. bear

    and that beta is going to be releases this quarter also

  152. Florian

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

  153. Florian

    and then get cracking

  154. Kev

    Florian: OK, I've poked the pp.

  155. Florian

    Kev: great :)

  156. Kev


  157. dwd

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

  158. Florian


  159. Kev

    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?

  160. Kev

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

  161. bear

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

  162. Florian

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

  163. Florian

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

  164. bear

    browserid itself just became viable the last couple of months

  165. bear

    the code was baking internally at moz most of the winter

  166. Kev

    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.

  167. dwd

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

  168. bear

    moz *internally* is pushing for this

  169. Kev

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

  170. bear

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

  171. bear

    so we are just a bit ahead of the wave

  172. bear

    dwd - I agree

  173. Florian

    yeah, we need both

  174. Florian

    but I think the service side exists

  175. Florian

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

  176. Kev

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

  177. Florian

    ah, right

  178. dwd

    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.

  179. MattJ

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

  180. Kev

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

  181. Kev

    +then that's great.

  182. dwd

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

  183. bear

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

  184. Florian

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

  185. bear

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

  186. Florian

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

  187. Kev

    bear: Which is useful, thnks.

  188. MattJ

    bear, shocking :P

  189. bear

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

  190. dwd

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

  191. bear likes how dwd said it

  192. Florian


  193. koski

    +1 what dwd said

  194. dwd

    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.

  195. bear

    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

  196. Kev

    "XMPP implements browserid" - what does that mean?

  197. dwd

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

  198. Kev

    In language we can put into the RFP :)

  199. Florian


  200. bear

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

  201. Kev

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

  202. bear

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

  203. Kev

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

  204. bear

    but yes, I suspect it is

  205. bear smacks his own hand for even bringing it up

  206. dwd would note that a browserid SASL mech is pretty simple.

  207. dwd

    But yeah, different (opposite) problem.

  208. Kev

    Although has fun recursive effects.

  209. Kev

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

  210. bear laughs

  211. Florian


  212. Kev

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

  213. Florian

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

  214. dwd

    Not quite, hang on.

  215. dwd

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

  216. bear

    anyone on the browserid team - they are very open

  217. waqas

    That would be very useful

  218. bear

    #identity channel on irc.mozilla.org

  219. dwd

    Can't they use XMPP?!

  220. bear

    irc is very much part of mozilla's dna

  221. dwd would like to design a retrovirus to recode that.

  222. bear


  223. Florian


  224. bear

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

  225. waqas

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

  226. dwd

    waqas, Authenticate yourself using an unauthenticated network!

  227. bear

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

  228. Kev

    BrowserID by nickserv. Sounds good to me.

  229. waqas

    dwd, I'm sure it has been tried

  230. dwd

    OK. FInal question...

  231. dwd

    How is the XSF going to decide who gets paid?

  232. Florian

    I think that's something the board should do

  233. dwd

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

  234. Florian

    maybe Board + Council?

  235. bear

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

  236. Kev

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

  237. dwd

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

  238. Kev

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

  239. bear

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

  240. Florian

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

  241. dwd

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

  242. Florian

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

  243. dwd

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

  244. bear

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

  245. Florian

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

  246. MattJ

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

  247. Florian

    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

  248. Florian

    MattJ: correct

  249. dwd

    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.

  250. Florian

    dwd: fair point

  251. Kev

    Sure it is.

  252. Kev

    You can't preclude someone else getting paid.

  253. Florian

    Kev: huh?

  254. Kev

    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.

  255. Florian

    I think it is

  256. Kev

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

  257. Florian


  258. Florian

    hence what Dave said makes sense

  259. Florian

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

  260. bear

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

  261. bear

    or the appearance that is happening

  262. Florian

    well, the XSF will accept all gratis work

  263. Kev

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

  264. Florian

    or at least I think it should

  265. dwd

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

  266. Florian

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

  267. Kev

    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.

  268. bear

    yes, moz tends to hire folks who are good contributors

  269. bear

    (as contractors or staff)

  270. Florian

    hmm, ok

  271. Florian

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

  272. Kev

    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 :)

  273. Florian

    Kev: right

  274. Kev

    I think we should avoid it.

  275. Florian


  276. Kev

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

  277. bear

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

  278. Florian

    "Jury member can't submit a project."

  279. bear

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

  280. Florian


  281. Kev

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

  282. bear

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

  283. Kev

    We're going to want something entirely permissive.

  284. Florian


  285. Florian

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

  286. Kev

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

  287. bear is a fan of MPLv2

  288. bear

    but I can how others may not be ;)

  289. Kev

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

  290. bear nods

  291. Florian

    I think that the way bear put it is fine

  292. Florian

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

  293. Florian

    i.e. we're paying people

  294. Florian

    and the free work can be seen as donations

  295. Florian

    so I think that makes sense and gives us freedom

  296. bear

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

  297. Florian


  298. Kev


  299. dwd

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

  300. Florian

    ok, I think we have a good start though

  301. dwd

    I think requiring a very liberal license is adequate.

  302. bear

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

  303. Florian

    bear: right

  304. Florian

    ok, I think we have a good start here

  305. bear

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

  306. Florian

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

  307. Florian

    on the wiki

  308. Florian

    any volunteers?

  309. Kev

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

  310. Florian

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

  311. bear flips and joins dwd and kev

  312. bear

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

  313. Florian

    I think we should write this up

  314. dwd

    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.

  315. bear

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

  316. bear

    florian - i'll start transfering it to the wiki

  317. Florian


  318. bear

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

  319. Florian

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

  320. bear


  321. Florian

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

  322. dwd

    Any volunteers?

  323. bear

    let me get this first draft on the wiki

  324. Florian


  325. Florian

    anyone willing to write Technology / Goals?

  326. Kev

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

  327. bear

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

  328. dwd

    Right, I'll do some work over it.

  329. Florian

    dwd: awesome, thanks :)

  330. Florian

    so one last thing ... time?

  331. Florian

    should we say, all written up by wednesday?

  332. Florian

    and then another meeting here?

  333. dwd

    We can do that, I think.

  334. Florian

    alright ....

  335. Florian


  336. dwd

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

  337. Florian

    dwd: sure

  338. Florian

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

  339. dwd

    Florian, Thanks!

  340. Florian

    thanks all!

  341. Florian

    I'll send a mail to the list later

  342. Florian

    members, jdev, standards, jadmin

  343. bear

    ok, wiki now has the etherpad contents

  344. Florian


  345. Florian

    thanks bear

  346. Florian

    thanks all !

  347. Florian

    Next meeting wednesday ... tbc

  348. bear


  349. Kev


  350. Florian has left

  351. koski has left

  352. Jef has left

  353. Jef has joined

  354. Jef has left

  355. Jef has joined

  356. Jef has left

  357. Jef has joined

  358. winfried has left

  359. waqas has joined

  360. Medics has left

  361. Tobias has joined

  362. Jef

    Young man, there's a place you can go

  363. Jef

    Young man, there's a place you can go

  364. Jef

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

  365. Jef

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

  366. Jef

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

  367. Jef

    They have everything for young men to enjoy

  368. Jef

    They have everything for young men to enjoy

  369. dwd

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

  370. dwd

    Or IETF, or indeed any four letter acronym.

  371. Jef


  372. MiGri


  373. Kev

    Eeee Tee Ell Aaay

  374. bear

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

  375. Tobias has joined

  376. waqas has joined

  377. Zash has left