Expose inner.send on AppWebsocket

[robbiecarlton]

No description provided.

[ThetaSinner]

Why expose this? There shouldn't be anything on the Holochain interface that isn't exposed to the client so there should be a dedicated method for any functionality you need. Is one of the methods doing something that doesn't work for you?

[jost-s]

Robbie and I spoke about this. In that moment I understood the issue better. Right now I'm recalling parts of it but don't completely piece them together. It's to do with avoiding an extra roundtrip between Envoy and Chaperone when signing zome calls from happ UIs. @robbiecarlton to the rescue

[ThetaSinner]

Awaiting reasoning

[robbiecarlton]

Hey, sorry I missed the notifications on this.

@ThetaSinner - the issue is that the call_zome method on AppWebsocket assumes a signer object, provided on instantiation, and then takes basic zome call args and constructs a signed zome call (called ZomeCall in the code) itself, using the signer object.

But in the envoy / chaperone pattern, the keys live in the web browser, so a signer object would have to make an additional network round trip for every zome call in order to sign the zome calls.

What we want to do instead is construct the signed zome call ourselves in chaperone, and then pass that directly to AppWebsocket, bypassing the internal construction of a signed zome call.

An alternative change to this client would be to just create a presigned_call_zome (or similar) method on AppWebsocket that just took a signed zome call directly. The reason I opted for the more general approach of exposing send is

1. it was simpler to implement
2. I don't see any security implications, given that this is just a convenience class on top of a websocket.

If there are objections to this more general approach, I'm happy to update it to the more restricted presigned_call_zome approach. lmk, and lmk if there's a name you like for that method

[ThetaSinner]

I see what you're after now.

I disagree that this requires an extra round trip though, because the singing mechanism doesn't require you to actually create the signature on demand. If you already have a signature, you can just return it from the sign function of an AgentSigner implementation.
If there is something about that interface that can be made more general then I'd be happy to work on that.

If we can't make that work in a tidy way then I'm open to adding a new function to the interface for requesting with a signed zome call.

I don't want to see the internals of this type get exposed because they will get used for other things (like calling new conductor functionality before it's been implemented in the client) which willl then break with serialisation errors rather than compiler errors when we make API changes.

[robbiecarlton]

@ThetaSinner - Your proposed solution works. However, it will require some additional moving parts in envoy (associating a signer with each websocket connection, including a hashmap of zome call hashes to signatures or equivalent).

If you're open to adding the option to make a presigned zome call, that would be my preference. Seems like that will be a very simple addition to this code base vs a more complicated addition to envoy.

This is partly motivated by the fact we're in a pretty big crunch here and this work on the envoy bump is going to be a blocker for the overall holo bump if it doesn't get in soon.

I'm happy to make the change, lmk what you think.

[ThetaSinner]

@robbiecarlton Done here #83

[ThetaSinner]

I'm going to close this now that we have another solution