Decoupling the communication layer from the account identities

[arner]

Intro

The communication layer (platform/view/services/comm) is currently coupled with node identities (through the resolvers), and account identities are also coupled with node identities (through the endpointservice). This is a bit hard to understand and maybe is more coupling than necessary; we might be more flexible without it.

The communication layer needs to be able to have mutually authenticated connections to other nodes. This implies:

• A list of node identifiers
• a way to resolve them so we can route to them over the internet
• Some form of PKI?

A simple implementation could just DNS and TLS with client authentication. Like with Fabric, we could explicitly trust specific CAs or specific (self-signed?) certificates or even just public keys. Right now, for websockets we have a routing-config.yaml with hostnames next to the resolvers configuration which also has addresses, and I suspect it has something to do with the mixing between node identity and transport. The application layer should be able to trust that the connection to another node is secure and authenticated. Also consider the possibility that in the future we might need a more dynamic way to contact new parties without updating core.yaml.

Are we currently using the node identity for anything else than authentication of a connection?

EndpointService bindings (account -> node)

Consider:

• Node A
  • account_alice
• Node B
  • account_bob

Alice wants to transfer 1 token to bob. If Node A doesn't have account_bob configured in its core.yaml, it has to create a binding before being able to request an ephemeral identity for account_bob:

node := view.Identity("Node B")
rec := view.Identity("account_bob")
eps := viewregistry.GetEndpointService(ctx)
eps.Bind(node, rec)
recipient, err := ttx.RequestRecipientIdentity(ctx, rec)

RequestRecipientIdentity will then use the just created binding to look up Node B from account_bob, and put the bytes of the literal "account_bob" in the request so that Node B can look up the wallet / identity for account_bob. The address of Node B (as well as the node's public key) to set up the connection comes from the resolvers configuration. This is a bit cumbersome and there is a risk of bugs as well; for instance if we create a wrong binding "Node A" -> "account_bob" this binding can be used by another thread.

In many usage scenarios, either Node A or Alice herself will already know that Bob is hosted by Node B. It would be more natural if we can just call RequestRecipientIdentity with the node id and the account alias.There is no technical need anymore for tight coupling between node identities and accounts, this can be left to the application.

recipient, err := ttx.RequestRecipientIdentity(ctx, node, rec)

Websockets / https

At the moment, there is some work to do for the production readiness of the websockets implementation (TLS is one item on the list!). Maybe this is a chance to try to simplify the relation between node identity and transport? Simplify could either mean remove the relation ór fully lean into it... Maybe we want to keep both, and validate both the certificate(s) of the transport and the node key on the application level? I don't know the details and all the reasoning but it seems like a discussion worth having.

Proposal

• remove the need for binding when creating a connecting to another node
• consider the other ways identities are interlinked and whether we could simplify it.

It's a bit of a ramble but it's not an easy subject, hopefully the gist of it makes sense :).