Daniel Porteous (dport)
Daniel Porteous (dport)
Today, the spec generated from our API says that it can return the success and error codes defined by the success / error response structs used in its result. To...
Currently with the API, e.g. `/events/:event_key`, the key manifests as just a string in the spec (though the `format` field is set, which is a start). Ideally it would instead...
When first developing v1 of the API, I had it that while we accepted and return `Vec` for the BCS content / accept type of each endpoint, the spec would...
Currently we use a mix of mime types for BCS: - `application/x-bcs` - `application/x.aptos.signed_transaction+bcs` - `application/x.aptos.output+bcs` I think we should just cut over to using only the first one, I...
Currently we check accept type using a function right at the start of the endpoint handler function. We could instead make this middleware (that we conditionally apply with `transform`) that...
These types existed to help clients understand the number types they were dealing with, but with an appropriate SDK, these aren't really necessary. In JS (the main reason we do...
# 🐛 Bug For events, if no paging params are given (`start` and `limit`), we return `default_limit` events starting from zero. For transactions, if no paging params are given, we...
Currently the best way to see what the evaluator choices are is to run a command like this: ``` $ cargo run -- configuration create --evaluators x --url http://whatever.com --configuration-name...
# 🚀 Feature Request Currently this move module compiles: ``` $ cat mytest/sources/MyTest.move module MyModule::MyTest { struct MyTest has key {} struct Vote has copy, drop, store { blah: u8,...
Currently the aptos CLI prompts you whenever you're doing something potentially risky. To avoid this you can pass `--assume-yes` but this gets old very fast for people who are used...