On-chain stake pool operator to delegates communication

[mmahut]

Opening this pull request to get a wider discussion from the community, it will get updated few times before the next CIP meeting.

An open question is to how to incorporate the support for multiple languages within one metadata transaction. Possible solution:

{
  "1991": {

    "lat": {
        "title": "Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do",
        "content": [ ... ],
    },
    "jap": { ... },

    "link": "https://example.com/blog.html",
    "expire": 10669033
  }
}

[leslieonline27]

This would be a game changer for the SPO / delegator relationship

• We could also add optional validFrom to the metadata - this would allow pool operators to prepare and broadcast messages they wish to be sent on a regular basis
• Could this same proposal cover delegator -> SPO communication? I imagine this would be a downstream implementation in the wallet / client
• Language suggestion above seems reasonable

[psychomb]

Thank you very muck Marek for putting this one out. Such a communication channel would be a great addition to the classical tool-box (newsletters, Telegram, etc) and has the potential to completely replace those eventually.

You mention abuse of the system. As I understood, the price of those transactions including metadata would be the main and only passive counter measure / deterrent against spams.

Tangential to that, how do you envision checking that communication only occurs between the operator of a pool and its delegates, effectively avoiding "delegate poaching" between pools ?

[mmahut]

• We could also add optional validFrom to the metadata - this would allow pool operators to prepare and broadcast messages they wish to be sent on a regular basis

This is a good idea! I will add it.

• Could this same proposal cover delegator -> SPO communication? I imagine this would be a downstream implementation in the wallet / client

Yes, it can indeed be between any two stake addresses. It will be up to the wallets to incorporate, but for SPOs, I can see tools such as pooltool.io to provide this "reply" communication for the SPOs.

You mention abuse of the system. As I understood, the price of those transactions including metadata would be the main and only passive counter measure / deterrent against spams.

Correct, it will not completely prevent spamming, but will decrease it for sure with a comparison to off-chain communication. Ideally, the user will be able to choose the notification levels within the wallet software (off-chain, on-chain message board, on-chain direct message).

Tangential to that, how do you envision checking that communication only occurs between the operator of a pool and its delegates, effectively avoiding "delegate poaching" between pools ?

This is up to the downstream wallets and tools, but as an example in the following code linked, we are listing all metadata transaction that has been sent to the specific (user's) stake address and we also check that this transaction has originated in one of the stake owner addresses.

https://github.com/fivebinaries/cip-metadata-communication-example/blob/master/1991.js#L15-L40

[psychomb]

@mmahut Thanks for the client code example. I guess ideally, either the reward or owner(s) addresses should pass validation.

[jbax]

Here are a few suggestions for consideration.

I'd really like to have a "format" field so wallets can "know" how to better present the information contained in these messages.

Using mime types, text messages could use:

"content": {
            "format": "text/plain"

"content": {
            "format": "application/rtf"

"content": {
            "format": "text/html"

(not official, but used a lot)

"content": {
            "format": "text/markdown"

While tabular data could be:

"content": {
            "format": "text/csv"

URLs

"content": {
            "format": "text/x-uri"

Or even:

"content": {
            "format": "text/uri-list"

Images (ok I'm pushing it now):

"content": {
            "format": "image/svg+xml"

If a wallet implementation does not support a given format, it may not display such messages, or simply try to display them as plain text.

In addition, if we could optionally store BASE64 encoded bytes (allows for shorter representation than HEX) we won't be limiting ourselves to UTF-8 only when it's not sufficient:

"content": {
            "encoding": "UTF-16BE",
            "payload": [
                  "TG9yZW0gaXBzdW0gZG9sb3Igc2l0IGFtZXQsIGNvbnNlY3RldHVyIGFkaXBpc2NpbmcgZWxpdCwg",
                  "c2VkIGRvIGVpdXNtb2QgdGVtcG9yIGluY2lkaWR1bnQgdXQgbGFib3JlIGV0IGRvbG9yZSBtYWdu",
                  "YSBhbGlxdWEuIFV0IGVuaW0gYWQgbWluaW0gdmVuaWFtLCBxdWlzIG5vc3RydWQgZXhlcmNpdGF0",
                  "aW9uIHVsbGFtY28gbGFib3Jpcy4="
            ]

Pushing this really really far, the BASE64 bytes could also be decoded into smallish files such as small reports, etc, and that would warrant having an extra field for "filename" or something of the type. (edit: binary file support could backfire badly - if someone posts illegal material it can't be taken down).

[mmahut]

@jbax I think that could be useful, I will add it.

[SebastienGllmt]

To keep things simple for the first version, I would suggest we don't pick a set of encodings to support (plus, I don't think we want to show anything but plain text in the wallet for safety reasons anyway). We can always extend this later by adding an encoding field and defining the default value as text

re: base64
I agree it makes sense. Although I'm slightly concerned that if we really think this standard will be used extensively enough that saving a few bytes is worth it, maybe this should be CIP would be better defined as a CBOR-based metadata instead of JSON-based

[mmahut]

After thinking about this, I agree with @SebastienGllmt, we might want to keep it simple as possible and see how people start using it. The standard is more about the way of communication than the actual JSON format, as that might be very tool specific too.

At first I did not even want to include the link field, as it might be used to expose the privacy of specific delegastor, but I hope the wallets will put in some redirect gateway with a warning.

[mmahut]

Rebased on latest master.

[dcoutts]

Seems like a reasonable proposal.

[mmahut]

I have incorporated the last changes from our discussion at the meeting. This is ready to be merged.

[kevinhammond]

Better communication with delegates is a good idea. I wonder whether this should normally be on-chain, though (most information will be of ephemeral importance)? I can see two kinds of information that might be provided.

• Specific kinds of information relating to key events that affect the pool the pool (we already do this for pool parameter changes, creation, retirement - what is missing is the broadcast mechanism that reaches users, but that should perhaps be off-chain?).

• General broadcast information for delegates (pool will be offline, rationale for parameter changes, change in ownership, requests for pledge, special offers ...) - this is usually ephemeral

The latter should be off-chain, doesn't need to be (significantly) restricted in size, and might be time-limited. It might be best served via a field in the pool metadata (or a similar mechanism)? What's then needed is a way for delegators to opt in or out of receiving the messages, filtering by pool, not seeing old messages etc. This would need to be set up at or after delegation time in the wallet (so there's an association between the user and the delegation address), and could be via email, text etc as well as the wallet itself. It might be necessary to comply with GDPR or other privacy/security legislation. It would be conceivable to target specific groups of user this way (eg to warn "whales" about saturation), though that might be seen as intrusive!

One key issue is that I shouldn't open myself to broadcast messages from SPOs who I do not have a relationship with (by delegating).