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.

WordPress Blogposts mit Solid verbinden – wp-linked-data 0.5 verfügbar

Ich habe gestern Version 0.5 von wp-linked-data veröffentlicht. Mit diesem WordPress Plugin könnt ihre euer Blog und die Blogartikel als Linked Data verfügbar machen und somit auch mit eurem Solid Profil verknüpfen.

In meinem Solid Profil habe ich dazu folgendes Tripel hinterlegt:

:me <foaf:weblog> <https://datenwissen.de#it>.

Mit folgendem LDflex Ausdruck könnt ihr z.B. die letzten Blogartikel von datenwissen.de ermitteln:

[https://datenwissen.de#it][„sioc:container_of“].dct_title

Auf eurer Benutzerseite in der WordPress-Adminoberfläche könnt ihr eure Solid WebID hinterlegen:

Die Daten eures Blogs verweisen dann auch zurück auf euer Solid Profil.

Die neue Version von wp-linked-data unterstützt zusätzliche RDF Serialisierungen, darunter auch JSON-LD.

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.

FrOSCon 2019: Die Rückeroberung des Social Web (Video)

Ich bin war dieses Jahr auf der FrOSCon mit einem Talk über Solid präsent:

Die Rückeroberung des Social Web

Eine Einführung in Solid

Video auf media.ccc.de öffnen

Folien des Vortrags: Web | PDF

Solid tritt an die Misstände im Social Web zu beheben. Dieser Vortrag erklärt die grundlegenden Konzepte und Technologien hinter Solid. Was macht Solid einzigartig? Welche Probleme löst es? Wie kann man mitwirken?

Letztes Jahr ging Web-Erfinder Tim Berners-Lee mit einem neuen, spannenden Projekt an eine größere Öffentlichkeit. Social Linked Data – kurz Solid – soll die Misstände des zentralisierten Social Webs beheben indem es das dezentrale WWW um soziale Funktionen erweitert und die Nutzer:innen in den Mittelpunkt stellt.

In diesem Vortrag erkläre ich die grundlegenden Konzepte und Technologien hinter Solid, erkläre warum dieser Ansatz so revolutionär ist und was Solid von verteilten Anwendungen wie Diaspora und Mastodon unterscheidet.

Ich werde zeigen, was mit Solid bereits heute möglich ist, was uns in Zukunft erwartet und wie jede:r diese Zukunft mitgestalten kann.

Vollständiges FrOSCon Programm

Solid Basics #002 – Deine Daten gehören dir

Ein wesentliches Merkmal von Solid ist die Trennung von Apps und Daten. Während deine Daten im traditionellen Social Web stets an eine bestimmte App bzw. einen bestimmten Dienst gekoppelt sind, liegen sie im Solid Ökosystem grundsätzlich in deinem eigenen Pod und du hast freie Wahl mit welcher App du sie verwalten und benutzen möchtest. Schauen wir uns an, was das praktisch bedeutet! Wenn du noch keinen Pod hast, besorge dir jetzt deine Identität im Web und wir legen los.

Als Beispiel schauen wir uns eine einfache Bookmarking App an: markbook.org. Dort kannst du beliebige Links als Lesezeichen hinterlegen, zum Beispiel um sie dir zum späteren Lesen vorzumerken.

Dank Solid benötigst du keinen Account bei marbook.org. Deine WebID genügt zum Einloggen: Nach einem Klick auf Login öffnet sich eine Providerauswahl. (Leider zur Zeit in einem Popup, was du ggf. im Browser erlauben musst)

Providerauswahl

Wenn du dich, wie in Teil 1 beschrieben, bei solid.community registriert hast, wählst du „Log in with Solid Community“. Dort loggst du dich dann mit deinem Username und Passwort ganz normal ein und wirst anschließend zurück zu markbook.org geleitet.

Login bei deinem Pod (z.B. solid.community)

Du wirst feststellen, dass markbook.org bereits deinen Namen und – falls du eins hinterlegt hast – dein Profilbild anzeigt. Diese Informationen lädt die App live aus deinem Solid Profil.

Markbook.org speichert selbst überhaupt keine Daten über dich. Nicht einmal die Lesezeichen, die wir gleich dort hinterlegen werden!

Um ein neues Lesezeichen anzulegen, klicke auf „Create Bookmark“ in der blauen Leiste oben. Es erscheint dann ein Dialog, in dem du einen Titel und die URL des Lesezeichen angeben kannst.

Ein Lesezeichen anlegen

Nach einem Klick auf „Post“, wird das Lesezeichen in deinem Solid Pod gespeichert und erscheint bei markbook.org in der Liste.

Das neu angelegte Lesezeichen, angezeigt auf markbook.org, gespeichert in deinem Solid Pod.

Der springende Punkt bei Solid ist, dass dieses Lesezeichen in deinem persönlichen Pod gespeichert wurde – markbook.org speichert keine Daten über dich oder deine Lesezeichen. Es ist eine reine Browser-App, die nur auf deinem Rechner oder Smartphone läuft.

Wenn du dich mit den Entwicklungswerkzeugen deines Browsers auskennst, kannst du dort verfolgen, dass markbook.org lediglich Daten an deinen Solid Pod sendet.

Schauen wir uns zum Abschluss die Daten einmal an! Mit Solid hast du volle Kontrolle über alle Daten die gespeichert werden und kannst diese jederzeit einsehen und löschen. „Deine Daten gehören dir“ ist hier kein Marketing-Bla-Bla, sondern technisch gewährleistet.

Deine Lesezeichen findest du unter einer URL der Form https://<username>.solid.community/public/bookmarks.ttl. Warum ich das weiß, bzw. wie man die genaue URL herausfindet erkläre ich in einem späteren Artikel. (Tipp für Neugierige: Alle Daten sind von deiner WebID ausgehend verlinkt. Folge dem Link namens „publicTypeIndex“). Für heute reicht es, wenn du in der genannten URL einfach deinen Benutzernamen an Stelle von <username> einsetzt.

Wenn du die URL im Browser öffnest, findest du dort die Daten des eben angelegten Lesezeichens.

Viel Spaß beim Experimentieren und Erkunden!

23.05, HamburgJS: Einführung in Solid

Nächsten Donnerstag, 23.05.2019, halte ich einen Talk über Solid beim HamburgJS Meetup.

The inventor of the Web, Tim Berners-Lee, introdruced a project called Solid, which is meant to re-decentralize the Social Web by extending the WWW as we know it with socially interlinked data. Solid shifts the way we have to think about building web applications fundamentally and gives interesting new opportunities. I will give an introduction of what exactly is Solid, how we can be part of it and how to build Solid applications.

(Talk submission)

Das Meetup findet bei Xing, Dammtorstraße 30, statt und beginnt um 19 Uhr.

Solid Basics #001 – Deine Identität im Web

Um am neuen Social Web teilhaben zu können, benötigst du zunächst (mindestens) eine globale Identität (WebID). Da Solid ein völlig offenes Ökosystem ist, kann im Prinzip jede Webaddresse (URI) mit entsprechender Konfiguration als WebID dienen. Ich möchte in dieser „Solid Basics“ Reihe die Dinge aber möglichst einfach halten. Ich zeige dir daher nun, wie du einen Account bei einem offenen Solid-Provider anlegst und direkt loslegen kannst.

Ein solcher Provider ist solid.community. Du kannst die Registrierungsseite benutzen um dort einen Account anzulegen und so eine WebID erhalten. Username und Password benötigst du um dich später einzuloggen. Der Username wird auch Teil deiner öffentlichen WebID. Die Email dient zur Account-Wiederherstellung, External WebID kannst du leerlassen.

Registrierungsformular bei solid.community

Nach der Registrierung landest du auf der Startseite deines neuen Solid Pods:

Deine WebID nach der Registrierung lautet https://<username>.solid.community/profile/card#me Neben einer WebID stellt dir solid.community, auch Speicherplatz für deine Daten zur Verfügung (Solid Pod). Wenn du die WebID im Browser abrufst siehst du dein Profil mit dem bei der Registrierung eingetragen Namen:

Du kannst über die Felder weitere Informationen eintragen und auch ein Profilbild hochladen. Die Oberfläche ist allerdings sehr sehr rudimentär und alles andere als schön zu bedienen. Die Stärke von Solid liegt jedoch darin, dass du nun beliebige (bessere) Solid-Apps im Web benutzen kannst um deine Daten zu verwalten und zu ergänzen. Mehr dazu folgt! Eine Identität mit der du dich einloggen kannst, hast du nun schon mal.