2024-04-02 Extensions Platform - Backend


  • 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" : [
  "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.?
    • Feed (similar to Blender Studio).
    • Profile setting to filter email notifications.
  • 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)
    • 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}
  • 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}/comment reported in 500 Server Error When Commenting #65
  • Approval Queue
    • Need extension.complete_state to use on templates.
    • Option: Unify status of extension and approval activity.
    • Option to hide virus versions
  • 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:


  • Json must contain the API version info on its body. (semantic version? or v1)
  • Blender should support all (old) API versions.


  • 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).


  • It seems fine to follow OpenAPI specification, and use swagger.
  • We may want to drop drf_spectacular.


  • Surface the errors from the .zip extraction code (read_manifest_from_zip).
  • Check for __init__.py when the .zip contains a folder.
  • Allow only a single theme (.xml) per .zip (see faulty file).


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.


  • 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.


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.


As a follow up we had a short meeting about Multi-OS. The conclusions were posted here: #74 - Platform specific (multi-OS) extensions and wheels - extensions-website - Blender Projects