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.