Adding namecoin "id/" namespace support into bitmessage

[phelix]

NMDF will sponsor a small bounty I guess. It should be decided and written down first what it will be for.

I posted in the bitmessage thread. Actually MOA suggested this a long time ago and there was some discussion which I and others derailed unfortunately https://bitcointalk.org/index.php?topic ... msg2578956

[domob]

NMDF will sponsor a small bounty I guess. It should be decided and written down first what it will be for.

I posted in the bitmessage thread. Actually MOA suggested this a long time ago and there was some discussion which I and others derailed unfortunately https://bitcointalk.org/index.php?topic ... msg2578956

That would be great! I think I should find enough time to implement it (at least in the form described above) within a week or so. But I'll wait for a consensus on what exactly "the community" wants as goals.

[domob]

Any new thoughts about this one? I would love to try my hands on it, as soon as there's some consensus worked out as to what the patch to bitmessage "should" do. Are there any new plans for a bounty?

[moa]

It's pretty straightforward isn't it? ... someone stores a BM-xxxx address in the namecoin blockchain and the bitmessage client looks it up somehow and delivers the address associated with the human readable field.

Not sure why it has to be in id/ naemspace necessarily since "email" is a field for d/name ... just add "bm" as a field to d/name spec?

[domob]

It's pretty straightforward isn't it? ... someone stores a BM-xxxx address in the namecoin blockchain and the bitmessage client looks it up somehow and delivers the address associated with the human readable field.

Not sure why it has to be in id/ naemspace necessarily since "email" is a field for d/name ... just add "bm" as a field to d/name spec?

Yes, that's precisely what I'm thinking about. But before I go and implement it, I would love to get some more feedback about how the community thinks this should be done best (enter the name into the "To" field and click a new button, or add functionality to import addresses from namecoin into the BM address book, or something else...)? The basic idea is straight-forward, as you point out.

I think it should belong to the identity namespace, at least if we talk about addresses for persons (or online identities). I guess the email field for domains is meant as a means to contact the domain owner, and of course one could also add a BM address there. I do however believe that it is more common to "just" message people instead of domain owners, and thus it makes sense IMHO to use a separate namespace for my personal contact information as opposed to contact information for my website. I hope I was able to clarify what I mean here, and this doesn't sound like nonsense....

[khal]

It's pretty straightforward isn't it? ... someone stores a BM-xxxx address in the namecoin blockchain and the bitmessage client looks it up somehow and delivers the address associated with the human readable field.

Not a lot of work, but still need to connect to namecoind (or nmcontrol) with right user/login, send rpc request and extract data from the result.

Not sure why it has to be in id/ naemspace necessarily since "email" is a field for d/name ... just add "bm" as a field to d/name spec?

Why would someone need a .bit domain to send a message in Bitmessage ?
That's why separated spec exists (and the d namespace could integrate them if it is relevant, but should not include all what is possible to do with namecoin :S)

Someone to start a bounty thread and promote it ?

[edit]I think that a bounty for the first and more simple part should be a good start. But you can also propose both in the bounty and people can donate for one or the other or both features.

[snailbrain]

if used the id/ prefix as standard, it might look tidier in bitmessage (as it could be invisible when you add a name).. also looks more noob friendly... e.g. just add snailbrain to the address book instead of id/snailbrain and bitmessage will auto insert the id/ when querying namecoin.

but not the end of the world if the user has to type in d/ or id/ in front.. (maybe good if you have the option to do different prefixes)

_____

personally i think would be best if it used just id or even bm... and have a "standard"

might be easier to search the namespace if all use the same prefix

in bitmessage there could be a search function which does the name_filter command (which i haven't completely figured out how to get the correct results).. it will just show a table of bm names, with email (if added) and expiry (probably good idea).. right click add to address book.. or just send them a message...

bitmessage would also need to be able to do a reverse lookup(?), so if someone sends you a message it can associate that with a name,, maybe bitmessage can cache the entire namespace (probably not that big), or maybe don't need to (it's all in nameindex.dat?)

[khal]

if used the id/ prefix as standard, it might look tidier in bitmessage (as it could be invisible when you add a name).. also looks more noob friendly... e.g. just add snailbrain to the address book instead of id/snailbrain and bitmessage will auto insert the id/ when querying namecoin.

but not the end of the world if the user has to type in d/ or id/ in front.. (maybe good if you have the option to do different prefixes)

_____

personally i think would be best if it used just id or even bm... and have a "standard"

Each software could display the namecoin id like they want.
If namecoin is the only way to identify users in a software, it could use the id without the namespace directly.
If there are other systems, like in Bitmessage where you have non namecoin ids, having a way to distinguish between both id types may be needed, for ex: khal@namecoin.

might be easier to search the namespace if all use the same prefix

in bitmessage there could be a search function which does the name_filter command (which i haven't completely figured out how to get the correct results).. it will just show a table of bm names, with email (if added) and expiry (probably good idea).. right click add to address book.. or just send them a message...

name_filter uses regexp.
To search for all names starting with "id/" (searching in value is not possible), not expired (go back to 36k blocks by default) :

Code: Select all

namecoind name_filter "^id/"

bitmessage would also need to be able to do a reverse lookup(?), so if someone sends you a message it can associate that with a name,, maybe bitmessage can cache the entire namespace (probably not that big), or maybe don't need to (it's all in nameindex.dat?)

Indeed, querying all names and filtering those containing a "bitmessage" record (and optionnaly caching the result) is the only way to do it.
name_filter can be used to query only recent records to get updates (will search for names updated in the last 500 blocks) :

Code: Select all

namecoind name_filter "^id/" 500

- name_filter is a bit slow, so, searching in a separate thread would be better
- one Bitmessage address can return several ids, which can all be fake users. Not sure it would be real a problem, because message are crypted with public keys (but someone can annoy someone else and publish "fucking-id-name" with his address)

[domob]

It's pretty straightforward isn't it? ... someone stores a BM-xxxx address in the namecoin blockchain and the bitmessage client looks it up somehow and delivers the address associated with the human readable field.

Not a lot of work, but still need to connect to namecoind (or nmcontrol) with right user/login, send rpc request and extract data from the result.

Not sure why it has to be in id/ naemspace necessarily since "email" is a field for d/name ... just add "bm" as a field to d/name spec?

Why would someone need a .bit domain to send a message in Bitmessage ?
That's why separated spec exists (and the d namespace could integrate them if it is relevant, but should not include all what is possible to do with namecoin :S)

Someone to start a bounty thread and promote it ?

[edit]I think that a bounty for the first and more simple part should be a good start. But you can also propose both in the bounty and people can donate for one or the other or both features.

As mentioned already, I volunteer to work on that as soon as I find some time, since I'm also personally interested in it. My proposal for a very first step:

Add a button (next to "load from address book" or what it is called) to the "To" field in the send dialog of Bitmessage, such that when I enter "domob" (or even id/domob) into "To" and click the button, it performs a lookup and replaces the value in To with the BM address. In my opinion, this is easy to use and has a very low potential of confusing users. What do you think about it? I believe I should be able to do that until late next week or so at the latest. (Still have to work my way into the Bitmessage source and also Python, but that seems definitely doable.)

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? Parsing the result (extracting the bitmessage JSON field) seems not like that much work to me, so I don't think it would be beneficial to use nmcontrol for that.

Of course, it would be great if someone wants to sponsor a bounty (or donate some coins)! But as I said, I'm also personally interested to see this done, and probably willing (although a little less motivated) to do it also without one. I would prefer though if not someone else works on this, too, snatches the bounty before I'm done and additionally makes my work wasted time.

[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)