To be honest this is completely the wrong way round if you look at the skill spam of Mycroft unless you are looking at this a different way. Due to qty there is no need to test as the complexity without a docker manager would be quite huge as well as overhead never mind just disk space.
Suppose you could all layer from a base but wow such a divergence from what Rhasspy is.
There is a reason its called R-Hass-Py because it choose a really good distributed model and if by skills you mean other application intent json processors so that the likes of Hassio, Mopidity, Kodi, Snapcast, Almond, Magicmirror as these are all examples of polished skills that become so proficient they are termed applications.
Really skills shouldn’t be Rhasspy specific as in this great and varied world of opensource there is a huge collection of software that need a interoperable intent api that the HMI of voice.ai of many can control and share.
Many of those applications already have MQTT & security methods that are backed by OS security and can reside in containers of many forms or other server instances.
As in skills do you mean the intent recognition and processing that all is needed for rhasspy to be a voice.ai HMI?
As yes it might be good to have a repo collection of intent recognition and process templates for common applications but that doesn’t need docker.
If you where thinking about docker installs of those applications that is really the remit of those applications.
Whatever you do don’t make Rhasspy a garbage can of spammed and poorly implemeneted skills that Mycroft frequently is.
To make it worse there is no need for rhasspy skill processing as voice.ai is a HMI!
With skills I mean whats commonly referred to as a skill in these voice applications. So any apllication that responds to the recogniced intent from the NLU. Whether thats implemented in a Docker Container, AppDaemon, HomeAssistant, directly on a microcontroller …
Well skills are always Rhasspy specific to the extend that they use Rhasspys methods. E.g. when using MQTT thats hermes, but all the skills are compatible with any other system that uses Hermes. However thats nothing docker has any influence on. So when someone wants to implement his component in a different system that he thinks is secure enough for him then there is no issue in doing so. E.g. with @koan idea of using AppDaemon this does not mean that from this point everyone is forced to use AppDaemon and write Python. For me having skills running directly on the host without anything stopping them from doing bad things is simply nothing I am fine with on my own device
Essentially docker is simply using these OS security features to achieve their containerisation + cgroups for resource accounting and limiting. So they simply provide a way to make use of these features in a simple way (With podman even without root priviledges).
I was mostly talking about something like a official skill store since @Vandaag brought up that skills should be read before they become official and I wanted to show that even with them stuff can go wrong and so security measurements still make sence. I am not really sure whether a skill store really makes much sence for Rhasspy given the big variety of ways skills are written, so I suppose it could be something like an awesome skill list. However my security concerns do not get smaller when isntalling things from an awesome skill list, since nobody maintaining such a list will do a security audit after each commit on a skill the list references. So docker is simply another way to deploy skills in a more secure way. People do not even need to write a docker container for this, since a Dockerfile for a python script is only a couple of lines, that can most likely be automatically generated anyways.
I am not sure whether I agree on this. I agree that in my opinion most skills written are useless spam. However looking at some of the top rated skills for Alexa I would personally call most of them spam aswell and yet apparently there are people using them. So while poorly implemented skills
are always bad, useless skills are something very opinionated.
I am not quite sure what you mean with skill processing, since Rhasspy basically sends out the intents over MQTT and so anyone can do with them whatever he wants. One of these things is using them in a skill that happens to be placed inside a docker containers
Its very simple you only need to look at the vast qty of skills available for that style of jumble sale offering to envisage what a container for each would be.
You don’t need a skill for that just MQTT to app and from app of intent or return message.
That is like saying your computer is keyboard specific because they use a keyboard. Rhasspy is a HMI nothing more!
Skill stores are from the likes of Amazon and Google to control and marketise a product and completely unnessacary and create overhead of skill store administration and control.
There are many applications missing a quality intent MQTT interface that would be a great addition to Rhasspy use they are however application MQTT interfaces that belong with the application.
It doesn’t need an awesome skill list as a simple collection of text transcriptions and the only return to rhasspy ever needed is a STT message.
Exactly its already all enabled and why do we need what you suggest.
It will do exactly the same and just bring in a raft of skills of verying quality and replication that places the onus on someone/org to control and administer.
There is a lack of applications with high quality MQTT interfaces and processes that have needs so entwined with the application they are part of the application not Rhasspy.
Googling for qty skills brought be up books to learn languages, so I really have no clue
I use skill as a short synonym for app that receives a mqtt message and returns a return message via mqtt in this context
My computer is not keyboard specific, but each keyboard has to use one of the interfaces my computer provides like e.g. USB with a specific protocol. In the same way each skill (synonym above) has to use one of the interfaces Rhasspy provides, which is e.g. MQTT with the hermes protocoll (there are others aswell)
I am talking about a simple list where someone writes down about skills he likes nothing fancy. Just so people that unlike you would like to use skills others create have a chance to see whats out there. This is not necessarily done by Rhasspy itself, but I am sure someone will create it and has absolutely nothing to do with the way a skill/whatever reacts to intents. Not quite sure what the STT should ever have to do with skills
Well I am talking about me wanting to run them in a docker container so I can ensure they do nothing stupid. Why do people develop Rhasspy in general? I suppose most simply because it is fun to them. So when there is someone who wants to create a awesome skill list thats his thing. Just because there is a list does not mean that you can not still create all the skills you need on your own
If so then that is a standalone MQTT app that has no requirements for Rhasspy and is how it should be.
TTS (not STT) by dumb ass dsylexia in full blown motion, return mesages using the voice HMI of a voice.ai.
So your talking about simple lists that need docker?
There is no need for “Secure architecture for Rhasspy apps” as there is no need for Rhasspy specific apps in terms of skills.
The first sentance of the OP is
“One thing I would generally love is having only restricted permissions for each skill.”
If you don’t see a need for Rhasspy specific apps, feel free to discuss about this in another topic. In this topic I’d like to explore the possibility to create such an architecture for people who do need these apps. Ok?
You want me to create a topic to discuss a feature in rhasspy that I don’t think is needed or should be introduced?! Rather than discuss that its not needed in the OP for its request?!
A poilte call for censorship I guess of opinion which is not Ok, but hey do whatever you wish that you have already decided.
So, to help you I created this topic. We can discuss here the need (or no need) for Rhasspy specific apps, so we can keep the discussion here and the discussion about securing Rhasspy apps in the other topic clean, because those are two separate topics.
