we need a real design for service identity --- currently we just have a sort of "finish this later" sketch.
@hdevalence suggests using ed25519 public keys for service instance addresses, and i think this is probably the right approach. i'd like to be able to layer in an encrypted transport for untrusted links layer, and using the pubkey as the address gives us a lot of benefits:
- guaranteed global uniqueness for free
- services can attest the data as having come from the address you wanted to route to
- identities can move across machines if a service can carry its own key material with it
- you don't need to build a whole PKI if addresses are public keys
- some extremely brain genius crypto stuff i'll let henry talk about
this does have the downside making addresses be 32 bytes long (twice the size of an IPv6 addr...). however, if you wanted to add transport encryption on top of a routing protocol, you would still be exchanging pubkeys in addition to routing addrs, so there is maybe some advantage to not having to exchange both.
another downside is that you can't easily use a scheme based on pubkeys to represent hierarchical addresses, the way you can with IP subnets. but maybe we will use a routing scheme that doesn't require that?
meanwhile, i think we should continue using UUIDs to identify service interfaces. so, a UUID identifies a particular RPC interface that a service serves, while a public key is the address of an individual service that you can route to.
you could do service discovery by, essentially, asking a discovery service (who you trust) "hey, i want someone who provides the service interface with this UUID" and getting back a set of ed25519 pub keys (addresses) that serve the service you wanted. since the discovery service signed the messages with its private key, you create a chain of trust for the discovered endpoints implicitly.
we need a real design for service identity --- currently we just have a sort of "finish this later" sketch.
@hdevalence suggests using ed25519 public keys for service instance addresses, and i think this is probably the right approach. i'd like to be able to layer in an encrypted transport for untrusted links layer, and using the pubkey as the address gives us a lot of benefits:
this does have the downside making addresses be 32 bytes long (twice the size of an IPv6 addr...). however, if you wanted to add transport encryption on top of a routing protocol, you would still be exchanging pubkeys in addition to routing addrs, so there is maybe some advantage to not having to exchange both.
another downside is that you can't easily use a scheme based on pubkeys to represent hierarchical addresses, the way you can with IP subnets. but maybe we will use a routing scheme that doesn't require that?
meanwhile, i think we should continue using UUIDs to identify service interfaces. so, a UUID identifies a particular RPC interface that a service serves, while a public key is the address of an individual service that you can route to.
you could do service discovery by, essentially, asking a discovery service (who you trust) "hey, i want someone who provides the service interface with this UUID" and getting back a set of ed25519 pub keys (addresses) that serve the service you wanted. since the discovery service signed the messages with its private key, you create a chain of trust for the discovered endpoints implicitly.