Die Zukunft der Obsidian-Plugins

• Obsidian Community wurde mit einem neuen Verzeichnis und einem Developer-Dashboard für Plugins und Themes eingeführt und vereint damit Einreichung, Verwaltung, Auffindbarkeit und Nutzung in einem durchgängigen Ablauf
• Seit der Veröffentlichung der Obsidian API im Jahr 2020 wurden von der Community mehr als 4.000 Plugins und Themes erstellt, und Plugins wurden über 120 Millionen Mal heruntergeladen
• Das neue Verzeichnis bietet Durchsuchen, Suche, Filtern und Sortieren und zeigt auf Projektseiten Screenshots, Detailinformationen und eine Sicherheits-Scorecard an
• Automatische Reviews gelten für alle Versionen und prüfen die Einhaltung der Entwicklerrichtlinien, die Codequalität sowie bekannte Schwachstellen und mögliches Schadverhalten
• Bestehende Projekte werden in das neue System migriert; Plugins und Themes, die die aktuellen Standards nicht erfüllen, erhalten vorübergehende Ausnahmen und werden danach schrittweise aus dem offiziellen Verzeichnis entfernt

---

Obsidian Community startet

• Obsidian Community startet als neues Verzeichnis und Developer-Dashboard für Obsidian-Plugins und -Themes
• Seit der Veröffentlichung der Obsidian API im Jahr 2020 wurden von der Community mehr als 4.000 Plugins und Themes erstellt, und Obsidian-Plugins kamen insgesamt auf mehr als 120 Millionen Downloads
• Ziel ist es, dass jeder Plugins und Themes einfacher und sicherer erstellen, veröffentlichen, entdecken und nutzen kann
• Dieser Start ist der Beginn eines größeren Plans, der die Community-Website, das Developer-Dashboard, automatische Reviews, Plugin-Sicherheit und Tools für Teams gemeinsam einführt

Community-Website und Developer-Dashboard

• Die neue Community-Website bietet Durchsuchen, Suche, Filtern und Sortieren zum Entdecken von Plugins und Themes
• Plugins lassen sich über Dutzende Kategorien wie Integrations, Bases, Charts und weitere Kategorien finden
• Projekte können nach Name, Download-Zahl, Beliebtheit, Veröffentlichungsdatum und Aktualisierungsdatum sortiert werden
• Jede Projekt-Detailseite enthält Screenshots, Detailinformationen und eine Sicherheits-Scorecard
• Für kostenpflichtige Plugins und offizielle Integrationen werden neue Labels angezeigt
• Autoren können ihrer Profilseite Unterstützungsoptionen, Website-Links und Social-Media-Links hinzufügen
• Die Obsidian-Community-Website bietet ein neues Developer-Dashboard, über das Autoren Projekte einreichen, verwalten und ihren Status verfolgen können
• Alle bestehenden Plugins, Themes und ausstehenden Einreichungen, die bisher über GitHub hinzugefügt wurden, werden automatisch auf die neue Website migriert
• Um den Besitz bestehender Projekte zu beanspruchen, muss man sich auf der Community-Website anmelden und sein GitHub-Konto verknüpfen
• Nach der Verknüpfung des GitHub-Kontos können bestehende Projekte verwaltet, neue Projekte eingereicht und die Profilseite bearbeitet werden

Automatische Reviews und Sicherheit

• Für alle Community-Projekte werden automatische Reviews eingeführt
• Das neue automatische Review-System scannt nicht nur die erste Einreichung, sondern jede Version nach Sicherheits- und Codequalitätsstandards
• Bisher prüfte ein kleines Team die ersten Einreichungen manuell auf Einhaltung der Developer Policies, doch mit wachsender Beliebtheit von Obsidian wurde es schwierig, mit dem Einreichungstempo mitzuhalten, und spätere Versionen wurden nicht mehr geprüft
• Da Coding Agents die Erstellung von Plugins beschleunigen, wurden die Review-Warteschlangen noch länger, und mit Tools wie der Obsidian CLI wird das Erstellen von Plugins einfacher
• Wenn ein Plugin oder Theme eingereicht wird, überprüft das automatische Review-System die Einhaltung der Entwicklerrichtlinien, die Befolgung von Best Practices im Quellcode und das Fehlen bekannter Schwachstellen
• Da sich die automatischen Tests laufend verbessern lassen, entsteht damit eine Grundlage, um Qualität und Sicherheit des Obsidian-Ökosystems umfassender zu erhöhen
• Manuelle Reviews bleiben bestehen. Dank des neuen Systems kann die Kapazität auf Plugins konzentriert werden, die eine tiefere Prüfung benötigen, etwa beliebte Plugins, empfohlene Plugins oder von der Community markierte Probleme
• Bestehende Plugins und Themes wurden im neuen System erneut geprüft, wobei ältere Plugins und Themes gefunden wurden, die die aktuellen Richtlinien nicht erfüllen
• Bestehende Projekte, die die aktuellen Standards nicht bestehen, erhalten vorübergehende Ausnahmen; alle Plugins und Themes, die das neue Review-Verfahren nicht bestehen, sollen jedoch letztlich schrittweise aus dem offiziellen Verzeichnis entfernt werden
• Das neue System hat in den vergangenen Tagen mehr als 2.300 ausstehende Einreichungen verarbeitet, und Entwickler, die auf eine Plugin-Review warten, können sich auf der Community-Website anmelden, um den aktuellen Status zu prüfen

• Automatische Scans

  • Jede Version wird automatisch auf Codequalität und Sicherheitslücken geprüft
  • Dazu gehört auch ein Malware-Scan, der erkennt, ob ein Plugin potenziell schädliche Zusätze enthält
  • Entwickler können im Developer-Dashboard detaillierte Hinweise, Warnungen und Fehlerkennzeichnungen für jedes Projekt einsehen

• Scorecard

  • Nutzer und Entwickler können in der Scorecard jedes Projekts den Status der automatischen Prüfungen einsehen
  • Die Scorecard soll weiter verbessert werden und dabei öffentliche Informationen, Datenschutz-Labels, Artifact Attestations, Ergebnisse manueller Reviews und die Übernahme von App-Funktionen integrieren

• Offenlegung des Zugriffsbereichs

  • In den kommenden Monaten soll die Transparenz bei Plugins und Autoren weiter erhöht werden
  • Plugins müssen angeben, worauf sie zugreifen, etwa auf Netzwerk, Dateisystem, Zwischenablage und andere Funktionen
  • Nutzer sollen diese Angaben vor der Installation eines Plugins einsehen können

• Verifizierte Autoren

  • Vertrauenswürdige Entwickler, die zusätzliche Verifizierungsschritte bestehen und in gutem Status bleiben, erhalten ein Label
  • Nutzer können Sicherheitsprobleme jederzeit direkt an das Obsidian-Team melden

Änderungen für Teams und auf App-Ebene

• Teams, die Obsidian verwenden, können bereits benutzerseitige Sicherheitskontrollen ausrollen
• In den kommenden Monaten sollen Teams Community-Plugins einfacher verwalten können, die sie erlauben möchten, und private Plugins an Teammitglieder verteilen können
• Teams, die offizielle Obsidian-Plugins bereitstellen, können das Official-Badge im Community-Verzeichnis beantragen
• Wenn ein Plugin dafür infrage kommt, kann man Kontakt aufnehmen
• Parallel zu Verbesserungen des Community-Verzeichnisses und des automatischen Review-Systems sind auch Änderungen an der Obsidian-App und API geplant, die Auffindbarkeit und Sicherheit erhöhen sollen
• Das Community-Ökosystem ist einer der unterhaltsamen und leistungsstarken Teile von Obsidian, und die Richtung ist, die Grundlage für weiteres Wachstum bereitzustellen
• Zum neuen Obsidian Community wird Feedback eingeholt

Wichtige Änderungen für Nutzer und Entwickler

• Auswirkungen auf Nutzer

  • Auf der neuen Community-Website lassen sich Plugins und Themes entdecken
  • Da die Review-Zeiten deutlich kürzer werden, muss Early-Access-Plugins möglicherweise seltener manuell installiert werden

• Einreichung neuer Plugins oder Themes

  • Auf der Community-Website anmelden und auf das neue Developer-Dashboard zugreifen
  • Das GitHub-Konto verknüpfen, das Repository für die Einreichung auswählen und die Schritte im Dashboard abschließen
  • Unmittelbar nach der Einreichung beginnt die Projektprüfung, und das Ergebnis ist in der Regel innerhalb weniger Minuten sichtbar
  • Wenn das Projekt besteht, kann es innerhalb von 24 Stunden in der App gesucht und heruntergeladen werden

• Besitz bestehender Plugins und Themes beanspruchen

  • Auf der Community-Website anmelden und auf das neue Developer-Dashboard zugreifen
  • Nach Verknüpfung des GitHub-Kontos kann der Besitz eines Plugins beansprucht und Titel, Beschreibung sowie Screenshots aktualisiert werden

• Sind Updates auch ohne Developer-Dashboard möglich?

  • Neue Versionen können weiterhin über GitHub veröffentlicht werden
  • Neue Releases werden automatisch geprüft; wenn sie die Review nicht bestehen, müssen die Details im Developer-Dashboard eingesehen werden

• Plugins und Themes, die automatische Reviews nicht bestehen

  • Neue Plugins und Themes müssen die automatische Review bestehen, bevor sie dem Verzeichnis hinzugefügt und auffindbar werden
  • Jede neue Version wird gescannt; wenn sie die Review nicht besteht, wird sie innerhalb von 24 Stunden aus der Suche entfernt
  • Bereits genehmigte Plugins und Themes können vorerst weiter genutzt werden, auch wenn sie die automatische Review nicht bestehen
  • Auch ältere Plugins sollen letztlich die neuen Standards erfüllen müssen, aber es gibt noch keinen festen Zeitplan; der Übergang soll gemeinsam mit den Community-Entwicklern festgelegt werden

• Automatische Reviews ohne Release-Einreichung ausführen

  • Mit dem eslint plugin lassen sich Obsidian-Plugins lokal anhand der offiziellen Entwicklerrichtlinien prüfen
  • Im Developer-Dashboard kann ein Vorschau-Scan für beliebige Branches, Tags oder Commits ausgeführt werden

• Co-Maintainer und Organisations-Repositories

  • Aktuell können in Obsidian Community nur Eigentümer von GitHub-Repositories das jeweilige Projekt bearbeiten
  • Bei Organisations-Repositories sind Besitzanspruch und Bearbeitung möglich, wenn die Organisationsmitgliedschaft öffentlich sichtbar ist
  • Unterstützung für mehrere Mitwirkende soll in naher Zukunft ergänzt werden

• Plugins mit geschlossenem Quellcode

  • Neue Plugins mit geschlossenem Quellcode werden derzeit nicht in das Verzeichnis aufgenommen
  • Bereits bestehende Plugins mit geschlossenem Quellcode können bis auf weitere Ankündigung weiter genutzt werden
  • Künftig soll geprüft werden, wie das neue Review-System an Plugins mit geschlossenem Quellcode angepasst werden kann

• Konto- und GitHub-Anforderungen

  • Für den Zugriff auf das neue Developer-Dashboard ist ein Obsidian-Konto erforderlich
  • Derzeit ist die Nutzung von GitHub erforderlich; künftig soll die Unterstützung weiterer Software-Hosting-Plattformen geprüft werden
  • Der GitHub-Login teilt den Benutzernamen und die Liste öffentlicher Repositories, und diese Informationen werden nur zur Bestätigung des Repository-Besitzes verwendet

• Labels Paid und Optional payments

  • Obsidian Community ist kein Store und bietet keine integrierte Zahlungslösung an
  • Entwickler können weiterhin externe Zahlungsmechanismen wie Lizenzschlüssel, API-Schlüssel oder Login-Gates verwenden
  • Entwickler müssen ihr Plugin korrekt einer von drei Kategorien zuordnen
  • Free bezeichnet Plugins ohne jede Form der Bezahlung und ohne jegliche Verbindung zu kostenpflichtigen Diensten; Spenden- und Unterstützungslinks sind erlaubt
  • Optional payments bedeutet, dass Nutzer optional zahlen können, um zusätzliche Funktionen freizuschalten, oder dass das Plugin mit einem kostenpflichtigen Dienst verbunden ist
  • Wenn ein Plugin mit einem kostenpflichtigen Dienst oder einer kostenpflichtigen API verbunden ist, muss es als Optional payments gekennzeichnet werden, auch wenn dieser Dienst eine kostenlose Stufe bietet
  • Paid bedeutet, dass Nutzer zahlen müssen, um die Hauptfunktionen zu verwenden, selbst wenn eine kostenlose Testphase angeboten wird
  • Diese Labels zeigen nicht an, ob der Plugin-Entwickler Zahlungen einsammelt, sondern welche Zahlungen Nutzer erwarten müssen

• Fehler in der Scorecard und Kontakt

  • Die Scorecard ist eine neue Funktion und kann Fehler enthalten; es kann zu False Positives oder False Negatives kommen
  • Wenn ungenaue Inhalte entdeckt werden, sollte der Kanal #plugin-dev im Obsidian Discord-Server kontaktiert werden
  • Bei Fragen oder Bedenken kann ebenfalls der Kanal #plugin-dev im Obsidian Discord-Server kontaktiert werden

[GN⁺]

Hacker-News-Kommentare

• Ich bin der CEO von Obsidian. Wir arbeiten seit fast einem Jahr an der neuen Community-Website und dem Review-System, und obwohl ich mich sehr auf diese erste Version freue, gibt es noch vieles, das wir verbessern müssen
  Ich habe versucht, im Blogpost, in den FAQ und sogar bei den nächsten Schritten auf der Roadmap so wenig wie möglich auszulassen, aber sicher ist mir trotzdem etwas entgangen, also fragt gern nach
  Unser Team besteht nur aus 7 Leuten, muss aber mit Tausenden von Plugin-Entwicklern und Millionen von Nutzern umgehen, daher war es sehr schwierig, widersprüchliche Prioritäten ausgewogen auszubalancieren
  Das neue System musste leicht einführbar sein, Abwärtskompatibilität wahren, bestehende Workflows nicht vollständig zerstören und zugleich deutlich besser sein als die frühere Methode; außerdem musste es die Sicherheit und Auffindbarkeit von Plugins schrittweise verbessern können
  Ich würde mich freuen, wenn ihr es als laufende Arbeit betrachtet; ich möchte Ideen und Beschwerden hören und dann weiter iterativ verbessern
  • Ich habe schon in mehrere Projekte Plugins eingebunden und dabei einmal überlegt, eine Struktur einzuführen, bei der das Projekt bestimmte Versionen als geprüft und vertrauenswürdig markiert
    Einer der Gründe, warum ich gezögert habe, war nicht nur der enorme Zeitaufwand, sondern auch die Sorge, dass das Projekt später die Verantwortung für einen Angriff tragen könnte, falls nach Abhängigkeit von diesem Review-Prozess einmal verschleierter Schadcode durchrutscht
    Mich würde interessieren, wie ihr darauf blickt
    Für mich fühlt sich das an wie der Unterschied zwischen Debian/Ubuntu, wo alles im Repository streng geprüft wird, und PyPI/npm, wo es überhaupt keine Review-Garantie gibt
  • Mir gefällt, dass man in den öffentlichen Informationen auf „Ein Plugin kann Anfragen an 1 externe Domain senden“ klicken kann und dann die tatsächliche Domain github.com sieht
    Ein Beispiel ist hier zu sehen: https://community.obsidian.md/plugins/zotlit
  • Mich würde interessieren, ob das automatische Scan-System Erweiterungen des Berechtigungsumfangs oder Änderungen beim Zugriff auf Netzwerk-Domains zur internen bzw. menschlichen Prüfung markiert
    Wenn zum Beispiel ein KI-Zusammenfassungs-Plugin anfangs mit einem vom Nutzer bereitgestellten OpenAI-Key auf url="api.openai.com"+path zugreift, wäre das eine sehr gängige Form, und ich bin gespannt, was die Community darauf aufbaut
    Wenn ein Update den Nutzern dann aber erlaubt, für eine OpenAI-kompatible API einen beliebigen Endpunkt zu wählen, wie kann man sicherstellen, dass diese Flexibilität nicht missbraucht wird, um einen Netzwerk-Exfiltrationspfad zu schaffen, der den Scan umgeht, und dass nicht unauffällig ein bösartiger Endpunkt vorausgefüllt in ein Update eingebaut wird?
  • Das Obsidian-Team hat großartige Arbeit geleistet. Ich werde weiter Obsidian Sync nutzen und hoffe, dass ich Community-Plugins mit mehr Ruhe einsetzen kann
  • Endlich ist es da
    Als ich Obsidian ausprobiert habe, stellte ich fest, dass die Datentabellen-Funktion nicht eingebaut ist, sondern ein Plugin mit vollständigem Zugriff, und habe es sofort wieder deinstalliert
    Dass das Team aber nur aus 7 Leuten besteht, überrascht mich
• Für alle, die es nicht wissen: Bisher waren neue Plugin-Einreichungen wegen des manuellen Reviews praktisch fast unmöglich. Dazu kam, dass das Schreiben von Plugins durch KI einfacher und unterhaltsamer geworden ist
  Der Unmut in der Entwickler-Community wurde immer größer, und auch das Team war durch die Last zunehmend erschöpft
  Deshalb Glückwunsch an das Team. Ein gewaltiger Skalierungsengpass wurde damit gelöst, und es ist ziemlich beeindruckend zu sehen, wie sie das aufbauen und weiter skalieren
  • Gibt es coole Plugins, die man empfehlen kann? Ich bin gerade von OneNote gewechselt, habe inzwischen sogar die Synchronisierung eingerichtet und fühle mich jetzt erst langsam wohl damit
• Ich nutze Obsidian zwar nicht, aber beim Lesen des Titels dachte ich zuerst, es ginge darum, alles auf wenige von der Firma genehmigte Plugins zu beschränken
  Wenn Softwarefirmen Titel wie „Die Zukunft von XYZ“ verwenden, erwartet man meist, dass sie XYZ stark einschränken oder auf das Ende vorbereiten
  • Ich habe mich gefragt, an welcher Stelle die Enshittification sichtbar wird
• Ich bin nicht sicher, ob man allein mit automatischen Prüfungen zuverlässig feststellen kann, ob ein Plugin bösartig ist
  Die beste und vielleicht einzige Möglichkeit, Plugin-Sicherheitsprobleme zu lösen, ist meiner Meinung nach eine Sandbox mit expliziter API und Berechtigungssystem
  • Zusätzlich zu „Es braucht eine Sandbox mit expliziter API und Berechtigungssystem“ würde ich sagen: Vor allem sollte sie meine persönlichen Daten nicht anfassen können. Das Problem ist nur, dass der Kern von Obsidian-Plugins gerade darin besteht, Dokumente zu lesen und zu schreiben
    Wenn sie allerdings nicht mit dem Internet kommunizieren können, scheint das kein großes Problem zu sein
    Beim weiteren Nachsehen wirkt es so, als seien Obsidian-Plugins in der JavaScript-/Electron-Architektur einfach JavaScript-Blöcke, die im globalen Bereich laufen, das gesamte Dateisystem im Rahmen der Benutzerrechte lesen und schreiben sowie HTTP-Anfragen senden können. Kann das jemand bestätigen?
  • Eigene Schadlogik wird dadurch natürlich nicht verhindert, aber es kann sehr dabei helfen zu beurteilen, ob Abhängigkeiten aktuell gehalten werden und ob bekannte CVEs enthalten sind. Das ist ähnlich wie bei Trivy oder bei der Art, wie Artifacthub so etwas hervorhebt
    Ich frage mich allerdings, wie gut das in diesem Ökosystem tatsächlich funktionieren wird. Meiner Erfahrung nach führen umfassende Scans leicht zu False Positives, also Fällen, in denen es zwar eine CVE gibt, sie im tatsächlichen Nutzungskontext aber nicht relevant ist
    Deshalb braucht man Wissen, um Scan-Ergebnisse richtig zu interpretieren, und das kann für Maintainer eine erhebliche Belastung werden
  • Lies einfach den Blogpost. Neben automatischen Scans und Kontrollfunktionen für das Team ist auch ein Berechtigungssystem geplant
    Berechtigungen allein können bestimmte bösartige Verhaltensweisen nicht verhindern, daher braucht man alles davon
    Schon ein Blick auf einige Scorecards auf der Community-Website zeigt schnell, dass manche Warnungen nicht durch ein Berechtigungssystem oder Sandboxing abgefangen werden können
    Im Blogpost stehen Details zum Rollout, und weil Änderungen an der Plugin-API nötig sind, soll das schrittweise eingeführt werden
  • Natürlich wird das nicht mit bestehenden Plugins kompatibel sein, daher würde ich Legacy-Plugins und neue Plugins trennen, bei der Installation von Legacy-Plugins viel Reibung einbauen und sie irgendwann auslaufen lassen
  • Auch Podman/Linux hat APIs und ein Berechtigungssystem, und trotzdem gab es Copy Fail: https://garrido.io/notes/podman-rootless-containers-copy-fai...
    Sicherheit und Berechtigungsvergabe sind einfach schwierig, und wenn man eine Plattform entwirft, muss man sich irgendwann fragen, ob die Risiken den Zugewinn an Flexibilität wert sind
    Ein vollkommen sicheres System zu planen ist aussichtslos
• Sehr interessant. Das ist ein Beleg aus der realen Welt dafür, dass automatisches Plugin-Review sogar mit einem kleinen Team möglich ist
  Irgendwann sollte ich wohl lernen, wie man in meinem eigenen Projekt ein ähnliches System umsetzt
  • Vielleicht ist es besser, erst einmal zu beobachten, wie sich das entwickelt. Das ist ein Katz-und-Maus-Spiel, und die Mäuse sind hier deutlich klüger
    Datenabfluss geschieht leise
• Als Nutzer weiß ich nicht, wie oder warum ich mir die Scorecard ansehen sollte
  Wenn dort eine lange Liste aus Fehlern und Linter-Warnungen steht, was soll ich dann damit anfangen?
  Mich interessiert, wie der ideale Ablauf auf Nutzerseite gedacht ist. Für Entwickler wirkt die Scorecard sinnvoll
• Schön, dass so ein Update kommt
  Community-Beiträge dieser Art zu verwalten ist schwierig, aber das wirkt wie ein großer Fortschritt
• Solange die Verfügbarkeit von Plugins nicht sinkt, insbesondere in meinem Fall selfhosted-livesync, sieht das gut aus
  Ich frage mich auch, welche Rolle KI bei solchen automatischen Reviews übernehmen könnte. Das wirkt wie ein ziemlich vielversprechender Anwendungsfall
• Sehr cool. Schade nur, dass die Website nur einen Dark Mode bietet und Menschen mit Astigmatismus das Lesen dadurch eher erschwert wird
  • Der Lesemodus von Firefox zeigt mit einem Klick schwarzen Text auf weißem Hintergrund. Andere Browser haben wahrscheinlich etwas Ähnliches
  • Das liegt daran, dass Obsidian schwarz ist. Es ist aber geplant, in naher Zukunft auch einen Light Mode hinzuzufügen
  • Ist damit eine sehr seltene Form von Astigmatismus gemeint? Ich habe seit über 30 Jahren Astigmatismus, kann diese Website aber völlig mühelos perfekt lesen
• Es wäre gut, wenn sich Plugins lokaler einfacher installieren ließen. Im Idealfall sollte man sie wirklich nur in einen Ordner kopieren müssen
  Wenn Obsidian keine proprietäre Software wäre, hätte ich das selbst geändert
  Es wird Zeit, dass jemand einen kompatiblen Klon baut
  • Genau so funktioniert es bereits. Ein Plugin ist einfach nur ein Ordner, den man in den .obsidian/plugins-Ordner im Vault kopieren kann
  • Man muss es buchstäblich nur in das Verzeichnis .obsidian/plugins/ einfügen