diff --git a/404.html b/404.html index abed86f..08ec9b8 100644 --- a/404.html +++ b/404.html @@ -91,7 +91,7 @@ diff --git a/approved/0001-agile-coretime.html b/approved/0001-agile-coretime.html index 95dd9e7..e42371f 100644 --- a/approved/0001-agile-coretime.html +++ b/approved/0001-agile-coretime.html @@ -90,7 +90,7 @@ diff --git a/approved/0005-coretime-interface.html b/approved/0005-coretime-interface.html index 1ea1e5e..c1e17c3 100644 --- a/approved/0005-coretime-interface.html +++ b/approved/0005-coretime-interface.html @@ -90,7 +90,7 @@ diff --git a/approved/0007-system-collator-selection.html b/approved/0007-system-collator-selection.html index c1f9b4e..2bdd198 100644 --- a/approved/0007-system-collator-selection.html +++ b/approved/0007-system-collator-selection.html @@ -90,7 +90,7 @@ diff --git a/approved/0008-parachain-bootnodes-dht.html b/approved/0008-parachain-bootnodes-dht.html index 4e7ed32..657aeb6 100644 --- a/approved/0008-parachain-bootnodes-dht.html +++ b/approved/0008-parachain-bootnodes-dht.html @@ -90,7 +90,7 @@ diff --git a/approved/0010-burn-coretime-revenue.html b/approved/0010-burn-coretime-revenue.html index cb4ae0c..e2d8605 100644 --- a/approved/0010-burn-coretime-revenue.html +++ b/approved/0010-burn-coretime-revenue.html @@ -90,7 +90,7 @@ diff --git a/approved/0012-process-for-adding-new-collectives.html b/approved/0012-process-for-adding-new-collectives.html index 4cc1199..2f21b67 100644 --- a/approved/0012-process-for-adding-new-collectives.html +++ b/approved/0012-process-for-adding-new-collectives.html @@ -90,7 +90,7 @@ diff --git a/approved/0014-improve-locking-mechanism-for-parachains.html b/approved/0014-improve-locking-mechanism-for-parachains.html index 73e1e96..ab612ca 100644 --- a/approved/0014-improve-locking-mechanism-for-parachains.html +++ b/approved/0014-improve-locking-mechanism-for-parachains.html @@ -90,7 +90,7 @@ diff --git a/approved/0022-adopt-encointer-runtime.html b/approved/0022-adopt-encointer-runtime.html index 61f74b3..15f2875 100644 --- a/approved/0022-adopt-encointer-runtime.html +++ b/approved/0022-adopt-encointer-runtime.html @@ -90,7 +90,7 @@ diff --git a/approved/0032-minimal-relay.html b/approved/0032-minimal-relay.html index c283398..b13dbb8 100644 --- a/approved/0032-minimal-relay.html +++ b/approved/0032-minimal-relay.html @@ -90,7 +90,7 @@ diff --git a/approved/0042-extrinsics-state-version.html b/approved/0042-extrinsics-state-version.html index f144ccd..26e88e0 100644 --- a/approved/0042-extrinsics-state-version.html +++ b/approved/0042-extrinsics-state-version.html @@ -90,7 +90,7 @@ diff --git a/approved/0043-storage-proof-size-hostfunction.html b/approved/0043-storage-proof-size-hostfunction.html index 02e2692..3ed310d 100644 --- a/approved/0043-storage-proof-size-hostfunction.html +++ b/approved/0043-storage-proof-size-hostfunction.html @@ -90,7 +90,7 @@ diff --git a/approved/0047-assignment-of-availability-chunks.html b/approved/0047-assignment-of-availability-chunks.html index 437fe4e..98e30f9 100644 --- a/approved/0047-assignment-of-availability-chunks.html +++ b/approved/0047-assignment-of-availability-chunks.html @@ -90,7 +90,7 @@ diff --git a/approved/0050-fellowship-salaries.html b/approved/0050-fellowship-salaries.html index 1c6d792..f1f3b60 100644 --- a/approved/0050-fellowship-salaries.html +++ b/approved/0050-fellowship-salaries.html @@ -90,7 +90,7 @@ diff --git a/approved/0056-one-transaction-per-notification.html b/approved/0056-one-transaction-per-notification.html index 701d83c..ad6c1dd 100644 --- a/approved/0056-one-transaction-per-notification.html +++ b/approved/0056-one-transaction-per-notification.html @@ -90,7 +90,7 @@ diff --git a/approved/0059-nodes-capabilities-discovery.html b/approved/0059-nodes-capabilities-discovery.html index 3c83768..9e6d90c 100644 --- a/approved/0059-nodes-capabilities-discovery.html +++ b/approved/0059-nodes-capabilities-discovery.html @@ -90,7 +90,7 @@ diff --git a/index.html b/index.html index af93c50..0c6b0c6 100644 --- a/index.html +++ b/index.html @@ -90,7 +90,7 @@ diff --git a/introduction.html b/introduction.html index af93c50..0c6b0c6 100644 --- a/introduction.html +++ b/introduction.html @@ -90,7 +90,7 @@ diff --git a/new/0074-stateful-multisig-pallet.html b/new/0074-stateful-multisig-pallet.html index 6dc88cc..7ec4374 100644 --- a/new/0074-stateful-multisig-pallet.html +++ b/new/0074-stateful-multisig-pallet.html @@ -90,7 +90,7 @@ @@ -784,7 +784,7 @@ Implement call filters. This will allow multisig accounts to only accept certain - @@ -798,7 +798,7 @@ Implement call filters. This will allow multisig accounts to only accept certain - diff --git a/new/0076-increase-max-length-of-identity-raw-data-values.html b/new/0076-increase-max-length-of-identity-raw-data-values.html new file mode 100644 index 0000000..a00bb0e --- /dev/null +++ b/new/0076-increase-max-length-of-identity-raw-data-values.html @@ -0,0 +1,340 @@ + + + + + + + RFC-0076: Increase maximum length of identity raw data values from 32 bytes - Polkadot Fellowship RFCs + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ + + + + + + + + + + + + + + + + + + +
+ +
+ + + + + + + + +
+
+

(source)

+

Table of Contents

+ +

RFC-0076: Increase maximum length of identity raw data values from 32 bytes

+
+ + + +
Start Date20 Feb 2024
DescriptionIncrease the maximum length of identity raw data values from 32 bytes
AuthorsLuke Schoen
+
+

Summary

+

This proposes to increase the maximum length of identity raw data values from a 32 bytes/chars limit to either a 64 bytes/chars limit or a 128 bytes/chars limit.

+

Motivation

+

Background

+

At the moment if you upload a file and pin it to IPFS storage you get an IPFS Content Identifier (CID), which is the unique ID of the file in the IPFS Network. That CID may be used to retrieve the file again via a standard IPFS interface and gateway from anywhere.

+

CIDs are reasonably short regardless of the size the underlying content and are based on the cryptographic hash of the content.

+

IPFS providers may default to using and recommending using CIDv1 [0] when using SHA256 generates a CID 46 bytes long, rather than CIDv0 [0] that generates a CID 59 bytes long, however CIDv0 may be be the preferred choice for minting and storing NFTs on-chain since it is cheaper.

+

Further, the URI protocol + CID for CIDv0 (ipfs://Qm...) will be 7+46=53 chars while for CIDv1 (ipfs://baf...) it will be 7+59=66 chars [1], so neither CIDv0 nor CIDv1 have a CID that supports a maximum length of 32 bytes, which exceeds the maximum 32 bytes/chars limit for bytes/string fields of their Polkadot on-chain identity.

+

Problem

+

If you want to set a Polkadot on-chain identity, users may provide raw data values of their email address "email" field, which may be longer than 32 bytes/chars (e.g. abcdefghijklmnopqrstuvwxyz@me.com or longer), and either just a CID or the URI protocol + CID associated with a legal document, as the value of the "legal" field, and the URI protocol + CID associated with the profile image to associated with their on-chain identity, as the value of the "image" field, however each field can only store a maximum length of 32 bytes/chars of information [3]. They may also want to set a custom value in the "additional" field, which currently only stores a maximum length of 32 bytes, since it currently has a FieldLimit.

+

Possible disadvantages of the current 32 bytes/chars limitation:

+
    +
  • Discourages users from using on-chain Web3 storage providers instead of Web2 storage providers to link to their on-chain identity. For example, in my Decentralized Voices application [4], since it is not possible to proactively provide a link in my on-chain identity to the IPFS CID associated with Conflict of Interest document that has been signed for integration with dApps or immediate verification by interested parties, it would instead be necessary to reactively share that IPFS CID upon each individual request from interested parties.
  • +
  • Encourages users to use Web2 storage providers and URL shorteners that may result in a plethora of on-chain profiles that have dead links.
  • +
  • Encourages dApps to use Web2 storage providers for their users, for example Polkassembly requesting users to upload a profile image that is stored in a Web2 storage provider rather than first defaulting to use the "image" field from their on-chain identity, since it may be the case that the "image" field of most on-chain identities is not widely used due to the maximum length of 32 bytes/chars restriction.
  • +
  • Discourages users from setting an on-chain identity by creating an extrinsic using Polkadot.js with identity > setIdentity(info), since if they try to provide their email address or website domain name that is longer than 32 characters, or try to use a IPFS CID, they will encounter an error.
  • +
  • Discourages users from using on-chain Web3 registrars to judge on-chain identity fields, where the shortest value they are able to generate is not less than or equal to the maximum length of 32 bytes.
  • +
+

Solution Requirements

+

The maximum length of identity raw data values should be increased from the current 32 bytes/chars limit at least a 59 bytes/chars limit (or a 66 bytes/chars limit) to support IPFS CIDs that are either CIDv0 or CIDv1.

+

They maximum length of "additional" field values should be increased by the same amount.

+

Stakeholders

+
    +
  • Any Polkadot account holder wishing to use a Polkadot on-chain identity for their: +
      +
    • Email addresses that are longer than 32 characters
    • +
    • Website domain names that are longer than 32 characters
    • +
    • Files that are stored on the IPFS Network since associated CIDs are longer than 32 characters
    • +
    +
  • +
+

Explanation

+

If a user tries to setting an on-chain identity by creating an extrinsic using Polkadot.js with identity > setIdentity(info), then if they try to provide an email address or a website domain name that is longer than 32 characters, or try to use the IPFS CID (which may be associated with a file such as a document or image), then they will encounter this error:

+
createType(Call):: Call: failed decoding identity.setIdentity:: Struct: failed on args: {...}:: Data.Raw values are limited to a maximum length of 32 bytes
+
+

Increasing maximum length of identity raw data values from the current 32 bytes/chars limit to at least a 59 bytes/chars limit (or a 66 bytes/chars limit) would overcome these errors and support IPFS CIDs that are either CIDv0 or CIDv1, satisfying the solution requirements.

+

Increasing the maximum length of "additional" field values would also overcome these errors and should be increased from the current 32 bytes/chars limitFieldLimit by the same amount.

+

Drawbacks

+

Performance

+

If Polkadot on-chain identities are able to store raw data values greater than the current maximum length of 32 bytes, then each identity may want to use the maximum (or more) amount of "additional" custom fields or more, which would impact storage and performance on the network.

+

Testing, Security, and Privacy

+

Implementations would need to be tested for adherance by checking that IPFS CIDs that are either CIDv0 or CIDv1 are supported.

+

No effect on security or privacy has been identified than already exists.

+

No implementation pitfalls have been identified.

+

Performance, Ergonomics, and Compatibility

+

Performance

+

It would be an optimization, since the associated exposed interfaces to developers and end-users could start being used.

+

To minimize additional overhead the proposal suggests at least a 59 bytes/chars limit (or a 66 bytes/chars limit) since that would at least provide support for IPFS CIDs that are either CIDv0 or CIDv1, satisfying the solution requirements.

+

Ergonomics

+

It alters exposed interfaces to developers and end-users since they will now be able to provide IPFS CIDs that are either CIDv0 or CIDv1 as the values of Polkadot on-chain identity raw data input fields. Optionally 66 bytes/chars limit could be established to optimise for the usage pattern end-users, since that may be more intuitive to them, as it would allow users to provide a link (e.g. URI protocol + CID) rather than just the CID.

+

Compatibility

+

Updates to Polkadot.js Apps, API and its documentation and those referring to it may be required.

+

Prior Art and References

+

Prior Art

+

No prior articles.

+

References

+ +

Unresolved Questions

+

Why can't we increase the maximum length of Polkadot on-chain identity raw data values and the "additional" field limit from 32 bytes/chars to an even longer maximum length than proposed of 128 bytes/chars?

+ +

Relates to RFC entitled "Increase maximum length of identity PGP fingerprint values from 20 bytes".

+ +
+ + +
+
+ + + +
+ + + + + + + + + + + + + + + + + + +
+ + diff --git a/new/0077-increase-max-length-of-identity-pgp-fingerprint-value.html b/new/0077-increase-max-length-of-identity-pgp-fingerprint-value.html new file mode 100644 index 0000000..5ee21bf --- /dev/null +++ b/new/0077-increase-max-length-of-identity-pgp-fingerprint-value.html @@ -0,0 +1,319 @@ + + + + + + + RFC-0077: Increase maximum length of identity PGP fingerprint values from 20 bytes - Polkadot Fellowship RFCs + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ + + + + + + + + + + + + + + + + + + +
+ +
+ + + + + + + + +
+
+

(source)

+

Table of Contents

+ +

RFC-0077: Increase maximum length of identity PGP fingerprint values from 20 bytes

+
+ + + +
Start Date20 Feb 2024
DescriptionIncrease the maximum length of identity PGP fingerprint values from 20 bytes
AuthorsLuke Schoen
+
+

Summary

+

This proposes to increase the maximum length of PGP Fingerprint values from a 20 bytes/chars limit to a 40 bytes/chars limit.

+

Motivation

+

Background

+

Pretty Good Privacy (PGP) Fingerprints are shorter versions of their corresponding Public Key that may be printed on a business card.

+

They may be used by someone to validate the correct corresponding Public Key.

+

It should be possible to add PGP Fingerprints to Polkadot on-chain identities.

+

GNU Privacy Guard (GPG) is compliant with PGP and the two acronyms are used interchangeably.

+

Problem

+

If you want to set a Polkadot on-chain identity, users may provide a PGP Fingerprint value in the "pgpFingerprint" field, which may be longer than 20 bytes/chars (e.g. PGP Fingerprints are 40 bytes/chars long), however that field can only store a maximum length of 20 bytes/chars of information.

+

Possible disadvantages of the current 20 bytes/chars limitation:

+
    +
  • Discourages users from using the "pgpFingerprint" field.
  • +
  • Discourages users from using Polkadot on-chain identities for Web2 and Web3 dApp software releases where the latest "pgpFingerprint" field could be used to verify the correct PGP Fingerprint that has been used to sign the software releases so users that download the software know that it was from a trusted source.
  • +
  • Encourages dApps to link to Web2 sources to allow their users verify the correct fingerprint associated with software releases, rather than to use the Web3 Polkadot on-chain identity "pgpFingerprint" field of the releaser of the software, since it may be the case that the "pgpFingerprint" field of most on-chain identities is not widely used due to the maximum length of 20 bytes/chars restriction.
  • +
  • Discourages users from setting an on-chain identity by creating an extrinsic using Polkadot.js with identity > setIdentity(info), since if they try to provide their 40 character long PGP Fingerprint or GPG Fingerprint, which is longer than the maximum length of 20 bytes/chars, they will encounter an error.
  • +
  • Discourages users from using on-chain Web3 registrars to judge on-chain identity fields, where the shortest value they are able to generate for a "pgpFingerprint" is not less than or equal to the maximum length of 20 bytes.
  • +
+

Solution Requirements

+

The maximum length of identity PGP Fingerprint values should be increased from the current 20 bytes/chars limit at least a 40 bytes/chars limit to support PGP Fingerprints and GPG Fingerprints.

+

Stakeholders

+
    +
  • Any Polkadot account holder wishing to use a Polkadot on-chain identity for their: +
      +
    • PGP Fingerprints that are longer than 32 characters
    • +
    • GPG Fingerprints that are longer than 32 characters
    • +
    +
  • +
+

Explanation

+

If a user tries to setting an on-chain identity by creating an extrinsic using Polkadot.js with identity > setIdentity(info), then if they try to provide their 40 character long PGP Fingerprint or GPG Fingerprint, which is longer than the maximum length of 20 bytes/chars [u8;20], then they will encounter this error:

+
createType(Call):: Call: failed decoding identity.setIdentity:: Struct: failed on args: {...}:: Struct: failed on pgpFingerprint: Option<[u8;20]>:: Expected input with 20 bytes (160 bits), found 40 bytes
+
+

Increasing maximum length of identity PGP Fingerprint values from the current 20 bytes/chars limit to at least a 40 bytes/chars limit would overcome these errors and support PGP Fingerprints and GPG Fingerprints, satisfying the solution requirements.

+

Drawbacks

+

No drawbacks have been identified.

+

Testing, Security, and Privacy

+

Implementations would be tested for adherance by checking that 40 bytes/chars PGP Fingerprints are supported.

+

No effect on security or privacy has been identified than already exists.

+

No implementation pitfalls have been identified.

+

Performance, Ergonomics, and Compatibility

+

Performance

+

It would be an optimization, since the associated exposed interfaces to developers and end-users could start being used.

+

To minimize additional overhead the proposal suggests a 40 bytes/chars limit since that would at least provide support for PGP Fingerprints, satisfying the solution requirements.

+

Ergonomics

+

No potential ergonomic optimizations have been identified.

+

Compatibility

+

Updates to Polkadot.js Apps, API and its documentation and those referring to it may be required.

+

Prior Art and References

+

No prior articles or references.

+

Unresolved Questions

+

No further questions at this stage.

+ +

Relates to RFC entitled "Increase maximum length of identity raw data values from 32 bytes".

+ +
+ + +
+
+ + + +
+ + + + + + + + + + + + + + + + + + +
+ + diff --git a/print.html b/print.html index ed72260..a26f507 100644 --- a/print.html +++ b/print.html @@ -91,7 +91,7 @@ @@ -781,6 +781,209 @@ Add expiry to proposals. After a certain time, proposals will not accept any mor
  • Implement call filters. This will allow multisig accounts to only accept certain calls.
  • +

    (source)

    +

    Table of Contents

    + +

    RFC-0076: Increase maximum length of identity raw data values from 32 bytes

    +
    + + + +
    Start Date20 Feb 2024
    DescriptionIncrease the maximum length of identity raw data values from 32 bytes
    AuthorsLuke Schoen
    +
    +

    Summary

    +

    This proposes to increase the maximum length of identity raw data values from a 32 bytes/chars limit to either a 64 bytes/chars limit or a 128 bytes/chars limit.

    +

    Motivation

    +

    Background

    +

    At the moment if you upload a file and pin it to IPFS storage you get an IPFS Content Identifier (CID), which is the unique ID of the file in the IPFS Network. That CID may be used to retrieve the file again via a standard IPFS interface and gateway from anywhere.

    +

    CIDs are reasonably short regardless of the size the underlying content and are based on the cryptographic hash of the content.

    +

    IPFS providers may default to using and recommending using CIDv1 [0] when using SHA256 generates a CID 46 bytes long, rather than CIDv0 [0] that generates a CID 59 bytes long, however CIDv0 may be be the preferred choice for minting and storing NFTs on-chain since it is cheaper.

    +

    Further, the URI protocol + CID for CIDv0 (ipfs://Qm...) will be 7+46=53 chars while for CIDv1 (ipfs://baf...) it will be 7+59=66 chars [1], so neither CIDv0 nor CIDv1 have a CID that supports a maximum length of 32 bytes, which exceeds the maximum 32 bytes/chars limit for bytes/string fields of their Polkadot on-chain identity.

    +

    Problem

    +

    If you want to set a Polkadot on-chain identity, users may provide raw data values of their email address "email" field, which may be longer than 32 bytes/chars (e.g. abcdefghijklmnopqrstuvwxyz@me.com or longer), and either just a CID or the URI protocol + CID associated with a legal document, as the value of the "legal" field, and the URI protocol + CID associated with the profile image to associated with their on-chain identity, as the value of the "image" field, however each field can only store a maximum length of 32 bytes/chars of information [3]. They may also want to set a custom value in the "additional" field, which currently only stores a maximum length of 32 bytes, since it currently has a FieldLimit.

    +

    Possible disadvantages of the current 32 bytes/chars limitation:

    + +

    Solution Requirements

    +

    The maximum length of identity raw data values should be increased from the current 32 bytes/chars limit at least a 59 bytes/chars limit (or a 66 bytes/chars limit) to support IPFS CIDs that are either CIDv0 or CIDv1.

    +

    They maximum length of "additional" field values should be increased by the same amount.

    +

    Stakeholders

    + +

    Explanation

    +

    If a user tries to setting an on-chain identity by creating an extrinsic using Polkadot.js with identity > setIdentity(info), then if they try to provide an email address or a website domain name that is longer than 32 characters, or try to use the IPFS CID (which may be associated with a file such as a document or image), then they will encounter this error:

    +
    createType(Call):: Call: failed decoding identity.setIdentity:: Struct: failed on args: {...}:: Data.Raw values are limited to a maximum length of 32 bytes
    +
    +

    Increasing maximum length of identity raw data values from the current 32 bytes/chars limit to at least a 59 bytes/chars limit (or a 66 bytes/chars limit) would overcome these errors and support IPFS CIDs that are either CIDv0 or CIDv1, satisfying the solution requirements.

    +

    Increasing the maximum length of "additional" field values would also overcome these errors and should be increased from the current 32 bytes/chars limitFieldLimit by the same amount.

    +

    Drawbacks

    +

    Performance

    +

    If Polkadot on-chain identities are able to store raw data values greater than the current maximum length of 32 bytes, then each identity may want to use the maximum (or more) amount of "additional" custom fields or more, which would impact storage and performance on the network.

    +

    Testing, Security, and Privacy

    +

    Implementations would need to be tested for adherance by checking that IPFS CIDs that are either CIDv0 or CIDv1 are supported.

    +

    No effect on security or privacy has been identified than already exists.

    +

    No implementation pitfalls have been identified.

    +

    Performance, Ergonomics, and Compatibility

    +

    Performance

    +

    It would be an optimization, since the associated exposed interfaces to developers and end-users could start being used.

    +

    To minimize additional overhead the proposal suggests at least a 59 bytes/chars limit (or a 66 bytes/chars limit) since that would at least provide support for IPFS CIDs that are either CIDv0 or CIDv1, satisfying the solution requirements.

    +

    Ergonomics

    +

    It alters exposed interfaces to developers and end-users since they will now be able to provide IPFS CIDs that are either CIDv0 or CIDv1 as the values of Polkadot on-chain identity raw data input fields. Optionally 66 bytes/chars limit could be established to optimise for the usage pattern end-users, since that may be more intuitive to them, as it would allow users to provide a link (e.g. URI protocol + CID) rather than just the CID.

    +

    Compatibility

    +

    Updates to Polkadot.js Apps, API and its documentation and those referring to it may be required.

    +

    Prior Art and References

    +

    Prior Art

    +

    No prior articles.

    +

    References

    + +

    Unresolved Questions

    +

    Why can't we increase the maximum length of Polkadot on-chain identity raw data values and the "additional" field limit from 32 bytes/chars to an even longer maximum length than proposed of 128 bytes/chars?

    + +

    Relates to RFC entitled "Increase maximum length of identity PGP fingerprint values from 20 bytes".

    +

    (source)

    +

    Table of Contents

    + +

    RFC-0077: Increase maximum length of identity PGP fingerprint values from 20 bytes

    +
    + + + +
    Start Date20 Feb 2024
    DescriptionIncrease the maximum length of identity PGP fingerprint values from 20 bytes
    AuthorsLuke Schoen
    +
    +

    Summary

    +

    This proposes to increase the maximum length of PGP Fingerprint values from a 20 bytes/chars limit to a 40 bytes/chars limit.

    +

    Motivation

    +

    Background

    +

    Pretty Good Privacy (PGP) Fingerprints are shorter versions of their corresponding Public Key that may be printed on a business card.

    +

    They may be used by someone to validate the correct corresponding Public Key.

    +

    It should be possible to add PGP Fingerprints to Polkadot on-chain identities.

    +

    GNU Privacy Guard (GPG) is compliant with PGP and the two acronyms are used interchangeably.

    +

    Problem

    +

    If you want to set a Polkadot on-chain identity, users may provide a PGP Fingerprint value in the "pgpFingerprint" field, which may be longer than 20 bytes/chars (e.g. PGP Fingerprints are 40 bytes/chars long), however that field can only store a maximum length of 20 bytes/chars of information.

    +

    Possible disadvantages of the current 20 bytes/chars limitation:

    + +

    Solution Requirements

    +

    The maximum length of identity PGP Fingerprint values should be increased from the current 20 bytes/chars limit at least a 40 bytes/chars limit to support PGP Fingerprints and GPG Fingerprints.

    +

    Stakeholders

    + +

    Explanation

    +

    If a user tries to setting an on-chain identity by creating an extrinsic using Polkadot.js with identity > setIdentity(info), then if they try to provide their 40 character long PGP Fingerprint or GPG Fingerprint, which is longer than the maximum length of 20 bytes/chars [u8;20], then they will encounter this error:

    +
    createType(Call):: Call: failed decoding identity.setIdentity:: Struct: failed on args: {...}:: Struct: failed on pgpFingerprint: Option<[u8;20]>:: Expected input with 20 bytes (160 bits), found 40 bytes
    +
    +

    Increasing maximum length of identity PGP Fingerprint values from the current 20 bytes/chars limit to at least a 40 bytes/chars limit would overcome these errors and support PGP Fingerprints and GPG Fingerprints, satisfying the solution requirements.

    +

    Drawbacks

    +

    No drawbacks have been identified.

    +

    Testing, Security, and Privacy

    +

    Implementations would be tested for adherance by checking that 40 bytes/chars PGP Fingerprints are supported.

    +

    No effect on security or privacy has been identified than already exists.

    +

    No implementation pitfalls have been identified.

    +

    Performance, Ergonomics, and Compatibility

    +

    Performance

    +

    It would be an optimization, since the associated exposed interfaces to developers and end-users could start being used.

    +

    To minimize additional overhead the proposal suggests a 40 bytes/chars limit since that would at least provide support for PGP Fingerprints, satisfying the solution requirements.

    +

    Ergonomics

    +

    No potential ergonomic optimizations have been identified.

    +

    Compatibility

    +

    Updates to Polkadot.js Apps, API and its documentation and those referring to it may be required.

    +

    Prior Art and References

    +

    No prior articles or references.

    +

    Unresolved Questions

    +

    No further questions at this stage.

    + +

    Relates to RFC entitled "Increase maximum length of identity raw data values from 32 bytes".

    (source)

    Table of Contents