Skill marketplace

[Stypox]

Dicio should be able to download skills from a marketplace where users can upload their own skills, whose development would be separated from Dicio, such as Mycroft Marketplace. A skill would be packaged as a compiled java file (i.e. a jar file) and then loaded at runtime by Dicio, to ensure the best performance. An alternative to this would be to have users install an app for each skill, and then sending Android intents around to communicate with skills: this is the approach taken by Athena, but I don't think it would work out well for Dicio since skills would then be unable to natively show graphical output to the user.
I will not focus on creating a skill marketplace right now, since Dicio is in a pretty early stage and still requires a lot of work. When (if) it will become more popular, and more people will start creating skills, creating a skill marketplace will become important. I opened this issue to illustrate my plans for the future ;-)

[dp0s]

Hey Stypox,
thanks for starting this discussion.
For now, I would prefer to create my own skills (rather than waiting for a market place).
I like the idea of creating a custom command (e.g. "call xyz") and then trigger a self-defined intent to another app. This would give me full flexibility.

What do you mean by the following? What kind of graphical output?

but I don't think it would work out well for Dicio since skills would then be unable to natively show graphical output to the user.

[Stypox]

For example, the weather skill shows a good-looking ui with the current weather. But it would difficult to share such (layout) information between apps using Android intents.

[dp0s]

OK, I see. Myself, I am more interested in launching other apps or activities by voice than displaying information.

Btw: thanks for creating this app and for publishing it on F-Droid! It's the only good voice assistent app on F-Droid that I have seen so far.

[Stypox]

Thanks! Also take a look at #40

[RokeJulianLockhart]

Why not allow skills to be provided as APK files, so that they are possible to install via F-Droid?

"http://github.com/tachiyomiorg/tachiyomi" does this, and the experience of installing potentially 15 addons that are for it is consequently significantly superior to what it is alternatively able to be.

[Stypox]

As I explained in the issue description, I think separate APKs would not be a good solution because it would be complicated (if not impossible) to pass graphical output between apps

[xxxserxxx]

While I don't voluntarily program in Java any longer, I'd help with writing the marketplace server component. Most of the effort here is in Dicio, but have you had any thoughts on the market protocol, or were you thinking about copying the MyCroft site?

I love this idea, by the way. I was originally searching the issues to see if there was a wiki for user-contributed skills; a sort of "awesome-dicio-skills" page, or something. A marketplace would be more accessible, for sure.

[Stypox]

@xxxserxxx So far I thought about two options to install skills on the users' phones:

• use a dynamically loaded Java class for the skill:

  • PRO: small disk usage, since the skill does not have to replicate the whole dicio-skill framework but can rely on classes available for import
  • PRO: simple to add skills to the market, a pull request to a specific repository handled by us would be enough (though in the future we might want to support a decentralized markets)
  • PRO: skills downloaded from the store would be able to interact with Dicio just like pre-installed skills, so for example they can provide specific actions with custom graphical output, ...
  • PRO: users would be able to install skills from within Dicio
  • CON: security problems if not done properly
  • CON: having to continuously handle skill addition and updates ourselves, adding more work for Dicio maintainers

• let the user download app-skills from F-Droid or other stores and have those apps communicate with Dicio using intents (for example, see AnySoftKeyboard's languages):

  • PRO: this is a common pattern in Android and is likely to work without security issues or other problems
  • PRO: anyone would be able to publish a skill for Dicio (and possibly just ship it side-by-side with another app, to let people interact with such app using Dicio)
  • CON: with Android intents, only simple things can be communicated between Dicio, so fancy UIs and actions would not be possible
  • CON: intents are slow and asynchronous, which would probably slow down the utterance-matching-and-scoring part and the startup time of Dicio
  • CON: requires much more work, since we need to define how the app-skills would interact with Dicio
  • CON: users would need to install one app for each skill they wish to add to Dicio, which some people might not want

As you can see from the number of pros and cons, I prefer the first option, but we need to handle the security problems properly. Let me know what you think of this.

Regarging the web interface, I think a static webpage hosted on GitHub Pages would be fine. That interface would just load the skills to show from the repository of skills I talked about above (which would also be a simple skill on GitHub).

If you want to help with any of this you are welcome! Sorry for answering so late, I focused on other projects in the last few months.

[Stypox]

@Doomsdayrs said in #96 to have a look at how Tachiyomi is able to install extensions using APKs, and then run Java/Kotlin code from them. I need to have a deep look into how it works, and see whether the installed APKs have the same CONs as the second option above, or maybe there are some Android APIs I did not know about for running Java code from another app.

[xxxserxxx]

There's an implicit CON in the first approach: you (the Dicio maintainers) make yourself a bottleneck for new extensions. It will add load and effort for you, and distract you from other efforts. It's a Cathedral approach, rather than a Bazaar approach. Whether this is a heavy lift or not, that's for you to decide. I'm however reminded of F-Droid, where new applications can take weeks, and version updates to take days, to make it out to users simply because of resource constraints.

If you decide the lift isn't too heavy, I too prefer the first approach. It allows some control: if a source is a known bad-actor, it can be removed from the market. It's more friendly to casual users (in-app extension always is); AnySoft can be a bit confusing until you figure out what's going on and how you're supposed to install things, and which bits are needed.

[Doomsdayrs]

Tachiyomi style extensions can work, Loading the interface implementation from another APK can work, and it seems that compose also works through Interfaces.