Irakli Gozalishvili
Irakli Gozalishvili
This may be a separate issue, but is related enough that I think it would make sense to capture here. While I see value in capabilities been open ended, I...
Thinking more about this I think it would be better to represent ucan capabilities not as an array of `Capability` but rather as a dictionary of constraints as that structure...
> There are use cases for overlapping capabilities. For example, I may want to be able to do atomic updates to multiple file systems, in which case I need several...
Oh I am a fool, my first example has same key twice.
I think my general sentiment is it would be nice if capabilities were structured in a way that removed any surface for an ambiguity. I am conceptualizing a capability is...
It is however worse highlighting though that such a structure would only support encoding constraints where all restrictions must be met. It will not allow encoding a structure in which...
> I generally like this line of thinking, however, that'd be more of a spec discussion and as such its benefits should be weighed against breaking existing implementations. _This_ library...
> till, I'd like to keep the types simple. We need to remember that if we have precise types, we still need to do the runtime checking that they're correctly...
> Who will read this error message? A user or a developer? > If it's a user, I don't think it makes sense to show them anything more meaningful -...
@expede I do share the dissatisfaction with packing two fields into a single key and it may indeed be a bad idea. Maybe it is indeed better to let them...