XSF Discussion - 2012-05-05

  1. Florian

    BrowserID talks in 4 minutes :)

  2. Zash


  3. dwd

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

  4. Florian

    heh, ok

  5. Florian

    let me pull up the Wiki page at the same time

  6. Florian

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

  7. Florian

    and Matt

  8. dwd

    Hey Ashley.

  9. Ashley

    hey there

  10. Florian


  11. Ashley

    how do we want to proceed?

  12. Florian

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

  13. Ashley

    makes sense

  14. Florian

    1. Technology

  15. Florian

    2. Goals

  16. Ashley

    should we have a background section?

  17. Florian

    3. What the XSF offers

  18. Kev

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

  19. Florian

    Kev: we haven't, no.

  20. Kev

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

  21. Florian


  22. Florian

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

  23. Florian

    at the XSF's discretion

  24. Florian

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

  25. Kev


  26. Florian

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

  27. Florian

    do those 4 sections sound alright?

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

  29. waqas

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

  30. Florian

    waqas: glad to hear :)

  31. Kev

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

  32. Florian

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

  33. Florian

    but yeah, should we go through the 4 sections?

  34. Florian

    starting with Background

  35. Kev

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

  36. Kev


  37. dwd

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

  38. Florian

    yup, I think that makes sense

  39. Florian

    maybe time-frame?

  40. Florian

    however, I think that would fit into goals

  41. dwd


  42. dwd

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

  43. dwd

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

  44. Ashley

    i would assume this would line up with mozilla

  45. Florian

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

  46. Ashley


  47. Ashley

    this says FF 15

  48. Kev

    So presumably we need something working far ahead of that.

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

  50. Florian


  51. waqas

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

  52. dwd

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

  53. Florian

    dwd: BOSH?

  54. dwd

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

  55. Florian

    but let's stick with the background part for now

  56. Ashley

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

  57. Florian

    the blogpost? sure

  58. Ashley


  59. Florian


  60. Florian

    anything else for Background?

  61. Florian

    else let's move on to Technology :)

  62. dwd

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

  63. Florian


  64. Ashley

    this may be a goal, but should be internet scale

  65. Florian

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

  66. Kev

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

  67. Florian

    as well as federation would be required for this to work

  68. Florian

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

  69. Florian

    does that make sense?

  70. Zash

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

  71. Florian

    maybe let's skip to Goals first

  72. Florian

    and come back to technology

  73. Florian

    that way we know what we want to achieve :)

  74. Florian

    one goal is obviously authentication

  75. Ashley

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

  76. Zash

    The SignIntoBrowser mentions bookmarks and contacts

  77. Florian

    Ashley: I think so

  78. dwd

    Ashley, Yes, I think so too.

  79. Florian

    I think contacts

  80. Florian

    as well as push

  81. Florian

    i.e. notifications

  82. Ashley

    yes, notifications would be great

  83. Florian

    for bookmarks, that's data storage

  84. Florian

    can we do that somehow with PEP?

  85. Florian

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

  86. dwd

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

  87. Zash

    and it mentions how to store it in PEP

  88. Florian

    oh, right ... yeah :D

  89. Florian

    ok, so let me rephrase that ...

  90. waqas

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

  91. Florian

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

  92. Kev

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

  93. Florian


  94. Ashley

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

  95. Kev

    Ashley: Very probably.

  96. dwd

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

  97. Kev

    To my mind what we want is:

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

  99. Kev

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

  100. Ashley

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

  101. Kev

    And see what comes back to us.

  102. dwd

    Kev, Seems reasonable.

  103. Florian

    Ashley: ok ... thanks for dropping by

  104. Florian

    Kev: makes sense

  105. Ashley

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

  106. Kev

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

  107. waqas


  108. Florian

    ok, does that look alright for the goals?

  109. Kev

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

  110. Kev

    Florian: Happy for me to poke at the pp?

  111. bear is late -sorry

  112. Florian


  113. Florian

    that's what it's there for :)

  114. bear

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

  115. bear

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

  116. Florian

    bear: thanks for the info :)

  117. bear

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

  118. bear

    and that beta is going to be releases this quarter also

  119. Florian

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

  120. Florian

    and then get cracking

  121. Kev

    Florian: OK, I've poked the pp.

  122. Florian

    Kev: great :)

  123. Kev


  124. dwd

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

  125. Florian


  126. 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?

  127. Kev

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

  128. bear

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

  129. Florian

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

  130. Florian

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

  131. bear

    browserid itself just became viable the last couple of months

  132. bear

    the code was baking internally at moz most of the winter

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

  134. dwd

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

  135. bear

    moz *internally* is pushing for this

  136. Kev

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

  137. bear

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

  138. bear

    so we are just a bit ahead of the wave

  139. bear

    dwd - I agree

  140. Florian

    yeah, we need both

  141. Florian

    but I think the service side exists

  142. Florian

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

  143. Kev

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

  144. Florian

    ah, right

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

  146. MattJ

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

  147. Kev

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

  148. Kev

    +then that's great.

  149. dwd

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

  150. bear

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

  151. Florian

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

  152. bear

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

  153. Florian

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

  154. Kev

    bear: Which is useful, thnks.

  155. MattJ

    bear, shocking :P

  156. bear

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

  157. dwd

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

  158. bear likes how dwd said it

  159. Florian


  160. koski

    +1 what dwd said

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

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

  163. Kev

    "XMPP implements browserid" - what does that mean?

  164. dwd

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

  165. Kev

    In language we can put into the RFP :)

  166. Florian


  167. bear

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

  168. Kev

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

  169. bear

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

  170. Kev

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

  171. bear

    but yes, I suspect it is

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

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

  174. dwd

    But yeah, different (opposite) problem.

  175. Kev

    Although has fun recursive effects.

  176. Kev

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

  177. bear laughs

  178. Florian


  179. Kev

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

  180. Florian

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

  181. dwd

    Not quite, hang on.

  182. dwd

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

  183. bear

    anyone on the browserid team - they are very open

  184. waqas

    That would be very useful

  185. bear

    #identity channel on irc.mozilla.org

  186. dwd

    Can't they use XMPP?!

  187. bear

    irc is very much part of mozilla's dna

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

  189. bear


  190. Florian


  191. bear

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

  192. waqas

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

  193. dwd

    waqas, Authenticate yourself using an unauthenticated network!

  194. bear

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

  195. Kev

    BrowserID by nickserv. Sounds good to me.

  196. waqas

    dwd, I'm sure it has been tried

  197. dwd

    OK. FInal question...

  198. dwd

    How is the XSF going to decide who gets paid?

  199. Florian

    I think that's something the board should do

  200. dwd

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

  201. Florian

    maybe Board + Council?

  202. bear

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

  203. Kev

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

  204. dwd

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

  205. Kev

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

  206. bear

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

  207. Florian

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

  208. dwd

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

  209. Florian

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

  210. dwd

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

  211. bear

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

  212. 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" :)

  213. MattJ

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

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

  215. Florian

    MattJ: correct

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

  217. Florian

    dwd: fair point

  218. Kev

    Sure it is.

  219. Kev

    You can't preclude someone else getting paid.

  220. Florian

    Kev: huh?

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

  222. Florian

    I think it is

  223. Kev

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

  224. Florian


  225. Florian

    hence what Dave said makes sense

  226. Florian

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

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

  228. bear

    or the appearance that is happening

  229. Florian

    well, the XSF will accept all gratis work

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

  231. Florian

    or at least I think it should

  232. dwd

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

  233. Florian

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

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

  235. bear

    yes, moz tends to hire folks who are good contributors

  236. bear

    (as contractors or staff)

  237. Florian

    hmm, ok

  238. Florian

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

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

  240. Florian

    Kev: right

  241. Kev

    I think we should avoid it.

  242. Florian


  243. Kev

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

  244. bear

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

  245. Florian

    "Jury member can't submit a project."

  246. bear

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

  247. Florian


  248. Kev

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

  249. bear

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

  250. Kev

    We're going to want something entirely permissive.

  251. Florian


  252. Florian

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

  253. Kev

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

  254. bear is a fan of MPLv2

  255. bear

    but I can how others may not be ;)

  256. Kev

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

  257. bear nods

  258. Florian

    I think that the way bear put it is fine

  259. Florian

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

  260. Florian

    i.e. we're paying people

  261. Florian

    and the free work can be seen as donations

  262. Florian

    so I think that makes sense and gives us freedom

  263. bear

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

  264. Florian


  265. Kev


  266. dwd

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

  267. Florian

    ok, I think we have a good start though

  268. dwd

    I think requiring a very liberal license is adequate.

  269. bear

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

  270. Florian

    bear: right

  271. Florian

    ok, I think we have a good start here

  272. bear

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

  273. Florian

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

  274. Florian

    on the wiki

  275. Florian

    any volunteers?

  276. Kev

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

  277. Florian

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

  278. bear flips and joins dwd and kev

  279. bear

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

  280. Florian

    I think we should write this up

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

  282. bear

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

  283. bear

    florian - i'll start transfering it to the wiki

  284. Florian


  285. bear

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

  286. Florian

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

  287. bear


  288. Florian

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

  289. dwd

    Any volunteers?

  290. bear

    let me get this first draft on the wiki

  291. Florian


  292. Florian

    anyone willing to write Technology / Goals?

  293. Kev

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

  294. bear

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

  295. dwd

    Right, I'll do some work over it.

  296. Florian

    dwd: awesome, thanks :)

  297. Florian

    so one last thing ... time?

  298. Florian

    should we say, all written up by wednesday?

  299. Florian

    and then another meeting here?

  300. dwd

    We can do that, I think.

  301. Florian

    alright ....

  302. Florian


  303. dwd

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

  304. Florian

    dwd: sure

  305. Florian

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

  306. dwd

    Florian, Thanks!

  307. Florian

    thanks all!

  308. Florian

    I'll send a mail to the list later

  309. Florian

    members, jdev, standards, jadmin

  310. bear

    ok, wiki now has the etherpad contents

  311. Florian


  312. Florian

    thanks bear

  313. Florian

    thanks all !

  314. Florian

    Next meeting wednesday ... tbc

  315. bear


  316. Kev


  317. Jef

    Young man, there's a place you can go

  318. Jef

    Young man, there's a place you can go

  319. Jef

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

  320. Jef

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

  321. Jef

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

  322. Jef

    They have everything for young men to enjoy

  323. Jef

    They have everything for young men to enjoy

  324. dwd

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

  325. dwd

    Or IETF, or indeed any four letter acronym.

  326. Jef


  327. MiGri


  328. Kev

    Eeee Tee Ell Aaay

  329. bear

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