My proposal: single TunnelbrokerService with a single RPC that takes targetDeviceID and generic message (API will probably expand in the future though)

Pros of my proposal:

• Better "separation of concerns"... Tunnelbroker does not need to concern itself with the contents of messages
• If we ever need some other internal service to send a message via Tunnelbroker, we won't need to update the .proto

Cons of my proposal:

• It shunts responsibility for checking validity of messages to clients. This can be done with cryptographic signatures, but it may be slightly more complicated
• It might complicate efforts to control spam / malicious actors in the future

Decision to create a separate service specifically for service A to talk to service B, versus just a unified service definition for service B

Since tunnelbroker needs to verify that it's the official identity service, I wanted a service specific to just those two. Especially if the services will require something like a token to authenticate.

Decision to have a specific RPC for issuing a specific kind of message, versus just have a generic RPC for issuing any message

My preference for type safety. If it compiles, it usually runs without issue. Just want to avoid a lot of "stringly" typed API.

I think I would prefer to see TunnelbrokerService with a single RPC that takes targetDeviceID and generic message

That feels like it's trying to work around protobuf messages, I don't see a clear advantage. It's also not as ergonomic in rust as just consuming the generated bindings for gRPC.

Shouldn't matter if the message is opaque to the Tunnelbroker service

Just doesn't feel right, that an error in another service will propagate through tunnelbroker. I understand where you're coming from, as tunnelbroker doesn't strictly need to know the contents, but it just still feels weird from an API standpoint.

But as a "broker", I understand your point.

Having identity service be aware of the "websocket payload", also couples identity service to being aware of the websocket implementation. Which would mean that the client messages would need to reside in a shared location (not necessarily a bad thing, but it is an implication of making the messages opaque).

Having identity service be aware of the "websocket payload", also couples identity service to being aware of the websocket implementation. Which would mean that the client messages would need to reside in a shared location (not necessarily a bad thing, but it is an implication of making the messages opaque).

Yeah, that makes sense.

If you're asking about verifying individual messages, this would probably be a better question of annuay as this is outside my expertise.

Yeah that's what I'm getting at. As an example approach, what if identity service has some certificate vended by a CA that the client trusts, and identity service signs the request for more one-time keys?

One nice property of this approach is that we can start by doing it without the signature, and then add the signature later when we're ready.

Just doesn't feel right, that an error in another service will propagate through tunnelbroker. I understand where you're coming from, as tunnelbroker doesn't strictly need to know the contents, but it just still feels weird from an API standpoint.

But as a "broker", I understand your point.

That's the core of my point... Tunnelbroker is already complicated enough as is. I'd like to keep a "separation of concerns" where understanding the contents of the payload is outside the scope of the Tunnelbroker service.

This was rebased on top of deleting the old tunnelbroker.proto. Which is why I had it as something else originally.