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 \o/
  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 hey
  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 http://piratepad.net/CMPIY1IvOm
  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 K.
  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 Yes.
  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 Probably.
  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 https://wiki.mozilla.org/Identity/Features/Sign_into_the_browser
  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 right
  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 yeah
  88. Florian alright
  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 right
  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 sure
  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 Yep
  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 sure
  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 Agree/disagree/abort/fail.
  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 right
  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 lol
  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 agree
  223. Florian heh
  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 right
  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 ok
  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 hmm
  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 right
  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 right
  298. Kev Right.
  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 alright
  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 cool
  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 http://wiki.xmpp.org/web/BID-RFP
  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 AOB?
  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 great!
  345. Florian thanks bear
  346. Florian thanks all !
  347. Florian Next meeting wednesday ... tbc
  348. bear thanks
  349. Kev Ta.
  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 lol
  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