Skip to content

Commit

Permalink
CIP-0020 | Update with new Implementors, Screenshots ... (cardano-fou…
Browse files Browse the repository at this point in the history
…ndation#394)

* Create cip0020-encryption-modes.json

* Update cip0020-encryption-modes.json

* Update README.md

* Update README.md

* Update README.md

* Create demo_via_nodeJS.js

* Create demo_via_PHP.php

* Update demo_via_nodeJS.js

* Update README.md

* Update README.md

* Update README.md

* Create cip0020-democode-PHP.php

* Delete demo_via_PHP.php

* Create cip0020-democode-NODEJS.js

* Delete demo_via_nodeJS.js

* Create normal-message-metadata.json

* Create encrypted-message-metadata.json

* Create cip0020-democode-BASH.sh

* Update cip0020-democode-BASH.sh

* Update README.md

* Update README.md

* Update README.md

* Update README.md

* Update README.md

* Update README.md

* Update README.md

* Added 'SPO Scripts' as an encrypted msg integration example

* Delete cip0020-encryption-modes.json

* Delete cip0020-democode-BASH.sh

* Delete cip0020-democode-NODEJS.js

* Delete cip0020-democode-PHP.php

* Delete encrypted-message-metadata.json

* Delete normal-message-metadata.json

* Updating README with updated Implementors

- This update uses the new Header-Scheme, added Implementors and updated some Screenshots

* Adjust authors list (remove markdown) + adjust section titles levels.

Co-authored-by: KtorZ <matthias.benkort@gmail.com>
  • Loading branch information
2 people authored and Ryun1 committed Nov 17, 2023
1 parent d9521a8 commit 498726f
Showing 1 changed file with 79 additions and 41 deletions.
120 changes: 79 additions & 41 deletions CIP-0020/README.md
Original file line number Diff line number Diff line change
@@ -1,116 +1,154 @@
---
CIP: 20
Title: Transaction message/comment metadata
Authors: Martin Lang <martin@martinlang.at>, Ola Ahlman <ola@ahlnet.nu>, Andrew Westberg <andrewwestberg@gmail.com>
Comments-URI: no comments yet
Status: Active
Type: Informational
Category: Metadata
Authors:
- Martin Lang <martin@martinlang.at>
- Ola Ahlman <ola@ahlnet.nu>
- Andrew Westberg <andrewwestberg@gmail.com>
Implementors:
- CNTools <https://cardano-community.github.io/guild-operators/#/Scripts/cntools>
- JorManager <https://bitbucket.org/muamw10/jormanager/>
- StakePoolOperator Scripts <https://github.com/gitmachtl/scripts>
- Cardanoscan.io <https://cardanoscan.io>
- AdaStat.net <https://adastat.net>
- Eternl Wallet <https://eternl.io>
- CardanoWall <https://cardanowall.com>
- Nami Wallet <https://namiwallet.io>
- CNFT <https://cnft.io>
- Cardano Explorer <https://cexplorer.io>
- SundaeSwap <https://https://sundaeswap.finance/>
- Minswap <https://minswap.org/>
- MuesliSwap <https://muesliswap.com/>
- DripDropz.io <https://dripdropz.io/>
- Typhon Wallet <https://typhonwallet.io/>
- Ledger Live <https://www.ledger.com/>
Discussions:
- https://github.com/cardano-foundation/CIPs/pull/100
- https://github.com/cardano-foundation/CIPs/pull/394
Created: 2021-06-13
License: CC-BY-4.0
---

# Abstract
# CIP-0020: Transaction message/comment metadata

## Abstract

This CIP describes a basic JSON schema to add messages/comments/memos as transaction metadata by using the metadatum label **674**.
Adding **informational text, invoice-numbers or similar** to a transaction on the cardano blockchain.

# Motivation
## Motivation

We have the utilities on the cardano blockchain now since the introduction of the "allegra-era". A simple consens about adding messages, comments or memos to transactions is still missing.
So the CIP authors came together to form a first implementation of this. It is straight and simple, additional keys and content can be added later.
The IOG main wallet `Daedalus` can now also directly show attached metadata information in the transaction details view. This CIP is the missing link to bring it together.

Current Tools/Sites/Explorers that have implemented it already or have plans to implement it:
Some of the current Tools/Sites/Explorers that have implemented it already:
* [CNTools](https://cardano-community.github.io/guild-operators/#/Scripts/cntools)
* [JorManager](https://bitbucket.org/muamw10/jormanager/)
* [StakePoolOperator Scripts](https://github.com/gitmachtl/scripts)
* [Cardanoscan.io](https://cardanoscan.io)
* [AdaStat.net](https://adastat.net)
* [CardanoCommunityWallet](https://ccwallet.io)
* [Eternl Wallet](https://eternl.io)
* [CardanoWall](https://cardanowall.com)
* [Nami Wallet](https://namiwallet.io)
* [CNFT](https://cnft.io)
* [Cardano Explorer](https://cexplorer.io)
* [SundaeSwap](https://https://sundaeswap.finance/)
* [Minswap](https://minswap.org/)
* [MuesliSwap](https://muesliswap.com/)
* [DripDropz.io](https://dripdropz.io/)
* [Typhon Wallet](https://typhonwallet.io/)
* [Ledger Live](https://www.ledger.com/)

# Specification
## Specification

The specification for the individual strings follow the general design specification for JSON metadata, which is already implemented and in operation on the cardano blockchain.
The used metadatum label is **`"674":`**, this number was choosen because it is the T9 encoding of the string "msg".
The message content has the key **`"msg":`** and consists of an **array** of individual **message-strings**.
The message content has the key **`"msg":`** and consists of an **array** of individual **message-strings**.
The number of theses **message-strings** must be at least one for a single message, more for multiple messages/lines. Each of theses individual **message-strings** array entries must be at most 64 bytes when UTF-8 encoded.

Format:
```
{
### Format:
```
{
"674":
{ "msg":
[
{
"msg":
[
"message-string 1" //Optional: ,"message-string 2","message-string 3" ...
]
}
}
```



Example for a single message/comment/memo:
### Example for a single message/comment/memo:
``` json
{
{
"674":
{ "msg":
[
{
"msg":
[
"This is a comment for the transaction xyz, thank you very much!"
]
}
}
```

Example for multiple messages/comments/memos:
### Example for multiple messages/comments/memos:
``` json
{
{
"674":
{ "msg":
[
{
"msg":
[
"Invoice-No: 1234567890",
"Customer-No: 555-1234",
"P.S.: i will shop again at your store :-)"
]
}
}
```
Example above in **Daedalus** currently (could be improved if CIP is implemented):
![image](https://user-images.githubusercontent.com/47434720/121822100-85b38a80-cc9d-11eb-9d13-1869746a69b2.png)

## Some Integration examples
&nbsp;<p>

### Some Integration examples

**Ledger Live** is offering a memo field
![image](https://user-images.githubusercontent.com/47434720/204649383-c34ae733-e136-41b8-8fa8-619dde978621.png)

**Daedalus** shows the metadata text (could be improved if CIP is implemented):
![image](https://user-images.githubusercontent.com/47434720/121822100-85b38a80-cc9d-11eb-9d13-1869746a69b2.png)

**Cardanoscan.io**, **Adastat.net** and other tools implemented it already, to show messages along transactions:
![image](https://user-images.githubusercontent.com/47434720/124379245-1f2af680-dcb6-11eb-97b7-10f70d840e88.png)
![image](https://user-images.githubusercontent.com/47434720/124381343-3ff94900-dcc2-11eb-8d03-8fbacd3322b0.png)
![image](https://user-images.githubusercontent.com/47434720/204633595-d865c7ee-0c30-4af1-bb55-3c0ad323b58c.png)
![image](https://user-images.githubusercontent.com/47434720/204634111-256c6c18-974a-41f5-a6e4-b9edee8f9d62.png)

**ccwallet.io** has added it with a message field on the sending-page, and shows it also on the transactions-page:
![image](https://user-images.githubusercontent.com/47434720/127367420-b360972d-c6e0-4002-865e-df070904bd30.png)
![image](https://user-images.githubusercontent.com/47434720/127367228-339ac059-007a-40fd-a6c0-97f890e93964.png)
![image](https://user-images.githubusercontent.com/47434720/127368912-c85dc9f0-6ee3-4cc1-a24b-9716a20f27d3.png)
**eternl.io** has added it with a message field on the sending-page, and shows it also on the transactions-page:
![image](https://user-images.githubusercontent.com/47434720/204632224-5be33098-00f6-41da-a2f0-7c138b28354f.png)
![image](https://user-images.githubusercontent.com/47434720/204632802-33f1afa5-d9b2-494f-84fe-d7f0594a7f1b.png)

**StakePool Operator Tools**: It works on the commandline like any other script of the collection by just adding the "msg: ..." parameter to a transaction. This automatically generates the needed metadata.json structure and attaches it to the transaction itself.
**StakePool Operator Scripts**: It works on the commandline like any other script of the collection by just adding the "msg: ..." parameter to a transaction. This automatically generates the needed metadata.json structure and attaches it to the transaction itself.
![image](https://user-images.githubusercontent.com/47434720/129110626-6bc5b3c3-102d-4793-b508-7d4190b31cf7.png)

**CNTools**:<br>
![image](https://user-images.githubusercontent.com/47434720/130353491-fc0f3a69-1937-4e72-b680-c04cc069b5c4.png)


# Rationale
## Rationale

This design is simple, so many tools on the cardano blockchain can implement it easily. The array type was choosen to have consistency, no need to switch between a string or
an array format, or testing against a string or array format. Updates in the future are possible, like adding a versioning key `"ver":`, adding a key `"utxo":` to provide specific data for every tx-out#idx in the transaction, making subarrays in the message-strings, etc. But for now, we need a common agreement to provide general messages/comments/memos with this CIP. The starting design war choosen as simple as possible to keep the additional transaction fees as low as possible.
an array format, or testing against a string or array format. Updates in the future are possible, like adding a versioning key `"ver":`, adding a key `"utxo":` to provide specific data for every tx-out#idx in the transaction, adding the `"enc":` key like for encrypted messages, making subarrays in the message-strings, etc. But for now, we need a common agreement to provide general messages/comments/memos with this CIP. The starting design war choosen as simple as possible to keep the additional transaction fees as low as possible.

## Wallet Implementation
### Wallet Implementation

Would be a good idea to hide the message/comment/note behind a "show unmoderated content" button/drop-down. Like the Metadata display on the Cardano Explorer. Also, it should be displayed as plain-text non-clickable. To enhance security further, URLs could be automatically deleted or hidden from such comments, to not welcome bad actors with phishing attempts. Another solution to start with would be to really limit the character space for display in Wallets, like limiting it to `a-zA-z0-9` and a handful of special chars like `+-_#()[]:` without a `.<>"/\` chars, so a domain or html code would not work. Last points are worth for discussions of course, because it would also filter out unicode.

## Handling ill-formed 674 metadata ##
### Handling ill-formed 674 metadata

It is up to the wallet-/display-/receiver-implementor to parse and check the provided metadata. As for the current state, its not possible to have the same label "674" more than once in a cardano transaction. So a check about that can be ignored at the moment. This CIP provides the correct implementation format, the parsing should search for the "674" metadata label and the "msg" key underneath it. There should also be a check, that the provided data within that "msg" key is an array. All other implementations like a missing "msg" key, or a single string instead of an array, should be marked by the display-implementor as "invalid". Additional keys within the "674" label should not affect the parsing of the "msg" key. As written above, we will likely see more entries here in the future like a "version" key for example, so additional keys should not harm the parsing of the "msg" key.
It is up to the wallet-/display-/receiver-implementor to parse and check the provided metadata. As for the current state, its not possible to have the same label "674" more than once in a cardano transaction. So a check about that can be ignored at the moment. This CIP provides the correct implementation format, the parsing should search for the "674" metadata label and the "msg" key underneath it. There should also be a check, that the provided data within that "msg" key is an array. All other implementations like a missing "msg" key, or a single string instead of an array, should be marked by the display-implementor as "invalid". Additional keys within the "674" label should not affect the parsing of the "msg" key. As written above, we will likely see more entries here in the future like a "version" key for example, so additional keys should not harm the parsing of the "msg" key.

## Implementation conclusion ##
### Implementation conclusion

A transaction message should be considered valid if the following apply:

Expand All @@ -129,6 +167,6 @@ _Optional to consider for the implementer:_

The implementation format in this CIP should be the ground base for transaction messages/comments/memos and should be respected by creator-/sender-implementations as well as in wallet-/receiver-/display-implementations.

# Copyright
## Copyright

This CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode)

0 comments on commit 498726f

Please sign in to comment.