Namecoin Forum

Currently, bitmessage addresses are raw strings, like bitcoin addresses but they could support "names" from the id namespace.

Bitmessage is one possible use case for the id namespace, see the Other possible usages section.

Do you think we can propose the idea to bitmessage ?

Very promising idea. I'm trying to figure out the technical implications.

We issue a name_new, and after this we do a
name_firstupdate id/my_shiny_new_identity <rand> <tx> BM-oo8Asu2WaN1UHJdCyJCPPnyvLabtpaEbe

Then there must be some entity in the bitmessage network with access to this information, obviously.

Does this mean we need an "id/" gateway server running both namecoind and some bitmessage software?
Or did you think of a completely decentralised system that is able to connect both worlds?

khal wrote:Currently, bitmessage addresses are raw strings, like bitcoin addresses but they could support "names" from the id namespace.

Bitmessage is one possible use case for the id namespace, see the Other possible usages section.

Do you think we can propose the idea to bitmessage ?

this is sort of related.. there is a 7.5btc bounty for the namecoin part

https://bitcointalk.org/index.php?topic=225954.0

you mean something like: bitmessage id/khal "how's da goin'?"
Sure thing.

I could never wrap my head about fellowtraveler's holy grail. As far as I see all he talks about could be easily done with namecoin, too.

snailbrain wrote:

khal wrote:Currently, bitmessage addresses are raw strings, like bitcoin addresses but they could support "names" from the id namespace.

Bitmessage is one possible use case for the id namespace, see the Other possible usages section.

Do you think we can propose the idea to bitmessage ?

this is sort of related.. there is a 7.5btc bounty for the namecoin part

https://bitcointalk.org/index.php?topic=225954.0

could not find it.. ?

phelix wrote:you mean something like: bitmessage id/khal "how's da goin'?"
Sure thing.

I could never wrap my head about fellowtraveler's holy grail. As far as I see all he talks about could be easily done with namecoin, too.

snailbrain wrote:

khal wrote:Currently, bitmessage addresses are raw strings, like bitcoin addresses but they could support "names" from the id namespace.

Bitmessage is one possible use case for the id namespace, see the Other possible usages section.

Do you think we can propose the idea to bitmessage ?

this is sort of related.. there is a 7.5btc bounty for the namecoin part

https://bitcointalk.org/index.php?topic=225954.0

could not find it.. ?

http://ciyam.org/open/?cmd=view&data=20 ... m=a2a9d6d5

khal wrote:Currently, bitmessage addresses are raw strings, like bitcoin addresses but they could support "names" from the id namespace.

Bitmessage is one possible use case for the id namespace, see the Other possible usages section.

Do you think we can propose the idea to bitmessage ?

This is definitely an interesting idea (in fact, I thought about something like that as a useful feature myself some time ago). We could start by defining a standard field in the id/ value to be used as bitmessage address if there is not yet one (but I don't think so). Then on the namecoin part everything is there, and it remains to add support to this to the bitmessage application.

domob wrote:This is definitely an interesting idea (in fact, I thought about something like that as a useful feature myself some time ago). We could start by defining a standard field in the id/ value to be used as bitmessage address if there is not yet one (but I don't think so). Then on the namecoin part everything is there, and it remains to add support to this to the bitmessage application.

I've put it at the end of the spec, on the " Other possible usages" section :
https://dot-bit.org/Namespace:Identity# ... ble_usages

Maybe we can create a bounty for this and reference it there : http://dot-bit.org/forum/viewtopic.php?f=5&t=473
or there http://dot-bit.org/Bounties :p

khal wrote:

domob wrote:This is definitely an interesting idea (in fact, I thought about something like that as a useful feature myself some time ago). We could start by defining a standard field in the id/ value to be used as bitmessage address if there is not yet one (but I don't think so). Then on the namecoin part everything is there, and it remains to add support to this to the bitmessage application.

I've put it at the end of the spec, on the " Other possible usages" section :
https://dot-bit.org/Namespace:Identity# ... ble_usages

Maybe we can create a bounty for this and reference it there : http://dot-bit.org/forum/viewtopic.php?f=5&t=473
or there http://dot-bit.org/Bounties :p

I would be interested in working on that, at least after I got some more stuff done for NameID. Especially of course if there's a bounty.

Sorry for another follow up, but let me clarify my current thoughts: What I can well imagine is to add a button (or something else) to the Bitmessage composing UI, which when clicked, would take the value entered into "To", try to interpret it as an id/ name, query the local namecoind for a corresponding Bitmessage address, and when one is found, replace the To entry with it.

That should do the trick. Or did you imagine some different functionality? As written already, I'm interested in working on that as my time permits.

domob wrote:Sorry for another follow up, but let me clarify my current thoughts: What I can well imagine is to add a button (or something else) to the Bitmessage composing UI, which when clicked, would take the value entered into "To", try to interpret it as an id/ name, query the local namecoind for a corresponding Bitmessage address, and when one is found, replace the To entry with it.

That should do the trick. Or did you imagine some different functionality? As written already, I'm interested in working on that as my time permits.

I imagined it like that, at first.
A further integration could be done with the address book too (and if a bm-address is changed in namecoin for one of your namecoin contacts in bitmessage, the bitmessage address book should be able to update it too).