Data tracks UniFFI

[ladvoc]

Summary of changes:

• Exposes data tracks core functionality through livekit-uniffi
  • This will eventually enable the following clients to share the Rust implementation: Swift, Kotlin, React Native, Flutter
• Minor changes to the data tracks crate to support this

Resolves CLT-2472

[pblazej]

Wiring up the Swift SDK — hit two gaps in the binding surface for join/reconnect @ladvoc @1egoman:

Join-time tracks. No join handler on RemoteDataTrackManager, even though the reference SDK runs event_from_join on connect (rtc_session.rs:531) — so a foreign client joining a room with existing data tracks won't see them. Either add a handle_sfu_join, or just feed join.other_participants through the existing handle_sfu_participant_update (what JS effectively does). Identical under the hood — both hit event_from_participant_info. Preference?

Quick-reconnect sync state. No way to build SyncState.publishDataTracks from the bindings. query_tracks() is exposed, but the uniffi DataTrackInfo drops pub_handle, so I can't construct PublishDataTrackResponse client-side the way JS/Rust do (their info carries the handle). Either expose pub_handle on the uniffi DataTrackInfo, or add a publish_responses_for_sync_state() returning the serialized responses (keeps the handle internal — probably cleaner).

Caveats: no released livekit-server (incl. 1.13.2) fills ParticipantInfo.data_tracks in the join, so join discovery isn't verifiable e2e atm — is the SFU side still unreleased?

[ladvoc]

Quick-reconnect sync state. No way to build SyncState.publishDataTracks from the bindings. query_tracks() is exposed, but the uniffi DataTrackInfo drops pub_handle, so I can't construct PublishDataTrackResponse client-side the way JS/Rust do (their info carries the handle). Either expose pub_handle on the uniffi DataTrackInfo, or add a publish_responses_for_sync_state() returning the serialized responses (keeps the handle internal — probably cleaner).

Makes sense, I implemented the latter in 4f18c9c. This replaces the query_tracks method that was previously exported.

[ladvoc]

Join-time tracks. No join handler on RemoteDataTrackManager, even though the reference SDK runs event_from_join on connect (rtc_session.rs:531) — so a foreign client joining a room with existing data tracks won't see them. Either add a handle_sfu_join, or just feed join.other_participants through the existing handle_sfu_participant_update (what JS effectively does). Identical under the hood — both hit event_from_participant_info. Preference?

Rust has these additional helpers to keep the interface between the rest of the client SDK and the data tracks managers as uniform as possible; instead of caring about specific fields in each response type, you hand over the whole response, and the logic of how the required information is extracted is kept as an implementation detail. A few other advantages:

• If the data track managers ever need additional information not extracted from participant info, no update to this interface will be needed.
• Local participant identity isn't needed when handling a join response but it is when handling a participant update; this gets modeled in the signature of each method.

I implemented handle_sfu_join_response in 8abcf90. While these helpers don't add any overhead in the Rust client integration since they accept the responses by reference, in an FFI context, there is additional overhead because the whole response must be serialized rather than just the relevant fields—I'm open to changing this if the additional overhead is a concern.

[ladvoc]

Caveats: no released livekit-server (incl. 1.13.2) fills ParticipantInfo.data_tracks in the join, so join discovery isn't verifiable e2e atm — is the SFU side still unreleased?

Data tracks is fully released in OSS and Cloud now so this would be unexpected. Do you have any repro steps for this?

[pblazej]

Do you have any repro steps for this?

No repro — false alarm on my side. The join does carry data_tracks on 1.13.2; my test was discarding the returned LocalDataTrack (_ = try await publishDataTrack(...)), which unpublishes it on drop, so the track was already gone before the late joiner arrived. Holding it, join-time discovery works. Both handle_sfu_join_response and publish_responses_for_sync_state are wired up and green e2e now.

That RAII-on-drop is really the last open question: should FFI consumers mirror Rust's semantics (drop = unpublish) or go "publication-like" (JS keeps the publication in its manager until an explicit unpublish)? We went publication-like on the Swift side so callers aren't forced to retain the handle — this diff shows it: livekit/client-sdk-swift@3e3043e

Framing it as "what should the convention be" rather than "should Rust change": the core's RAII is correct/idiomatic for Rust consumers — the divergence is about what the FFI bindings present. JS and (now) Swift both land on publication-like, so there's a de-facto convention worth making explicit.

For concreteness, the Swift lifecycle surface:

API	Semantics
publishDataTrack(name:)	publication-like — SDK retains it; discarding the handle does not unpublish
track.unpublish() / await track.waitForUnpublish()	explicit unpublish + await
withDataTrack(name:) { … }	scoped RAII — auto-unpublishes when the block exits

withDataTrack is the compromise: it keeps Rust's RAII where it's genuinely a feature (an explicit lexical scope where auto-cleanup is exactly what you want), while the default publishDataTrack stays publication-like so discarding the handle doesn't surprise-unpublish.

[pblazej]

I don't see any functional gaps here preventing Swift integration

The rest is mostly consumer-side discussion (like the RAII pattern mentioned above).

Before merging please update both SPM_SIZE_LIMIT_BYTES and ANDROID_SIZE_LIMIT_BYTES with the final sizes.

Approximate sizes @ the latest commit:

• SPM_SIZE_LIMIT_BYTES = 1152136
• ANDROID_SIZE_LIMIT_BYTES = 1250710

[pblazej]

@hiroshihorie cc what's your take on applying that in flutter (as the infra is ~complete)?

[ladvoc]

I have temporarily disable Dart tests in CI since they are currently failing. In the interest of getting this merged, we can address in a follow-up PR.