Firefox and cross-browser support
The API has nothing browser-specific, but the sandbox hasn't been run in Firefox. Open questions include sandbox manifest support, data: module imports, and whether the worker inherits the no-network policy.
Roadmap
Built in the open, one phase at a time.
Venora is young. This page separates what exists from what's planned, so nothing here should surprise you after you install it.
Current status
Phase 3: actively being developed.
The plugin runtime and Plugin API v1 are implemented and tested in Chromium. Current work focuses on browser support, developer experience, documentation and distribution.
- Venora
- 0.1.0
- Plugin API
- v1, complete
- Latest milestone
- Phase 3.4
- Distribution
- From source only
01 Done
What's been built.
-
Early phases
A plugin manager for Fermo
A Manifest V3 extension that adds a Plugins page to Fermo's settings, bundled plugins, ZIP import, a permissions dialog, and uninstall.
-
Phase 2.5
The sandboxed runtime
Every plugin, bundled ones included, moved out of the page into its own sandboxed frame, with a message bridge, permission-checked capabilities and the session-token guard.
-
Phase 3.1 – 3.2
Plugin API v1, specified and implemented
The namespaced
venoraAPI, private plugin storage, API-version enforcement, and validation of settings and manifests. The specification is checked against the code by tests. -
Phase 3.3
The UI security boundary
Plugin code moved into a worker with no DOM, Venora's UI moved into protected shadow roots and the top layer, and plugin text, names and CSS were locked down.
-
Phase 3.4
Runtime hardening and resource controls
Per-plugin resource accounts, rate limits, message-size limits, capability timeouts, the watchdog, install size limits, and the toolbar recovery menu with safe mode.
02 Next
What's being worked toward.
Near-term work on Venora itself. None of these exist yet.
Planned
Planned
Packed releases and distribution
A packed extension release instead of loading the source folder in developer mode.
Planned
Developer experience and documentation
Better tooling and guides for plugin authors, building on the API v1 specification, plus clearer permission information for users.
Planned
Additional plugin APIs
New capabilities can be added within API v1. Each needs a specification entry, permissions, tests and a security review first.
03 Later
A plugin ecosystem, eventually.
Later phases. These need hosted infrastructure that doesn't exist yet. There is no registry, account system or hosted service today.
- Future
Plugin registry and discovery
Finding plugins from inside Venora instead of passing ZIP files around.
- Future
Hosted and automatic updates
Today, updates are manual and Venora never checks for new versions.
- Future
Publisher verification
A way to know who published a plugin. Today, nothing is signed or verified.
- Future
Maintainer accounts and profiles
Identities for plugin maintainers, tied to a future registry.
- Future
Maintainer badges
Explained below.
- Future
Ratings, reviews and issue reporting
Community feedback on plugins, once there is somewhere to host it.
Concept · not implemented
Maintainer badges
The idea is a badge beside a plugin maintainer's name in Fermo, seen only by people who have Venora installed. Because Venora runs in your browser, the badge would appear across Fermo instances, and a viewer wouldn't need the maintainer's plugin installed to see it.
Making that trustworthy needs hosted infrastructure: maintainer accounts and a source of truth for who maintains what. That belongs to the ecosystem phases above. Nothing like it is in Venora today.
04 Not in API v1
Deliberately left out, for now.
The API v1 specification excludes these. Any of them would need a specification change and a security review before it could be added.
- General network access
- Account data APIs
- DOM or arbitrary-element access
- Plugin-to-plugin messaging
- Commands
- Notifications beyond toasts
- RPC
- TypeScript SDK
- Hosted developer portal