Skip to content

Conversation

@willscott
Copy link
Contributor

These are not used in CIDs regularly, so size is not a primary concern. As such, adding to a high byte range space.

These are not used in CIDs regularly, so size is not a primary concern. As such, adding to a high byte range space.
@warpfork
Copy link
Contributor

warpfork commented Nov 9, 2021

So the idea is that these aren't used for codecs, but are magic numbers that may be used... somewhere else, in specific places where we're expecting to talk about ADLs, such as in a field of integer type in a selector extension we're about to propose?

@willscott
Copy link
Contributor Author

in general i would not expect them to be directly embedded as CIDs, but they are sufficiently cid-adjacent that they should not conflict with other defined multi-codecs, and I believe warrant their own namespace in the multicodec registry in which to be defined and delineated.

Copy link
Member

@Stebalien Stebalien left a comment

Choose a reason for hiding this comment

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

No reason not to merge these as draft codes.

@Stebalien
Copy link
Member

Nvm. Apparently we're not using codecs.

@Stebalien Stebalien closed this Mar 2, 2022
@willscott
Copy link
Contributor Author

this got deprecated in favor strings

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants