@ laoc42

Just calling it Open is not enough - Herausforderungen öffentlicher Bildungsinfrastrukturen und wie Nostr helfen könnte

Ich möchte gerne mit euch teilen, an welchen Konzepten ich arbeite, um die öffentliche Bildungsinfrastruktur mit Hilfe von Nostr zugänglicher und offener zu gestalten. Ich arbeite im Bereich öffentlicher Bildungsinfrastrukturen, besonders im Feld von Open Educational Resources (#OER). OER sind offen lizenzierte Bildungsmaterialien, die mit einer offenen Lizenz, meist einer Creative Commons Lizenz, versehen sind (CC-0, CC-BY, CC-BY-SA). Durch die klare und offene Lizenzierung ist es leicht möglich, die Lernmaterialien auf die individuellen Bedarfe anzupassen, sie zu verbessern und sie erneut zu veröffentlichen.

Seit vielen Jahren wird einerseits die Entwicklung freier Bildungsmaterialien gefördert, andererseits werden Plattformen, insbesondere Repositorien gefördert, die diese Materialien verfügbar machen sollen. Denn irgendwo müssen diese Materialien zur Verfügung gestellt werden, damit sie auch gefunden werden können.

Das klappt allerdings nur so mittelgut.

Herausforderungen

Nach vielen Jahren Förderung kann die einfache Frage: "Wo kann ich denn mein OER-Material bereitstellen" nicht einfach beantwortet werden. Es gibt Services, bei denen ich mein OER hochladen kann, jedoch bleibt es dann eingeschlossen in dieser Plattform und wird nicht auf anderen Plattformen auffindbar. Außerdem sind diese Services häufig an bestimmte Bildungskontexte gebunden oder geben Content erst nach einer Qualitätsprüfung frei. Dies führt dazu, dass ein einfaches und gleichzeitig öffentliches Teilen nicht möglich ist.

Diese und weitere Herausforderungen haben ihren Ursprung darin, dass Service und Infrastruktur in der Architektur öffentlichen Bildungsarchitektur ungünstig vermischt werden. Als Infrastruktur verstehe ich hier die Bereitstellung einer öffentlichen und offen zugänglichen Bildungsinfrastruktur, auf der Daten ausgetauscht, also bereitgestellt und konsumiert werden können. Jedoch existiert eine solche Infrstruktur momentan nicht unabhängig von den Services, die auf ihr betrieben werden. Infrastrukturbetreiber sind momentan gleichzeitig immer Servicebetreiber. Da sie aber die Hand darüber haben wollen, was genau in ihrem Service passiert (verständlich), schränken sie den Zugang zu ihrer Infrastruktur mit ein, was dazu führt, dass sie Lock-In Mechanismen großer Medienplattformen in der kleinen öffentlichen Bildungsinfrastruktur replizieren.

Es ist in etwas so, als würde jeder Autobauer auch gleichzeitig die Straßen für seine Fahrzeuge bauen. Aber halt nur für seine Autos.

Anhand einiger beispielhafter Services, die bestehende Plattformen auf ihren Infrastrukturen anbieten, möchte ich die Herausforderungen aufzeigen, die ich im aktuellen Architekturkonzept sehe:

• Upload von Bildungsmaterial
• Kuration: Zusammenstellung von Listen, Annotation mit Metadaten
• Crawling, Indexierung und Suche
• Plattfformübergreifende Kollaboration in Communities -> Beispiel: Qualitätssicherung (was auch immer das genau bedeutet)
• KI- Services -> Beispiel: KI generierte Metadaten für BiIdungsmaterial

Material Upload

Der Service "Material-Upload" oder das Mitteilen eines Links zu einem Bildungsmaterial wird von verschiedenen OER-Pattformen bereitgestellt (wirlernenonline.de, oersi.org, mundo.schule).

Dies bedeutet konkret: Wenn ich bei einer der Plattformen Content hochlade, verbleibt der Content in der Regel auch dort und wird nicht mit den anderen Plattformen geteilt. Das Resultat für die User: Entweder muss ich mich überall anmelden und dort mein Material hochladen (führt zu Duplikaten) oder damit leben, dass eben nur die Nutzer:innen der jeweiligen Plattform meinen Content finden können.

Der "Open Educational Resource Search Index" (OERSI) geht diese Herausforderung an, indem die Metadaten zu den Bildungsmaterialien verschiedener Plattformen in einem Index bereitgestellt werden. Dieser Index ist wiederum öffentlich zugänglich, sodass Plattformen darüber auch Metadaten anderer Plattformen konsumieren können. Das ist schon sehr gut. Jedoch funktioniert das nur für Plattformen, die der OERSI indexiert und für alle anderen nicht. Der OERSI ist auf den Hochschulbereich fokussiert, d.h. andere Bildungskontexte werden hier ausgeschlossen. Der Ansatz für jeden Bildungsbereich einen passenden "OERSI" daneben zustellen skaliert und schlecht und es bleibt die Herausforderung bestehen, dass für jede Quelle, die indexiert werden soll, ein entsprechender Importer/Crawler geschrieben werden muss.

Dieser Ansatz (Pull-Ansatz) rennt den Materialien hinterher.

Es gibt jedoch noch mehr Einschränkungen: Die Plattformen haben sich jeweils auf spezifische Bildungskontexte spezialisiert. D.h. auf die Fragen: Wo kann ich denn mein OER bereitstellen, muss immer erst die Gegenfrage: "Für welchen Bildungsbereich denn?" beantwortet werden. Wenn dieser außerhalb des allgemeinbildendenden Bereichs oder außerhalb der Hochschule liegt, geschweige denn außerhalb des institutionellen Bildungsrahmens, wird es schon sehr, sehr dünn. Kurzum:

• Es ist nicht einfach möglich OER bereitzustellen, sodass es auch auf verschiedenen Plattformen gefunden werden kann.

Kuration

Unter Kuration verstehe ich hier die Zusammenstellung von Content in Listen oder Sammlungs ähnlicher Form sowie die Annotation dieser Sammlungen oder des Contents mit Metadaten.

Einige Plattformen bieten die Möglichkeit an, Content in Listen einzuordnen. Diese Listen sind jedoch nicht portabel. Die Liste, die ich auf Plattform A erstelle, lässt sich nicht auf Plattform B importieren. Das wäre aber schön, denn so könnten die Listen leichter auf anderen Plattformen erweitert oder sogar kollaborativ gestaltet werden, andererseits werden Lock-In-Effekte zu vermieden.

Bei der Annotation mit Metadaten treten verschiedene zentralisierende Faktoren auf. In der momentanen Praxis werden die Metadaten meist zum Zeitpunkt der Contentbereitstellung festgelegt. Meist durch eine Person oder Redaktion, bisweilen mit Unterstützung von KI-Services, die bei der Metadateneingabe unterstützen. Wie aber zusätzliche eigene Metadaten ergänzen? Wie mitteilen, dass dieses Material nicht nur für Biologie, sondern auch für Sport in Thema XY super einsetzbar wäre? Die momentanen Ansätze können diese Anforderung nicht erfüllen. Sie nutzen die Kompetenz und das Potential ihrer User nicht.

• Es gibt keine interoperablen Sammlungen
• Metadaten-Annotation ist zentralisiert
• User können keine eigenen Metadaten hinzufügen

Crawling, Indexierung und Suche

Da die Nutzer:innen nicht viele verschiedene Plattformen und Webseiten besuchen wollen, um dort nach passendem Content zu suchen, crawlen die "großen" OER-Aggregatoren diese, um die Metadaten des Contents zu indexieren. Über verschiedene Schnittstellen oder gerne auch mal über das rohe HTML. Letztere Crawler sind sehr aufwändig zu schreiben, fehleranfällig und gehen bei Design-Anpassungen der Webseite schnell kaputt, erstere sind etwas stabiler, solange sich die Schnittstelle nicht ändert. Durch den Einsatz des Allgemeinen Metadatenprofils für Bildungsressourcen (AMB) hat sich die Situation etwas verbessert. Einige Plattformen bieten jetzt eine Sitemap an, die Links zu Bildungsmaterial enthalten, die wiederum eingebettet script-tags vom Typ application/ld+json enthalten, sodass die Metadaten von dort importiert werden können.

Beispiel: e-teaching.org bietet hier eine Sitemap für ihre OER an: https://e-teaching.org/oer-sitemap.xml und auf den jeweiligen Seiten findet sich ein entsprechendes script-Tag.

Das ist schon viel besser, aber da geht noch mehr:

Zunächst ist dieser Ansatz nur für Plattformen und Akteure praktikabel, die über IT-Ressourcen verfügen, um entsprechende Funktionalitäten bei sich einbauen zu können. Lehrende können dies nicht einfach auf ihrem privaten Blog oder ähnliches umsetzen. Zum anderen besteht immer noch ein Discovery Problem. Ich muss nach wie vor wissen, wo ich suchen muss. Ich muss die Sitemaps kennen, sonst finde ich nichts. Statt eines Ansatzes, bei dem Akteure eigenständig mitteilen können, dass sie neuen Content haben (Push-Ansatz), verfolgen wir derzeit einen Ansatz, bei dem jede Plattform für sich Content im Pull-Verfahren akquiriert. Dies führt an vielen Stellen zu Doppelarbeiten, ist ineffizient (mehrere Personen bauen genau die gleichen Crawler, aber halt immer für ihre Plattform) und schliesst vor allem kleine Akteure aus (lohnt es sich einen Crawler zu programmieren, wenn die Webseite "nur" 50 Materialien bereitstellt?).

Anstatt erschlossene Daten zu teilen, arbeiten die Plattformen für sich oder stellen es höchstens wieder hinter eigenen (offenen oder geschlossenen) Schnittstellen bereit. Das ist wohl nicht das, was wir uns unter einer offenen und kollaborativen Gemeinschaft vorstellen, oder?

Bei der Suche stehen wir vor ähnlichen Herausforderungen, wie bereits oben geschildert. Obwohl verschiedene OER-Aggregatoren in Form von Repositorien oder Referatorien bereits viele der "kleineren" Plattformen indexieren und somit eine übergreifende Suche anbieten, ist es nicht möglich, diese Aggregatoren gemeinsam zu durchsuchen. Dies führt im Endeffekt dazu, dass die User wieder verschiedene Plattformen ansteuern müssen, wenn sie den gesamten OER-Fundus durchsuchen wollen.

• An vielen Stellen wird Content doppelt erschlossen, aber immer für die eigene Plattform
• Es gibt keinen geteilten Datenraum, in den Akteure Content "pushen" können
• Es gibt keine plattformübergreifenden Suchmöglichkeiten

Plattformübergreifende Kollaboration

Das wäre schön, oder? Mir ist schleierhaft, wie #OEP (Open Educational Practices, genaue Definition durch die Community steht noch aus) ohne funktionieren soll. Aber es gibt meines Wissens nach nicht mal Ansätze, wie das technisch umgesetzt werden soll (oder doch? let me hear).

Ein Szenario für solche plattformübergreifende Kollaboration könnte Qualitätssicherung sein. Gesetzt, dass sich zwei Plattformen / Communities auf etwas verständigt haben, dass sie als "Qualität" bezeichnen, wie aber dieses Gütesiegel nun an den Content bringen?

Plattform A: Na, dann kommt doch alle zu uns. Hier können wir das machen und dann hängt auch ein schönes Badge an den Materialien.

Plattform B: Ja, aber dann hängt es ja nicht an unseren Materialien. Außerdem wollen/müssen wir bei uns arbeiten, weil welche Existenzberechtigung hat denn meine Plattform noch, wenn wir alles bei dir machen?

• Obwohl nun #OEP in aller Munde sind, gibt es keine technischen Ansätze, wie (plattformübergreifende) Kollaboration technisch abgebildet werden kann

KI-Services

Was ist heute schon komplett ohne das Thema KI zu erwähnen? Mindestens für den nächsten Förderantrag muss auch irgendetwas mit KI gemacht werden...

Verschiedene Projekte erarbeiten hilfreiche und beeindruckende KI-Services. Beispielsweise, um die Annotation von Content mit Metadaten zu erleichtern, Metadaten automatisch hinzuzufügen, Content zu bestimmten Themen zu finden oder (halb-)automatisch zu Sammlungen hinzuzufügen. Aber (vielleicht habt ihr es schon erraten): Funktioniert halt nur auf der eigenen Plattform. Vermutlich, weil die Services nah am plattformeigenen Datenmodell entwickelt werden. Und da die Daten dieses Silo nicht verlassen, passt das schon. Das führt dazu, dass an mehreren Stellen die gleichen Services doppelt entwickelt werden.

• KI-Services funktionieren oft nur auf der Plattform für die sie entwickelt werden

Zusammenfassung der Probleme

Wir machen übrigens vieles schon sehr gut (Einsatz des AMB, Offene Bidungsmaterialien, wir haben eine großartige Community) und jetzt müssen wir halt weiter gehen.

(Die OER-Metadatengruppe, die das Allgemeine Metadatenprofil für Bildungsressourcen (AMB) entwickelt hat, bekommt für ihre Arbeit keine direkte Förderung. Gleichzeitig ist sie eine zentrale Anlaufstelle für alle, die mit Metadaten in offenen Bildungsinfrastukturen hantieren und das Metadatenprofil ist eines der wenigen Applikationsprofile, das öffentlich einsehbar, gut dokumentiert ist und Validierungsmöglichkeiten bietet.)

Betrachten wir die gesamten Plattformen und die beschriebenen Herausforderungen aus der Vogelperspektive, so lassen sich drei ineinander verschränkte Kernbestandteile unterscheiden, die helfen, die beschriebenen Probleme besser zu verstehen:

• User
• Service
• Daten

User: Auf (fast) allen Plattformen agieren User. Sie laden Material hoch, annotieren mit Metadaten, sind in einer Community, suchen Content usw. Egal, ob sie sich einloggen können/müssen, irgendetwas bieten wir unseren Usern an, damit sie daraus hoffentlich Mehrwerte ziehen

Service: Das ist dieses irgendetwas. Die "Webseite", die Oberfläche, das, wo der User klicken und etwas tun kann. Es ist das, was den Daten oft eine "visuelle" Form gibt. Der Service ist der Mittler, das Interface zwischen User und Daten. Mithilfe des Services lassen sich Daten erzeugen, verändern oder entfernen (Es gibt natürlich auch viele nicht-visuelle Services, die Interaktion mit Daten ermöglichen, aber für die meisten normalen Menschen, gibt es irgendwo was zu klicken).

Daten: Die Informationen in strukturierter maschinenlesbarer Form, die dem User in gerenderter Form durch einen Service Mehrwerte bieten können. Ungerenderte Daten können wir schwieirg erfassen (wir sind ja nicht Neo). Das können entweder die Metadaten zu Bildungmaterialien sein, die Materialien selbst, Profilinformationen, Materialsammlungen o.ä.

Meines Erachtens nach haben viele der oben beschriebenen Herausforderungen ihren Ursprung darin, dass die drei Kernbestandteile User, Service, Daten ungünstig miteinander verbunden wurden. Was kein Vorwurf sein soll, denn das ist genau die Art und Weise, wie die letzten Jahre (Jahrzehnte?) Plattformen immer gebaut wurden:

• User, Service und Daten werden in einer Plattform gebündelt

Das heisst durch meinen Service agieren die User mit den Daten und ich kann sicherstellen, dass in meiner kleinen Welt alles gut miteinander funktioniert. Sinnvoll, wenn ich Microsoft, Facebook, X oder ähnliches bin, weil mein Geschäftsmodell genau darin liegt: User einschließen (lock-in), ihnen die Hohheit über ihren Content nehmen (oder kannst du deine Facebook Posts zu X migrieren?) und nach Möglichkeit nicht wieder rauslassen.

Aber unsere Projekte sind öffentlich. Das sind nicht die Mechanismen, die wir replizieren sollten. Also was nun?

Bildungsinfrasstrukturen auf Basis des Nostr-Protokolls

Nostr

Eine pseudonyme Person mit dem Namen "fiatjaf" hat 2019 ein Konzept für ein Social Media Protokoll "Nostr - Notes and Other Stuff Transmitted By Relays" wie folgt beschrieben:

It does not rely on any trusted central server, hence it is resilient, it is based on cryptographic keys and signatures, so it is tamperproof, it does not rely on P2P techniques, therefore it works.

Fiatjaf, 2019

Die Kernbestandsteile des Protokolls bestehen aus:

• JSON -> Datenformat
• SHA256 & Schnorr -> Kryptographie
• Websocket -> Datenaustausch

Und funktionieren tut es so:

User besitzen ein "Schlüsselpaar": einen privaten Schlüssel (den behälst du für dich, nur für dich) und einen öffentlichen Schlüssel, den kannst du herumzeigen, das ist deine öffentliche Identität. Damit sagst du anderen Usern: Hier schau mal, das bin ich. Die beiden Schlüssel hängen dabei auf eine "magische" (kryptografische) Weise zusammen: Der öffentliche Schlüssel lässt sich aus dem privaten Schlüssel generieren, jedoch nicht andersherum. D.h. falls du deinen öffentlichen Schlüssel verlierst: Kein Problem, der lässt sich immer wieder herstellen. Wenn du deinen privaten Schlüssel verlierst: Pech gehabt, es ist faktisch unmöglich, diesen wieder herzustellen.

Die Schlüsselmagie geht jedoch noch weiter: Du kannst mit deinem privaten Schlüssel "Nachrichten" signieren, also wie unterschreiben. Diese Unterschrift, die du mit Hilfe des privaten Schlüssels erstellst, hat eine magische Eigenschaft: Jeder kann mithilfe der Signatur und deinem öffentlichen* Schlüssel nachprüfen, dass nur die Person, die auch den privaten Schlüssel zu diesem öffentlichen Schlüssel besitzt, diese Nachricht unterschrieben haben kann. Magisch, richtig? Verstehst du nicht komplett? Nicht schlimm, du benutzt es bereits vermutlich, ohne dass du es merkst. Das ist keine fancy neue Technologie, sondern gut abgehangen und breit im Einsatz.

Merke: User besitzen ein Schlüsselpaar und können damit Nachrichten signieren.

Dann gibt es noch die Services. Services funktionieren im Grunde wie bereits oben beschrieben. Durch sie interagieren die User mit Daten. Aber bei Nostr ist es ein kleines bisschen anders als sonst, denn: Die Daten "leben" nicht in den Services. Aber wo dann?

Wenn ein User einen Datensatz erstellt, verändert oder entfernen möchte, wird dieses "Event" (so nennen wir das bei Nostr) mit deinem privaten Schlüssel signiert (damit ist für alle klar, nur du kannst das gemacht haben) und dann mehrere "Relays" gesendet. Das sind die Orte, wo die Daten gehalten werden. Wenn ein User sich in einen Service einloggt, dann holt sich der Service die Daten, die er braucht von diesen Relays. User, Service und Daten sind also entkoppelt. Der User könnte zu einem anderen Service wechseln und sich dieseleben Daten von den Relays holen. Keine Lock-In Möglichkeiten.

Merke: User, Service und Daten sind entkoppelt.

Zuletzt gibt es noch die Relays. Relays sind Orte. Es sind die Orte, zu denen die Events, also die Daten der User, ihre Interaktionen, gesendet und von denen sie angefragt werden. Sie sind sowas wie das Backend von Nostr, allerdings tun sie nicht viel mehr als das: Events annehmen, Events verteilen. Je nach Konfiguration dürfen nur bestimmte User auf ein Relay schreiben oder davon lesen.

Das Protokoll ist von seinem Grunddesign auf Offenheit und Interoperabilität ausgelegt. Keine Registrierung ist nötig, sondern nur Schlüsselpaare. Durch kryptografische Verfahren kann dennoch die Authentizitität eines Events sichergestellt werden, da nur die Inhaberin des jeweiligen Schlüsselpaares dieses Event so erstellen konnte. Die Relays sorgen dafür die Daten an die gewünschten Stellen zu bringen und da wir mehr als nur eines benutzen, haben wir eine gewisse Ausfallsicherheit. Da die Daten nur aus signierten JSON-Schnipseln bestehen, können wir sie leicht an einen anderen Ort kopieren, im Falle eines Ausfalls. Durch die Signaturen ist wiederum sichergestellt, dass zwischendurch keine Veränderungen an den Daten vorgenommen wurden.

Beispiel: Ein Nostr Event

Hier ein kleiner technischer Exkurs, der beschreibt, wie Nostr Events strukturiert sind. Falls dich die technischen Details nicht so interessieren, überspringe diesen Abschnitt ruhig.

Jedes Nostr Event besitzt die gleiche Grundstruktur mit den Attributen:

• id: Der Hash des Events
• pubkey: Der Pubkey des Urhebers des Events
• created_at: Der Zeitstempel des Events
• kind: Der Typ des Events
• tags: Zusätzliche Metadaten für das Event können in diesem Array hinterlegt werden
• content: Der textuelle Inhalt eines Events
• sig: Die Signatur des Events, um die Integrität der Daten zu überprüfen

json { "id": <32-bytes lowercase hex-encoded sha256 of the serialized event data>, "pubkey": <32-bytes lowercase hex-encoded public key of the event creator>, "created_at": <unix timestamp in seconds>, "kind": <integer between 0 and 65535>, "tags": [ [<arbitrary string>...], // ... ], "content": <arbitrary string>, "sig": <64-bytes lowercase hex of the signature of the sha256 hash of the serialized event data, which is the same as the "id" field> }

Die verwendeten Eventtypen sowie die existierenden Spezifikationen lassen sich unter https://github.com/nostr-protocol/nips/ einsehen.

Wichtig ist auch: Du kannst einfach anfangen, Anwendungen zu entwickeln. Die Relays werden alle Events akzeptieren, die dem o.g. Schema folgen. Du musst also niemanden um Erlaubnis fragen oder warten, bis deine Spezifikation akzeptiert und hinzugefügt wurde.

You can just build things.

Exkurs: Nostr für Binärdaten - Blossom

Ja, aber... das ist doch nur für textbasierte Daten geeignet? Was ist denn mit den Binärdaten (Bilder, Videos, PDFs, etc)

Diese Daten sind oft recht groß und es wurde sich auf das Best-Practice geeignet, diese Daten nicht auf Relays abzulegen, sondern einen besser geeigneten Publikationsmechanismus für diese Datentypen zu finden. Der Ansatz wird als "Blossom - Blobs stored simply on mediaservers" bezeichnet und ist recht unkompliziert.

Blossom Server (nichts anderes als simple Medienserver) nutzen Nostr Schlüsselpaare zur Verwaltung Identitäten und zum Signieren von Events. Die Blobs werden über ihren sha256 Hash identifiziert. Blossom definiert einige standardisierte Endpunkte, die beschreiben wie Medien hochgeladen werden können, wie sie konsumiert werden können usw.

Die Details, wie Authorisierung und die jeweiligen Endpunkte funktionieren, werden in der genannten Spezifikation beschrieben.

Nostr 🤝 Öffentliche Bildungsinfrastrukturen

Wie könnten Herausforderungen gelöst werden, wenn wir Nostr als Basis für die öffentliche Bildungsinfrastruktur einsetzen?

Material-Upload

• Es ist nicht einfach möglich OER bereitzustellen, sodass es auch auf verschiedenen Plattformen gefunden werden kann.

Mit Nostr als Basis-Infrastruktur würden die Metadaten und die Binärdaten nicht an den Service gekoppelt sein, von dem aus sie bereitgestellt wurden. Binärdaten können auf sogenannten Blossom-Servern gehostet werden. Metadaten, Kommentare und weitere textbasierte Daten werden über die Relay-Infrastruktur verteilt. Da Daten und Service entkoppelt sind, können die OER Materialien von verschiedenen Anwendungen aus konsumiert werden.

Kuration

• Es gibt keine interoperablen Sammlungen
• Metadaten-Annotation ist zentralisiert
• User können keine eigenen Metadaten hinzufügen

Sammlungen sind per se interoperabel. Auf Protokollebene ist definiert, wie Listen funktionieren. Die Annotation mit Metadaten ist an keiner Stelle zentralisiert. Das Versprechen der RDF-Community "Anyone can say anything about any topic" wird hier verwirklicht. Ich muss mir ja nicht alles anhören. Vielleicht konsumiere ich nur Metadaten-Events bestimmter Redaktionen oder User. Vielleicht nur diejenigen mit einer Nähe zu meinem sozialen Graphen. Jedenfalls gibt es die Möglichkeit für alle User entsprechende Metadaten bereit zu stellen.

Crawling, Indexierung und Suche * An vielen Stellen wird Content doppelt erschlossen, aber immer für die eigene Plattform * Es gibt keinen geteilten Datenraum, in den Akteure Content "pushen" können * Es gibt keine plattformübergreifenden Suchmöglichkeiten

Keine Doppelerschließungen mehr. Wenn ein User im Netzwerk ein Metadatenevent veröffentlicht hat, ist es für alle konsumierbar. Der Datenraum ist per se geteilt. Plattformübergreifende Suche wird durch die Kombination aus Relays und NIPs ermöglicht. In den NIPs können spezielle Query-Formate für die jeweiligen NIPs definiert werden. Relays können anzeigen, welche NIPs sie untersützten. Eine plattformübergreifende Suche ist im Nostr eine relay-übergreifende Suche.

Plattformübergreifende Kollaboration

• Obwohl nun #OEP in aller Munde sind, gibt es keine technischen Ansätze, wie (plattformübergreifende) Kollaboration technisch abgebildet werden kann

Nostr ist der technische Ansatz.

KI-Services

• KI-Services funktionieren oft nur auf der Plattform für die sie entwickelt werden

Es gibt im Nostr das Konzept der Data Vending Machines (s. auch data-vending-machines.org). Statt also einfach nur eine API zu bauen (was auch schon sehr schön ist, wenn sie offen zugänglich ist), könnten diese Services auch als Akteure im Nostr Netzwerk fungieren und Jobs annehmen und ausführen. Die Art der Jobs kann in einer Spezifikation beschrieben werden, sodass die Funktionsweise für alle interessierten Teilnehmer im Netzwerk einfach nachzuvollziehen ist.

Die Services könnten sogar monetarisiert werden, sodass sich hier auch Möglichkeiten böten, Geschäftsmodelle zu entwickeln.

Fazit

Die Open Education Community ist großartig. Es sind einzigartige und unglaublich engagierte Menschen, die sich dem hehren Ziel "Zugängliche Bildung für Alle" -> "Offene Bildung" verschrieben haben. Wir verwenden Creative Commons Lizenzen -> Commons -> Gemeingüter. Es ist okay, dass viele Projekte von Sponsoren und Förderungen abhängig sind. Was wir machen, ist im Sinne eines Gemeingutes: Öffentliche Bildung für alle. Also zahlen wir als Gemeinschaft alle dafür.

Was nicht okay ist: Dass das, wofür wir alle gezahlt haben, nach kurzer Zeit nicht mehr auffindbar ist. Dass es eingeschlossen wird. In öffentlich finanzierten Datensilos. Es muss für alle auch langfristig verfügbar sein. Sonst ist es nicht zugänglich, nicht offen. Dann ist das O in OER nur ein Label und Marketing, um für eine ABM-Maßnahme 3 Jahre Geld zu bekommen. Denn nichts anderes ist Content-Entwicklung, wenn der Content nach drei Jahren weggeschmissen wird.

Und dasselbe gilt für OEP. Offene Lernpraktiken, sind auch nur eine Phrase, wenn wir die passende technische Infrastruktur nicht mitdenken, die wirkliche Offenheit und Kollaboration und damit die Umsetzung offener Lernpraktiken ermöglicht.

Und wenn wir uns jetzt nicht Gedanken darüber machen, die Infrastruktur für offenes Lernen anzupassen, dann werden wir vermutlich in einigen Jahren sehen können, was bei politischen Umorientierungen noch davon übrig bleiben wird. Wenn die Fördertöpfe komplett gestrichen werden, was bleibt dann übrig von dem investierten Geld?

Wir brauchen Lösungen, die engagierte Communities weiter betreiben können und denen kein Kopf abgeschlagen werden kann, ohne dass wir zwei neue daneben setzen könnten.

Wir müssen uns jetzt Gedanken darüber machen.

Wie offen will öffentliche Bildungsinfrastruktur sein?