Skip to content

Add subscription permission by source and name #1043

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 5 commits into
base: main
Choose a base branch
from
Open

Add subscription permission by source and name #1043

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
a7d5c05
Add subscription permission by source and name
lukasIO Apr 11, 2025
3f5874c
generated protobuf
github-actions[bot] Apr 11, 2025
7ef2003
change fields on TrackPermission
lukasIO Apr 11, 2025
3a6cb84
Merge branch 'lukas/source-subscr-perm' of github.com:livekit/protoco…
lukasIO Apr 11, 2025
db50077
generated protobuf
github-actions[bot] Apr 11, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
118 changes: 84 additions & 34 deletions livekit/livekit_rtc.pb.go
View file
Open in desktop

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

10 changes: 7 additions & 3 deletions protobufs/livekit_rtc.proto
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -340,10 +340,12 @@ message SubscribedQualityUpdate {

message TrackPermission {
// permission could be granted either by participant sid or identity
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

change comment if participant_sid is marked deprecated?

string participant_sid = 1;
string participant_sid = 1 [deprecated = true];
bool all_tracks = 2;
repeated string track_sids = 3;
repeated string track_sids = 3 [deprecated = true];
string participant_identity = 4;
repeated TrackSource track_sources = 5;
repeated string track_names = 6;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would make this another message to have source, name pairing explicit. If both are repeated and if we are doing intersection match, we would have to check all combinations of the two and allow it. Is that the intention? Or should we have explicit pairs (and the fields inside the pairing can be optional)?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oh, that's a good point!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe it doesn't even have to be repeated 🤔

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think a repeated pairing makes sense. That will allow something like camera, front and mic, back to be allowed, but not permitting camera, back, mic, front.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it has to be repeated to support multiple sources...?

allowed: [{source: MIC}, {source: CAM}, {etc...}]

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes

}

message SubscriptionPermission {
Expand All @@ -353,8 +355,10 @@ message SubscriptionPermission {

message SubscriptionPermissionUpdate {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

wait, this is the wrong message 🤦

string participant_sid = 1;
string track_sid = 2;
string track_sid = 2 [deprecated = true];
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is a response message, shouldn't this be in request?

Also, checking with a customer about this also. Maybe, keep track_sid also? I am on the fence too on that.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

haha jinx, commented above

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

keeping track_sid seems like a footgun now that we always generate new track ids on republish

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should the SubscriptionPermissionUpdate sent from the server down still translate to track_sid in the response?
or should we match the tracks client side also by source and/or name?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah true, I am just trying to think if it will be useful in any situation as that gives a very specific thing and that is already in the system.

Tracks can be published without having a source or name. But, track_sid is always there.

I cannot think of a case, but just feels like there is something that would need that specificity. We can remove and bring it back later if needed I guess.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should the SubscriptionPermissionUpdate sent from the server down still translate to track_sid in the response? or should we match the tracks client side also by source and/or name?

jinx again, I was adding a note about it too.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should the SubscriptionPermissionUpdate sent from the server down still translate to track_sid in the response?

ideally both server/client would only have to think about name/source for permissions but idk if we can do this without breaking the api...? also to Raja's point even though we're deprecating this i don't think we're going to clean up the code immediately and if customers have use cases that the new model doesn't support we'll get push-back.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe not deprecate here. This is just an info message. It can have the current SID server sees. Also not sure if we want to include source/name in this message. I guess we can, but not sure if it is needed. It is optional, but if unused, might as well not have it?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it's not purely informational, we also use it client side to setAllowed on publications: https://github.com/livekit/client-sdk-js/blob/0c1c18cce46ec5e78c50912277b378fae04997f1/src/room/Room.ts#L1723-L1734

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah true, so I guess having SID is a good thing then?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't have an opinion on whether or not track_sid should stay here, it's just an additional step for the server to translate between source + name on the request to the trackSid

bool allowed = 3;
optional TrackSource track_source = 4;
optional string track_name = 5;
}

message SyncState {
Expand Down