Nick Johnson
Nick Johnson
I agree with the sentiment, but I'm not so sure this is a practical way to handle it. It needs thought.
Known issue - you really shouldn't be logging this much. Still a bug, though, so I'll leave it open.
@jdevcs @nazarhussain would it be possible to take another look at this?
I'm sorry to hear that. This change is crucial to ENS, so we're happy to implement it in the ENS package if that's your preference. Because it's a general-purpose standard...
@ligi A CAIP number is not an 'authority' in the RFC 3986 meaning of the word: > Many URI schemes include a hierarchical element for a naming > authority so...
I think it makes more sense for CAIPs to maintain a registry rather than try and make the standard number part of the URI. Email URIs are `mailto:[email protected]`, not `rfc:822:[email protected]`....
While it'd be nice to have a URI scheme for each CAIP, it's probably more realistic to be something like `caip:eip155:1:...`, and have a CAIP registry that defines how `eip155`...
It should be easy to maintain a registry, then!
Are there any plans to improve this workflow so changes to Kubernetes secrets are picked up? Google managed SSL certificates don't support wildcards, so this is still very useful for...
The current blocklyduino has at least some support for variable type - you can't drop a string and an int as two arguments to a math operator, for instance.