Attendees:
- Anna Sirota
- Dalai Felinto
- Oleg Komarov
Meeting to plan the next steps for backend for the Extensions Platform.
Recent changes
There have been a bit of an hiatus here due to the Alpha launch, followed by part of the team going to GDC.
To keep it short:
- Site (and Blender) features were polished enough for an Alpha release.
- A great deal was spent on making the experience smooth on both ends (site and Blender).
- Focus on bug fixing and tweaking the site based on feedback.
The next planned tasks are on the issue tracker. But here are them presented with a bit more context:
Site features
- JSON
version: Implement API version.blocklist: Blocklist - need a new status for this.data: Nest list of extensions dict under âdataâ with id as a prop.- Pending decision on whether to use lists or a dict.
- Update docs.
- Donât deploy before aligning with Campbell.
- Example:
{
"version": "1",
"blocklist" : [
"Dark_Purple_Green"
],
"data" : [
{ id="Dark_Purple_Green", ... },
{ id="orient_and_origin_to_selected", ... },
{ id="Gold_Pro_Theme", ... }
]
}
- Notifications
- Email
- For moderators:
- When a new extension is sent to approval queue.
- When a review is reported.
- When an extension is reported.
- For owner of an extension:
- When any activity happens on approval queue of your extension.
- When any review happens on your extension.
- For everyone:
- When any activity happens after you interacted with the approval queue of an extension.?
- For moderators:
- Feed (similar to Blender Studio).
- Profile setting to filter email notifications.
- Email
- Media
- Featured Image
- Write guidelines
- Aspect ratio (16:9)
- Size (min 1080p)
- Text (avoid small text, avoid low contrast)
- No Blender (or Blender community) logos
- No banners/badges (like ânew!â)
- Avoid graphic content (nudity, violence)
- It doubles as the first image in the gallery (TBD, most likely we wonât display it in the gallery)
- Write guidelines
- Introduce Thumbnails for files #51
- Do not allow GIF previews #57
- Extension Previews: Allow videos (native or yt embed?)
- Extension Detail: Allow YouTube embed {youtube id}
- Featured Image
- Blender versions:
- Filter version based on blender_version query argument: Get the latest extension compatible with that version. (right now we only check the latest to see if it is on the range, but donât check the previous ones to find a valid one).
- Support deleting extensions #66
- Blocklist for slugs
- test-extension
- Any previously deleted extension
- Suggest Maximum Version.
- Anyone can suggest this, owners or moderators can âapproveâ.
- Owner also can set it directly on the version edit page.
- Sentry
- âTemplateDoesNotExistâ 403.
- âCannot record change â%sâ to %s: user pk=%s does not existâ (Note: this also happens when we generate fake data).
ImproperlyConfigured /approval-queue/{slug}/commentreported in 500 Server Error When Commenting #65
- Approval Queue
- Need
extension.complete_stateto use on templates. - Option: Unify status of extension and approval activity.
- Option to hide virus versions
- Need
- Abuse Reports
- Add âResolvedâ and âDismissâ status.
- Should add a note when setting to resolved or when archiving.
- Dev: Generate Fake Data is missing details #50
- Ratings:
- Implement replies #64
- If more than one version, force users to pick a version.
API
- Json must contain the API version info on its body. (semantic version? or v1)
- Blender should support all (old) API versions.
Proposal:
api_version_max: Parameter set by Blender to educate the server on which API it could send back.- The server internally redirects the URL to the correct entry point.
- Explicit API version can be an explicit part of the URL endpoint.
- Used for other APIs clients.
- Used for other APIs actions (e.g., upload extension).
OpenAPI
- It seems fine to follow OpenAPI specification, and use swagger.
- We may want to drop drf_spectacular.
Validator
- Surface the errors from the .zip extraction code (read_manifest_from_zip).
- Check for
__init__.pywhen the .zip contains a folder. - Allow only a single theme (.xml) per .zip (see faulty file).
Multi-OS
Some different ideas:
- Single manifest for all OSs
- Platform is a list field on manifest: [âwindows-x86â, âwindows-armâ, âlinux-x86â, âlinux-armâ, âmac-x86â, âmac-armâ]
- We could use
{platform-arch}- use the wheel convention, as we need to map this anyway (or we could in fact infer this based on bundled wheelâs). - All wheels listed on the manifest.
- Wheels have easily extracted architecture.
- The package builder would be able to generate individual packages for different architectures.
- A .zip with all the wheels would also work.
- Single manifest per platform
On the server side, platform could to the File (instead of a version).
On rating and review, platform user-agent can be passed.
To be discussed:
- Wheels and security.
- Any compiled package can be checked on the server via ClamAV.
- Checksum for wheels against Pypi server.
- Keep a record of previously checked wheels.
- Multi-OS.
Front-end:
- Support html for manifest errors.
Blender Internet access
The original design was to alert the users everytime they turn a repository on. Even the splashscreen option to enable access to the internet would actually simply be enabling the extensions repository.
This can get quite annoying. Instead we could have a single checkbox that clearly states that Blender will check for updates (on the internet) upon launching.
Security
Packages flagged as insecure (deleted? disabled by staff? a new status we donât have yet?) should still be on JSON so Blender knows to remove it and probably warn the user.