Publish capsules: anyone can run a marketplace, ElastOS-signed ones are trusted by default

Offen
  • Stimmt etwas nicht?
#525 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Anfängerfreundlichkeit
25/100
Issue-Typ
Feature
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
rust
Bereich
backend, devtools, security

Rechercherichtung

Start by reading related issues #500 and #281, then inspect the existing elastos publishing and model catalog flows mentioned in the issue. The issue leaves the capsule identity hash unresolved and describes changes across packaging, signing, catalogs, trust, hosting, updates, withdrawal, templates, and documentation. Done means completing the end-to-end acceptance scenarios listed in the issue, including publishing and installing a capsule from another Home.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

enhancement

Problem

A developer can make and sign a capsule, but elastos publish only stores it on their own Home (#500), and Marketplace trusts only the ElastOS release. Nobody outside the release can offer a game, a document, media or an app to other Homes.

Direction (Anders, 3 Nov 2026)

Everyone can create their own marketplace. Marketplaces signed by ElastOS are trusted by default.

Model

  • Package: a capsule folder becomes one bundle named by its hash. Which hash form becomes the identity is settled here, after the reproducibility tests.
  • Sign: the publisher signs a record outside the bundle: "this hash is my capsule X, version Y", with their own DID key. Several publishers or reviewers can vouch for the same hash.
  • A marketplace is a signed catalog: a list of records with size, description and icon, signed by whoever runs that marketplace, carrying its name bound to its DID. It uses the same shape as the model catalog, so there is one catalog format.
  • Trust: every Home trusts the ElastOS catalogs by default. Any other marketplace is added only by the owner, with approval in Inbox that shows its name, DID and where the link came from. Marketplace labels each item with who signed it and whether that marketplace is trusted by ElastOS. The ElastOS catalog can list marketplaces it vouches for. The owner can remove any added marketplace.
  • Names belong to their publisher (publisher plus name), so two publishers can ship apps with the same name. A game names its player by hash or through a trusted catalog.
  • Hosting: bytes come over Carrier from any Home that holds them and announces it, as model packages do (#281). The catalog says whether an item is held only by its publisher or replicated.
  • Updates are new records from the same publisher with a higher version. The Home offers them, asks again in Inbox when permissions or the player change, and never replaces bytes silently.
  • Withdrawal: a publisher can withdraw a record, and an ElastOS block list stops a harmful hash in every marketplace. A Home refuses to launch a withdrawn or blocked hash and tells the owner.
  • Tools: the elastos command works without a repository checkout: pack, sign (DID record), catalog add|withdraw|publish, plus templates (a game for the GBA Emulator, a document or media item, a web app shown in Home) and a guide. These replace the current manifest signature, raw trusted_keys, the elastos.component/v1 scaffold and the old templates.

Done means

  • Someone outside the release packs, signs and publishes a free content capsule (a game for the GBA Emulator) into their own marketplace from a fresh install, following the guide.
  • Another Home adds that marketplace (Inbox approval shows name, DID and source), sees the item labelled as not trusted by ElastOS, gets it, opens it, and removes the marketplace again.
  • An item in the ElastOS catalog shows as trusted and installs with no extra approval step beyond Get.
  • Same name from two publishers: both install, neither replaces the other.
  • Update with changed permissions asks again; withdrawal and the ElastOS block list stop a launch with a clear message.
  • The item is fetched from a holder other than the publisher while the publisher's Home is offline.
  • Old signing paths and templates removed; docs updated.

Out of scope

Paid items (licences, protected media #388, paid services) and apps from other publishers that run code (they wait for confined workers, #471, #173).

Related

#333 (Get and Remove for release items, 2.1.0), #465, #274, #213, #281, #500, #285, #171, #192 (closed; its naming, update and revocation Done means are carried here).

Vorherrschende Sprache
Rust
Sterne
6
Forks
2
Ø Merge
1 T. 3 Std.
Gemergte PRs (30 T.)
42

Entwicklungsumgebung

Dieses Projekt bietet weder Dev-Container noch Dockerfile noch Beitragsleitfaden – die Einrichtung liegt bei Ihnen. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus elastos/elastos-runtime

Alle Issues in elastos/elastos-runtime

Ähnliche Issues

Weitere Issues zu Rust

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.