Core buyer, seller and paid-distribution flows exist in source and are exercised in local end-to-end environments. The project is not yet a stable public release.
Implemented in the current connector
“Implemented” means the capability exists in the current development source. It does not yet mean that the project promises a stable interface, production support or compatibility beyond the stated target.
Independent registry sources
Persistent sources, GitHub repository URL discovery, strict registry parsing and compatible-release selection.
Buyer installation flow
Registry extensions are presented in the existing extension screen and handed to the platform-provided upload, install and update lifecycle.
Seller publication
Valid plugin ZIPs attached to digital products can be inspected, published and updated without a separate packaging service.
Paid account access
Customer- and sales-channel-scoped tokens derive access from product, order, download and payment state. Full revocation is rechecked for artifact requests.
Repository onboarding
Public and private GitHub repositories can create a draft product or link releases to an existing product, followed by scheduled synchronization.
Download safety
Production HTTPS rules, SSRF-aware requests, redirect revalidation, size limits, SHA-256 verification and ZIP preflight checks.
Credential handling
Buyer and private-repository credentials are encrypted at rest, fingerprinted in Administration and restricted to their configured origin.
Local end-to-end verification
Separate buyer and seller environments exercise anonymous registries, purchase, update, refund, token rotation and repository synchronization.
Being validated before a stable release
Compatibility across supported 6.7 minor releases
The Administration adapter touches private upstream components and must be retested for every supported minor line.
Production installation and recovery behavior
Setup, upgrade, failed download, invalid package, credential rotation and seller outage behavior need release-grade operational guidance.
Seller and administrator user experience
Repository onboarding, publication diagnostics, access delivery and lifecycle errors need testing outside the development environment.
Versioned build and release gates
The canonical repository, automated checks, reproducible packages, release notes and upgrade promises must align before a stable tag.
Immediate project milestones
- Move the connector into its canonical ExtensionMesh repository.
- Establish CI and a tested compatibility matrix for supported versions.
- Publish administrator, seller and extension-author setup guides.
- Ship a clearly labelled pre-release and collect real installation feedback.
- Extract shared registry conventions from the proven implementation.
Deliberately later—or not promised
- Support for systems without a concrete connector and maintainer.
- A universal cross-system protocol designed ahead of implementation.
- One central directory or mandatory ExtensionMesh service.
- Unattended extension installation or background updates.
- Per-domain, seat, device or quantity-based licence enforcement.
- Additional repository providers before a real use case requires them.
This status is based on Extension-Mesh/shopware. See the connector model for the project-wide boundary.