Planning Board for the Community Repo

[patrickgold]

Hey everyone!

This discussion thread handles the idea of the long-planned Community Repo/Store/Addon Place/Whatever it will be called.

Normally this idea would not be on the plate today, however Ali aka. 4H1R, a developer with experience in web development, has kindly offered to work on this separate project (thanks a lot!), as such the community repo idea gains traction now.

Currently nothing is developed and we are still in the planning phase, so we thought now is the time to gather ideas/initial feedback for the idea from the community. Any kind of feedback is welcome, be it new ideas for the community repo, feedback on the plan or criticism.

The Name

One of the most unsure things for this concept is the name. Suggestions are highly welcome here. For now (and in the announcement below) we will use the temporary name "Community Repo" until we find a good one.

The Idea/Concept

The main idea of the Community Repo is to have a unified place where the community can post their theme creations, custom keyboard layouts, extensions, dictionaries and so on. A place we took inspiration from is the Firefox Addons Page, which bundles all kind of community-created content for the Firefox browser and at least in my opinion is a really cool concept.

The currently planned initial features/concepts are as follows:

• Primary focus is extensions
  • Each extension has their own page with screenshots, description, meta data information (like homepage, issue tracker, donation link, etc.)
  • Extensions can be bundled into collections (private/public)
  • Extensions can be reviewed with a 1-5 star system and comment
  • Extensions can be tagged/categorized for easier discovery
  • Extensions/Reviews can be reported (in case of spam/inappropriate content), which will trigger admin intervention
• Download system
  • Each extension has a release history and each release offers a flex file for download
  • Each release carries meta data info like version number and license (as the license could change with a new version)
  • Each release has a simple download count
  • To complete this feature the core app needs a more robust import system and should be a file handler for .flex files, which allows that FlorisBoard opens if the user clicks "Open file" in the browser after download
• Global search for extensions, global landing page
• Accounts
  • For starters a simple email/password account
  • Allows to perform actions such as collection creation, reviewing
  • If set to developer also allows to publish extensions
  • Currently undecided is how we should verify extensions and how we combat bot submissions, should this pose a problem a stricter verification system needs to be put in place
• A recommended system to feature extraordinary extensions

As theme extensions are the most stable ones these will be the first ones to be supported, other categories will follow as the development of extensions stabilizes in the core project.

Server/Storage hosting + estimated costs

We currently plan to use the following server/storage options as those are relatively cheap for the expected initial workload:

• DigitalOcean's Droplets for the vcloud server:
  • Regular/1GB option for 6$/month at first
  • Regular/2GB option for 12$/month if the above option is too weak
• DigitalOcean's Spaces for file storage/CDN (5$/month initially)
  • Here we can theoretically use any provider as long as they are S3-compatible
• Domain: Here we will use a subdomain of the already existing florisboard.org domain, which costs 1$/month

For starters the above selected plans should be more than enough and if we manage to exceed those plan's limits it probably means this project has grown a lot. To fund these recurring costs I'll use the donations I received from quite a few of you in the past and also in the future.

Technical details

This section is only relevant if you have understanding of databases. Below is the draft for the initial SQL database layout:

The separated "media" table is the bridge for the file storage.

[Kasi07]

Based on the AUR, I'd suggest the name Florisbord User Repository, or perhaps Store (FUR/FUS for short). The latter could be pronounced like Fuzz.

[patrickgold]

It is an interesting name, however as suggested in another comment thread it is a very technical term and the target audience is more broad than just technical users, so a name in the direction of "FlorisBoard AddOns" would probably be more favorable.

[mschiff]

I personally find "Repo" in the name to be a too technical term. As this thing is also supposed to be for non-tech people (aka users) I would suggest something like

• Florisboard AddOns
• Florisboard Store
• Florisboard AddOn Store
• Florisboard Extensions
• Florisboard Contributions
• Florisboard Contrib Store

Possibly "User" can be added to any of these

[patrickgold]

Thanks for your name suggestions!

Personally I am currently leaning towards FlorisBoard AddOns, as it is a general term for additional stuff for FlorisBoard that isn't used within the app.

As for the term "repo", I agree that it is a very technical term. Coming from the Linux/CS world I am heavily used to that term, but I agree that the store should be for general users so it isn't a good fit.

[M00NJ]

"Florisstore" is my suggestion.

[itsmartashub]

Lmao, I meant the same, just Floristore, without the second S.
Also like @mschiff's Florisboard AddOns. Simple, straightforward, professional. It clearly indicates that it's a place for additional features.

[patrickgold]

Floristore is an interesting combination but its hard to mentally process while writing the word that one s is missing haha.

FlorisBoard AddOns would be a good name as the term "Addon" isn't used anywhere else in the app and thus is a general term for additional stuff for FlorisBoard.

[Fezuks]

Hello! Have you already decided which technologies will be used in developement?

[4H1R]

Hi
Yes for the backend we're gonna use Laravel.
The API is gonna have documentation so the community can create their own design/frontend if they want.

For the frontend we're gonna use Nextjs + Tailwindcss

Contributions are welcome as always

[Fezuks]

Okay, thanks!

[Waelwindows]

I think it's important that we rethink how we do the backend. Specifically, whether we need one in the first place.

Many of the features proposed don't require a backend or can be easily retrofitted in such a way. For example, the extension review and commenting system could probably be moved over to something like giscus with GitHub Discussions. We could statically host some machine-readable format such as JSON to describe the extensions in a way that can be queried by the site and so on.

Example extension structure (bikesheddable)

├── dictionaries
└── themes
    ├── another-awesome-theme
    └── my-awesome-theme
        ├── extension.json
        ├── image01.webp
        ├── my-awesome-theme-v0-1-0.flex
        └── my-awesome-theme-v0-1-1.flex

Note how the extension id is its folder's name now.

Extension schema (bikesheddable)

{
	"name": "My Awesome Theme",
	"type": "theme"
	"authors": ["waelwindows",],
	"categories": ["retro", "noir", "material-aware"]
	"description": "A cool retro noir theme that's Material You aware."
	"license": "Apache-2.0 OR MIT" // SPDX license identifier
	"contact-details": {
		"home-page": "https://example.com/awesome-theme",
		"source": "https://github.com/waelwindows/awesome-theme",
		"support": {
			"website": "https://example.com",
			"email": "[email protected]",
			"matrix": "@wael:example.com"
		}
	},
	"releases": {
		"0.1.0": { "date": "2023-11-25T16+00:00" }
		"0.1.1": { "date": "2023-11-25T16+00:00" }
	}
}

Why should we consider this? For one, its easier for us to use existing and open technologies than rolling our own, especially considering the project's goals. It promotes openness and helps with user trust as users would much rather trust a publicly available file rather than an opaque server. If we use a git repo for the addon repository it also makes adding extensions much easier to audit in that users must make a PR which the moderators can check first. This will also help with cost as we wouldn't have to host a server for the static files.

We must also rethink whether we want to store user data as that would mean we'd have to comply with GDPR and other data privacy laws. Considering this and the scope of the project, I don't think it's within scope to add features such as "private extensions collections" and so on.