You guys probably have a better idea than I do, considering that you applied in the past as an organization. However, this faq provides a list of the questions Google will be asking you to include in the proposal. You should probably have the questions answered well before the application period begins, just so you don't miss the deadline.

I figured I'd link it, just in case you haven't seen it.

Other than the proposal, the only other thing I can think of is the wiki page of ideas for GSoC. It seems to be in sort of a draft state right now. Plus I think it needs to be updated with information like about how I am working on NMControl for Android. So that probably isn't a potential GSoC project anymore.

josephbisch wrote:You guys probably have a better idea than I do, considering that you applied in the past as an organization. However, this faq provides a list of the questions Google will be asking you to include in the proposal. You should probably have the questions answered well before the application period begins, just so you don't miss the deadline.

I figured I'd link it, just in case you haven't seen it.

Other than the proposal, the only other thing I can think of is the wiki page of ideas for GSoC. It seems to be in sort of a draft state right now. Plus I think it needs to be updated with information like about how I am working on NMControl for Android. So that probably isn't a potential GSoC project anymore.

Thanks Joseph. Yeah, the GSoC wiki page needs to be cleaned up. And maybe merged into www.namecoin.info; I'm a little uneasy leaving it on the wiki (unless we can protect it).

So, applications start soon (at 9th February). I'll submit an application again (and let you read over my questionaire answers for suggestions). Is there anything I should specifically mention in the application? Also, does anyone know a Googler who could vouch for us?

The only thing I can think of saying in the application might be that there is already a student (me) who has expressed interest in applying to Namecoin.

Also, I found this: http://www.google-melange.com/gsoc/docu ... king_on_an. Basically, it says that a student can work on a project that that student was previously working on as long as there is a clear separation between the work done previously and the work done for GSoC. So I actually would be able to apply to work on Armory for Namecoin as part of GSoC if I wanted to. I'm not saying that I will definitely apply for the project, but I do have the option, whereas I previously thought I wasn't able to.

I think Jeremy said during one of our irc meetings that he would clean up the ideas page. That is something that still needs to be done. I think it is okay to leave Armory as a potential project, because I don't think I will be able to even start on name transactions before the start of GSoC due to school and other commitments and activities.

I've updated the ideas page. There are a few remaining issues that I wanted to check with you guys on.

(1) We need a consensus on whether it's useful to allow voluntary encryption. Indolering and I both believe that it's useful, though not one of the highest-priority items on our agenda. Ryan said he was against it and was planning to write up why, but I don't believe he has gotten around to doing so. Last I heard Daniel was in favor, but it's been a while so I might be wrong on that.

(2) We need requirements, expected outcomes, and a mentor for Anonymity and Taint Analysis Tools. (Ryan seems like he might be a logical mentor.)

(3) We need expected outcomes and a mentor for Renewal Keys. Ryan seems like he might be a logical mentor; Daniel might also be good.

(4) Armory: keep or remove? If Joseph wants to work on it for GSoC, I think it's okay to keep. If Joseph is expecting to finish it before GSoC (which it sounds like he isn't?), then we should remove. Thoughts?

(5) Block Explorer: Who should be mentor? Daniel or Ryan maybe?

(6) It is my opinion that the file signing proposal linked in the doc will not scale, since it stores a hash of every file in the blockchain. It also makes it unfeasible for multiple parties to sign the same file. I think a system that only stores keys rather than file hashes in the blockchain makes more sense. Phelix disagrees here. Can we hammer this out?

(7) We need a mentor for Bitmessage. I'd prefer not to be the mentor for this one. Daniel, Phelix, Ryan, are any of you good for this?

Also, I checked, and my friend who vouched for us last time is no longer at Google. I don't know any other current Google employees.

biolizard89 wrote:(1) We need a consensus on whether it's useful to allow voluntary encryption. Indolering and I both believe that it's useful, though not one of the highest-priority items on our agenda. Ryan said he was against it and was planning to write up why, but I don't believe he has gotten around to doing so. Last I heard Daniel was in favor, but it's been a while so I might be wrong on that.

I'm still in favour. I've been in contact with someone who basically proposed the same idea on his own. His reasoning was that he would like to store, for instance, his address in his id/ name, and then have Amazon or other shops ship to it. This would allow him to change the address in a single place when moving, without having to change it all over the web with various companies. The same goes for mobile phone number and other things. Having partial encryption allows precisely that without the need to share things publicly. NameID could, in theory, be extended to do the decryption (if the user enters the password) and hand over such details just to the selected servers on login using the OpenID protocol. I think a scheme like this makes a lot of sense. But see also (6) below.

biolizard89 wrote:(2) We need requirements, expected outcomes, and a mentor for Anonymity and Taint Analysis Tools. (Ryan seems like he might be a logical mentor.)

(3) We need expected outcomes and a mentor for Renewal Keys. Ryan seems like he might be a logical mentor; Daniel might also be good.

I'm available as a mentor basically for any project, although I agree that others are probably better suited for some tasks (like things related to DNS, security and stuff like that).

biolizard89 wrote:(4) Armory: keep or remove? If Joseph wants to work on it for GSoC, I think it's okay to keep. If Joseph is expecting to finish it before GSoC (which it sounds like he isn't?), then we should remove. Thoughts?

I suggest to keep it, or maybe replace it with a more generic "work on a standalone UI" (as it was for last year, IIRC).

biolizard89 wrote:(5) Block Explorer: Who should be mentor? Daniel or Ryan maybe?

I'm available (as stated above), although I can probably mostly help with the backend stuff. But I guess that interested students will have experience with web design and layout and all that stuff anyway, so they probably mostly need help with the backend.

biolizard89 wrote:(6) It is my opinion that the file signing proposal linked in the doc will not scale, since it stores a hash of every file in the blockchain. It also makes it unfeasible for multiple parties to sign the same file. I think a system that only stores keys rather than file hashes in the blockchain makes more sense. Phelix disagrees here. Can we hammer this out?

I'm not fully decided about this one. I think that the proposal with hashes in the blockchain is very elegant, but as you point out, it is not really scalable.

A much wider-scope idea is the following: Could we add a full-blown DHT to the network itself, that can be used to store "secondary" data for names? This would allow bigger values, allow for values that are not (definitely) saved in the blockchain for eternity (might improve privacy at least a little, even though each node is, of course, free to keep a private archive if they wish) and also make things like updates faster. The DHT entries could be signed by keys linking them to ownership of a name on the blockchain, so that security of name ownership is preserved. Maybe this is a stupid idea, and it probably needs to be fleshed out. But it could be a useful idea for the future, and it could potentially be an interesting GSoC project to build a proof-of-concept implementation here.

biolizard89 wrote:(7) We need a mentor for Bitmessage. I'd prefer not to be the mentor for this one. Daniel, Phelix, Ryan, are any of you good for this?

I can do the mentoring here. Seems like an obvious fit since I've done NameID and the original Bitmessage integration.