Blog /Majel 2.0: Planning & Experimentation

May 11, 2021 23:51 +0100  |  Free Software Majel 0

I'm going to try to do a better job of recording my development process here, and to that end, I wanna talk about my latest Big Shiny Idea.

My Majel project was mostly well-received, but the most common piece of feedback I got was how hard it was to install. The dependency on Mycroft really kicked the project in the nuts because Mycroft isn't really user-friendly and the company behind it doesn't appear to be prioritising that aspect because they intend to make their money selling physical devices.

On top of that, Mycroft isn't exactly ideal for this sort of thing, since it's operating on the same premise as Alexa & Google Home: it's actively listening for commands which means there's a constant battle between being able to hear said commands and you know, playing music. I'm just tired of saying "Hey Mycroft... HEY MYCROFT" and getting nothing because it can't tell the difference between my voice and the one on the tv.

So I have a new plan, with a new architecture, and dreams of usability. Fun stuff!

At the moment in my head there are at least 3 components: the "orchestrator", the cloud service, and the remote.

The Orchestrator

This is basically what Majel already is, but I'm going to refactor it to leverage pyautogui and control your whole desktop rather than just your browser.

The Remote

No more yelling at the screen. You have an app on your phone consisting of a two buttons: listen and stop, along with the possibility of a few presets you use often. These buttons send messages to the orchestrator to tell it what to do.

There's no reason this has to be just a mobile app though. It can be a tap on your watch, or an IOT button if you like.

The Cloud Service

Unfortunately, after a lot of digging, I've found that there's no (easy) way that you can have a web app or mobile app talk to an unencrypted websocket. There's restrictions built into most platforms that block that sort of thing, so you have to encrypt the traffic, and the easiest way for non-nerds to do that is to use a 3rd-party service. This is that service: a dumb relay between remotes and orchestrators that itself cannot impersonate a remote (for obvious security reasons). This cloud service could be self-hosted of course, but for new users, or people who just don't care about that sort of thing, remotes & orchestrators will connect to

So that's the idea. I'm still in the planning phase, but I've got a lot of energy behind me on this for the moment. We'll have to see where that leads. For now, here's the diagram I worked out tonight:


Post a Comment of Your Own

Markdown will work here, if you're into that sort of thing.