Messaging system

[khal]

The first draft to support a messaging system in namecoin has been written by zamgo :
http://dot-bit.org/Messaging_System

I didn't imagine it with existing name_* commands because its usage is limited (last message overwrite previous one), but why not ?

Any thoughts on this ?

[zamgo]

I was thinking about using new name_* commands (like in the Name Exchange proposal), but that would mean we have to wait until all the new commands are written, tested and put into the namecoind distribution. So instead this is a proposal for a semi-workable system using existing namecoind code.

The message value 'history' is actually all in the blockchain, so previous messages are still available. But reading the previous messages is not easy with current rpc commands. Using a blockexplorer does help. And currently only dot-bit blockexplorer supports showing name/value pairs.

Two possible rpc updates that would make messaging easier:

• - name_history {name} - Basically a combo of name_debug1 and name_scan {name} 0 that also returns the value of the name as it was at each transaction listed.

• - add a field "owner_address" to the returns of name_list and name_scan.

[JohnDoe]

I really like it, although I think the network fee will temporarily make this system not very attractive. The public nature of the messages and the 1023 max size might limit its usefulness as well.

[zamgo]

Yes, the cost is a concern. Best to try this on testnet for a while first

The 1023 limit makes it a SMS/twitter type of thing. Creating longer messages via multiple chained-together m/ names is possible.

The public nature of messages is a choice of the sender. Message content can be encrypted. For example a short-ish 'PGP MESSAGE' block of armored ascii will fit in 1023 characters.

[khal]

By using existing name_* commands, here are the limits :
- you must own a name to send a message
- your full message is limited to 1023 chars (without merging several messages, like the import field of the d/ namespace)

To send an encrypted message, you could use GPG keys (by putting a key id, or using the import-like of the d/ namespace "": [[p/khal], [gpgfingerprint]]), or namecoin addresses, only if you know the public key, which is only available when someone send money to this address (an address is used for each name_* operation, so we could also send message to name owners and namecoin will retrieve the associated public key).

Example of a name of the personal namespace (more info here),
p/khal :

Code: Select all

{
  "mail": "khal@dot-bit.org",
  "gpgfingerprint": "3ef2a1ff5b9f651b95638e8f9cc5b92e965d69a9",
  "btc": "1KHAL8bUjnkMRMg9yd2dNrYnJgZGH8Nj6T",
  "nmc": "N1KHAL5C1CRzy58NdJwp1tbLze3XrkFxx9"
}

Whatever solution is chosen, this patch will have an utility somewhere :
- Add name_history RPC command

[khal]

Here is the second step :
- Add owner address in name_scan, name_list and name_history

[moa]

Here is the second step :
- Add owner address in name_scan, name_list and name_history

Hi khal,

I tried your patch but it doesn't seem to return the address .. or am I missing something here?

Code: Select all

$ namecoind name_scan d/dot-bit 1
[
    {
        "name" : "d/dot-bit",
        "value" : "{\"info\":{\"description\":\"Dot-BIT Project - Official Website\",\"registrar\":\"http://register.dot-bit.org\"},\"ns\":[\"ns0.web-sweet-web.net\",\"ns1.web-sweet-web.net\"],\"map\":{\"\":{\"ns\":[\"ns0.web-sweet-web.net\",\"ns1.web-sweet-web.net\"]}},\"email\":\"register@dot-bit.org\"}",
        "txid" : "2a80cc6c3b0746e034265256327c451980ff5b76aad4533206fd56c1c528ef97",
        "expires_in" : 6926,
        "address" : ""
    }
]

Am very happy that you are implementing this functionality ... it will be very useful.

[khal]

Hum, indeed, it works only with small domain names...

I've a small hack (testing if opcode = 6, even if it shouldn't return this value) :
https://github.com/khalahan/namecoin/co ... 19eb62c940

You will need to add --force when updating the repository

[doublec]

https://github.com/khalahan/namecoin/co ... 19eb62c940

Why does DecodeNameAddress in that commit take an 'op' parameter? It doesn't appear to be used or is there some macro magic going on?

[khal]

Indeed, it is not used anymore, i've removed it.

But, the patch still doesn't work on all names. The GetOp methods seems broken...
I'll look at that in 1 week at least.