Namecoin Forum

1.) register an eMail account at some random free eMail hoster
2.) include the address in an ID
3.) send encrypted and signed mails "to an ID"
4.) only mails signed by an id are considered valid
5.) user should only need to deal with IDs, never with actual eMail addresses

Advantages:
* inherent key handling
* possibility to add spam prevention measures via proof of burn, wot
* one can switch mail hosters easily
* can use existing infrastructure (in contrast to bitmessage)

Implementation via Thunderbird plugin, standalone software, local eMail relay?

can nmcontrol theoretically sign/encrypt messages? that' would be great.

phelix wrote:Implementation via Thunderbird plugin, standalone software, local eMail relay?

Using the wire protocol (no need to run a namecoin client)
or via RPCs (requires running a namecoin client)
or maybe even PoW-secured API?

Seems like most of this proposal could be implemented via a Namecoin id/ add-on to something like EnigMail.

biolizard89 wrote:Seems like most of this proposal could be implemented via a Namecoin id/ add-on to something like EnigMail.

Yes, that's something I would also love to see. Unfortunately, the Enigmail developers did not like the idea when I brought it up some time ago - so it has not much chances of being eventually merged in. (Not even "just" key handling via id/.)

Their argument was that Enigmail is supposed to be a front-end for GnuPG, and thus they only support things that are in GnuPG (with a UI added). GnuPG, on the other hand, is an implementation of the respective RFC. Thus, in effect, they said that we would need to get id/ into OpenPGP itself in order to be officially supported by Enigmail. I do not know how realistic that is (maybe it actually is), neither do I know how much effort it would be to maintain a fork of Enigmail.

domob wrote:

biolizard89 wrote:Seems like most of this proposal could be implemented via a Namecoin id/ add-on to something like EnigMail.

Yes, that's something I would also love to see. Unfortunately, the Enigmail developers did not like the idea when I brought it up some time ago - so it has not much chances of being eventually merged in. (Not even "just" key handling via id/.)

Their argument was that Enigmail is supposed to be a front-end for GnuPG, and thus they only support things that are in GnuPG (with a UI added). GnuPG, on the other hand, is an implementation of the respective RFC. Thus, in effect, they said that we would need to get id/ into OpenPGP itself in order to be officially supported by Enigmail. I do not know how realistic that is (maybe it actually is), neither do I know how much effort it would be to maintain a fork of Enigmail.

How is retrieving keys from keyservers handled in Enigmail? Is that code actually part of GPG? If it's part of GPG, then yes, I think id/ support would need to be added to GPG. If not, then I don't follow the logic of the Enigmail devs.

johnc wrote:can nmcontrol theoretically sign/encrypt messages? that' would be great.

You mean like the satoshi client? NMControl does not usually handle private or public keys.

The signing/encryption part should be easy to implement (Bitcointalk: Encrypt/decrypt arbitrary text using bitcoin keys!)

biolizard89 wrote:How is retrieving keys from keyservers handled in Enigmail? Is that code actually part of GPG?

Yes

kresp0 wrote:

biolizard89 wrote:How is retrieving keys from keyservers handled in Enigmail? Is that code actually part of GPG?

Yes

Thanks for that info. So it sounds like adding id/ to GPG would be the logical step. Maybe there would be a way to have NMControl follow the keyserver protocol, so that GPG doesn't need changes itself?

biolizard89 wrote:Thanks for that info. So it sounds like adding id/ to GPG would be the logical step. Maybe there would be a way to have NMControl follow the keyserver protocol, so that GPG doesn't need changes itself?

I guess that it may be possible to have an id/ keyserver to retrieve keys. When someone ask for a key, the server would search, download and verify the key based on the blockchain information and then upload it to the client.

But, what about submitting a key to the server? The server would verify and store the key, sure. But how is that reflected on the blockchain? A write operation has some cost. Who pays it? Maybe some rich namecoiner could afford to sponsor a server. Or the MIT Digital Currency Initiative, as they (MIT) also have a nice PGP keyserver

Another problem submitting keys is where to store them. If I verify your identity and key fingerprint and sign your key, where on the blockchain should that information go? Should that information be on the blockchain at all? The keyserver cannot touch id/user as they do not have the private key. Maybe the server should create another identity to put there a link and fingerprint to the received signed keys?

After 2 minutes of thought, I think that a id/ keyserver which acts like a normal gpg keyserver but also just read the information on the blockchain could be useful enough. In the example before, the server would verify and upload the keys to the rest of normal keyservers. It may also scan the whole blockchain and upload the valid keys to the public keyservers if they are not already there.