The first secure, decentralized, human-meaningful naming system.
https://forum.namecoin.org/
I think that would be great - but since I personally prefer the command-line to a lot of UIs, you will probably have to discuss that with others who plan on using that feature.snailbrain wrote:was waiting for any bug reports and minor fixes before doing anything else on it.. but we could have ID Tab, with all that too
I also propose a new field "nmcsig" as I think it will become more widely used to put a self-signed message/hash, etc into the value to prove ownership of the nmc-address where the name/value pair are stored.snailbrain wrote:was waiting for any bug reports and minor fixes before doing anything else on it.. but we could have ID Tab, with all that toodomob wrote:That would be great! What about even adding a whole set of possible options for identities (as described on the wiki)? Like real name, email address, bitmessage, bitcoin address, namecoin address, PGP fingerprint?snailbrain wrote:excellent work .. we can add bitmessage field to configure names part of qt (to make it very easy)
Code: Select all
id/somename {"nmcsig":"HDKmzKf1vY7XDnmOYy6Wx0HDQVZMjHpftv/PnFDXnDjvVSm8PXX++BMCfHZK1OitECSXGA7c7MQ4Elkujmuh+eA="}Sounds like a good idea to me - if there's some kind of consensus formed as to this field, I can definitely implement it in some way into my patch.moa wrote: Why do this?
Since namecoin allows anyone to send a name-value to any other nmc address, anyone viewing the blockchain can never be sure if the owner of the nmc key actually put that name-value pair at that address. However, if the name is self-signed and stored as part of the value by that nmc priv key then it is much more likely that that name should be at that address with those values.
I suppose there could also be a "selfsigname" field that is specifically the nmcsig of the "name" part of the "id/name" supposedly signed by the address it resides at and not some other generic nmc signed message.
Yeah, you're right .... but the particular case that bought it up was if the name expired (say by accident memory lapse, owner drops into a coma, etc) and then an attacker grabbed the name and sent it back to original owner's nmc address but this time with a BM-attacker, or fingerprint:hacker, value etc. Having the nmcsig(value) in there prevents this happening ... actually you make me think of a good point here. I should have said nmcsig(value) NOT nmcsig(name) ... I only said this because the case I was looking at we use for the name a secured hash, i.e. a value.domob wrote:Sounds like a good idea to me - if there's some kind of consensus formed as to this field, I can definitely implement it in some way into my patch.moa wrote: Why do this?
Since namecoin allows anyone to send a name-value to any other nmc address, anyone viewing the blockchain can never be sure if the owner of the nmc key actually put that name-value pair at that address. However, if the name is self-signed and stored as part of the value by that nmc priv key then it is much more likely that that name should be at that address with those values.
I suppose there could also be a "selfsigname" field that is specifically the nmcsig of the "name" part of the "id/name" supposedly signed by the address it resides at and not some other generic nmc signed message.
EDIT: Thinking about it - why is the situation you try to avoid different from just someone registering a name and not sending it around at all? If you were not yet a namecoin user, I can easily register "id/moa" with a rogue BM address to fake users into sending messages for you to me if they don't check that you indeed have a BM-enabled NMC identity. How is the situation you describe different from this one?
Code: Select all
id/somename {"bitmessage":"BM-goodguysbmaddress","selfsigbm":"NMCSIG(BM-goodguysbmaddress)"}
I'll send you one with PM when I get back to my wallet to generate it. Thanks!phelix wrote:Thread on the bitmessage forum: https://bitmessage.org/forum/index.php/ ... 563.0.html
Should I send the bounty to your normal address? Otherwise please pm.
Bounty paid out. Thank you for the great work.domob wrote:I'll send you one with PM when I get back to my wallet to generate it. Thanks!phelix wrote:Thread on the bitmessage forum: https://bitmessage.org/forum/index.php/ ... 563.0.html
Should I send the bounty to your normal address? Otherwise please pm.
If you ask me like that... be modular so it will also be possible to be used for other software, e.g. electrum desktop.Do you (or someone else) have more suggestions for what the code should also do? If not, I'll try to figure out how to "officially" submit a push request into the Bitmessage repository and see whether this gets done. (Atheros seems interested judging from the thread at the bitmessage forum.)
Received it, thanks!phelix wrote:Bounty paid out. Thank you for the great work.domob wrote:I'll send you one with PM when I get back to my wallet to generate it. Thanks!phelix wrote:Thread on the bitmessage forum: https://bitmessage.org/forum/index.php/ ... 563.0.html
Should I send the bounty to your normal address? Otherwise please pm.
I think the basic interfacing code to do RPC calls is (somewhat) reusable. Do you think it would make sense to abstract it even more so that one file can be copied to a new project without any changes? This would basically just mean removing the BM specific configuration routines and putting them into another file. I don't think this should be done, though, because I'm not sure whether the BM people like it to have even two new files in their code just for Namecoin integration.phelix wrote:If you ask me like that... be modular so it will also be possible to be used for other software, e.g. electrum desktop.Do you (or someone else) have more suggestions for what the code should also do? If not, I'll try to figure out how to "officially" submit a push request into the Bitmessage repository and see whether this gets done. (Atheros seems interested judging from the thread at the bitmessage forum.)
It does raise the interesting point to ponder what a generic namecoin-enabler plug-in/add-on might look like ... e.g. I see people are configuring Thunderbird to use BM-protocol http://www.youtube.com/watch?v=ppk_zzjZRIgso a namecoin id/ enabled Thunderbird or any email client and once you start down that path ... then the possibilities seem to increase considerably for using this technique for authenticated messaging of many kindsI think the basic interfacing code to do RPC calls is (somewhat) reusable. Do you think it would make sense to abstract it even more so that one file can be copied to a new project without any changes? This would basically just mean removing the BM specific configuration routines and putting them into another file.
Do you think it would indeed be a good idea to try integrating that into Electrum? I can try that out - although I've so far not yet used it at all.
