Messaging FAQ & Guidelines
The Ownership Token grants you the ability to broadcast messages to all token holders. The protocol uses IPFS and JSON to display messaging within the wallet.
Messaging Q1 2019
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.
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.
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>
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.
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>
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)
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…