Project change of direction.

[mlopezsegura]

A change in the project's direction. Good evening to everyone following the program's development. To continue with its development, I have to make a fundamental decision regarding the program: we can no longer include either TermWrapper or RdpWrapper within it.

You might be wondering why. Simply put, a program like this does not comply with the Windows EULA. To distribute it, I can only offer the software without TermWrapper. At first glance, this may seem like a dramatic change—as the program will stop working on Windows Pro and Home editions—but "if the community distributes those packages, there is no problem."

There are also major changes coming regarding devices, as well as some surprises concerning network adapters—plus better isolation for Steam.

https://discord.gg/uAu9WWqzw

[Dani6ca-T]

Hi!

First of all, thank you for the update and for being transparent about the project's new direction. I understand the reasons behind the decision regarding TermWrapper and RdpWrapper, and I think moving towards a more modular architecture could open up some interesting possibilities.

I'd like to suggest a few ideas that could make OpenStreamMultiSeat even more versatile.

1. Streaming Host Manager — Vibeshine / Vibepollo integration

Would it be possible to introduce a dedicated Streaming Host Manager directly into the web dashboard?

For example, allow users to install, update, switch between, or uninstall alternative streaming hosts:

• [Vibeshine](https://github.com/Nonary/vibeshine) — based on Sunshine.
• [Vibepollo](https://github.com/Nonary/Vibepollo) — based on Apollo.

Ideally, the application would automatically detect whether either of these projects is already installed on the system.

Users could then manage their preferred streaming host directly from OpenStreamMultiSeat without having to manually download, install, replace binaries, or reconfigure everything.

Some possible features:

• Automatic detection of installed streaming hosts and their versions.
• Installation and updates from official upstream releases.
• Switching between compatible hosts.
• Configuration and paired-client preservation when switching.
• Backup and rollback in case an update or migration fails.
• Detection of service, process, port and configuration conflicts.

I believe this could be particularly useful because Vibeshine and Vibepollo offer interesting improvements in virtual display management, Windows Graphics Capture, GPU selection and display recovery.

Of course, this should be implemented through a compatibility layer or host provider architecture rather than tightly coupling their source code to OpenStreamMultiSeat.

2. Network Adapter Management

Since you mentioned upcoming improvements related to network adapters, perhaps it would be useful to eventually provide:

• Selecting a specific network adapter for a streaming session.
• Binding sessions to specific local IP addresses.
• Network connection diagnostics.
• Per-session network status and monitoring.
• Automatic detection of port and firewall conflicts.

3. Device Profiles

A profile system could simplify hardware configuration for different scenarios:

• Gaming — optimized for streaming performance.
• Desktop — regular remote desktop usage.
• Multi-seat — multiple independent users.
• Virtual Display — automated virtual monitor management.
• Hybrid GPU — selecting the appropriate GPU for capture and encoding.

4. Improved Steam and Application Isolation

Your plans for better Steam isolation sound very promising. It might also be worth considering independent Steam configurations, persistent authentication, game settings and process management for each session.

5. Community Components Manager

Following the decision to separate TermWrapper/RdpWrapper from the main distribution, perhaps a dedicated component manager could be useful.

It could detect missing dependencies, check compatibility, provide links to trusted community-maintained packages, verify checksums and digital signatures, and help users install or update optional components.

The important part would be keeping these components separate from the main application distribution and making their source and installation requirements transparent.

---

I realize that these ideas would require additional development and shouldn't necessarily be priorities for the next release.

Personally, I think the Streaming Host Manager would be particularly valuable. It could make OpenStreamMultiSeat a unified management platform rather than tying users to a single streaming host implementation.

I'd be interested to hear your thoughts on whether something like this would fit your vision for the project.

I'd also be happy to help with testing, feedback, and potentially contributing to some of these improvements.

Thanks again for your work!