Ravencoin — KAAAWWW! The Messaging Protocol.
Assets activated, in a squeaker, on November 5th, 2018. Messaging on Ravencoin is the next phase.
The idea for Ravencoin messaging came from my passive involvement in a conversation that took place at Satoshi Roundtable where a project that used ERC-20 tokens wanted to change technologies. They’d been working for a long time to get their token holders to move to another technology. During this same conversation, someone else chimed in that they have a NASDAQ listed company and have the same problem communicating with their shareholders.
I learned that for a NASDAQ company to hold a vote, they need to pay a quasi-monopoly company to collect a list of their shareholders because that information isn’t in a single location. The information is spread across different brokerages. After paying $30K, the company gets a list of names and mailing addresses. No phone numbers, or e-mail addresses. They must then send dead-tree paper documents to the shareholders. In 2018, this is a broken system.
The goal of messaging is to allow token issuers a way to notify their token holders without knowing who they are. By design, the messaging in Ravencoin is not private. It could be a vote, a notification, a thank you, an opportunity, or a request. I don’t know exactly how this platform will be used. I’m continually surprised at the creativity and ingenuity of Ravencoin users.
The KAAAWWW protocol has a secondary advantage that an IPFS hash can be attached to any asset transfer. This will allow data to be included for any transaction. The data goes in IPFS and only the hash is stored on-chain. Clients are free to display the IPFS information with each transaction.
Any IPFS message that is sent with a channel token (e.g. ASSET~Channel) with the input and output address being the same will be considered a broadcast message to the holders of ASSET. The owner token (e.g. ASSET!) will be a default channel token and allow messaging. Channel tokens will only be needed if there’s a reason for additional channels, such as the ability to mute some and not others or to distribute responsibility for types of messages sent.
Can I send the message to new token holders even if the token holder has transferred the token multiple times?
Yes, that’s the whole point. That’s the real advantage of the system.
Can I send a message to just one of my token holders and not to the others?
No. This is a “broadcast” messaging system.
Can I encrypt the message?
Sure, but then you need a way to send the decryption key to all the token holders. If you can do that, consider sending the message using that system instead.
Won’t this be used to spam people?
We are taking some steps to prevent that in the reference clients. If token holders always add tokens to a new address when they purchase them, then the reference client can quarantine any tokens that are sent unsolicited to the same address, and also mute the channels for unsolicited tokens. The details are below.
Can I turn off the messages?
Of course. The user is always in control. I’d recommend leaving messaging on for any tokens you purchase, and mute any tokens you are sent unsolicited. The reference client will try to do this for you.
What is messaging for?
We don’t tell people how to use the Ravencoin asset platform, and we expect ideas far beyond what we can possibly imagine. But one use for messaging is to let your token holders know that they’ll receive a vote token and where to send it to register their preference. Another use would be to notify token holders of a future delivered item (Kickstarter-like) that the item is ready to be shipped and to visit a site to redeem their token.
Technical Stuff Ahead…
Ok, now this blog post is going to get a bit technical. Feel free to skip anything that doesn’t make sense to you. Don’t worry, the plan is to make it easy to use and hide all the complexity.
Core protocol changes
Extend the OP_RVN_ASSET to include optional IPFS data for any transfer:
RVNT <standard transfer info><0xHH><0x12><0x20><32 bytes encoding 256 bit IPFS hash>[optional 4 bytes]
0xHH — File type 0x00 — NO data, 0x01 — IPFS hash, 0x02 through 0xFF RESERVED
0x12 — IPFS Spec — Using SHA256 hash
0x20 — IPFS Spec — 0x20 in hex specifying a 32 byte hash.
…. (32 byte hash in binary)
Optional 4 bytes (32 bit unsigned int) - Message expires unix epoch
Note that 34 bytes are exactly a decoded IPFS hash which includes the 0x12 and 0x20 bytes, and the 32 bytes of the hash. This is useful for re-encoding. If the byte following the standard transfer is 0x01, then the next 34 bytes can be encoded to get the IPFS string starting with Qm…
Goal: A simple message format without photos. URL links are allowed and reference clients will automatically “linkify” the message for valid URLs.
For display by reference clients, the message file must be a valid JSON file.
“subject”:”This is the optional subject”,
“message”: “This is required.”,
Only message is required
The message file goes in IPFS, and the IPFS hash is added to the transfer transaction.
- Clients are free to show or not show poorly formed messages. Reference clients will limit message display to properly formed messages.
- If the subject is missing, the first line of the message will be used (up to 80 chars).
- Standard JSON encoding for newlines, tabs, etc. https://www.freeformatter.com/json-escape.html
- Expiration is optional. Will stop showing the message after X date, where X is specified as Unix epoch. Good for invites, voting requests, and other time-sensitive messages that have no value after a specific date.
- By default, clients will not show a message after X blocks (default 1 year)
- Amount of subject shown will be client dependent — Reference client likely to cut off at 80 chars.
- Messages longer than 15,000 (about 8 pages) will not be pinned to IPFS by some scanners.
- Messages longer than 15,000 characters may be rejected altogether by the client.
- Images will not be shown in reference clients. Other clients may show any IPFS content at their discretion.
- IPFSHash is only a “published” message if the Admin/Owner or Channel token is sent from/to the same address. This allows for standard transfers with metadata that isn’t “published”. Remember “publishing” is just the client choosing to display the message or notify the user.
Client handling of messages
- Pop-up messages or notifications when running live.
- Show messages for any assets sent to a new address — by default
- Mute messages for assets sent to an address that was already on-network.
- Have a setting to not show messages older than X
- IPFSHash (or 8 bytes of it) = <byte>
One difficulty we have is that tokens can be sent to any Ravencoin asset holder unsolicited. This happens on other asset platforms like Counterparty. In many cases, this is good and is a way for asset issuers to get their token known. It is essentially an airdrop.
However, combined with the messaging capabilities of Ravencoin, this can, and likely will become a spam strategy. Someone who wants to send messages (possible scams) to Ravencoin asset holders, which they know are crypto-savvy people, will create a token with billions of units, send it to every address, and then send messages using the talking stick for that token. Unless we preemptively address this problem, Ravencoin messaging will become a useless spam channel.
Anyone can stop the messages for an asset by burning the asset, or by turning off the channel.
A simple solution is to automatically mute the channel (by default) for the 2nd asset sent to an address. The reason this works is that the assets that you acquire through your actions will generally be to a newly generated address. The normal workflow would be to purchase an asset on an exchange, or through an ICO/STO sale. For an exchange, you’ll provide a withdrawal address, and best practice says you request a new address from the client with File->’Receiving addresses…’->New. To provide an address to the ICO/STO issuer, you would do the same. It is only the case where someone is sending assets unsolicited to you where an address would be re-used for asset tokens. This is not 100% the case, and there may be rare edge-cases, but this allows us to set the channels to listen or silent by default.
Assets sent to addresses that were already ‘on-chain’ can be quarantined. The user can burn them or take them out of quarantine.
Since every asset transfer transaction can have a message associated, and the message can be of any type because it is a reference to an IPFS file. It will be optional for the clients to read the IPFS file and display data. We are providing a recommendation for a JSON file format that only shows text — See spec above.
Channel Design Decisions
- Reference clients will have a “Primary” channel that is automatic and displays messages when ownership token is sent back to itself with a message in the established format.
- Allow the owner token to act as a talking stick on the “Primary” channel.
- Can add an additional talking stick on that channel by creating ASSET~Primary. Cost for channel token is 5 RVN.
- Only display messages in reference clients that fit a spec.
- Do not automatically display messages for quarantined ASSETS
- All messages are public in IPFS with only the IPFS reference on-chain, but the clients/browsers/explorers will determine what message types are shown.
- Any transaction can have an IPFS message hash. The client decides which (if any) are shown.