Jump to: navigation, search

Difference between revisions of "GSoC 2016 Project Ideas"

[quality revision][pending revision]
(Add Joseph's opinions.)
 
Line 2: Line 2:
  
 
'''This Ideas Page is still under construction, and contains some relics from 2015.  Check back soon for updates.'''
 
'''This Ideas Page is still under construction, and contains some relics from 2015.  Check back soon for updates.'''
 +
As only 2 weeks left, move comments to separate page and trim down for final review  --[[User:DrLLau|DrLLau]]
  
 
If you are interested in working on one of the following projects, get in touch with us!  For low-latency discussion, many of our developers can be reached via #namecoin-dev on Freenode IRC (we also are present in #namecoin).  If you're not able to get an answer on there (which is possible, since several of our developers won't be able to respond during class or work), please post in the [https://forum.namecoin.info/ forum].  If you have your own ideas for good Namecoin projects, we would love to hear them and support you with those, too!
 
If you are interested in working on one of the following projects, get in touch with us!  For low-latency discussion, many of our developers can be reached via #namecoin-dev on Freenode IRC (we also are present in #namecoin).  If you're not able to get an answer on there (which is possible, since several of our developers won't be able to respond during class or work), please post in the [https://forum.namecoin.info/ forum].  If you have your own ideas for good Namecoin projects, we would love to hear them and support you with those, too!
  
 
'''Should we remove domob from the "possible mentor" list?  --[[User:Biolizard89|Biolizard89]] ([[User talk:Biolizard89|talk]]) 06:40, 5 January 2016 (UTC)'''
 
'''Should we remove domob from the "possible mentor" list?  --[[User:Biolizard89|Biolizard89]] ([[User talk:Biolizard89|talk]]) 06:40, 5 January 2016 (UTC)'''
 +
OK, merge into client project --[[User:DrLLau|DrLLau]]
  
 
'''Check whether we have additional mentors whom we can list.  --[[User:Biolizard89|Biolizard89]] ([[User talk:Biolizard89|talk]]) 08:42, 5 January 2016 (UTC)'''
 
'''Check whether we have additional mentors whom we can list.  --[[User:Biolizard89|Biolizard89]] ([[User talk:Biolizard89|talk]]) 08:42, 5 January 2016 (UTC)'''
 +
TBC Joseph role as admin to name-names --[[User:DrLLau|DrLLau]]
  
 
<table border="1" cellpadding="4">
 
<table border="1" cellpadding="4">
Line 39: Line 42:
  
 
'''Should we remove the criticism of coinbase commitments?  Daniel is doing UNO coinbase commitments without waiting for Bitcoin.  --[[User:Biolizard89|Biolizard89]] ([[User talk:Biolizard89|talk]]) 06:37, 5 January 2016 (UTC)'''
 
'''Should we remove the criticism of coinbase commitments?  Daniel is doing UNO coinbase commitments without waiting for Bitcoin.  --[[User:Biolizard89|Biolizard89]] ([[User talk:Biolizard89|talk]]) 06:37, 5 January 2016 (UTC)'''
 +
Ack - not a criticism so can leave as is --[[User:DrLLau|DrLLau]]
 +
  
 
'''I would say so, given it is something we are going ahead with. --[[User:Josephbisch|Josephbisch]] ([[User talk:Josephbisch|talk]]) 15:15, 18 January 2016 (UTC)'''
 
'''I would say so, given it is something we are going ahead with. --[[User:Josephbisch|Josephbisch]] ([[User talk:Josephbisch|talk]]) 15:15, 18 January 2016 (UTC)'''
Line 73: Line 78:
 
'''I will leave this for others to comment on. --[[User:Josephbisch|Josephbisch]] ([[User talk:Josephbisch|talk]]) 15:15, 18 January 2016 (UTC)'''
 
'''I will leave this for others to comment on. --[[User:Josephbisch|Josephbisch]] ([[User talk:Josephbisch|talk]]) 15:15, 18 January 2016 (UTC)'''
  
 +
Yes as this would support the concept of trustees, proxy voting or delegation of authority. The open question is under what circumstances is it reversible injective mapping, --[[User:DrLLau|DrLLau]]
 
</td>
 
</td>
 
   <td>
 
   <td>
Line 86: Line 92:
 
   <td>
 
   <td>
 
Your encryption system implemented into the Namecoin client or NMControl.
 
Your encryption system implemented into the Namecoin client or NMControl.
 +
 +
'''I'm a little concerned that the above is vague. Are you wanting a engine to pick/swap for future proofing, a mechanism for remote user-defined name/value manipulation or programming hook for customisation?  --[[User:DrLLau|DrLLau]]'''
  
 
'''Should we rephrase the above to make clear that ncdns is okay as an alternative to NMControl?  --[[User:Biolizard89|Biolizard89]] ([[User talk:Biolizard89|talk]]) 07:54, 5 January 2016 (UTC)'''
 
'''Should we rephrase the above to make clear that ncdns is okay as an alternative to NMControl?  --[[User:Biolizard89|Biolizard89]] ([[User talk:Biolizard89|talk]]) 07:54, 5 January 2016 (UTC)'''
Line 101: Line 109:
 
</td>
 
</td>
 
   <td>
 
   <td>
Namecoin suffers the same problems with traceability (lack of anonymity) of coin flows that Bitcoin does. When Namecoin is used for its stated purpose to provide censorship-resistant browsing and registration of domains for possibly controversial purposes (e.g. under repressive regimes), this may be even a bigger problem than with Bitcoin. Unfortunately, there is not a good way for these users to easily evaluate what information is leaking to statistical and graph theory attackers. You can think of ways to improve this, possibly by implementing "taint analysis" similar to what Blockchain.info does. Remember that names carry more data than currency transactions, and thus a Namecoin taint analyzer can be much more effective.  For example, learning that the same individual probably controls two given names, one of which has publicly traceable ownership data in its value (e.g. an IP address), may reveal a lot. We are particularly interested in helping users learn about potential anonymity implications of their actions *before* they issue a transaction, although this is not a strict requirement for this project.
+
Namecoin suffers the same problems with traceability (lack of anonymity) of coin flows that Bitcoin does. When Namecoin is used for its stated purpose to provide censorship-resistant browsing and registration of domains for possibly controversial purposes (e.g. under repressive regimes), this may be even a bigger problem than with Bitcoin. Unfortunately, there is not a good way for these users to easily evaluate what information is leaking to statistical and graph theory attackers. Paradata (impression of data on other data as in [https://en.wikipedia.org/wiki/Digital_footprint passive digital footprints]) is impossible to erase and may lead to adverse consequences. You can think of ways to improve this, possibly by implementing "taint analysis" similar to what Blockchain.info does. Remember that names carry more data than currency transactions, and thus a Namecoin taint analyzer can be much more effective.  For example, learning that the same individual probably controls two given names, one of which has publicly traceable ownership data in its value (e.g. an IP address), may reveal a lot. We are particularly interested in helping users learn about potential anonymity implications of their actions *before* they issue a transaction, although this is not a strict requirement for this project.
  
 
'''Are we in agreement that this is still desirable?  I believe that it is.  --[[User:Biolizard89|Biolizard89]] ([[User talk:Biolizard89|talk]]) 08:02, 5 January 2016 (UTC)'''
 
'''Are we in agreement that this is still desirable?  I believe that it is.  --[[User:Biolizard89|Biolizard89]] ([[User talk:Biolizard89|talk]]) 08:02, 5 January 2016 (UTC)'''
Line 154: Line 162:
 
<tr>
 
<tr>
 
   <td>
 
   <td>
Armory Port
+
Armory Port (project to be deleted/deferred or rolled into lightweight client)
 +
 
 
</td>
 
</td>
 
   <td>
 
   <td>
Line 200: Line 209:
 
<tr>
 
<tr>
 
   <td>
 
   <td>
File Signing &amp; Verification
+
File Signing &amp; Verification. Fuzzy Immutable Data.
 +
 
 
</td>
 
</td>
 
   <td>
 
   <td>
 
Namecoin can provide an excellent base for signing files (like software releases) and verifying their integrity, e.g. in combination with GPG.  Implement a tool that handles this, both for signers and users just wanting to verify their downloads (should be easy to use for them). You can propose a programming language / toolkit to use for this project. There exists already some code to interface to the Namecoin API over JSON-RPC for some languages (C++, Python, PHP), and it is easy to do from others as well.
 
Namecoin can provide an excellent base for signing files (like software releases) and verifying their integrity, e.g. in combination with GPG.  Implement a tool that handles this, both for signers and users just wanting to verify their downloads (should be easy to use for them). You can propose a programming language / toolkit to use for this project. There exists already some code to interface to the Namecoin API over JSON-RPC for some languages (C++, Python, PHP), and it is easy to do from others as well.
 +
 +
The more challenging extension is extending immutable data to handle fuzziness. An example is a voting record where the proposal is fixed, but the names eligible to vote may vary up to a time-window (resolution frame) and the choice is indeterminable if a veto/block is cast or not affirmed afterwards by abstainers.This is equivalent to finding a hash of size n+m which first n digits are the same for all voting records outside time window and the last resolves to zero for all the varying component. The hash function may be a secret.
  
 
'''Is this still relevant?  --[[User:Biolizard89|Biolizard89]] ([[User talk:Biolizard89|talk]]) 08:40, 5 January 2016 (UTC)'''
 
'''Is this still relevant?  --[[User:Biolizard89|Biolizard89]] ([[User talk:Biolizard89|talk]]) 08:40, 5 January 2016 (UTC)'''
Line 217: Line 229:
 
</td>
 
</td>
 
   <td>
 
   <td>
domob, phelix?
+
domob, phelix? drllau
 
</td>
 
</td>
 
</tr>
 
</tr>
Line 227: Line 239:
 
   <td>
 
   <td>
 
Namecoin is very well suited to distribute any type of &quot;public key&quot; for human-readable names / online identities. This has already been taken advantage of for Bitmessage, and a proof-of-concept implementation for OTR fingerprints in Pidgin exists, too. Think about other possible uses (e. g., Bitcoin addresses in wallet software like Electrum, or GPG keys) and implement them.
 
Namecoin is very well suited to distribute any type of &quot;public key&quot; for human-readable names / online identities. This has already been taken advantage of for Bitmessage, and a proof-of-concept implementation for OTR fingerprints in Pidgin exists, too. Think about other possible uses (e. g., Bitcoin addresses in wallet software like Electrum, or GPG keys) and implement them.
 +
 +
IPv6 has more sophisticated Secure Neighbour Discovery mechanisms which are targetted for mobile or location aware infostructures. However PKI are one of the most challenging tasks for a security conscious world and careful thought needs to apply to balancing usability with risk mitigation.
 +
  
 
'''Is this still relevant?  I vaguely recall that Phelix has been working on GPG stuff?  --[[User:Biolizard89|Biolizard89]] ([[User talk:Biolizard89|talk]]) 08:40, 5 January 2016 (UTC)'''
 
'''Is this still relevant?  I vaguely recall that Phelix has been working on GPG stuff?  --[[User:Biolizard89|Biolizard89]] ([[User talk:Biolizard89|talk]]) 08:40, 5 January 2016 (UTC)'''
Line 246: Line 261:
 
<tr>
 
<tr>
 
   <td>
 
   <td>
Full Bitmessage Integration
+
Non-surjective P2P Messaging
 
</td>
 
</td>
 
   <td>
 
   <td>
[https://bitmessage.org Bitmessage] has already some support for Namecoin IDs by Domob. It should be extended in a way that in the GUI all bitmessage addresses that have corresponding Namecoin IDs (/id namespace) will be replaced by the IDs. To do so it will be necessary to securely lookup both ways id-->address, address-->id so it will be necessary to do some cross signing and storing the signature in the id or an additional name that can be found directly via the address. To be accepted upstream it would be helpful if it could fall back to addresses only if no name data source can be found.
+
A protocol (possibly publish/subscribe) to support secure short messaging to one or many participants.
 +
+
 +
An example is [https://bitmessage.org Bitmessage] which already some support for Namecoin IDs by Domob. It could be extended in a way that in the GUI all bitmessage addresses that have corresponding Namecoin IDs (/id namespace) will be replaced by the IDs. To do so it will be necessary to securely lookup both ways id-->address, address-->id so it will be necessary to do some cross signing and storing the signature in the id or an additional name that can be found directly via the address. To be accepted upstream it would be helpful if it could fall back to addresses only if no name data source can be found.
  
 
'''Is Bitmessage still maintained?  I don't see any releases on their site in over a year.  --[[User:Biolizard89|Biolizard89]] ([[User talk:Biolizard89|talk]]) 08:40, 5 January 2016 (UTC)'''
 
'''Is Bitmessage still maintained?  I don't see any releases on their site in over a year.  --[[User:Biolizard89|Biolizard89]] ([[User talk:Biolizard89|talk]]) 08:40, 5 January 2016 (UTC)'''
  
 
'''Seems to not be maintained any more. I say we drop this idea. --[[User:Josephbisch|Josephbisch]] ([[User talk:Josephbisch|talk]]) 15:15, 18 January 2016 (UTC)'''
 
'''Seems to not be maintained any more. I say we drop this idea. --[[User:Josephbisch|Josephbisch]] ([[User talk:Josephbisch|talk]]) 15:15, 18 January 2016 (UTC)'''
 +
 +
 +
Suggest making it more generic and just use BitMessage as example. I'd like to see something that allows short messaging loops/branches without have every single message as a separate namecoin transaction as it allows faster confirmation of validity. --[[User:DrLLau|DrLLau]]
 +
 
</td>
 
</td>
 
   <td>
 
   <td>
Line 262: Line 283:
 
</td>
 
</td>
 
   <td>
 
   <td>
Bitmessage with Namecoin IDs
+
Short messages chained/branched with Namecoin IDs
 +
 
 
</td>
 
</td>
 
   <td>
 
   <td>
Line 275: Line 297:
 
   <td>
 
   <td>
 
Namecoin can be used for lots of novel and interesting use cases, and existing use cases are open for improvement. Propose your own use case or improvement, and discuss it with us!
 
Namecoin can be used for lots of novel and interesting use cases, and existing use cases are open for improvement. Propose your own use case or improvement, and discuss it with us!
 +
 +
'''Is there time to refine these into a project? --[[DrLLau|DrLLau]]'''
 
</td>
 
</td>
 
   <td>
 
   <td>

Latest revision as of 18:46, 7 February 2016

Namecoin intends to apply for Google Summer of Code 2016 as a mentor organization.

This Ideas Page is still under construction, and contains some relics from 2015. Check back soon for updates.

As only 2 weeks left, move comments to separate page and trim down for final review  --DrLLau

If you are interested in working on one of the following projects, get in touch with us! For low-latency discussion, many of our developers can be reached via #namecoin-dev on Freenode IRC (we also are present in #namecoin). If you're not able to get an answer on there (which is possible, since several of our developers won't be able to respond during class or work), please post in the forum. If you have your own ideas for good Namecoin projects, we would love to hear them and support you with those, too!

Should we remove domob from the "possible mentor" list? --Biolizard89 (talk) 06:40, 5 January 2016 (UTC) OK, merge into client project --DrLLau

Check whether we have additional mentors whom we can list. --Biolizard89 (talk) 08:42, 5 January 2016 (UTC)

TBC Joseph role as admin to name-names --DrLLau

Project

Description

Difficulty

Requirements

Expected outcomes/Deliverables

Possible mentors

Light Client

Namecoin needs a light client, which can be used to get name values trustlessly but without the need to store the full blockchain. There are multiple possible ideas to tackle this, depending on your interests and likes. One is to implement an SPV client for Namecoin, similar to what is described already in the Bitcoin whitepaper and what is implemented by BitcoinJ. You may find HashEngineering's NamecoinJ helpful. Another idea is to ignore transactions and blocks older than 36,000 blocks, since those cannot have current name transactions. Adding wire protocol commands is totally fine if it helps you in accomplishing this. However, we do not wish to add coinbase commitments (e.g. the UTXO set) until Bitcoin does so. You are free to propose a programming language of your choice as well as your own ideas for implementing a light client and discuss your choice with the community. You may find the following writeups by Hugo interesting: Namecoin Node Types and State of Namecoin.

Should we remove the criticism of coinbase commitments? Daniel is doing UNO coinbase commitments without waiting for Bitcoin. --Biolizard89 (talk) 06:37, 5 January 2016 (UTC) Ack - not a criticism so can leave as is --DrLLau


I would say so, given it is something we are going ahead with. --Josephbisch (talk) 15:15, 18 January 2016 (UTC)

Should we mention that BitcoinJ might be willing to merge altcoin-enabling abstractions? Should we mention Coinomi? --Biolizard89 (talk) 06:37, 5 January 2016 (UTC)

Might motivate some individuals if they know that their work may be merged into the larger BitcoinJ. So I think that should be mentioned. Looks like Coinomi supports Namecoin, but just currency transactions. I guess we could mention that too, but I don't know if Coinomi has much of a user base? Maybe we can get some idea of how popular it is. The GitHub numbers seem kind of low, but that isn't necessarily a good measure of usage of the software by end-users. --Josephbisch (talk) 15:15, 18 January 2016 (UTC)

Hard

Excellent understanding of how Bitcoin and Namecoin work, good ability to design your own software project architecture.

A light client that is installable and supports all Namecoin transaction types.

domob, Ryan?, Jeremy

Name/Value Encryption

Right now, all names and values are easily enumerable by the public, which is bad for privacy in certain applications (e.g. someone wants to link their email address with a GPG key without making that email address public). Develop a reliable protocol for encrypting and/or obfuscating names and/or values in the blockchain, to improve privacy, and implement it. Some first ideas were already given by gmaxwell, and others have been brought up in discussions, such as this proposal by Jeremy. We first need to decide on a good system based on your ideas and proposals, and then you need to implement that into Namecoin.

Note that if your proposal requires changes to the consensus rules (e.g. storing hashes of names instead of names), you will probably only be implementing them on a testnet (for merging into mainnet once sufficient review has occurred).

Can everyone confirm that this is still desirable? I believe that it is. --Biolizard89 (talk) 07:54, 5 January 2016 (UTC)

I will leave this for others to comment on. --Josephbisch (talk) 15:15, 18 January 2016 (UTC)

Yes as this would support the concept of trustees, proxy voting or delegation of authority. The open question is under what circumstances is it reversible injective mapping, --DrLLau

Medium-Hard

Good knowledge about cryptography. Depending on your proposal, excellent understanding of the Bitcoin/Namecoin code-base and internals may (or may not) be necessary. We expect that NMControl-based proposals will be easier for students than Namecoin Core-based proposals.

Should we rephrase the above to make clear that ncdns is okay as an alternative to NMControl? --Biolizard89 (talk) 07:54, 5 January 2016 (UTC)

Yes --Josephbisch (talk) 15:15, 18 January 2016 (UTC)

Your encryption system implemented into the Namecoin client or NMControl.

I'm a little concerned that the above is vague. Are you wanting a engine to pick/swap for future proofing, a mechanism for remote user-defined name/value manipulation or programming hook for customisation? --DrLLau

Should we rephrase the above to make clear that ncdns is okay as an alternative to NMControl? --Biolizard89 (talk) 07:54, 5 January 2016 (UTC)

Yes --Josephbisch (talk) 15:15, 18 January 2016 (UTC)

domob, Ryan?, Jeremy

Anonymity and Taint Analysis Tools

Namecoin suffers the same problems with traceability (lack of anonymity) of coin flows that Bitcoin does. When Namecoin is used for its stated purpose to provide censorship-resistant browsing and registration of domains for possibly controversial purposes (e.g. under repressive regimes), this may be even a bigger problem than with Bitcoin. Unfortunately, there is not a good way for these users to easily evaluate what information is leaking to statistical and graph theory attackers. Paradata (impression of data on other data as in passive digital footprints) is impossible to erase and may lead to adverse consequences. You can think of ways to improve this, possibly by implementing "taint analysis" similar to what Blockchain.info does. Remember that names carry more data than currency transactions, and thus a Namecoin taint analyzer can be much more effective. For example, learning that the same individual probably controls two given names, one of which has publicly traceable ownership data in its value (e.g. an IP address), may reveal a lot. We are particularly interested in helping users learn about potential anonymity implications of their actions *before* they issue a transaction, although this is not a strict requirement for this project.

Are we in agreement that this is still desirable? I believe that it is. --Biolizard89 (talk) 08:02, 5 January 2016 (UTC)

The Open Bitcoin Privacy Project (mostly run by Kristov Atlas and Justus Ranvier) may be a relevant source of expertise. --Biolizard89 (talk) 08:02, 5 January 2016 (UTC)

Are we in agreement that Zerocash is sufficiently immature that it shouldn't be mentioned here? --Biolizard89 (talk) 08:02, 5 January 2016 (UTC)

Medium

Knowledge of Bitcoin's anonymity properties/attacks.

A working tool for helping Namecoin users analyze their anonymity or taint.

domob, Ryan?, Jeremy

Renewal Keys

Right now it is not possible to securely delegate renewal permissions for a name without also delegating alteration and transfer permissions for that name. This is because renewal is the same blockchain operation as alteration: name_update (which is analogous to spending a standard coin). You can fix this by creating, testing, and deploying pubkey scripts which allow two keys to spend a name, with one of the keys being restricted to spending the name in a way that produces the same pubkey script.

You may have to extend Namecoin's script system with an additional opcode; this is acceptable, as long as the result is a softfork (only 51% of miners have to upgrade), not a hardfork (100% of users must upgrade). Note that if your project requires changes to the consensus rules, you will be implementing on a testnet. Merging to mainnet will occur later after sufficient review has occurred.

Are we in agreement that this is still desired? I believe it is. --Biolizard89 (talk) 08:16, 5 January 2016 (UTC)

Should we make it clear that the implementation outlined at the end of the first paragraph is a suggestion and not a requirement? I.e. if someone can find another way to do renewal keys that is in some way superior, we shouldn't automatically reject it. --Biolizard89 (talk) 08:16, 5 January 2016 (UTC)

Is "no hardfork" a hard requirement, or just something that's highly desirable? IMHO if a compelling case can be made that a hardfork offers better functionality, we shouldn't automatically reject it. --Biolizard89 (talk) 08:16, 5 January 2016 (UTC)

Hard

Very good knowledge of Bitcoin or Namecoin's script system.

A working proof-of-concept of delegating renewal permissions.

domob, Ryan?

Armory Port (project to be deleted/deferred or rolled into lightweight client)

Finish implementing Namecoin support in Armory (including name operations), so that users can take advantage of its advanced features (in particular, cold storage / offline transactions) both for secure storage of NMC as well as names. Joseph Bisch did some preliminary basic Namecoin support (without any Namecoin-specific transaction types), so it can be helpful to take a look at his work.

I suggest removing this due to ATI indefinitely suspending free software development in August 2015. Maybe consider merging with the Light Client section and just say "port a Bitcoin client to Namecoin", with any currently unported client that's on bitcoin.org except for Armory being okay? --Biolizard89 (talk) 08:26, 5 January 2016 (UTC)

Medium

Good understanding of how Namecoin works (particularly names and the associated transaction types), C++ and Python experience for hacking on Armory. Some knowledge of the Armory codebase is helpful, but not necessary.

An installable version of Armory that supports Namecoin specific transaction types and the display/storage/transfer of names through the GUI. It is not necessary for the changes to be merged upstream.

domob

Block Explorer

Create a Namecoin block explorer with support for names. This would preferably be done by modifying an existing Bitcoin block explorer. Ryan suggests Insight (source code here), but you're welcome to pick your own choice. By itself, this may be too small of a project, so you may wish to combine with parts of the taint analysis project listed above. A fork detector would also be a useful feature to add.

Opinions on whether this is still relevant? mhanne has a free software block explorer with name support. What's the effort level and benefit of Insight? --Biolizard89 (talk) 08:33, 5 January 2016 (UTC)

Easy-Medium

Experience with web development and design, possibly Ajax.

A deployable block explorer with support for names.

domob, Ryan?

File Signing & Verification. Fuzzy Immutable Data.

Namecoin can provide an excellent base for signing files (like software releases) and verifying their integrity, e.g. in combination with GPG. Implement a tool that handles this, both for signers and users just wanting to verify their downloads (should be easy to use for them). You can propose a programming language / toolkit to use for this project. There exists already some code to interface to the Namecoin API over JSON-RPC for some languages (C++, Python, PHP), and it is easy to do from others as well.

The more challenging extension is extending immutable data to handle fuzziness. An example is a voting record where the proposal is fixed, but the names eligible to vote may vary up to a time-window (resolution frame) and the choice is indeterminable if a veto/block is cast or not affirmed afterwards by abstainers.This is equivalent to finding a hash of size n+m which first n digits are the same for all voting records outside time window and the last resolves to zero for all the varying component. The hash function may be a secret.

Is this still relevant? --Biolizard89 (talk) 08:40, 5 January 2016 (UTC)

Easy

Ability to design and develop your own software project, skills in designing an easy-to-use and cross-platform UI. Basic understanding of how Namecoin works.

Installable/runnable software in at least one programming language that handles the workflow for both signers and verifiers for the Namecoin-based signing/verification of files.

domob, phelix? drllau

Secure Public Key Distribution

Namecoin is very well suited to distribute any type of "public key" for human-readable names / online identities. This has already been taken advantage of for Bitmessage, and a proof-of-concept implementation for OTR fingerprints in Pidgin exists, too. Think about other possible uses (e. g., Bitcoin addresses in wallet software like Electrum, or GPG keys) and implement them.

IPv6 has more sophisticated Secure Neighbour Discovery mechanisms which are targetted for mobile or location aware infostructures. However PKI are one of the most challenging tasks for a security conscious world and careful thought needs to apply to balancing usability with risk mitigation.


Is this still relevant? I vaguely recall that Phelix has been working on GPG stuff? --Biolizard89 (talk) 08:40, 5 January 2016 (UTC)

Easy

Knowledge about the particular use-case and tool where you want to add Namecoin support, and basic understanding of Namecoin and public key crypto systems.

Software that supports the distribution of public keys in a secure way using Namecoin.

domob

Non-surjective P2P Messaging

A protocol (possibly publish/subscribe) to support secure short messaging to one or many participants.

	+	

An example is Bitmessage which already some support for Namecoin IDs by Domob. It could be extended in a way that in the GUI all bitmessage addresses that have corresponding Namecoin IDs (/id namespace) will be replaced by the IDs. To do so it will be necessary to securely lookup both ways id-->address, address-->id so it will be necessary to do some cross signing and storing the signature in the id or an additional name that can be found directly via the address. To be accepted upstream it would be helpful if it could fall back to addresses only if no name data source can be found.

Is Bitmessage still maintained? I don't see any releases on their site in over a year. --Biolizard89 (talk) 08:40, 5 January 2016 (UTC)

Seems to not be maintained any more. I say we drop this idea. --Josephbisch (talk) 15:15, 18 January 2016 (UTC)


Suggest making it more generic and just use BitMessage as example. I'd like to see something that allows short messaging loops/branches without have every single message as a separate namecoin transaction as it allows faster confirmation of validity. --DrLLau

Easy-Medium

Python, PyQt GUI, scripting with signatures and namecoin

Short messages chained/branched with Namecoin IDs

domob

Your Own Namecoin Use or Enhancement

Namecoin can be used for lots of novel and interesting use cases, and existing use cases are open for improvement. Propose your own use case or improvement, and discuss it with us!

Is there time to refine these into a project? --DrLLau

?

?

?

?

New 2016 project ideas: Tor hidden service naming. I2P hidden service naming. IP-based .bit naming while using Tor/I2P. TLS implementation improvements. Segregated name values. --Biolizard89 (talk) 06:57, 5 January 2016 (UTC)