BitcoinCash/chip-bcmr
1
Fork 0
Code Issues Pull Requests Releases Activity

standardize image URI for IdentitySnapshots

Browse Source
This commit is contained in:
Jason Dreyzehner
2023-05-09 12:11:17 -04:00
parent 924593cfc4
commit 852916c341
3 changed files with 21 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files
bcmr-v2.schema.json
+6 -5
View File
@@ -56,7 +56,7 @@
},
"uris": {
"$ref": "#/definitions/URIs",
"description": "A mapping of identifiers to URIs associated with this identity. URI identifiers may be widely-standardized or registry-specific. Values must be valid URIs, including a protocol prefix (e.g. `https://` or `ipfs://`). Clients are only required to support `https` and `ipfs` URIs, but any scheme may be specified.\n\nThe following identifiers are recommended for all identities:\n- `icon`\n- `web`\n\nThe following optional identifiers are standardized:\n- `blog`\n- `chat`\n- `forum`\n- `icon-intro`\n- `registry`\n- `support`\n\nFor details on these standard identifiers, see: https://github.com/bitjson/chip-bcmr#uri-identifiers\n\nCustom URI identifiers allow for sharing social networking profiles, p2p connection information, and other application-specific URIs. Identifiers must be lowercase, alphanumeric strings, with no whitespace or special characters other than dashes (as a regular expression: `/^[-a-z0-9]+$/`).\n\nFor example, some common identifiers include: `discord`, `docker`, `facebook`, `git`, `github`, `gitter`, `instagram`, `linkedin`, `matrix`, `npm`, `reddit`, `slack`, `substack`, `telegram`, `twitter`, `wechat`, `youtube`."
"description": "A mapping of identifiers to URIs associated with this identity. URI identifiers may be widely-standardized or registry-specific. Values must be valid URIs, including a protocol prefix (e.g. `https://` or `ipfs://`). Clients are only required to support `https` and `ipfs` URIs, but any scheme may be specified.\n\nThe following identifiers are recommended for all identities:\n- `icon`\n- `web`\n\nThe following optional identifiers are standardized:\n- `blog`\n- `chat`\n- `forum`\n- `icon-intro`\n- `image`\n- `migrate`\n- `registry`\n- `support`\n\nFor details on these standard identifiers, see: https://github.com/bitjson/chip-bcmr#uri-identifiers\n\nCustom URI identifiers allow for sharing social networking profiles, p2p connection information, and other application-specific URIs. Identifiers must be lowercase, alphanumeric strings, with no whitespace or special characters other than dashes (as a regular expression: `/^[-a-z0-9]+$/`).\n\nFor example, some common identifiers include: `discord`, `docker`, `facebook`, `git`, `github`, `gitter`, `instagram`, `linkedin`, `matrix`, `npm`, `reddit`, `slack`, `substack`, `telegram`, `twitter`, `wechat`, `youtube`."
}
},
"required": ["name", "token"],
@@ -90,7 +90,7 @@
},
"IdentityHistory": {
"$ref": "#/definitions/RegistryTimestampKeyedValues<IdentitySnapshot>",
"description": "A timestamp-keyed map of {@link IdentitySnapshot } s documenting the evolution of a particular identity. Typically, the current identity information is the latest record when lexicographically sorted, but in cases where a planned migration has not yet begun (the snapshot's timestamp has not yet been reached), the immediately preceding record is considered the current identity.\n\nThis strategy allows wallets and other user interfaces to offer better experiences when an identity is rebranded, a token redenominated, or other important metadata is modified in a coordinated update. For example, a wallet may warn token holders of a forthcoming rebranding of fungible tokens they hold; after the change, the wallet may continue to offer prominent interface hints that the rebranded token identity was recently updated.\n\nNote, only the latest two {@link IdentitySnapshot } s should be considered part of an identity's \"current\" information. E.g. even if two snapshots have active, overlapping migration periods (i.e. an older snapshot's\n {@link IdentitySnapshot.migrated } timestamp has not yet been reached), clients should only attempt to display the migration from the previous to the latest snapshot.\n\nIf the current snapshot's {@link IdentitySnapshot.migrated } isn't specified, the snapshot's index is a precise time at which the snapshot takes effect and clients should begin using the new information. If `migrated` is specified, the snapshot's index is the timestamp at which the transition is considered to begin, see {@link IdentitySnapshot.migrated } for details.\n\nEach timestamp must be provided in simplified extended ISO 8601 format, a 24-character string of format `YYYY-MM-DDTHH:mm:ss.sssZ` where timezone is zero UTC (denoted by `Z`). Note, this is the format returned by ECMAScript `Date.toISOString()`.\n\nIn the case that an identity change occurs due to on-chain activity (e.g. an on-chain migration that is set to complete at a particular locktime value), registry-recorded timestamps reflect the real-world time at which the maintainer of the registry believes the on-chain activity to have actually occurred. Likewise, future-dated timestamps indicate a precise real-world time at which a snapshot is estimated to take effect, rather than the Median Time Past (BIP113) UNIX timestamp or another on-chain measurement of time."
"description": "A timestamp-keyed map of {@link IdentitySnapshot } s documenting the evolution of a particular identity. The current identity information is the snapshot associated with the latest timestamp reached. If no timestamp has yet been reached, the snapshot of the oldest timestamp is considered current. Future-dated timestamps indicate planned migrations.\n\nThis strategy allows wallets and other user interfaces to offer better experiences when an identity is rebranded, a token redenominated, or other important metadata is modified in a coordinated update. For example, a wallet may warn token holders of a forthcoming rebranding of fungible tokens they hold; after the change, the wallet may continue to offer prominent interface hints that the rebranded token identity was recently updated.\n\nTimestamps may be order by time via lexicographical sort. For determinism, it is recommended that implementations sort from newest to oldest in exported registry JSON files.\n\nIf the current snapshot's {@link IdentitySnapshot.migrated } isn't specified, the snapshot's index is a precise time at which the snapshot takes effect and clients should begin using the new information. If `migrated` is specified, the snapshot's index is the timestamp at which the transition is considered to begin, see {@link IdentitySnapshot.migrated } for details.\n\nEach timestamp must be provided in simplified extended ISO 8601 format, a 24-character string of format `YYYY-MM-DDTHH:mm:ss.sssZ` where timezone is zero UTC (denoted by `Z`). Note, this is the format returned by ECMAScript `Date.toISOString()`.\n\nIn the case that an identity change occurs due to on-chain activity (e.g. an on-chain migration that is set to complete at a particular locktime value), registry-recorded timestamps reflect the real-world time at which the maintainer of the registry believes the on-chain activity to have actually occurred. Likewise, future-dated timestamps indicate a precise real-world time at which a snapshot is estimated to take effect, rather than the Median Time Past (BIP113) UNIX timestamp or another on-chain measurement of time."
},
"IdentitySnapshot": {
"additionalProperties": false,
@@ -134,7 +134,7 @@
},
"uris": {
"$ref": "#/definitions/URIs",
"description": "A mapping of identifiers to URIs associated with this identity. URI identifiers may be widely-standardized or registry-specific. Values must be valid URIs, including a protocol prefix (e.g. `https://` or `ipfs://`). Clients are only required to support `https` and `ipfs` URIs, but any scheme may be specified.\n\nThe following identifiers are recommended for all identities:\n- `icon`\n- `web`\n\nThe following optional identifiers are standardized:\n- `blog`\n- `chat`\n- `forum`\n- `icon-intro`\n- `registry`\n- `support`\n\nFor details on these standard identifiers, see: https://github.com/bitjson/chip-bcmr#uri-identifiers\n\nCustom URI identifiers allow for sharing social networking profiles, p2p connection information, and other application-specific URIs. Identifiers must be lowercase, alphanumeric strings, with no whitespace or special characters other than dashes (as a regular expression: `/^[-a-z0-9]+$/`).\n\nFor example, some common identifiers include: `discord`, `docker`, `facebook`, `git`, `github`, `gitter`, `instagram`, `linkedin`, `matrix`, `npm`, `reddit`, `slack`, `substack`, `telegram`, `twitter`, `wechat`, `youtube`."
"description": "A mapping of identifiers to URIs associated with this identity. URI identifiers may be widely-standardized or registry-specific. Values must be valid URIs, including a protocol prefix (e.g. `https://` or `ipfs://`). Clients are only required to support `https` and `ipfs` URIs, but any scheme may be specified.\n\nThe following identifiers are recommended for all identities:\n- `icon`\n- `web`\n\nThe following optional identifiers are standardized:\n- `blog`\n- `chat`\n- `forum`\n- `icon-intro`\n- `image`\n- `migrate`\n- `registry`\n- `support`\n\nFor details on these standard identifiers, see: https://github.com/bitjson/chip-bcmr#uri-identifiers\n\nCustom URI identifiers allow for sharing social networking profiles, p2p connection information, and other application-specific URIs. Identifiers must be lowercase, alphanumeric strings, with no whitespace or special characters other than dashes (as a regular expression: `/^[-a-z0-9]+$/`).\n\nFor example, some common identifiers include: `discord`, `docker`, `facebook`, `git`, `github`, `gitter`, `instagram`, `linkedin`, `matrix`, `npm`, `reddit`, `slack`, `substack`, `telegram`, `twitter`, `wechat`, `youtube`."
}
},
"required": ["name"],
@@ -275,6 +275,7 @@
},
"OffChainRegistryIdentity": {
"additionalProperties": false,
"description": "An identity representing a metadata registry that is not published on-chain and therefore has no authbase or trackable authchain.",
"properties": {
"description": {
"description": "A string describing this identity for use in user interfaces.\n\nIn user interfaces with limited space, descriptions should be hidden beyond the first newline character or `140` characters until revealed by the user.\n\nE.g.:\n- `The common stock issued by ACME, Inc.`\n- `A metadata registry maintained by Company Name, the embedded registry for Wallet Name.`\n- `Software developer and lead maintainer of Wallet Name.`",
@@ -297,7 +298,7 @@
},
"uris": {
"$ref": "#/definitions/URIs",
"description": "A mapping of identifiers to URIs associated with this identity. URI identifiers may be widely-standardized or registry-specific. Values must be valid URIs, including a protocol prefix (e.g. `https://` or `ipfs://`). Clients are only required to support `https` and `ipfs` URIs, but any scheme may be specified.\n\nThe following identifiers are recommended for all identities:\n- `icon`\n- `web`\n\nThe following optional identifiers are standardized:\n- `blog`\n- `chat`\n- `forum`\n- `icon-intro`\n- `registry`\n- `support`\n\nFor details on these standard identifiers, see: https://github.com/bitjson/chip-bcmr#uri-identifiers\n\nCustom URI identifiers allow for sharing social networking profiles, p2p connection information, and other application-specific URIs. Identifiers must be lowercase, alphanumeric strings, with no whitespace or special characters other than dashes (as a regular expression: `/^[-a-z0-9]+$/`).\n\nFor example, some common identifiers include: `discord`, `docker`, `facebook`, `git`, `github`, `gitter`, `instagram`, `linkedin`, `matrix`, `npm`, `reddit`, `slack`, `substack`, `telegram`, `twitter`, `wechat`, `youtube`."
"description": "A mapping of identifiers to URIs associated with this identity. URI identifiers may be widely-standardized or registry-specific. Values must be valid URIs, including a protocol prefix (e.g. `https://` or `ipfs://`). Clients are only required to support `https` and `ipfs` URIs, but any scheme may be specified.\n\nThe following identifiers are recommended for all identities:\n- `icon`\n- `web`\n\nThe following optional identifiers are standardized:\n- `blog`\n- `chat`\n- `forum`\n- `icon-intro`\n- `image`\n- `migrate`\n- `registry`\n- `support`\n\nFor details on these standard identifiers, see: https://github.com/bitjson/chip-bcmr#uri-identifiers\n\nCustom URI identifiers allow for sharing social networking profiles, p2p connection information, and other application-specific URIs. Identifiers must be lowercase, alphanumeric strings, with no whitespace or special characters other than dashes (as a regular expression: `/^[-a-z0-9]+$/`).\n\nFor example, some common identifiers include: `discord`, `docker`, `facebook`, `git`, `github`, `gitter`, `instagram`, `linkedin`, `matrix`, `npm`, `reddit`, `slack`, `substack`, `telegram`, `twitter`, `wechat`, `youtube`."
}
},
"required": ["name"],
@@ -392,7 +393,7 @@
"type": "number"
},
"patch": {
"description": "The patch version is incremented when an existing identity or identity snapshot is modified (e.g. to correct an error or add a missing piece of information) or when other registry properties (e.g. registry `name`, `description`, `uris`, etc.) are modified.\n\nGenerally, substantive changes to an existing identity should be made using a new identity snapshot in a minor version upgrade – this allows clients to provide a better user experience by noting the change in relevant user interfaces.\n\nFor example, patch upgrades might include spelling corrections in an existing snapshot or the addition of an `icon-svg` containing a higher-resolution version of an existing `icon` image. On the other hand, a rebranding in which the icon is substantially changed may warrant a new identity snapshot to be added in a minor version upgrade.",
"description": "The patch version is incremented when an existing identity or identity snapshot is modified (e.g. to correct an error or add a missing piece of information) or when other registry properties (e.g. registry `name`, `description`, `uris`, etc.) are modified.\n\nGenerally, substantive changes to an existing identity should be made using a new identity snapshot in a minor version upgrade – this allows clients to provide a better user experience by noting the change in relevant user interfaces.\n\nFor example, patch upgrades might include spelling corrections in an existing snapshot or the addition of an `icon` containing a higher-resolution version of an existing `icon` image. On the other hand, a rebranding in which the icon is substantially changed may warrant a new identity snapshot to be added in a minor version upgrade.",
"type": "number"
}
},