Plugin oder Theme veröffentlichen

Jeder kann ein Plugin oder Theme im Community Store listen. Der Store liest öffentliche GitHub-Repositories, prüft die Form dessen, was er findet, und listet es sofort.

Was das Repository braucht

• Ein Plugin: smabar.json im Wurzelverzeichnis für ein einzelnes Plugin oder plugins/<id>/smabar.json für mehrere. Die id im Manifest ist die Store-Kennung; Kennungen gehören dem, der sie zuerst beansprucht, Plugins und Themes sind getrennte Namensräume.
• Ein Theme: themes/<name>.json.
• Eine LICENSE-Datei im Wurzelverzeichnis. Ohne sie wird das Repository abgelehnt.
• Eine README.md neben dem Manifest. Der Store zeigt sie auf der Plugin-Seite. Hashtags darin, etwa #wetter #vorhersage, werden zu Suchbegriffen neben den store.keywords des Manifests: bis zu zehn, außerhalb von Code, jeder beginnt mit einem Buchstaben.
• Ein icon.png neben dem Manifest (auch .webp, .jpg oder .jpeg; quadratisch, mindestens 128×128 Pixel, höchstens 512 KiB). Die App nutzt es als Plugin-Icon, der Store zeigt es auf der Karte und der Plugin-Seite.
• Ein Ordner screenshots/ neben dem Manifest: bis zu sechs PNG-, WebP- oder JPEG-Bilder mit je höchstens 3 MiB, in der Reihenfolge der Dateinamen. Bilder im Format 3:2, etwa 1200×800, füllen die Galerie am besten. Ein Theme nimmt themes/<name>.png, für weitere themes/<name>-2.png und so fort.
• Keine Symlinks und keine Git-Submodule irgendwo in einem Plugin-Ordner, und höchstens zweihundert Ordner darunter.

Hat dein Agent das Plugin gebaut, bitte ihn, das Repository vorzubereiten; er kennt das Manifest-Format und kann die README schreiben.

Versionen

Die version im Manifest ist die Update-Einheit: erhöhen und pushen, und jede Installation bekommt die neue Version angeboten. Ein Release-Tag v<version> (einzelnes Plugin) oder <id>-v<version> (Sammlungen und Themes) heftet die gelistete Version an dieses Tag; ohne Releases listet der Store den Standard-Branch. Ein Tag, dessen Version von der Datei abweicht, wird abgelehnt, nie still korrigiert.

Einreichen

Eine Anfrage prüft die Plugins und Themes deines Repositorys:

curl -X POST https://store.smabar.com/submit \
  -H 'content-type: application/json' \
  -d '{"url":"https://github.com/<owner>/<repo>"}'

Die Antwort nennt jedes gefundene Plugin und Theme mit accepted oder rejected und bei einer Ablehnung die verletzte Regel. Pro Repository werden höchstens 20 neue Plugins und Themes zusammen innerhalb rollender 24 Stunden veröffentlicht. Updates bereits gelisteter Einträge verbrauchen keine Plätze. Weitere Einträge werden zunächst abgewiesen; sobald das Repository gelistet ist, versucht der Crawl alle 15 Minuten sie erneut, wenn Plätze frei werden – auch ohne weiteren Commit. Löschen von Einträgen oder Umbenennen des Repositorys setzt das Limit nicht zurück.

Zehn Einreichungsversuche pro Stunde und Adresse sind erlaubt. Zusätzlich darf eine Adresse standardmäßig höchstens fünf neue Repositories von drei verschiedenen GitHub-Konten innerhalb von 24 Stunden einreichen; IPv6-Adressen teilen sich das Kontingent ihres /64-Netzes. Dasselbe Repository erneut einzureichen verbraucht keinen weiteren Platz im Quellenlimit. Bei HTTP 429 nennt die Antwort die Wartezeit. Der Betreiber kann ganze Repositories oder GitHub-Konten einschließlich zukünftiger Einträge sperren; gesperrte Quellen erhalten HTTP 403.

Was der Store nicht tut

Er prüft keinen Code, führt ihn nicht aus, signiert ihn nicht und hostet ihn nie. Clients laden von GitHub, prüfen den Inhalt gegen den signierten Katalog und zeigen jede Voraussetzung vor der Installation. Beliebtheit ist kein Sicherheitssignal, und der Store tut nicht so. Stellt sich eine Version als schädlich heraus, wird sie gesperrt, was sie auf jedem Rechner deaktiviert, aber nichts löscht.