POC: Companion 'Cloud' 2.0

[Julusian]

Input is wanted, on whether this is a feature worth having, and whether the rough architecture proposed here is good.
Do not read into the code, and do not critique the UI at this stage.

This is a largely vibe coded implementation of a potential new direction for Companion Cloud.
At this stage I am trying to decide if this is a good direction/architecture and is worth spending more time on. It was an evening of prompting, so I don't mind at all if this gets thrown away as not worthwhile

The long story is that Companion Cloud is deprecated because Bitfocus do not wish to continue with it. Reasons on that are unclear, and not our concern. Some users do utilise and rely on it, and there isn't really a good substitute flow for it. Parts of it can be replaced by satellite, but it has limitations.

I realised that the cloud service is essentially an event bus, used to allow multiple Companions to talk without needing direct connections. So I took that and realised there are a bunch of of the shelf solutions/brokers that could be used to replace that.
By doing that, we allow more flexibility in how this is deployed, and it means that the Companion project doesn't need to host anything for this to be usable.

The design is for there to be a common protocol that can be used over many different transports.
For this POC, I started with a mqtt transport, as there are many off the shelf servers that can be run yourself and setup with tls and basic auth. (I am running mosquitto in docker for testing this)
The final implementation of this should have more transports, and I expect the list will grow over time as users request them.
The intention is that each companion can be setup with multiple transports. each one will be a single 'connection', and companion will eventually talk to each other over multiple to get redundancy.

Because of this bring-your-own-infastructure approach, I am not intending for any form of security within the protocol. Any security should be applied at the transport level (eg user+pass or api key for connecting to the broker).
Although it may be that companion wants to have some access rules to limit how much they expose to link or potentially to a transport. (eg so a peer can be readonly to one mqtt server, but rw to another)

The aim here is to pipe rendered buttons over this link, and push/rotate events back.
This is done in a subscription approach, to minimise the amount of data companion is sending (reducing cost both on companion and the broker).
I also think it would be good to be able to pipe variables over this, but that doesnt feel like MVP.

Instead of implementing the client as a module and being subject to the limitations that imposes, this is done with a new control type. That means that the user doesn't need to deal with adding multiple actions and a feedback to truely mirror a remote button, instead we can handle all that for them, and handle issues they would have encountered with long presses.
Q) How does this behave if using the 'use another buttons style' on one of these buttons?

At this stage, I can say that it kinda works. Its easy to break it, the code is garbage and the ui does not match the style of anything else. But it gives an idea of a new approach that could be taken

Name of 'link' is TBD, but I think makes sense as we are 'linking' companion installations.

Idea for future transports:

• Direct connection? (a dedicated listener port on each companion, for simple flat
• aws iot core
• rabbitmq?
• ably
• webrtc?
  some thought probably needs to go into the protocol (particularly around how failover between transports happens) to ensure it is truely modular

[coderabbitai]

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[socket-security]

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	mqtt@​5.15.0

View full report