More Consistency Between REST API and WebSocket API

I've been playing around with Baserow recently and came across some inconsistencies between the REST API and the WebSocket API.

First of which is the authentication mechanism. The REST API just needs a token that is created via the Baserow settings, but for WS, one needs to authenticate with username and password in order to get a JWT token which only lasts for 1 hour. Can WS use leverage the same token system already implemented for REST? Or, can the REST tokens be used in order to generate a JWT token for WS? I'm not sure of the precedence here, this is my first time interacting with WS directly.

Secondly, when using WS, all fields come back with the field_{#} ID, instead of named. I know this is the default behavior in the REST API as well, but is there some way to also instruct WS messages to come through with named fields? If not, then almost by default any application that leverages the WS API will also need to leverage the REST API to fetch the field => name mapping and then map each row's columns manually for every WS message.

Finally, and this is a bit more of a stretch I think, when I initiate a WS connection to a certain table, I also want to get the current table's values. I understand that this is different on a case by case basis, but for my use case, I want to display the content in my application and then use WS to update those values. Since WS doesn't give me the ability to query/fetch a whole table, I'm left again with having to leverage both the REST API (for original fetching of content to display on page load) and the WS API (for updates coming through).

Thanks for all of the hard work that goes into this application! Just the fact that there is both a REST API and WS API is amazing!