Adding namecoin "id/" namespace support into bitmessage

[domob]

Few suggestions : https://bitmessage.org/wiki/API_Reference bitmessage has an API ... maybe Atheros will pipe out whatever methods you might need if you ask pleasantly?

Also maybe make the lookups somewhat configurable so that a local namecoind/nmccontrol could be used, etc ... i.e. do not just hard code khal's .bit DNS server IP address for name look-ups (jk)

Thanks for the input! I'm definitely planning to use rather the local namecoind by default instead of a public one, because I personally think that's the way to go for decentralisation. My current plan is to make host/port/user/passwort for the RPC connection configurable (if I manage to do that), but default to local namecoind in any case. (Or even use *only* the local namecoind or nmcontrol for the beginning.)

[moa]

Few suggestions : https://bitmessage.org/wiki/API_Reference bitmessage has an API ... maybe Atheros will pipe out whatever methods you might need if you ask pleasantly?

Also maybe make the lookups somewhat configurable so that a local namecoind/nmccontrol could be used, etc ... i.e. do not just hard code khal's .bit DNS server IP address for name look-ups (jk)

Thanks for the input! I'm definitely planning to use rather the local namecoind by default instead of a public one, because I personally think that's the way to go for decentralisation. My current plan is to make host/port/user/passwort for the RPC connection configurable (if I manage to do that), but default to local namecoind in any case. (Or even use *only* the local namecoind or nmcontrol for the beginning.)

Keep in mind that your average user actually doesn't like configurability ... they want something that "just works" without fiddling (and opportunities to mess it all up) ... out of the box behaviour should just work for the casual user (e.g. look-up a public namecoin DNS server) but configurability for local namecoind look-up and other options for increased autonomous and decentralised behaviour available (config file, pull-down menu or whatever).

Also could maybe include the functionality for a bitmessage user to register a namecoin bitmessage id for themselves from inside bitmessage? Not sure how much extra work this would entail though, but it would be great if all bitmessage users suddenly become a potential namecoin audience just by upgrading to the latest bitmessage s/ware.

[khal]

I'm thinking of using "namecoind name_show id/domob" directly instead of nmcontrol. Is there a good reason why I should use nmcontrol instead?

For the simple use case, I would choose namecoind, but for more complex things... it might have some interest to chose nmcontrol.

Features of NMControl :
+ no login/password required to read data in the blockchain (connect to 127.0.0.1:9000 and you are done)
+ data pre-processing
+ can read data from a file instead of namecoind (less security but lighter bundle, but need updates)
+ data can be cached in NMControl, so searching in values (reverse lookup) will be faster, or even pre-calculated
- another dependency is added
- system to authenticate is not done and would be required to create an id

Of course, it would be great if someone wants to sponsor a bounty (or donate some coins)!

Start a new thread at bitcointalk or bitmessage forum to say what you're doing, what is the advancement and ask for donation/funding.

Do the namecoin funding has some coins to spend on this ?

[domob]

Keep in mind that your average user actually doesn't like configurability ... they want something that "just works" without fiddling (and opportunities to mess it all up) ... out of the box behaviour should just work for the casual user (e.g. look-up a public namecoin DNS server) but configurability for local namecoind look-up and other options for increased autonomous and decentralised behaviour available (config file, pull-down menu or whatever).

Of course, the base setup should work out-of-the-box. I'm currently thinking about using the local namecoind by default, though, so the user would have to install it. But when something working is there already, we can of course discuss alternatives like using nmcontrol with a cached local file as data store or a remote RPC server to use instead by default.

Also could maybe include the functionality for a bitmessage user to register a namecoin bitmessage id for themselves from inside bitmessage? Not sure how much extra work this would entail though, but it would be great if all bitmessage users suddenly become a potential namecoin audience just by upgrading to the latest bitmessage s/ware.

I presume we could do that (calling back to namecoind), although there are some difficulties: You would need to get namecoins prior to that (and thus be exposed to namecoin anyway), we need to handle the name_new / name_firstupdate actions with a suitable time interval between them, the user may want to add more than just his/her BM address to his new identity, and so on. In short, I believe this is something which does not fit very well into the bitmessage client itself - we should rather add this to namecoin-qt, if identities become more mainstream.

[domob]

I'm thinking of using "namecoind name_show id/domob" directly instead of nmcontrol. Is there a good reason why I should use nmcontrol instead?

For the simple use case, I would choose namecoind, but for more complex things... it might have some interest to chose nmcontrol.

Features of NMControl :
+ no login/password required to read data in the blockchain (connect to 127.0.0.1:9000 and you are done)
+ data pre-processing
+ can read data from a file instead of namecoind (less security but lighter bundle, but need updates)
+ data can be cached in NMControl, so searching in values (reverse lookup) will be faster, or even pre-calculated
- another dependency is added
- system to authenticate is not done and would be required to create an id

Thanks for the details! I think the login/password stuff won't be too much of a problem (default values can be read from ~/.namecoin/bitcoin.conf or the Windows equivalent, that shouldn't be too hard), but the possibility of different data sources (without requiring a blockchain) may be interesting in the future. Maybe I really look into this, let's see.

Of course, it would be great if someone wants to sponsor a bounty (or donate some coins)!

Start a new thread at bitcointalk or bitmessage forum to say what you're doing, what is the advancement and ask for donation/funding.

Do the namecoin funding has some coins to spend on this ?

Good idea, I'll create announcements there and will post my updates (as soon as there are some) in the BM forum, too. I certainly will appreciate donations (and would love to "earn" my first namecoins ), but will start work nevertheless even without a fixed bounty already sponsored or so. This will be a good possibility for me to get into Python, which I in fact wanted to do already for at least five years or so....

[phelix]

Hmm... not sure if a lot of people will start Namecoin and wait for the blockchain to download just to translate a name. On the other hand people interested in Bitmessage should also be interested in Namecoin.

Anyway, NMDF is offering 0.5BTC for this project.

* Needs to be able to query namecoind via rpc or pynamecoin (https://github.com/phelixbtc/ncsc)
* Needs to be able to query nmcontrol (configuration option or automatic if easily possible)

Maybe it is possible to use parts of the rpc code that nmcontrol itself uses to talk to namecoind.

I think it should work like this: no slash in the entered name: id/ will be prefixed. Otherwise use name as entered.

Registering names should stay out of this IMHO.

[domob]

Hmm... not sure if a lot of people will start Namecoin and wait for the blockchain to download just to translate a name. On the other hand people interested in Bitmessage should also be interested in Namecoin.

Anyway, NMDF is offering 0.5BTC for this project.

* Needs to be able to query namecoind via rpc or pynamecoin (https://github.com/phelixbtc/ncsc)
* Needs to be able to query nmcontrol (configuration option or automatic if easily possible)

Maybe it is possible to use parts of the rpc code that nmcontrol itself uses to talk to namecoind.

I think it should work like this: no slash in the entered name: id/ will be prefixed. Otherwise use name as entered.

Registering names should stay out of this IMHO.

Great! I'll start as soon as I come home from work today (which was the original plan anyway, but the bounty motivates more, of course ). I'll probably start to bind to namecoind only, but will add nmcontrol support when that is done.

[virtual_master]

An interesting idea from which could profit both Namecoin and Bitmessage.

[phelix]

Nice and simple rpc example...

https://github.com/bitcoin/bitcoin/blob ... /bitrpc.py

[domob]

Nice and simple rpc example...

https://github.com/bitcoin/bitcoin/blob ... /bitrpc.py

Is it ok if I use that package (jsonrpc)? Apparently it is not installed by default with Python on my system, and I also wasn't able to locate the right Debian package right-away (if there even exists one). So I'm not sure how easy it would be for potential users to install it as additional dependency...? Or is this easier with Windows, and only Debian's "fault"?

EDIT: Don't mind, I'm rolling my own implementation based on rpcClient.py in nmcontrol directly with sockets. I wasn't able to figure out how to tell jsonrpc not to block and ask for user/password on the console when the authentication info is wrong, which is unacceptable behaviour in my case.