Describe your suggested feature
First of all, thank you for the work you've put into Cloudstream. It has become one of the most flexible and extensible streaming applications available, and one of its greatest strengths is precisely its plugin architecture and active development.
I'd like to propose a feature that, in my opinion, is no longer just a convenience feature, but one of the missing pieces that could significantly increase Cloudstream's long-term value: native synchronization between devices.
Why this matters
Many users today don't use a single device anymore.
A typical user may have:
- an Android phone
- a tablet
- an Android TV
- an emulator
- a secondary phone
Currently, each installation behaves like an isolated application.
Favorites, watch progress, installed repositories, extensions, settings and other personal data remain locked to one device unless the user manually exports and imports backups.
While manual backups are useful, they don't solve the real problem:
Users expect their experience to continue seamlessly regardless of the device they pick up.
Streaming platforms have trained users to expect synchronization by default. Although Cloudstream is a fundamentally different project, the user expectation remains the same.
This is more than cloud backups
I don't believe this feature should simply upload the application's internal folder or database.
Instead, I think Cloudstream could benefit from introducing a stable synchronization layer independent of the application's internal implementation.
Rather than synchronizing internal files, synchronize a logical representation of the user's data.
For example:
- Library
- Favorites
- Watch progress
- History
- Settings
- Installed repositories
- Installed extensions
- Playback preferences
- Subtitle preferences
- User-defined lists
This abstraction layer would become the synchronization contract.
Internally, Cloudstream could continue changing databases, preferences or storage layouts without affecting synchronization compatibility.
As long as the import/export adapter continues generating the same synchronization format, users would not lose compatibility.
This would also make future migrations considerably easier.
A possible architecture
Instead of synchronizing application files:
Cloudstream Data
↓
Export Adapter
↓
Cloudstream Sync Format
↓
Synchronization Backend
↓
Import Adapter
The synchronization format becomes the stable API instead of the internal database.
This approach greatly reduces future maintenance costs.
Three implementation levels
Option 1 — Cloud Backup
The simplest implementation.
Cloudstream exports its synchronization package.
The package is encrypted.
It is uploaded automatically to a cloud provider such as Google Drive.
Other devices periodically check for updates and restore changes.
Advantages:
- relatively small development effort
- no infrastructure to maintain
- easy for most users
- works well as an optional feature
Option 2 — Advanced User Sync
Support generic storage providers through standards such as WebDAV.
This allows synchronization through:
- Nextcloud
- OwnCloud
- Synology NAS
- self-hosted servers
- other compatible providers
Advantages:
- no dependency on a single cloud provider
- privacy-friendly
- attractive for advanced users
- future-proof
Option 3 — Native Cloudstream Sync
The ideal long-term solution.
Instead of uploading complete backups, synchronize only incremental changes.
Example:
User watches episode 18.
Instead of uploading an entire backup, send:
Watch Progress → Episode 18
If another device watches episode 20 before synchronization completes, conflict resolution becomes straightforward.
Advantages:
- minimal bandwidth
- almost instantaneous synchronization
- fewer conflicts
- scalable
- professional user experience
Conflict resolution
Most synchronization problems can be solved through deterministic rules.
Examples:
- Highest watch progress wins.
- Latest settings modification wins.
- Favorites merge automatically.
- Deleted items propagate after confirmation.
These are well understood synchronization strategies already used by many mature applications.
Security
Regardless of the chosen architecture, synchronization should ideally use end-to-end encryption.
User data should remain encrypted before leaving the device.
Whether the storage provider is Google Drive, WebDAV or a future Cloudstream server, the synchronization backend should never need access to plaintext user information.
Development effort
I understand that this is not a small feature.
It would require knowledge in areas such as:
- Kotlin
- Android background workers
- serialization
- synchronization algorithms
- conflict resolution
- encryption
- cloud authentication
- storage abstraction
However, most of this work is isolated from the streaming engine itself.
Once a stable synchronization model exists, future maintenance becomes much simpler because changes inside Cloudstream only require updating the export/import adapter rather than redesigning the synchronization system.
Flexibility
This doesn't necessarily have to become part of the core application.
It could exist as:
- a native Cloudstream feature
- an optional module
- a companion application
- a plugin, if the current architecture allows sufficient access
Any of these approaches would already represent a substantial improvement over manual backups.
A possible long-term benefit
One interesting consequence of introducing a stable synchronization format is that it could eventually become useful beyond the main project.
If synchronization is based on a documented data format rather than internal databases, compatible forks could potentially implement support for it without depending on Cloudstream's internal storage implementation.
That could improve portability across the ecosystem while allowing every project to evolve independently.
Final thoughts
Cloudstream has already solved one of the hardest problems: extensibility.
Adding synchronization would solve one of the last major usability gaps.
This is not merely a convenience feature.
It improves continuity, reduces friction when changing devices, decreases the likelihood of users losing their personal library, and makes Cloudstream feel like a truly modern cross-device application.
I understand this would require planning and development time, but I believe it is the kind of foundational improvement whose value grows over the years. It is the sort of feature users rarely notice once it exists because it simply becomes part of the expected experience—and that is usually the mark of good infrastructure.
Thank you for considering the idea.
Other details
I want to emphasize that this proposal is not intended to suggest a complete implementation must be developed immediately or that the current architecture is insufficient. Cloudstream is already a complex project, and I understand that every new feature introduces maintenance costs and long-term responsibilities.
The main goal of this request is to start a discussion about creating a sustainable synchronization foundation that can grow over time.
A possible approach could begin with a smaller scope:
- A stable export/import synchronization format.
- Manual encrypted backups.
- Basic restoration between devices.
Then, depending on adoption and available development resources, it could evolve into:
- Automatic synchronization.
- Incremental updates.
- Multiple storage providers.
- Advanced conflict resolution.
Starting with the data model and synchronization layer would likely provide the biggest long-term benefit, because it would create a foundation that future features can build upon.
Another potential advantage is reducing recurring user issues related to device changes, reinstallations, migrations and accidental data loss. A reliable synchronization system could reduce support requests while improving the overall user experience.
I also think it would be valuable to consider designing the synchronization format independently from Cloudstream's internal database structure. This would allow future versions to evolve without breaking user backups and could potentially make compatibility with other community-maintained forks easier.
Even if a full synchronization system is not currently feasible, defining the format and architecture first could be a realistic intermediate step toward this goal.
Thank you for considering this suggestion and for continuing to maintain and improve Cloudstream.
Acknowledgements
Describe your suggested feature
First of all, thank you for the work you've put into Cloudstream. It has become one of the most flexible and extensible streaming applications available, and one of its greatest strengths is precisely its plugin architecture and active development.
I'd like to propose a feature that, in my opinion, is no longer just a convenience feature, but one of the missing pieces that could significantly increase Cloudstream's long-term value: native synchronization between devices.
Why this matters
Many users today don't use a single device anymore.
A typical user may have:
Currently, each installation behaves like an isolated application.
Favorites, watch progress, installed repositories, extensions, settings and other personal data remain locked to one device unless the user manually exports and imports backups.
While manual backups are useful, they don't solve the real problem:
Users expect their experience to continue seamlessly regardless of the device they pick up.
Streaming platforms have trained users to expect synchronization by default. Although Cloudstream is a fundamentally different project, the user expectation remains the same.
This is more than cloud backups
I don't believe this feature should simply upload the application's internal folder or database.
Instead, I think Cloudstream could benefit from introducing a stable synchronization layer independent of the application's internal implementation.
Rather than synchronizing internal files, synchronize a logical representation of the user's data.
For example:
This abstraction layer would become the synchronization contract.
Internally, Cloudstream could continue changing databases, preferences or storage layouts without affecting synchronization compatibility.
As long as the import/export adapter continues generating the same synchronization format, users would not lose compatibility.
This would also make future migrations considerably easier.
A possible architecture
Instead of synchronizing application files:
Cloudstream Data
↓
Export Adapter
↓
Cloudstream Sync Format
↓
Synchronization Backend
↓
Import Adapter
The synchronization format becomes the stable API instead of the internal database.
This approach greatly reduces future maintenance costs.
Three implementation levels
Option 1 — Cloud Backup
The simplest implementation.
Cloudstream exports its synchronization package.
The package is encrypted.
It is uploaded automatically to a cloud provider such as Google Drive.
Other devices periodically check for updates and restore changes.
Advantages:
Option 2 — Advanced User Sync
Support generic storage providers through standards such as WebDAV.
This allows synchronization through:
Advantages:
Option 3 — Native Cloudstream Sync
The ideal long-term solution.
Instead of uploading complete backups, synchronize only incremental changes.
Example:
User watches episode 18.
Instead of uploading an entire backup, send:
Watch Progress → Episode 18
If another device watches episode 20 before synchronization completes, conflict resolution becomes straightforward.
Advantages:
Conflict resolution
Most synchronization problems can be solved through deterministic rules.
Examples:
These are well understood synchronization strategies already used by many mature applications.
Security
Regardless of the chosen architecture, synchronization should ideally use end-to-end encryption.
User data should remain encrypted before leaving the device.
Whether the storage provider is Google Drive, WebDAV or a future Cloudstream server, the synchronization backend should never need access to plaintext user information.
Development effort
I understand that this is not a small feature.
It would require knowledge in areas such as:
However, most of this work is isolated from the streaming engine itself.
Once a stable synchronization model exists, future maintenance becomes much simpler because changes inside Cloudstream only require updating the export/import adapter rather than redesigning the synchronization system.
Flexibility
This doesn't necessarily have to become part of the core application.
It could exist as:
Any of these approaches would already represent a substantial improvement over manual backups.
A possible long-term benefit
One interesting consequence of introducing a stable synchronization format is that it could eventually become useful beyond the main project.
If synchronization is based on a documented data format rather than internal databases, compatible forks could potentially implement support for it without depending on Cloudstream's internal storage implementation.
That could improve portability across the ecosystem while allowing every project to evolve independently.
Final thoughts
Cloudstream has already solved one of the hardest problems: extensibility.
Adding synchronization would solve one of the last major usability gaps.
This is not merely a convenience feature.
It improves continuity, reduces friction when changing devices, decreases the likelihood of users losing their personal library, and makes Cloudstream feel like a truly modern cross-device application.
I understand this would require planning and development time, but I believe it is the kind of foundational improvement whose value grows over the years. It is the sort of feature users rarely notice once it exists because it simply becomes part of the expected experience—and that is usually the mark of good infrastructure.
Thank you for considering the idea.
Other details
I want to emphasize that this proposal is not intended to suggest a complete implementation must be developed immediately or that the current architecture is insufficient. Cloudstream is already a complex project, and I understand that every new feature introduces maintenance costs and long-term responsibilities.
The main goal of this request is to start a discussion about creating a sustainable synchronization foundation that can grow over time.
A possible approach could begin with a smaller scope:
Then, depending on adoption and available development resources, it could evolve into:
Starting with the data model and synchronization layer would likely provide the biggest long-term benefit, because it would create a foundation that future features can build upon.
Another potential advantage is reducing recurring user issues related to device changes, reinstallations, migrations and accidental data loss. A reliable synchronization system could reduce support requests while improving the overall user experience.
I also think it would be valuable to consider designing the synchronization format independently from Cloudstream's internal database structure. This would allow future versions to evolve without breaking user backups and could potentially make compatibility with other community-maintained forks easier.
Even if a full synchronization system is not currently feasible, defining the format and architecture first could be a realistic intermediate step toward this goal.
Thank you for considering this suggestion and for continuing to maintain and improve Cloudstream.
Acknowledgements