Wire Protocol Definition #1
Conversation
|
This pull request has been linked to Shortcut Story #8495: Wire Protocol: Implement Protobufs. |
| @@ -0,0 +1,3 @@ | |||
| package api | |||
|
|
|||
| //go:generate protoc -I=$GOPATH/src/github.com/rotationalio/ensign/proto --go_out=. --go_opt=module=github.com/rotationalio/ensign/pkg/api --go-grpc_out=. --go-grpc_opt=module=github.com/rotationalio/ensign/pkg/api ensign/v1beta1/event.proto ensign/v1beta1/topic.proto ensign/v1beta1/ensign.proto | |||
There was a problem hiding this comment.
This generate.go file should handle all versions of ensign (which is why it is on the outer level above the v1beta1 folder).
| message OpenStream { | ||
| string topic = 1; | ||
| string group = 2; | ||
| } |
There was a problem hiding this comment.
Is there any sense of "permission" that needs to be encoded into the OpenStream message? For instance, might this need to include information that the server can use to validate whether a would-be subscriber should be allowed access to the data in the stream, e.g. based on their region or their privacy settings? Or is permission defined only on the level of an Event (i.e. with the Region and Encryption fields). I know full geographic awareness isn't an MVP feature, so it's also fine if this is a future discussion to come back to.
There was a problem hiding this comment.
This is an excellent question and one that merits some discussion.
My current plan is to have authentication and authorization (at a broad level) as a token in the header of the requests. The user would have to supply a client ID or client ID and secret via the SDK for this to work. The token could have claims in it for fine grained permissions if we thought that would be useful.
What I hadn't considered is whether or not we want some sort of fine grained permissions system on events; e.g. read/write permissions for different event types/topic combinations? Maybe something similar to Linux file permissions where we have "owners", "group", and "other" permissions?
In terms of the region that the event originates from, there are three methods of retrieving this information:
- Use the users IP address and MaxMind to geolocate the sender.
- Use the geoping RRData method and use the location of the ensign node the user connects to
- Allow the user to specify what location the data is coming from (e.g. from the device's GPS)
The first and second options cannot be spoofed, so we would probably want to ensure that subscribers use one of these methods so we don't get a subscriber in Iowa saying they're in Tokyo. However, for publishers -- we may want to allow them to specify the region of the data for compliance purposes? E.g. if the publisher is in Ohio they may want to specify certain types of data is Canadian?
Clearly a lot to discuss here; it would be good if we could have a whiteboarding session on this topic once we get to it.
This PR specifies the initial protocol buffers for the Ensign protocol including the event definition and the primary RPC definitions. This is meant to be a starting place so that we can iterate on what data is actually needed, developing enums and other data structures as necessary. The question for this PR is whether we're happy with the design framework and where Ensign might go from here.
Fixes SC-8495