-
Notifications
You must be signed in to change notification settings - Fork 12
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
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
Add unsafe decoding? #62
Comments
In my opinion, we should stick with the name |
@bgins they're different! Parse is equivalent to |
@expede Yep, I'm aware they are different. I didn't state that very well. I think that most developers won't be familiar with the term |
What should the result type for Also big 👍 for adding stuff to the library, informed by usage sites. This makes sense. |
What would you think about making this even less safe? 😆 Something like |
I was thinking about this some more, and we should consider what tools might want to use the raw decode function. The use case I mention above is something that would be useful in ucan.xyz, but the safer type may be better for other tools and internally in |
Just trying to understand: Would you say this unsafe decode function belongs into ucan.xyz and we should close this issue? Or is there something that you think belongs into ts-ucan? |
For a raw decoding function to be useful in ucan.xyz, it should only check that a token has three sections, the sections are seperated by We do these steps in the I would propose we:
Does that sound like a good way to approach this? |
Hm. I think that means there's no one blocked by us putting a raw decoding function into |
Agreed. Let's hold on this for now. 👌 One use case I can imagine for raw decoding is debugging while developing an app, but once we have raw decoding in ucan.xyz, that should fulfill that use case. Some developers may still want the raw decoding function, but we can hold off until someone requests it. |
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
Summary
Problem
ts-ucan
does not provide a raw decoding function.Impact
Tools that wish to inspect a UCAN in its raw form are unable to do so without some level of parsing/validation.
Solution
Provide a raw decoding function.
Detail
Is your feature request related to a problem? Please describe.
Tools that wish to inspect a defective UCAN are unable to do so.
Describe the solution you'd like
The raw decoding function should:
.
separatorsNaming and/or namespacing will be an important consideration for the last point. A few possibilities:
ucan.unsafeDecode
ucan.unutterableFoulDecode
subtle
, for exampleucan.subtle.unsafeDecode
internal
as a namespace whereucan.internal.decode + ucan.internal.validate => ucan.validate
parse
instead ofvalidate
, because the that's decode + validate{insert-bikeshedding-here}
Describe alternatives you've considered
Developers can write their own raw decoding function.
The text was updated successfully, but these errors were encountered: