Wie könnte Nostr ins GCS eingebunden werden?
Nostr wäre als Basistechnologie interessant, in dem Nutzer ihre eigenen Fähigkeiten, Bedürfnisse, Mittel/Ressourcen usw. in einer ValueFlows- oder einer anderen RDFS/OWL-artigen Struktur posten und abrufen können.
Was bräuchte man:
- Nostr-Events. Nachrichtentypen mit strukturierten Daten (z.B. ValueFlows).
- Eine Suchmaschine, die diese Events suchen (und sortieren) kann.
- eventuell GCS-freundliche Relays, die auf die Arten von Nachrichten des GCS und die Spam-Herausforderungen (siehe oben zu PoW) optimiert sind.
Erst mal orientiert an der GCS-Werkzeugliste :
Jedes der “Werkzeuge” könnte theoretisch durch Nostr bereitgestellt werden:
- Werkzeug der Mittel: Events, die Mittel und die Nutzungsregeln beschreiben. (inklusive der zeitl. Verfügbarkeit)
- Werkzeug zur Unterstützung sozialer Prozesse: Einfache Nachrichten-Events und Kalenderfunktionen. Das kann mit jedem existierenden Nostr-Client getan werden, für Kalenderfunktionen gibt es auch bereits einen Event-Typ.
- Werkzeug der Selbstvermittlung: Events, die Bedürfnisse und Lebensaspekte beschreiben. Hier kann man sich an einem “Angebot” auf einem Marketplace bzw. Classified Listings orientieren. (siehe NIP-Liste)
- Vorschlag- und Abfrage-Werkzeug: Suchmaschine / Filter-Funktion von Relays (Teil der Funktionen eines Nostr-Clients).
- Werkzeug der Verknüpfung von Prozessen und Mitteln: Zitat “Um gemeinsam Pläne zu schmieden, müssen Szenarien und Pläne (soweit es selbstbestimmten Präferenzen nach möglich ist) transparent sein - also welches Mittel wofür verwendet wird, wer mit wem wann zusammenarbeiten könnte, welche alternativen Szenarien es zur Lösung eines Problems gibt etc. pp. Ich denke, das ist ein seperateres Werkzeug, das natürlich eng verknüpft mit dem Werkzeug zur Unterstützung sozialer Prozesse ist.” Dieses Werkzeug könnte in einem zweiten Schritt entwickelt werden, indem z.B. für Pläne ebenfalls strukturierte Events bereit gestellt werden.
Allerdings sind einige Funktionen davon wahrscheinlich einfacher und besser mit traditionelleren Web-Technologien wie Wikis (Semantic MediaWiki/Wikidata) zu lösen. Und für viele fehlen bessere Implementierungen.
Wahrscheinlich wäre die schnellste und zuverlässigste Strategie, um eine Art GCS aufzubauen ein Mix aus dezentralem Messaging (hier kann Nostr seine Stärken ausspielen) und statischen Websites (in der Regel Wikis), die miteinander über ein gemeinsames Vokabular (OWL/RDFS/JSON-LD usw.) kommunizieren können. Projekte, aber auch Einzelpersonen, können Websites oder Wikis betreiben. Diese Wikis könnten via Nostr abgefragt werden und mit Diskussionen und “Echtzeitelementen” angereichert werden. Wiki-Bots können relevante Informationen aus Nostr in die Wikis übertragen.
Ich habe mir auch die “Funktionen” durchgeschaut laut dem (noch nicht veröffentlichen) Text “Teilen für Fortgeschrittene”, die man eventuell mit Nostr verwirklichen könnte:
- Bereits vorhanden: 11 (Brücken - allerdings wohl nicht zu allen möglichen Protokollen!), 12 (Identitätscluster), 13 (Kommunikationsräume), Vertrauenssystem (21), Diskussionsforen (24, 26), Dezentrale Wikis (Funktionen 1, 2, 4, 6, 7, 8, 9, 25, 28, 29) (siehe unten)
- Problemlos implementierbar: Abbilder zentr. Informationsquellen (3), Brücken (5), Scheduling (14, 15), Pooling (17), “Bedeutung von Regeln/Ressourcen” (22, 23), “Schnittstellen zur Wissensweitergabe” (27)
- Vermutlich möglich: Inferenzen (10), Regel-Suchmaschine (16), Mangel/Überflussituation (18), ,
- Schwierig: Reputationssystem (19, 20) - Problem: Nachrichten können gelöscht werden. Es müsste also eine andere Instanz die Nachrichten, die auf relevante positive/negative Reputation hinweisen, speichern. Ein einfaches Badge-System ist dagegen vorhanden (s.o.)
Zu dezentralen Wikis: Mir scheint diese Technologie bisher eher experimentell zu sein. Diese Funktionen würde ich eher mit traditionellen Wikis realisieren.
Soviel erstmal, vielleicht hilft es weiter. 