Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CIP0006 Stake pool extended metadata #15

Merged
merged 11 commits into from
Mar 8, 2021
176 changes: 176 additions & 0 deletions CIP6/CIP6.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,176 @@
---
CIP: 6
Title: Extended Metadata
Authors: Mike Fullman <mike@fullman.net>, Markus Gufler <gufmar@gmail.com>
Comments-URI:
papacarp marked this conversation as resolved.
Show resolved Hide resolved
Status: Draft
Type: Standards
Created: 2020-07-20
License: CC-BY-4.0
---

## Abstract

This CIP defines the concept of extended metadata for pools that is referenced from the pool registration data stored on chain.

## Motivation

As the ecosystem around Cardano stake pools proliferate so will the desire to slice, organize and search pool information dynamically. Currently the metadata referenced on chain provides 512 bytes that can be allocated across the four information categories ([delegation-design-specification Section 4.2)](https://hydra.iohk.io/build/790053/download/1/delegation_design_spec.pdf):
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that the 512 bytes limitation only exists in softwares currently dealing with metadata (i.e. cardano-wallet and SMASH). Having a max size that is rather constrained prevents some DOS attacks on softwares consuming metadata. Yet, it should be possible to increase that limit to makes it possible to include more information, while still keeping a reasonable size.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that the 512 bytes limitation only exists ... it should be possible to increase that limit to makes it possible to include more information, while still keeping a reasonable size.

it is an interesting option indeed, that should be considered as a possible way to go. In that case it any change requires a re-registration on chain with the new hash. Having it only linked from main to the extended json file makes it more flexible but also a little bit less trusted.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The limit for on chain data is great for those of us parsing, doubling it would be fine but I do think keeping it constrained and allowing the extended metadata to be the place for flexible and fast changes is the right tradeoff.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The limit for on chain data is great for those of us parsing, doubling it would be fine but I do think keeping it constrained and allowing the extended metadata to be the place for flexible and fast changes is the right tradeoff.

Agreed, it's way better to have a strictly defined set of mandatory metadata and more flexible set of extended metadata, while mandatory metadata may be subject to extensive CIP review process, extended metadata provide the ability to innovate with after-the-fact formalization thru the CIP process for greater interoperability.


| key | Value | Rules |
| --- | --- | --- |
| `ticker` | Pool ticker. uppercase | 5 Characters Maximum, Uppercase letters and numbers |
| `description` | Pool Description. Text that describes the pool | 50 Characters Maximum |
| `homepage` | A website URL for the pool | 64 Characters Maximum, must be a valid URL |
| `name` | A name for the pool | 50 Characters Maximum |

Many additional attributes can be envisioned for future wallets, pool explorers, and information aggregators. The proposal below outlines an initial strategy for capturing this extended metadata.

## Specification

#### On Chain referenced metadata file
We define one more line for the on chain referenced metadata file that references another json file on a url with the extended metadata. The proposed metadata is as follows:

| key | Value | Rules |
| --- | --- | --- |
| `ticker` | Pool ticker. uppercase | 5 Characters Maximum, Uppercase letters and numbers |
| `description` | Pool Description. Text that describes the pool | 50 Characters Maximum |
| `homepage` | A website URL for the pool| 64 Characters Maximum, must be a valid URL |
| `name` | A name for the pool | 50 Characters Maximum |
| `extended` | A url for extended metadata| Optional, 64 Characters Maximum, must be a valid URL |

#### Extended Metadata
The file located at the URL for extended data is a json compliant text file with the following top level fields:

| key | Description |
| --- | --- |
| `serial` | set to YYYYMMDDxx on every update |
| `itn` | ITN pool validation data |
| `info` | Corporate image, contacts and about details |
| `pools` | Pool details |

Since this extended metadata file has no checksum and can be updated at any time by the pool operator, a **serial number** is useful to easily identify updates.

The purpose of this first (**itn**) extension is the verifiable linking of an ITN pool ticker with its counterpart in Mainnet to identify fraudulent duplicates.

#### Complete Extended Metadata Example
```
{
"serial": 2020072001,
"itn": {
"owner": "ed25519_pk1...",
"witness": "ed25519_sig1..."
},
"info": {
"CI": {
papacarp marked this conversation as resolved.
Show resolved Hide resolved
"logo_url_png_icon_64x64": "https://mycoolpool.com/icon.png",
"logo_url_png_logo": "https://mycoolpool.com/logo.png",
"color_main": "#RRGGBB",
"logo_vector": "https://mycoolpool.com/logo.svg"
},
"social": {
"twitter_handle": "coolpool",
"telegram_handle": "coolpool",
"facebook_handle": "coolpool",
"youtube_handle": "coolpool",
"twitch_handle": "coolpool",
"discord_handle": "coolpool",
"github_handle": "coolpool"
},
"contact": {
"abuse": "abuse@pooldomain.org",
"support": "help@pooldomain.org",
"telegram_admin":"coolpool"
},
"company": {
"name": "Company Name",
"addr": "Street, Number",
"city": "London",
"country": "UK",
"company_id": "123456789",
"vat_id": "GB123456789"
},
"operator": {
"country": "UK",
"sex": "2"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

probably this should be "gender" instead

},
"about": {
"team_affiliation": [
"ISPPA",
"Cardano Ambassador"
],
"me": "Long description of me",
"server": "long description of server details",
"company": "long description of company details"
},
"rss": "https://mycoolpool.com/xml/poolrss.xml"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

RSS as well as Atom are very painful standards that are becoming obsolete, they have been discontinued by most browsers already. We might want to investigate alternatives, such as JSON Feed.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

interesting

indeed RSS seems has slowly died out in last 15 years (https://trends.google.com/trends/explore?date=all&q=rss)

I had to lookup what https://www.jsonfeed.org/ is.
Exists since 2017
has surprisingly many supported plugins and libraries https://jsonfeed.org/code/

here is the github home: https://github.com/manton/JSONFeed

https://en.wikipedia.org/wiki/JSON_Feed
https://en.wikipedia.org/wiki/Comparison_of_feed_aggregators

we might need to understand first how SPos want to use news feeds (beside the social networks and chat services)

},
"pool": {
"id": "0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f",
"country": "UK",
"os": "LINUX",
"infrastructure": "AWS",
"status": "act",
"saturated_recommend":"0a0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f"
}

}
```

#### Extended Metadata Schema

see incorporated file [schema.json](schema.json)

## Infrastructure Mapping
```
[
{"Code": "aws", "Name": "Amazon Cloud"},
{"Code": "google", "Name": "Google Cloud"},
{"Code": "azure", "Name": "Microsoft Cloud"},
{"Code": "digitalocean", "Name": "Digital Ocean"},
{"Code": "baremetall", "Name": "Bare Metal Server(local)"},
{"Code": "baremetalh", "Name": "Bare Metal Server(hosted)"},
{"Code": "ovh", "Name": "OVH Cloud"},
{"Code": "hetzner", "Name": "Hetzner"},
{"Code": "vultr", "Name": "Vultr"},
{"Code": "godaddy", "Name": "Go Daddy"},
{"Code": "aruba", "Name": "Aruba"},
{"Code": "hostinger", "Name": "Hostinger"},
{"Code": "othervps", "Name": "Other VPS"},
{"Code": "lpcsbc", "Name": "Low Power/Cost SBC (pi, rockspi, etc)"},
{"Code": "undisclosed", "Name": "Undisclosed"}
]
```

## Operating System Mapping
```
[
{"Code": "linux", "Name": "Linux"},
{"Code": "osx", "Name": "Apple OSX"},
{"Code": "win", "Name": "Windows"},
{"Code": "freebsd", "Name": "FreeBSD"},
{"Code": "undisclosed", "Name": "Undisclosed"}
]
```

## Pool Status Mapping
```
[
{"Code": "act","Name": "Active"},
{"Code": "ret","Name": "Retired"},
{"Code": "off","Name": "Offline for Maintenance"},
{"Code": "exp","Name": "Experimental"},
{"Code": "dnu","Name": "Do Not Delegate To This Pool"}
]
```
## Backwards compatibility

No fields are removed or changed in the current on chain metadata. The new field `extended` is optional and not necessary to parse for any entities that do not need additional information about a pool

## Reference implementation

N/A

## Copyright

This file is documentation, and therefore subject to CC-BY-4.0 (and not subject to Apache 2.0).
Loading