SyncPlay 2.0

[TimGels]

Moving this discussion from Matrix to GitHub Discussions in this Meta repository.

---

As you might know, the current state of SyncPlay is considered sub-optimal by the majority of the team members. This is in terms of complexity in maintainability and the complexity in implementing it for a client. It has been a point of discussion for a long time now and it is time to get discussions about it written down in the proper place, in Jellyfin Meta!

To get started, the following bullet points have been constructed from the discussion over at Matrix. But they should be treated as a starting point of this discussion. They can, and will change. I encourage everyone to share their thoughts, ideas and concerns in this discussion.

Current bullet points gathered from the Matrix discussion:

• Latency should be low. Preferably at maximum in the low sub hundred(s) milliseconds. This, due to SyncPlay often being used with VoIP between people.

Server

• A more simple API for clients to implement, making it less error prone and difficult to implement.
• Implemented in Web as a plugin to keep the logic separated as much as possible from the inner logic of web.

Web

• Should be able to cope with high latency between users.
• Should be able to cope with some delayed events due to bandwidth constraints.

Please try to keep things on-topic and constructive.

[PeachesMLG]

As far as the backend is concerned Id say the Controller code is fairly simple.

I think the only thing we may want to potentially look into is merging the Playstate and SyncPlay controllers into one api since they are fairly similar.

What would the benifits be for making this a plugin in the frontend?
You can still have the code logic seperated from the main player without making it a plugin no?

[ferferga]

My 2 cents here, I'm also investigating on how to modularize a frontend application (at least in jellyfin-vue land), but I believe this should not be pluginized:

• It's core in server
• As you say, belonging to all the playback stuff, its fairly easy for consumers to plug in already.
• As with all endpoints, being available doesn't mean it must be used, that's up to the client developer and I don't see the incompatibility there...

[thornbill]

All playback related functionality in web is plugin based. This would make syncplay follow the same general logic as every other type of playback and allows a replacement to be developed while the current implementation still exists.

We really should consider renaming web plugins... they aren't at all similar to server plugins and it's just a source of confusion for anyone that isn't deeply familiar with web. 😅

[nielsvanvelzen]

From a client perspective with almost no knowledge about the current SyncPlay implementation:

• There is no way to get notified about new SyncPlay rooms being created via WebSockets
• Except for the "list" endpoint, none of the SyncPlay API's return data
  • When I create a room, it doesn't return the room info so I have no idea what id the room has
  • When I join a room, it does not return the (updated) room info
• All API operations for syncplay have weird names
• SyncPlay does not allow multiple sessions, I'd expect some token to be returned when I create/join a room that I need to supply for each manipulation
• When a room changes in SyncPlay, it does not send that data over the WebSocket connection. Instead of just says "type=UserJoined" and you need to query all freaking rooms via the list endpoint to get the info for the user that joined
• There is no way to rename a SyncPlay room after it has been created
• The player controls should be send over the PlayState API instead of the SyncPlay API (unify both)
• There is no endpoint to get the information for a single SyncPlay group

Hopefully these (brief) observations can help with the redesign.