Add support for official Addons Store

[patrickgold]

Feature idea

This is a direct preparation for the upcoming official Addons Store, which in the future will be the main hub for official and community created themes, layouts, language packs, etc.

As FlorisBoard is a privacy-focused keyboard and we thus cannot add the NETWROK permission to the app, we have to get creative on how to easily install stuff from the Addons Store. Thus the idea is to display and manage the Addons Store as a website inside the user's browser, and when the user wants to install a new addon, they can simply download the extension file and then open it, which will trigger FlorisBoard's file handler defined in the Manifest and redirect this to the extension import screen.

• Add file import handler for .flex files
• Add share import handler for .flex files
• Add user-readable error messages for common errors
• Add measures to protect the integrity of the app
  • Prevent ZIP bomb attacks
  • Prevent large file size attacks
  • Prevent file/path name max length attacks
  • Prevent relative parent path expansion overwrite attacks (e.g. $zip/../../files/prefs.json)
  • ... more? ...
• Add support for installation/update status detection from within the Addons Store UI
• Add UI for managing installed addons easily within the app UI

Important is that the Addons Store never has direct control, it can just suggest to install/update an extension, the final decision is done by the user from within the import handler app UI. Removal of addons MUST be done from within the app UI.

Initial goal is that theme extensions are supported, later on also keyboard extensions. With v0.5 support for language packs will be added.

In parallel to this efforts the Addons Store itself with be publicly beta-tested by @4H1R, who kindly offered his expertise writing the Addons Store for this project too. This issue is intended to stay open for a few PRs and beta releases.

Any feedback/idea proposals for this are highly appreciated, just comment down below!

[TPS]

Would this include (existing & new) languages/layouts, also? That'd help keep the APK free from stuff a paticular user may not use.

Also, this might need some tuning to not run afoul of F-Droid rules, since these addons aren't themselves being published there as APKs. Maybe reach out to current F-Droid repo folks? (Sorry, I don't have their GitHub handles handy, else I'd do it here myself.)

[patrickgold]

Would this include (existing & new) languages/layouts, also? That'd help keep the APK free from stuff a paticular user may not use.

Yes, the addons store is a mix of community and official content and in the future new languages and layouts will be added this way. Some important languages and fallback layouts will always be present in the APK though, also for now some languages that require custom logic not representable yet with json/xml files or plugins (e.g. Chinese, etc.)

Also, this might need some tuning to not run afoul of F-Droid rules, since these addons aren't themselves being published there as APKs. Maybe reach out to current F-Droid repo folks?

That's a good point actually, thanks for pointing this out. In essence addons in the way FlorisBoard plans to support them are exclusively json/xml/dictionary files that are parsed and NEVER exectuable code or script files, so it shouldn't be an issue, especially because for themes the manual import mechanism that works the same as the addons but less convenient is already present in the current F-Droid version. But I will still reach out to them on GitLab or their discussion forum just to make sure.

[Glitchy-Tozier]

Interesting idea! I see, you've stuck with .flex ;)

I've been wondering about how to let users know there's an update to their installed addons. It seems difficult to do since Florisboard cannot (and should not) access the internet. What could be done, however, are the following:

1. When opening the store from a link generated within Florisboard, add installed package-IDs and their versions as URL-parameters. The store could then read those and suggest updates where necessary. This option works well when manually opening the store.
2. To "automatically" get notified of updates, we could include a list of the store's current packages' names and versions in the apk on every new release of Florisboard. Then, Florisboard could compare that list to the installed addons' versions. If the installed version numbers are older than what is shown in the list, suggest an update to the user. This nicely synergizes with the first idea (pass out-of-date packages as parameters).
   • Of course, if there's >thousands of addons, such a list could become too big. Thus, I suggest listing the X most recently updated packages instead of all of them.

[patrickgold]

There's an additional way this can be done without FlorisBoard accessing the internet:

FlorisBoard could expose its own uri scheme, lets use fladdons:// as an example. With this, the addons store can then query e.g. fladdons://list?installed and retrieve this list in the body response in the format addonid:version. Same goes for just querying a single addon if its installed and which version. I am not sure though if I will do it this way, your idea sounds also intriguing but could have its own problems in the future.

Regarding your second point, I dislike linking FlorisBoard releases to addons versions, I don't know that just does not sound like a clean solution to me.

Also some additional thought must go into how we handle the fact that there may be both FlorisBoard and FlorisBoard Beta present on a system?

[TPS]

Also some additional thought must go into how we handle the fact that there may be both FlorisBoard and FlorisBoard Beta present on a system?

In parallel to that, handling release/beta/nightly/canary/whatever versions of the addons themselves?

[Turhvjbufv]

Not sure if that is an obvious idea
but please make it so that addons that wants to be on the addon store must be open source