It is great that you folks have publicly documented the API, it would be good if sooner rather than later (as apps further uptake it) you could enhance the granularity of the oath scopes. I have a hard time not imagining there are plenty of applications that do not need to remotely start the car, or unlock it, or add another key, or access the live camera. Right now the vehicle_cmds is all or nothing posing quite a security issue if you need any of those commands you need to give access to all. Similarly vehicle_device_data which various analytic tools use require giving access to real time location as well, which again is not needed for different applications.
It may also be worthwhile to document the official protobuf protocol rather than requiring to reverse it from the go code. You announced the public API documentation and EOL'ed it in the same step. It is a minor detail but for those not looking to run a secondary app to convert all commands to the new standard (as even new apps in not-go would need to do this by default) would make things easier.
Worth noting: for intelligent EV charging like https://evcc.io, really only the wakeup and start/stop charging commands are needed. Maybe create groups of commands for specific use cases?
It is great that you folks have publicly documented the API, it would be good if sooner rather than later (as apps further uptake it) you could enhance the granularity of the oath scopes. I have a hard time not imagining there are plenty of applications that do not need to remotely start the car, or unlock it, or add another key, or access the live camera. Right now the vehicle_cmds is all or nothing posing quite a security issue if you need any of those commands you need to give access to all. Similarly vehicle_device_data which various analytic tools use require giving access to real time location as well, which again is not needed for different applications.
It may also be worthwhile to document the official protobuf protocol rather than requiring to reverse it from the go code. You announced the public API documentation and EOL'ed it in the same step. It is a minor detail but for those not looking to run a secondary app to convert all commands to the new standard (as even new apps in not-go would need to do this by default) would make things easier.