Namecoin Forum

This idea was brought up by Domob here and was further discussed here.

I just ran across the Skier keyserver (Python): https://github.com/SkierPGP/Skier

It looks like it is too much for this purpose but may be helpful in creating a minimal local server. E.g. to be used in NMControl.

[edited]

> It looks like it is too much for this purpose but may be helpful in creating a minimal local server

A recent commit makes it possible to "thin" the server: "Allow enabling or disabling of certain, more bloaty Skier features.":
https://github.com/SkierPGP/Skier/commi ... a3896bb1ba

Edit: Maybe the source of this Thunderbird plugin could be modified to talk to Namecoin (instead of OpenLDAP).

Secure Addressing 1.6
by Hiroya Matsuba
This add-on provides features to avoid sending emails to wrong addresses. Key features are a confirmation window of recipient's addresses upon sending, name and affiliation look up at mail composition and main windows, and safe auto completion.

somename wrote:> It looks like it is too much for this purpose but may be helpful in creating a minimal local server

A recent commit makes it possible to "thin" the server: "Allow enabling or disabling of certain, more bloaty Skier features.":
https://github.com/SkierPGP/Skier/commi ... a3896bb1ba

That certainly is an improvement. What I had in mind was a very simple bottle request.

Any objections to a bounty for an NMControl plugin?

Edit: Maybe the source of this Thunderbird plugin could be modified to talk to Namecoin (instead of OpenLDAP).

Secure Addressing 1.6
by Hiroya Matsuba
This add-on provides features to avoid sending emails to wrong addresses. Key features are a confirmation window of recipient's addresses upon sending, name and affiliation look up at mail composition and main windows, and safe auto completion.

Hmm this looks more complicated. Also the keyserver approach should work with every mail client.

I had completely missed we already have a bounty for this. Maybe I should take a break.

Still, how would this work? Search the keyserver for id/user and have the keyserver reply with exactly one key? This would mean the keyserver would have to dig through the whole id namespace.

phelix wrote:This would mean the keyserver would have to dig through the whole id namespace.

This is no big issue, I think. Currently (~5000 id/ records) reading in into a simple cache array takes less than an hour using name_show. Probably much less with name_filter or a new purpose-built RPC. Even if we have half a million ids this doesn't take a lot more time as most CPU time is wasted separating the 600000+ d/ records.
After this cache setup the keyserver could permanently listen to incoming blocks, extract any id content from a new block and update the cache.

cassini wrote:

phelix wrote:This would mean the keyserver would have to dig through the whole id namespace.

This is no big issue, I think. Currently (~5000 id/ records) reading in into a simple cache array takes less than an hour using name_show. Probably much less with name_filter or a new purpose-built RPC. Even if we have half a million ids this doesn't take a lot more time as most CPU time is wasted separating the 600000+ d/ records.
After this cache setup the keyserver could permanently listen to incoming blocks, extract any id content from a new block and update the cache.

Actually "name_filter id/" takes only 10 seconds or so. Maybe this is the way to go for now.

The way I assume this should work is by getting the actual key from a keyserver. Tor support could be added but it still is not very nice. Alternatively we could store the key in the blockchain (my pubkey is ~1200 bytes - 3 names/values). Opinions?

phelix wrote:The way I assume this should work is by getting the actual key from a keyserver. Tor support could be added but it still is not very nice. Alternatively we could store the key in the blockchain (my pubkey is ~1200 bytes - 3 names/values). Opinions?

I think we shouldn't put pubkeys into the blockchain. Instead, I agree with phelix that getting the key from a keyserver over Tor and verifying the fingerprint against the blockchain seems fine. Doesn't the id/ format also allow to specify a link to the pubkey if hosted somewhere? This (if present) could also be used.

domob wrote:

phelix wrote:The way I assume this should work is by getting the actual key from a keyserver. Tor support could be added but it still is not very nice. Alternatively we could store the key in the blockchain (my pubkey is ~1200 bytes - 3 names/values). Opinions?

I think we shouldn't put pubkeys into the blockchain. Instead, I agree with phelix that getting the key from a keyserver over Tor and verifying the fingerprint against the blockchain seems fine. Doesn't the id/ format also allow to specify a link to the pubkey if hosted somewhere? This (if present) could also be used.

Will ECC pubkeys fit in the blockchain acceptably? I think GPG has added support for them in beta versions. (Not certain on this.)

biolizard89 wrote:

domob wrote:

phelix wrote:The way I assume this should work is by getting the actual key from a keyserver. Tor support could be added but it still is not very nice. Alternatively we could store the key in the blockchain (my pubkey is ~1200 bytes - 3 names/values). Opinions?

I think we shouldn't put pubkeys into the blockchain. Instead, I agree with phelix that getting the key from a keyserver over Tor and verifying the fingerprint against the blockchain seems fine. Doesn't the id/ format also allow to specify a link to the pubkey if hosted somewhere? This (if present) could also be used.

Will ECC pubkeys fit in the blockchain acceptably? I think GPG has added support for them in beta versions. (Not certain on this.)

Yeah they should fit. This would be cool. But with my enigmail I can not create ECC keys so we should probably allow other methods, too, and maybe postpone this a bit.