Skip to content

Conversation

pblazej
Copy link
Contributor

@pblazej pblazej commented Sep 16, 2025

Incarnation of:

Key differences:

  • Mostly leverages Swift-native approach (protocols + default impl)
  • Caching is opt-in wrapper (which could be extended to Keychain tho)

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 haven't pushed the respective proto, it does not provide any kind of "validation" for the payload keys, etc.

Copy link

@1egoman 1egoman left a comment

Choose a reason for hiding this comment

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

Looks pretty good to me! I'm not going to be able to comment on some of the swift specific things being done, hopefully others can weigh in on that stuff.

@pblazej pblazej force-pushed the blaze/connection-provider branch from 901e390 to 84a6093 Compare September 17, 2025 08:32
@pblazej
Copy link
Contributor Author

pblazej commented Sep 18, 2025

There will be some renaming to TokenSource and TokenSource.Endpoint as discussed with JS.

@pblazej pblazej changed the title Credential providers Token source Sep 19, 2025
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Moved it to a separate file for visibility.

@pblazej
Copy link
Contributor Author

pblazej commented Sep 19, 2025

Added JWT support (if we really want it 👍)


/// `Sandbox` queries LiveKit Sandbox token server for credentials,
/// which supports quick prototyping/getting started types of use cases.
/// - Warning: This token endpoint is **INSECURE** and should **NOT** be used in production.
Copy link
Contributor

Choose a reason for hiding this comment

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


/// Protocol for types that can provide connection credentials.
/// Implement this protocol to create custom credential providers (e.g., fetching from your backend API).
public protocol TokenSource: Sendable {
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 we'll need to expand this docstring to explain the whole system, since it seem like the entrypoint where people will encounter tokens for the first time (on the params to the room connect method)

@pblazej pblazej force-pushed the blaze/connection-provider branch from e27bd11 to 6b47bb2 Compare September 24, 2025 13:26
@pblazej
Copy link
Contributor Author

pblazej commented Sep 25, 2025

Not sure about the final form (stateless/stateful), depends on JS impl as well 👍

Copy link

@xianshijing-lk xianshijing-lk left a comment

Choose a reason for hiding this comment

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

some thoughts from a quick glance, pretty solid code in general.

/// `Sandbox` queries LiveKit Sandbox token server for credentials,
/// which supports quick prototyping/getting started types of use cases.
/// - Warning: This token endpoint is **INSECURE** and should **NOT** be used in production.
public struct Sandbox: TokenEndpoint {

Choose a reason for hiding this comment

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

Nit, is this like mostly for prototyping ?

I am wondering if we should name it as LiveKitSandbox ? so that it will be more explicit. And we can use similar approaches for other prototype APIs.

// MARK: - Cache

/// `CachingTokenSource` handles caching of credentials from any other `TokenSource` using configurable store.
public actor CachingTokenSource: TokenSource, Loggable {

Choose a reason for hiding this comment

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

This looks like a TokenManager to me :)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We can try to resolve naming in JS first to avoid back-and-forth 🥲


/// Protocol for abstract store that can persist and retrieve a single cached credential pair.
/// Implement this protocol to create custom store implementations e.g. for Keychain.
public protocol TokenStore: Sendable {

Choose a reason for hiding this comment

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

Are we expecting the advanced users to extend this TokenStore protocol ?

Any reason that a persistent store might not meet all the needs ?

It might just be me, I wonder whyTokenStore is tied to one credential, will it be a valid use case that a token needs to be refreshed since a session life is long ? in that case, we might want to update a tokenStore rather than re-creating a new one ? (it might just make things a bit less error prone for the long term)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Copy link
Contributor

Choose a reason for hiding this comment

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

on an ongoing session tokens are automatically refreshed by the server and sent down to provide support for reconnects.

@pblazej
Copy link
Contributor Author

pblazej commented Sep 30, 2025

@xianshijing-lk thanks for all the great feedback, there's a slightly longer discussion on the JS PR already, it's hard to keep'em in sync: livekit/client-sdk-js#1645

@pblazej pblazej force-pushed the blaze/connection-provider branch from 51915ab to 0c89008 Compare October 2, 2025 08:10
case participantIdentity = "participant_identity"
case participantMetadata = "participant_metadata"
case participantAttributes = "participant_attributes"
case roomConfiguration = "room_configuration"
Copy link
Contributor

Choose a reason for hiding this comment

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

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good point, I still need to move to protobufs for serialization - that's fixed there 👍

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 think I'll finally go for some equivalent of your ProtoConverterTest (that does not exist for Swift yet) vs exposing protobufs.

This needs a separate ticket as the approach is unclear (reflection, etc.)

/// - Configuring recording or streaming options
///
/// - SeeAlso: [Room Configuration Documentation](https://docs.livekit.io/home/get-started/authentication/#room-configuration) for more info.
public let roomConfiguration: RoomConfiguration?
Copy link
Contributor Author

Choose a reason for hiding this comment

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

JS diff: skips agentName/agentMetadata as it's still nested inside RoomConfiguration.agents and can be injected from the upcoming session...

@pblazej pblazej requested a review from xianshijing-lk October 3, 2025 12:20
@pblazej pblazej requested review from davidzhao and xianshijing-lk and removed request for xianshijing-lk October 3, 2025 12:24
# Conflicts:
#	Package.swift
#	[email protected]
#	Tests/LiveKitTestSupport/TokenGenerator.swift
/// - ``EndpointTokenSource``: For custom backend endpoints using LiveKit's JSON format
/// - ``CachingTokenSource``: For caching credentials (or use the `.cached()` extension)
public protocol TokenSourceConfigurable: Sendable {
func fetch(_ options: TokenRequestOptions) async throws -> TokenSourceResponse
Copy link
Contributor Author

Choose a reason for hiding this comment

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

TokenRequestOptions? is also an option here as mentioned above, similarly to ... connectOptions: ConnectOptions? = nil, roomOptions: RoomOptions? = nil

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 at least for the sandbox token server the options would be required?

Copy link
Contributor Author

@pblazej pblazej Oct 8, 2025

Choose a reason for hiding this comment

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

Technically, I don't think so (but it obfuscates the intention)

image

@pblazej pblazej force-pushed the blaze/connection-provider branch from d44e893 to 6feec3e Compare October 7, 2025 08:05
Copy link

@xianshijing-lk xianshijing-lk left a comment

Choose a reason for hiding this comment

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

from a quick look, lgtm

@pblazej
Copy link
Contributor Author

pblazej commented Oct 8, 2025

@hiroshihorie @davidliu as we won't integrate that into the Room (could be internal as well) let's just make sure it's acceptable for agents and move on.

I think Android and Swift are almost identical atm, really easy to compare and follow, left some minor comments on Android.

@xianshijing-lk
Copy link

Is this ready to land ? Please let me know if you need help on the review or ping other reviewers

Thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants