Archiv der Kategorie: Solid

Bestellübersicht im Solid Pod: Unstrukturierte Infos mithilfe von ChatGPT konvertieren

Wie behaltet ihr den Überblick über eure Online-Bestellungen? Es kann schwierig sein, sich an alle Details zu erinnern, insbesondere wenn man in vielen verschiedenen Shops einkauft. Solid kann euch helfen, alle Bestellungen zentral in eurem Pod zu speichern und zu organisieren.

Aber habt ihr jemals versucht, unstrukturierte Daten wie E-Mail-Bestellbestätigungen im Pod zu speichern? Wenn ja, wisst ihr sicherlich, wie mühsam und fehleranfällig das sein kann, da viele Shops nur HTML- oder reine Text-Bestätigungen liefern. Das Erstellen von RDF von Hand ist aufwändig und fehleranfällig und daher keine praktikable Lösung. In diesem Blogpost möchte ich euch zeigen, wie ihr mit ChatGPT unstrukturierte Daten aus E-Mail-Bestellbestätigungen und anderen Textquellen im Solid Pod speichern könnt.

ChatGPT, ein von OpenAI trainiertes Sprachmodell, kann unstrukturierten Text in strukturierte Daten umwandeln und damit auch das Erstellen von RDF ermöglichen. Dies ist in allen Fällen hilfreich, in denen man keine strukturierten Daten hat, aber ein interoperables Format für Solid benötigt.

Ich habe genau das nun ausprobiert, um eine E-Mail-Bestellbestätigung in RDF umzuwandeln, und war beeindruckt! Zwar musste ich noch ein paar Fehler manuell korrigieren, aber im Vergleich zur manuellen Übertragung aller Daten war das immer noch eine große Zeitersparnis.

Hier ist ein Beispielprompt, den ich ChatGPT gegeben habe:

Konvertiere folgende Bestelldetails nach RDF:

Ihre Bestellung Nummer 3456789 vom 08.12.2022

Carenesse Aleppo Soap, 60% Olive Oil 40% Laurel Oil, Approx. 200 g, original olive oil soap, natural product, vegan handmade shower soap, natural soap
Verkauf durch: Carenesse - natürlich schön
Rücksendung bis zum 31.01.2023 möglich.
EUR 11,69
Zustand: Neu - Carenesse Qualität, garantiert echt nur mit Carenesse-Etikett/Label, nur bei Carenesse

Und hier ist das beeindruckende Ergebnis, das ich von ChatGPT schlussendlich erhalten habe:

@prefix rdf:    <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix xsd:    <http://www.w3.org/2001/XMLSchema#> .
@prefix schema: <http://schema.org/> .

<#this>
    a schema:Order ;
    schema:orderNumber "3456789" ;
    schema:orderDate "2022-12-08T00:00:00Z"^^xsd:dateTime ;
    schema:acceptedOffer [
        a schema:Offer ;
        schema:itemOffered [
            a schema:Product ;
            schema:name "Carenesse Aleppo Soap" ;
            schema:description "60% Olive Oil 40% Laurel Oil, Approx. 200 g, original olive oil soap, natural product, vegan handmade shower soap, natural soap" ;
            schema:seller [
                a schema:Organization ;
                schema:name "Carenesse - natürlich schön"
            ] ;
        ] ;
        schema:price [
            a schema:PriceSpecification ;
            schema:price "11.69" ;
            schema:priceCurrency "EUR"
        ] ;
        schema:itemCondition "http://schema.org/NewCondition" ;
        schema:description "Rücksendung bis zum 31.01.2023 möglich."
    ] .

Man beachte, dass ChatGPT hier verschiedene Elemente der Bestellung wie Bestellnummer, Artikel, Preis und Verkäufer erkannt und strukturiert hat. Es war faszinierend, fast schon magisch, zu sehen, wie ChatGPT aus meinen unstrukturierten Bestelldetails RDF erzeugt hat.

Wenn ihr also auch Schwierigkeiten habt, strukturierte Daten aus z.B. E-Mail-Bestellbestätigungen zu gewinnen und in eurem Solid-Pod zu speichern, kann ChatGPT eine interessante Option sein. Allerdings sollte man dabei beachten: ChatGPT ist ein Cloud-Dienst, was bedeutet, dass ihr eure Daten an einen externen Anbieter übertragen müsst. Dies passt nicht ganz zum Ziel von Solid, volle Kontrolle über die eigenen Daten zu behalten. Mit Bedacht eingesetzt kann es aber sehr hilfreich sein und hat enormes Potential.

Conversations about Software Engineering: Solid

Ich habe mit dem CaSE-Podcast über Solid gesprochen.

In der Folge gehe ich näher darauf ein, wie eingeschränkt wir mit den heute typischen Apps sind und welche Möglichkeiten uns das Solid-Ökosystem im Gegenzug eröffnet. Viel Spaß beim Anhören!

Solid is a specification that lets people store their data securely in decentralized data stores called Pods. But why do we want to keep our data decentralized? What problems does Solid solve? In this episode, Angelo Veltens explains to Lucas Dohmen the advantages (but also potential disadvantages) of this project.

Solid Forms: Deklarative datengetriebene User Interfaces

Kontrolle über die eigenen Daten ist ein wesentliches Ziel von Solid. Dazu werden Daten in User Pods gespeichert und sind unabhängig von bestimmten Apps. Ich kann mir eine passende Anwendung für meine Zwecke aussuchen und diese jederzeit leicht wechseln.

Wirkliche Kontrolle erhält man aber nur, wenn man selbst in der Lage ist Daten zu erzeugen und für sich zu nutzen, ohne abhängig davon zu sein, dass jemand anderes erst eine App entwickelt. Benutzer*innen sollen in der Lage sein, genau die Daten in ihren Pod zu schreiben die sie brauchen. Nicht jede*r kann oder will erst eine komplexe Programmiersprache lernen, um eine App für ein bestimmtes Problem zu entwickeln.

Ein Low Code System für Solid

Das Solid Forms System ermöglicht die deklarative Beschreibung von Eingabeformularen und somit die Erstellung einfacher Anwendungen. Die Formulare werden einfach mittels Linked Data beschrieben (zum Beispiel in Turtle Syntax) und irgendwo im Web hinterlegt (im Pod, auf Github, …). Man kann sie entweder von Hand schreiben, oder eine App nutzen. Solid Forms sind quasi die Low Code / No Code Variante von Solid Apps.

Ein einfaches Solid Form in Turtle Syntax kann wie folgt beschrieben werden:

ex:form a ui:Group
  ui:parts (ex:part1 ex:part2) .

ex:part1 a ui:SingleLineTextField ;
  ui:property vcard:fn;
  ui:label "name" .

ex:part2 a ui:EmailField ;
  ui:property vcard:hasEmail ;
  ui:label "email" .

Dieses Formular besteht aus zwei Eingabefeldern: Eines für den Namen und eines für die E-Mail-Adresse. Diese Form des High-Level-Designs erlaubt mehrere unterschiedliche Implementierungen, also Code der die Formulare dann tatsächlich als User Interface benutzbar macht. Eine solche Implementierung ist Teil von solid-ui, der UI-Bibiothek von SolidOS. Weitere Implementierungen, z. B. in ReactJS und MUI, als Web Components, oder für native Apps sind denkbar.

Rendering des oben beschriebenen Formulars mittels solid-ui

Zur Beschreibung der Eingabefelder benutzt Solid Forms die UI-Ontologie, welche zahlreiche nützliche Felder, von der einfachen Texteingabe bis zum Color-Picker bereits mitbringt. Komplexere Felder können davon abgeleitet werden. Kennt eine Implementierung ein bestimmtes Feld nicht, kann sie auf eine einfachere Eingabevariante zurückfallen, sodass Anwendungen stets benutzbar bleiben.

Solid Forms kennt viele verschiedene Arten von Eingabefeldern (klicken zum Vergrößern)

Wird ein Solid Form abgeschickt, speichert es die Daten im Solid Pod. Jemand der ein Formular erstellen möchte, muss sich also weder um die Programmierung des Frontends, noch des Backends kümmern, sondern kann sich voll und ganz auf die inhaltliche Beschreibung eines Formulars für die benötigten Daten kümmern. Programmierkenntnisse sind dazu nicht erforderlich.

Links die Beschreibung des Formularfeldes, rechts das Rendering durch die Forms-Implementierung (hier solid-ui) und in der Mitte das RDF-Tripel, das im Pod abgespeichert wird. (klicken zum Vergrößern)

Deklarative Micro-Frontends

Ein weiterer interessanter Aspekt ist die mögliche Verlinkung von Formularen. Da es sich um Linked Data handelt, können verschiedene Teile eines Formulars auf unterschiedlichen Servern liegen und von verschiedenen Verantwortlichen gepflegt werden. Man kann also ein ganzes „Web of Forms“ erstellen. Solid Forms ermöglicht damit sozusagen deklarative Micro-Frontends! Natürlich können die Forms auch mit dem Rest des Web of Data verknüpft werden. Autocomplete-Felder können Daten aus öffentlichen Quellen, wie zum Beispiel Wikidata laden, oder Vorschläge aus dem persönlichen Pod einblenden.

Ein durch solid-ui gerendertes Autocomplete mit Vorschlägen aus Wikidata.

Ein Formular für Formulare

Formulare in Turtle zu beschreiben ist zwar einfacher als Programmieren, aber sicher nicht für jede*n etwas. Da Formulare aber auch nur Daten (Linked Data) sind, können sie wie alles andere auch durch Apps erzeugt werden. Dies senkt die Einstiegshürden weiter ab.

Vorsicht, jetzt wird es meta: Eine App zur Erzeugung von Formularen kann auch als Solid Form beschrieben werden. Das „Form Form“ ermöglicht es andere Solid Forms zu erstellen und zu bearbeiten.

Going meta: Mit dem „Form Form“ können Solid Forms mittels UI bearbeitet werden. Dieses UI ist selbst ein Solid Form.

Tim Berners-Lee, der Erfinder des WWW und Begründer von Solid, hat das Forms Systems am Mittwoch persönlich vorgestellt und erklärt. Eine Aufzeichnung seiner Präsentation könnt ihr hier anschauen.

Das Form System ist sehr mächtig, aber noch spärlich dokumentiert. Zukünftig sollen Tutorials für Einsteiger*innen entstehen. Weitere Implementierungen mit einer guten User Experience und Form Registries zur Wiederverwendung von nützlichen Formularen (so etwas wie GitHub für Forms) sind zukünftig denkbar.

Weiterführende Links

Alice und Bob entdecken Solid

Was ist Solid? In 30 unterhaltsamen und leicht verdaulichen Comics hat Patrick Hochstenbach dies im „Solvember“ erklärt – jeden Novembertag gab es ein neues Bildchen zum Thema Solid.

Das Comic Solvember #1
 Creative Commons Attribution-ShareAlike 4.0 International License. (c) @hochstenbach 2021

Angefangen bei den Grundlagen zeigen die Protagonist*innen Alice und Bob unter anderem wie Zugriffskontrolle mittels WebACL und Linked Data Notifications funktionieren und was das für die beiden in der Praxis bedeutet.

Schaut es euch an! Alle Abenteuer von Alice und Bob findet ihr zum Durchstöbern auf seinem Solid Pod.

programmier.bar Podcast zum Solid Project

Ich war zu Gast bei der programmier.bar und hab ein bisschen was zu Solid erzählt:

Klingt “All of your data, under your control.” gut für dich? Diesen Ansatz verfolgt das Solid Project und will damit das Internet dezentralisieren. Geleitet wird es von Tim Berners-Lee, dem Erfinder des World Wide Web selbst, der die heutige Entwicklungsrichtung des Umgangs mit Nutzungsdaten kritisch sieht. Wie eine Dezentralisierung ablaufen soll, erklärt uns in dieser Folge Angelo Veltens.

Folge 79 – Solid Project mit Angelo Veltens

Hört mal rein 🙂

Tweets befreien: Solid Pod als persönliches Twitter-Archiv nutzen

Bei Diensten wie Twitter, vertraue ich meine Inhalte und Daten einem zentralen Anbieter an. Das kann zum Problem werden, da ich von diesem Anbieter abhängig werde und die Kontrolle verliere, ob und wie lange meine Daten für mich und andere verfügbar sind. Ich möchte jedoch Datensouveränität, also meine Daten langfristig für eigene Zwecke nutzen können. Ich habe deshalb alle meine Tweets in einen Solid Pod exportiert.

Dank der DSGVO sind Twitter und Co. inzwischen verpflichtet, persönliche Daten auf Anfrage maschinenlesbar heraus zu geben. Bei Twitter findest du die Option in den Account Einstellungen unter „Deine Twitter Daten“:

Twitter Archiv anfordern

Sobald Twitter dir das Archiv bereit gestellt hat, kannst du dessen kompletten Inhalt auf einen Solid Pod hochladen. Neben strukturierten JSON-Daten enthält es auch eine hübsche HTML Variante, die du unter der entsprechenden Pod-URL abrufen kannst:

HTML Twitter-Archiv im Solid Pod

Nun hast du ein persönliches Online-Archiv all deiner Twitter-Aktivitäten, das dir niemand mehr wegnehmen kann. Die Zugriffsrechte des Ordners solltest du auf jeden Fall beschränken, da das Archiv auch private Daten, wie zum Beispiel Direktnachrichten enthält.

Die HTML-Seite ist ganz nett, die Stärke von Solid liegt aber in der Verlinkung von Daten, um diese in anderen Kontexten nutzbar zu machen. Ich möchte, dass andere auf die Tweets verweisen können, um mit ihnen zu interagieren. Ich habe daher die öffentlichen Tweets auch als Linked Data in meinem Pod verfügbar gemacht.

Im Original-Archiv liegen alle Tweets maschinenlesbar in der Datei data/tweet.js vor. Mit einem kleinen NodeJS-Skript habe ich diese zu Linked Data konvertiert. Zunächst iteriert das Skript durch die Liste der Tweets und legt für jeden Tweet eine Ressource in einem rdflib Store an:

const me = sym('https://angelo.veltens.org/profile/card#me');
tweets.forEach(({id, full_text, created_at}) => {
    const date = new Date(created_at);
    const path = createPath(date, id);
    const doc = sym(`https://store.example/${path}`)
    const it = sym(`https://store.example/${path}#it`);

    store.add(it, RDF('type'), AS('Note'), doc);
    store.add(it, AS('content'), full_text, doc);
    store.add(it, AS('attributedTo'), me, doc);
    store.add(it, AS('published'), date, doc);
    store.add(it, AS('url'), sym(`https://twitter.com/i/web/status/${id}/`), doc);

    targetFiles.push({ doc, path })
});

Ich habe mich für das Activity-Streams-Vokabular entschieden, da dieses bereits erfolgreich im Fediverse (z.B. Mastodon) verwendet wird und ich möglichst kompatibel werden möchte.
Nachdem alle tweets zum Typ as:Note konvertiert wurden exportiere ich jede Ressource in eine eigene Turtle (.ttl) Datei. Dadurch können bei Bedarf feingranulare Zugriffsrechte gesetzt werden:

targetFiles.forEach(({doc, path}) => {
    const data = serialize(doc, store, null, 'text/turtle')
    const file = `./data/result/${path}$.ttl`
    writeFile(file, data);
})

Das war auch schon alles Wesentliche. Das ganze Skript inklusive der hier nicht gezeigten Hilfsmethoden habe ich als Snippet bei Gitlab hinterlegt.

Nachdem das Ergebnis auf einen Solid Pod geladen wurde, wird jeder Tweet durch eine URI identifiziert und kann abgerufen und verlinkt werden. Der unten abgebildete Tweet zum Beispiel hat die URI https://angelo.veltens.org/public/tweets/2019/08/1161337802652626946#it.

Der Solid Data Browser ist in der Lage, sowohl eine HTML Ansicht des Tweets zu rendern, als auch die zugrunde liegenden Rohdaten anzuzeigen:

Nun können die „Tweets“ im Solid Ökosystem ihr volles Potential entfalten und unabhängig von der Plattform Twitter bestehen.

Vielleicht hast du ja Lust, eine Solid Microblogging-App zu bauen?

Mit Solid nach Mastodon posten, geht das?

Ein Blogpost bei Mastodon beschreibt, wie man quasi „manuell“ über das ActivityPub Protokoll auf einen Mastodon-Toot antworten kann.

We want to send a Mastodon user a message from our own, non-Mastodon server.

Ich dachte mir: Das muss doch auch mit einem Solid Pod klappen. Angelehnt an den Originalartikel ist unser Ziel in diesem Artikel daher:

Wir wollen einem Mastodon User eine Nachricht von unserem Solid Pod senden.

Los geht’s! 🚀

Der „Actor“

Idealerweise würden wir natürlich mit unserer Solid Web ID tätig werden, da ich aber im ersten Schritt möglichst wenig vom Originalartikel abweichen möchte (um mögliche Probleme zu vermeiden), habe ich mir wie dort beschrieben ein Schlüsselpaar angelegt und das fertige JSON-LD für den Actor auf meinem Solid Pod veröffentlicht. Leider ist der Data Browser Stand heute nicht in der Lage die Rohdaten aufzubereiten. Ein klassisches curl zeigt aber, dass es geklappt hat:

> curl https://angelo.veltens.org/profile/actor

{
  "@context": [
  "https://www.w3.org/ns/activitystreams",
  "https://w3id.org/security/v1"
  ],
  "id": "https://angelo.veltens.org/profile/actor",
  "type": "Person",
  "preferredUsername": "angelo",
  "inbox": "https://angelo.veltens.org/inbox",
  "icon": {
    "type": "Image",
    "mediaType": "image/jpeg",
    "url": "https://angelo.veltens.org/profile/me.jpg"
  },
  "publicKey": {
  "id": "https://angelo.veltens.org/profile/actor#main-key",
  "owner": "https://angelo.veltens.org/profile/actor",
  "publicKeyPem": "-----BEGIN PUBLIC KEY..."
}
}

Ich hab auch gleich noch ein Profilbild (icon) dazu gepackt, damit es etwas persönlicher aussieht und auch meine normale Solid Inbox verlinkt.

Webfinger

Auch die statische Webfinger Datei ist leicht platziert, da der Node Solid Server einen .well-known Ordner von Haus aus mitbringt. Nun lässt sich das Profil schon über die Mastodon-Suchleiste auffinden 🎉

Der auf dem Solid-Pod platzierte Actor ist über Mastodon auffindbar

So weit so gut!

Die Nachricht

Auch die Nachricht verfasse ich wieder als JSON-LD und lege sie in meinem Pod ab:

{
  "@context": "https://www.w3.org/ns/activitystreams",

  "id": "https://angelo.veltens.org/public/toots/hello-solid#create",
  "type": "Create",
  "actor": "https://angelo.veltens.org/profile/actor",

  "object": {
    "id": "https://angelo.veltens.org/public/toots/hello-solid#note",
    "type": "Note",
    "published": "2020-07-12T20:26:27+0200",
    "attributedTo": "https://angelo.veltens.org/profile/actor",
    "inReplyTo": "https://mastodon.social/@Gargron/100254678717223630",
    "content": "<p>Hello from Solid</p>",
    "to": "https://www.w3.org/ns/activitystreams#Public"
  }
}

Für den folgenden Schritt, brauchen wir die Datei aber auch auf dem lokalen Rechner.

Das Skript

Für die Erzeugung einer gültigen HTTP-Signature brauchen wir ein Skript, wie im Originalpost bereits beschrieben. Dort müssen wir noch unsere eigene keyId hinterlegen und ggf. den Namen der JSON-Datei an unsere anpassen, aber dann kann es schon losgehen.

Das Skript gibt leider keine Auskunft, ob es geklappt hat. Bei mir war es so, dass mein Post partout nicht bei Mastodon erscheinen wollte. Ich habe das Skript daher erstmal so umgeschrieben, dass es ein curl Kommando erzeugt, das ich manuell ausführen und besser debuggen kann:

Trotzdem hat die Antwort auf den Post von @Gargon erstmal nicht funktioniert. Der Server antwortete mit 202 (Accepted), aber die Nachricht erschien immer noch nicht! 😒

Der Durchbruch ⛏

Im SocialHub Forum gibt es ein paar Spekulationen woran es liegen könnte. Der Node Solid Server geht z.B. nicht korrekt mit dem Mime-Type application/activity+json um, und versteht auch JSON-LD Profile nicht korrekt.

Letztlich habe ich es aber doch noch geschafft einen Post abzusetzen, der auch auf Mastodon sichtbar wird. Bei mastodon.online hat es funktioniert. Dort hatte ich mir zuvor einen nativen Account angelegt, um die Webfinger-Suche zu testen. Auf einen Post dieses Accounts konnte ich dann auch mit meinem Solid-Actor antworten. Möglicherweise liegt es daran, dass die mastodon.online Instanz den Actor durch die vorherige Suche schon kannte, aber sicher weiß ich es nicht.

Hier ist jedenfalls das Ergebnis:

Bonus: Inbox-Nachrichten

Bereits kurz nachdem ich erstmals meinen Actor auf mastodon.online suchte, fiel mir auf, dass dieser Server seitdem Änderungen in meine Inbox kommunizierte.

Warum also nicht mal eine Direktnachricht ausprobieren? 💌

Mit dem Mastodon Account schreibe ich meinen Solid-Actor an

Die Nachricht konnte problemlos abgesetzt werden und erschien kurz darauf in der Inbox meines Solid-Pods. Da der Data Browser nicht in der Lage ist JSON-LD Daten anzuzeigen, habe ich die Daten kurzerhand manuell nach Turtle konvertiert:

Nach der manuellen Konvertierung kann auch der Data Browser die Daten anzeigen.

Fazit

Es funktioniert! Ein Solid Pod eignet sich grundsätzlich, um einen ActivityPub Actor und Posts zu beherbergen. Die LDP Inbox ist in der Lage Nachrichten von Mastodon zu empfangen. Hier und da hakt es noch und das alles ist natürlich weit entfernt von einer praktischen Benutzbarkeit. Es zeigt aber, dass Solid und ActivityPub sich technisch gut ergänzen. Einen Solid Server kompatibel zu gestalten dürfte keine große Herausforderung sein. Wenn die Daten dann auch noch hübsch dargestellt werden, bietet ein Solid Pod ein Tor zum Fediverse.

Solid: Neues aus der Community, große Ankündigungen von Inrupt

Was ist eigentlich in den letzten Monaten im Solid-Projekt passiert? Die Solid World July gibt einen Überblick über das 1. Halbjahr 2020.

Während am W3C die Spezifikation verfeinert wird und die Community an Apps tüftelt, fällt Inrupt erstmals seit langem wieder mit großen Ankündigungen auf.

Solid World_July from Solid Project on Vimeo.

W3C Solid Community Group

Die Community Group arbeitet in verschiedenen Panels an der Weiterentwicklung der Spezifikationen. Sie sammelt dazu Use Cases und Anforderungen von App-Entwickler*innen und Solid Early Adaptors.

Solid Community

Die Solid Community insgesamt arbeitet darüber hinaus auch an Apps, Tools, Dokumentation und mehr. Wie man mitwirken kann beschreibt der Prozess. Die Website unter solidproject.org bietet einen guten Einstieg für Benutzer*innen, Entwickler*innen, Unternehmen und allgemein Interessierte. Darüber hinaus gibt es weiterhin das Forum, den Chat und eine Reddit Community.

Open Link

Open Link arbeitet schon seit vielen Jahren an Linked Data und WebID Software. Der Support von Solid ist ein logischer Schritt. Mit YouID lassen sich Solid Profildokumente und Identitäten erstellen. Der Structured Data Sniffer erlaubt das Speichern von Webseiten und Daten im Solid Pod.

Inrupt

Inrupt fällt mit großen Neuankündigungen auf: Ein Team der Ghent University unter Führung von Ruben Verborgh entwickelt den Community Solid Server, eine Open-Source-Neuentwicklung und Alternative zum Node Solid Server (NSS). Inrupt finanziert und unterstützt die Entwicklung.

Für NSS wird Inrupt noch Bugfixes und Sicherheitsupdates bereitstellen, aber keine neuen Features mehr entwickeln. Außerdem hat Inrupt neue JavaScript-Client-Bibliotheken veröffentlicht und weitere für andere Programmiersprachen angekündigt.

Inrupt ist mit dem pod-server und dem react-sdk zuvor bereits Ähnliches angegangen und dort nach einiger Zeit eher mit Inaktivität und Intransparenz aufgefallen. Ich bin gespannt ob die neuen Anläufe ihren Schwung erhalten und Inrupt die Kommunikation mit der Community wieder intensiviert. Regelmäßige Statusupdates wurden auf der Solid World zumindest versprochen.

Eine weitere vielversprechende Ankündigung ist ein Enterprise Solid Server, der hoffentlich eine gute Grundlage für professionelles Pod-Hosting und unternehmenskritische Anwendungen geben wird.

Informiert bleiben

Die Solid World findet monatlich statt. Updates zum Nachlesen gibt es im Newsletter This Month in Solid.

Solid Basics #003 – Immer der Nase nach

Wie finde ich interessante Daten in Solid Pods? Solid arbeitet nach dem Prinzip „Follow your nose“. Sowohl Menschen, als auch Maschinen und Apps können damit, ausgehend vom Social-Web-Profil, weitere interessante Daten finden.

Mit diesem Prinzip, kannst du zum Beispiel die Folien meiner Vorträge in meinem Solid Pod entdecken. Legen wir los!

Ausgangspunkt ist mein Profil unter https://angelo.veltens.org/profile/card. Es verlinkt meine WebID mit einer Vielzahl weiterer Informationen. Wenn du den Link anklickst, öffnet sich der „Solid Data Browser“. Nicht erschrecken: er ist noch sehr hässlich, aber dennoch äußerst nützlich, um „Follow your nose“ zu verdeutlichen.

Relativ weit oben findest du meinen Namen „Angelo Veltens“ gefolgt von „performer In“ und einer Auflistung von „it“. Es handelt sich dabei um Daten-Tripel, die eine Beziehung zwischen mir und weiteren Dingen herstellen.

Alle Bestandteile dieser Tripel sind Links, die wir anklicken können, um zu verstehen was genau dahinter steckt. Klicke mit der mittleren Maustaste auf „performer In“, um den Link in einem neuen Tab zu öffnen. Du befindest dich nun auf schema.org und erfährst:

Event that this person is a performer or participant in.

Beschreibung der Beziehung „performerIn“ bei schema.org.

Wir wissen nun also, dass „perfomer In“ auf Veranstaltungen verweist, auf denen ich aufgetreten bin. Folgen wir dieser Spur weiter! Zurück auf der Profilseite klickst du auf einen der „it“-Links, um Informationen zur jeweiligen Veranstaltung abzurufen. Dort werden wir womöglich auf Vortragsfolien stoßen.

Im Data Browser öffnen sich nun Informationen zur ausgewählten Veranstaltung. Ab jetzt geht es in einer Baumstruktur weiter. Frag mich nicht warum – ich sagte bereits, das User Interface ist murks 🤷‍♂️. Bitte versuche es für den Moment zu akzeptieren und das dahinterliegende Prinzip zu verstehen.

In den Veranstaltungsdaten findest du neben Name und Beschreibung auch einen Punkt „Work Featured“. Klicke auf das kleine Dreieck vor „slides“, um weitere Daten auszuklappen. Der Type „Presentation Digital Document“ lässt erahnen, dass wir die Folien gefunden haben.

Daten eines Events in einer aufklappbaren Baumstruktur. „Work featured“ führt weiter zu den Vortragsfolien.

Um die Folien einzusehen, müssen wir aber noch die konkreten Dateien finden. Davon kann es mehrere geben. Unter „Associated Media“ kannst du einen weiteren Abschnitt „web“ und/oder „pdf“ aufklappen und kommst dort zu konkreten Ausprägungen der Folien (PDF oder HTML). Wenn du nun noch die „Content Url“ aufklappst kannst du die Folien betrachten. (Alternativ kannst du den Wert von „Content Url“ per drag-and-drop in die Browserleiste ziehen – erneut 🤷‍♂️)

Einige Ebenen tiefer finden sich die konkreten Dateien der Vortragsfolien. In diesem Bild als PDF-Dokument.

Wozu der ganze Aufriss?

Zugegeben, das war jetzt nicht nur wegen des Data-Browser-UIs eine schlechte User Experience. Darum geht es hier aber auch gar nicht.

Ein wichtiger Aspekt von Solid ist die grundsätzliche Auffindbarkeit von Daten, ausgehend vom Profil einer Benutzer:in, allein durch das Folgen von Links. In der Praxis wird das, was wir hier mühsam von Hand durchgeführt haben, durch Apps automatisiert.

Wirf einen Blick in den Abschnitt „Talks“ meiner Website. Die Seite macht genau das, was wir gerade getan haben, nur viel schneller und automatisch. Dadurch ist die Seite in der Lage alle Infos, Folien und Videoaufzeichnungen meiner Talks gebündelt und gut zugänglich darzustellen.

Durch die Trennung von Apps und Daten, sind auch andere Webseiten und Anwendungen in der Lage, diese Informationen zu verwerten.

Das Follow-your-nose-Prinzip lässt sich automatisieren. Apps können die Daten dann auch „in hübsch“ anzeigen.

Solid – Fragen & Antworten

Auf der FrOSCon 14 habe ich einen Talk zu Solid gehalten. In der anschließenden Fragerunde gingen überwältigend viele Hände nach oben. Ich möchte diesen Blogartikel nutzen, um die zahlreichen Fragen noch einmal aufzugreifen, sie zu dokumentieren und gegebenenfalls etwas ausführlicher zu beantworten, als es in der knappen Zeit möglich war.

Ist es geplant, Daten von Facebook importieren zu können?

Ja, das ist definitiv geplant und Leute arbeiten daran. In der Praxis ist es tatsächlich nicht so einfach, da sich Facebook mit Händen und Füßen gegen solche Initiativen wehrt. Facebook hat eigentlich die Pflicht – spätestens seit der DSGVO – alle Daten herauszugeben.

Ruben Verborgh hat versucht, von diesem Recht Gebrauch zu machen und wirklich alle Daten von Facebook zu erhalten. Sein Ringen mit dem Konzern zieht sich nun schon seit Monaten hin.

Es ist aber nur eine Frage der Zeit, bis Facebook sich dem geltenden Recht beugen muss. Dann wird es für uns alle einfacher, unser Recht durchzusetzen. Tools, welche die Daten in ein Solid-kompatibles Format übersetzen, lassen sich dann recht leicht programmieren.

Wer kann Bobs Kommentar unter dem Beitrag von Alice sehen? Wer legt die Zugriffsrechte fest?

Wenn Bob einen Kommentar schreibt, wird dieser in Bobs eigenem Pod gespeichert. Bob selbst kann bestimmen, wer darauf zugreifen darf. Der Pod steuert die Zugriffsrechte über Web Access Control (WAC). Damit Alice den Kommentar lesen kann, wird Bob ihr zumindest Leserechte geben. Er kann darüber hinaus aber auch der Öffentlichkeit, oder einer bestimmten Gruppe Rechte erteilen. Ob der Kommentar tatsächlich unter Alices Beitrag erscheint, kann Alice entscheiden, indem sie zu Bobs Beitrag verlinkt, oder dies unterlässt.

Ich identifiziere mich über eine URI im Web. D.h. mein Hoster kann sich als mich ausgeben?

Die URI allein reicht dazu nicht. WebID-OIDC erfordert zur Authentisierung auch Benutzername und Passwort. Wie bei regulärem Webspace oder zentralen Diensten gilt aber auch bei Solid: Ich muss meinem Anbieter vertrauen. Ein Server- bzw. Dienste-Betreibender kann grundsätzlich die dort gespeicherten Daten einsehen und ggf. auch die Identität von Accounts annehmen. Solid unterscheidet technisch zwischen reinen Daten-Pods und dem Identity Provider, welcher die Authentifizierung vornimmt. Nur letzterer könnte mit böser Absicht deine Identität missbrauchen. Das wäre in etwa so, als wenn dein Mail-Provider eine Mail in deinem Namen versendet. Ein seriöser Anbieter ist also essentiell.

Wenn du auf Nummer sicher gehen willst, betreibst du den entsprechenden Pod selbst. In weniger sensiblen Bereichen kannst du dann dennoch auf gehostete Pods setzen. Jede Person kann ihr persönliches Maß an Schutzbedürftigkeit und Vertrauen selbst definieren.

Kann ich Daten von einem Pod exportieren und zu einem anderen umziehen? Was passiert mit den bestehenden Links?

Ja, das geht. Bestehende Links können durch eine Weiterleitung (HTTP Redirect) auf das neue Ziel verweisen.

Alternativ kannst du eine eigene Domain benutzen. Das geht durch entsprechende DNS-Konfiguration auch dann, wenn du den Pod nicht selbst betreibst. Wenn du den Pod-Provider wechselst, ziehen nur die Daten um, bleiben aber unter deiner Domain erreichbar.

Angenommen ich erlaube, dass in einem Post mein Bild angezeigt wird. Kann ich explizit einer Anwendung verbieten, dieses Bild anzuzeigen? Wird bei jedem Linkzugriff die Authentifizierung geprüft?

Ja, du kannst einzelne Anwendungen und auch einzelne Nutzer:innen sperren. Dein Pod prüft die Berechtigungen, bevor er dein Bild, oder irgendwelche Daten, an eine Anwendung ausliefert.

Wie sieht es mit mobilen Apps aus?

Solid ist nicht auf Web-Apps beschränkt. Auch native Apps sollen auf Pods zugreifen können. Solid Apps sind oft Webanwendungen oder Progressive Web Apps (PWA), weil dies für die meisten Anwendungsfälle ausreicht. Für native mobile Apps brauchen wir noch mehr Leute, die sich mit dem Thema beschäftigen. Die Library-Unterstützung ist hier noch nicht so gut.

Wie gut skaliert Solid? Gibt es Probleme mit mehreren Pods / Datenquellen?

Bis jetzt habe ich in der Praxis keine Performanceprobleme gesehen. Auch wenn ich angenommen hunderte Freunde habe und tausende Bilder in der Timeline: Eine App zeigt ja nie alles auf einmal an, sondern hat eine Seitennavigation oder Endless-Scrolling. Wenn gleichzeitig nur 10 oder 20 Bilder angezeigt werden, passieren auch nur 10-20 Requests. Das ist absolut kein Problem. Auch mehrere Datenquellen sind kein Thema: Das Web kennt nur URIs und ruft die Daten von diesen ab, egal wo sie liegen. Die Last verteilt sich dann sogar auf mehrere unabhängige Server.

Was wenn ich meinen Server abschalte?

Nehmen wir an, du hast einen Kommentar zu meinem Beitrag geschrieben. Mein Beitrag verlinkt zu diesem. Nun schaltest du deinen Server ab. Eine App, die meinen Beitrag lädt und dann dem Link zu deinem Kommentar folgt, wird einen HTTP Status 404 (Not Found) oder vielleicht 500 oder ähnliches bekommen.

Die Apps müssen mit so etwas umgehen können, den Kommentar vielleicht ausblenden, oder „gelöschter Kommentar“ oder ähnliches anzeigen. Solche Fehler werden definitiv auftreten. Eine gute Solid App ist resilient programmiert und geht vernünftig damit um.

Macht es Diskussionen nicht unübersichtlich, wenn Server ausfallen oder abgeschaltet werden?

Möglicherweise ja. Die Frage ist, wird es unübersichtlicher als heute auf zentralen Plattformen? Auch dort kommt es vor, dass der Anbieter Inhalte sperrt oder Accounts löscht. Oder Diskutierende löschen ihre Beiträge wieder, oder blockieren dich. Ich gehe davon aus, dass die Masse der Solid Pods auf zuverlässigen Systemen betrieben wird. Das garantiert aber nicht, dass alle Inhalte für alle Zeit erreichbar sein werden.

Bei Diaspora und Mastodon sind am Ende doch alle bei einer zentralen Platform gelandet. Wo ist der Unterschied?

Der Unterschied ist, dass wir alle frei wählen können, wo wir welche Daten speichern und über welche Apps wir diese nutzen. Wenn 90% am Ende bei einem einzigen Anbieter sein wollen, ist das aus meiner Sicht ok. Daraus allein ergibt sich noch kein Problem. Entscheidend ist, dass unsere Daten und Interaktionen zueinander kompatibel sind. Im Gegensatz zu z.B. Mastodon ist Solid auch nicht auf einen einzelnen Use-Case („twittern“) beschränkt, sondern bietet eine Plattform um alle denkbaren Apps zu entwickeln und miteinander zu vernetzen. Es trennt strikt zwischen Apps und Daten. Bei „dezentralen Daten-Silos“, wie Mastodon und Diaspora ist es bequem sich einfach bei einer prominenten Instanz anzumelden und diese zu nutzen, was ungewollt un einer Zentralisierung führt. Bei Solid hingegen, ist es bequem Daten zu dezentralisieren und Apps zu wechseln, weshalb ich denke, dass dies passieren wird, ohne dass Menschen darüber groß nachdenken.

Wo liegt der Unterschied zu Protokollen wie ActivityPub?

Beide haben gewisse Überschneidungen in den Zielen. ActivityPub und Solid können sich gut ergänzen. Ein Solid Server könnte z.B. das Activity Pub Protokoll implementieren. Das Activity Streams Vokabular lässt sich schon heute wunderbar nutzen, um Social-Web-Aktivitäten in einem Solid Pod zu speichern. Solid insgesamt bietet aber deutlich mehr Freiheiten und geht über den Zweck von ActivityPup hinaus. Im Solid Ökosystem lassen sich alle möglichen Daten miteinander verlinken.

Gibt es einen Standard um Referenzen zu eigenen (wissenschaftlichen) Publikationen abzulegen?

Da Solid und allgemein Linked Data im wissenschaftlichen Umfeld entstanden sind, sollte es gerade in diesem Bereich an nichts mangeln. Mit Dublin Core z. B. lassen sich die wichtigsten Metadaten über Veröffentlichungen erfassen.

Wo liegen denn die verlinkten Daten? Was wenn ich berühmt werde und zehntausende Requests bekomme?

Um viele Anfragen verarbeiten zu können, muss ein Pod-Server skalieren. Daten die ein so großes öffentliches Interesse wecken, wirst du definitiv nicht mehr auf einem Raspberry Pi bei dir zuhause hosten können, sondern du suchst dir einen guten Dienstleister.

Das heißt aber nicht, dass du alle deine Daten bei einem Provider hosten musst. Bei Solid kannst du die Daten auf beliebig viele Pods verteilen und miteinander verlinken. Während du öffentliche Daten mit vielen Requests bei einem passenden Dienst einstellst, wirst du private Daten vielleicht weiterhin zuhause lagern.

Ist es nicht für die Masse zu kompliziert und aufwändig sich mit Solid zu befassen?

Die Nutzung von Solid-Apps und Pods muss nicht komplizierter sein, als die Benutzung von Social-Media-Diensten heute. Wenn ich mich nicht mit der Technik befassen möchte, dann kann ich die Daten weiterhin „in der Cloud“ speichern. Diese „Cloud“ wird dann jedoch kein abgeschottetes Daten-Silo sein, sondern ein Netzwerk aus verlinkten Solid-Pods. Dadurch habe ich jederzeit Zugriff auf meine Daten und kann frei entscheiden, mit welchen Apps ich sie verwende.

Durch die Verlinkung der Daten sind auch hybride Lösungen kein Problem: So kann ich zum Beispiel öffentliche Bilder im Pod einer kostenlosen Fotoplattform hosten und private Urlaubsfotos beim Pod-Anbieter meines Vertrauens oder auf einem eigenen Server.

Zertifikate muss ich mir selber holen?

Wenn du einen Solid-Server selbst betreiben möchtest, dann muss dieser unter HTTPS laufen und du brauchst ein Zertifikat, ja. Das ist jedoch heute dank Let’s Encrypt keine große Sache mehr.

Wie kann ich darauf vertrauen, dass die Rechte korrekt verwaltet/gesetzt werden?

Auch für die Berechtigungen kann es Solid-Apps geben und du kannst frei wählen, welche du dafür verwenden möchtest. Nimm eine App deines Vertrauens, oder programmiere dir bei Bedarf eine eigene. Grundsätzlich kannst du die Rechte aber direkt im Solid-Server setzen. Da alle Daten (zumindest beim Node Solid Server) als Textdateien vorliegen, kannst du im Zweifel sogar die Rechte über einen einfachen Texteditor wie vim setzen, wenn du auf Nummer sicher gehen möchtest.

Kostet ein Pod wirklich 15-20 Euro?! Also muss ich ordentlich blechen oder meine Privatsphäre aufgeben?

Nein, das ist eine salopp dahergesagte Zahl! Wie die Preise sich entwickeln und welche Geschäftsmodelle und Initiativen entstehen ist völlig offen. Neben bezahlten Dienstleistern können auch öffentliche und soziale Lösungen entstehen: Zum Beispiel könnten Bibliotheken, Vereine und Universitäten als Pod-Hoster in Erscheinung treten. Was auch immer passiert ist jedoch ein Fortschritt im Vergleich zu heute, wo für uns alle nur die Option „Privatsphäre aufgeben“ besteht.