Martins Blog

Die Softare Wallabag kann man sich als eine Art Pocket-Klon vorstellen: Eine Software, die Lesezeichen (Web-Adressen) und vor allem Texte daraus verwaltet und diese in einer angenehmen Art zum Lesen aufbereitet. Überflüssige Seiteninhalte werden entfernt und nur der Text wird dargestellt. Wallabag ist Open Source und wird via GitHub gepflegt, User können Bugs einreichen und sich am Prozess beteiligen. Die Software ist in PHP geschrieben und nutzt standardmässig eine SQLite-Datenbank. Das hat sich für meinen Anwendungsfall (Einzelnutzer, aber 10.000+ Lesezeichen) nicht als Problem herausgestellt; im Gegenteil: Backups sind beispielsweise sehr einfach zu handhaben.
Wer keine Lust hat, Wallabag selbst zu installieren, kann sich auch eine gemietete Version klicken.

Wallabag zieht mittels Readability ein Text-Exzerpt von Websites, was sehr angenehm ist und in den allermeisten Fällen problemlos ¹. Dies hat auch den schönen Nebeneffekt, dass man eben diesen Volltext als Link, PDF, HTML, ePub oder Mobi bereit stellen kann. Maximale Flexibilität also.

Dieser Volltext ist auch von allen Tracking-Mechanismen der Original-Seite befreit, das heißt der Seitenbetreiber kann dann nicht mehr tracken, wie lange ein bestimmter Artikel aus Wallabag heraus aufgerufen wird, wie lange man daran liest etc. Ebenfalls profitiert ein im Heimnetz laufendes Wallabag auch von netzwerkweiten Werbeblockern wie Pi-Hole und lädt Schrott erst gar nicht ins Archiv.

Wallabags Volltext in der eigenen Datenbank ist auch dann noch vorhanden, wenn die ursprüngliche Website in der Zwischenzeit offline gegangen ist. Allerdings wird — anders als bei Archive.org oder ArchiveBox, auf das später eingegangen wird, nicht der Look and Feel der Originalseite bewahrt.

Wallabag hat außerdem Support für Tags (Schlagwörter) und einen gelesen / ungelesen-Status, bietet sich also somit als persönliches Themen-Archiv und „zu-Lesen“-Liste an. Angenehm dabei ist, dass der Lesestand innerhalb der Artikel synchronisiert wird und die Dauer, die das Lesen des Artikels noch etwa betragen wird, angezeigt wird. Fange ich also am iPhone an, einen Artikel zu lesen und höre mittendrin auf, steht mir der aktuelle Stand später auf dem gleichen oder einem anderen Gerät zur Verfügung.
Neben den Tags gibt es eine Volltext-Suche innerhalb der kompletten Datenbank, die hier und da über vergessene Tags hinwegsehen lässt.

Leider lässt sich die Leseansicht von Wallabag nicht konfigurieren — hier würde ich mir verschiedene Schriftarten, Hintergründe, Zeilenabstände und so weiter wünschen. Vielleicht kommt das in einer kommenden Version. Bis dahin behelfe ich mir mit dem Lesemodus meines Browsers, wo man genau diese Sachen dann einstellen kann. Wallabags Volltext bringt natürlich bei langen Texten am meisten Gewinn, bei Websites, die aus viel Javascript und dynamisch nachgeladenen Inhalten bestehen, klappt das nicht oder nicht gut. In diesem Fall dient Wallabag dann allenfalls als Link-Sammlung mit Tags.

Das Client-Management von Wallabag für externe Clients wie beispielsweise das Firefox-Plugin oder den Kindle Consumer

Ein weiteres geniales Feature ist, das Wallabag hinter Paywalls schauen und den Volltext dieser Artikel auch heraus ziehen kann — ein gültiges Abo bei der entsprechenden Website natürlich voraus gesetzt. Die Architektur des Dienstes bietet hier für alle möglichen Quellseiten eine Scriptdatei an, in welcher man das Parsing für die Website anpassen und die Paywall-Authentifizierung hinterlegen kann. Wallabag bietet eine API für andere Applikationen an und somit wird sicher gestellt, dass beispielsweise Browser-Erweiterungen oder Import-/Export-Services auch von unabhängigen Dritten bereit gestellt werden können.

Nach der eigenen Größe der Datenbank bemisst sich der Plattenplatz, den man für Wallabag einplanen muss, insbesondere dann, wenn auch Bilder zu Artikeln gesichert werden sollen.

Die iOS-App von Wallabag ist leider kaum zu gebrauchen.

Man merkt Wallabag und — ganz besonders — der offiziellen iOS-App an manchen Stellen an, dass hier keine professionelle Firma, sondern ein Team von Open-Source-Entwicklern an den Reglern ist: Das Interface hat einige Merkwürdigkeiten², glücklicherweise sind die am meisten benutzten Sachen (Lesemodus, Tagging, Suche etc) aber gut gepflegt und durchaus angenehm zu benutzen. Bugs werden regelmäßig gefixt und neue Versionen erscheinen kontinuierlich. Gleiches kann man von der iOS-App leider überhaupt nicht sagen. Verzerrte Bilder, Abstürze, Krater-Fließtext und Abstürze im Share-Sheet sind nur einige der Ärgerlichkeiten. Die App ist wirklich unbenutzbar und ich lasse sie nur wegen der Sharing-Funktion installiert, aber selbst die stürzt leider oft ab und reißt die darunter liegende App mit in den Abgrund. Hier gibt es noch deutlichen Verbesserungsbedarf, aber da ja alles Open-Source ist, können sich Freiwillige beteiligen.

Die folgenden Themen werden in der Wallabag-Artikelserie behandelt:
Einleitung — Auf Vorrat gespeichert: Das eigene Web-Archiv auf dem NAS
Teil 1: Was kann Wallabag?
Teil 2: Wallabag via Docker auf Synology NAS
Teil 3: Wallabag-Tuning
Teil 4: Wallabag und Paywalls
Teil 5: Wallabag-Backup und Versionsupdates
Teil 6: RSS-Import zu Wallabag
Teil 7: Wallabag und eReader
Teil 8: Archivebox und Wallabag

Das heißt, der komplette Text einer Seite ist verfügbar und sonst nichts. ↩
Beispielsweise eine 0 / 1 statt eines Schalters für einige Optionen ↩

Wenn ihr meine Blog-Postings schon etwas länger verfolgt, wisst ihr vielleicht, dass ich ein Fan von NAS-Boxen bin, schon 2012 habe ich darüber geschrieben. Ich versuche mein NAS für immer mehr Dienste einzubinden und den großen Cloud-Anbietern meine Daten, sofern möglich, nicht anzuvertrauen. Kürzlich habe ich eine unschöne Erfahrung mit dem Lesezeichen-Dienst Pinboard gemacht, der mich dazu veranlasst hat, ein neues NAS-Projekt zu starten: Die eigenen Lesezeichen auf dem eigenen Server zu speichern. Die komplette hier vorgestellte Software ist Open Source und lässt sich via Docker leicht auf (nicht nur) einem Synology NAS installieren. Dies hier beigefügte Isolierung der Software ist mittlerweile zu einem Standard in der Industrie geworden.

Kurz zum Hintergrund: Ich speichere meine Lesezeichen, also Links zu anderen Websites, seit rund 10 Jahren mittels Online-Services. Die Speicherung im Browser wurde mir schnell zu unübersichtlich und auch mit der starren Hierarchie bin ich nicht immer gut klar gekommen. Im Browser have ich nur noch Seiten gespeichert, die ich jeden Tag zur Arbeit brauche. Eine „flache“ Speicherung der Lesezeichen mittels Tags (Schlagwörtern) gefiel mir hingegen wesentlich besser.

Mit der Speicherung angefangen habe ich bei del.icio.us, danach bin ich (mit Abstechern über Pocket und Instapaper) bei Zootool und schließlich bei Pinboard gelandet.
Jeder dieser Services hat einen anderen Fokus, im Kern geht es aber prinzipiell darum, Lesezeichen zu interessanten Websites / Artikel abzulegen und diese (hoffentlich) später abzuarbeiten und zu lesen. Da ich diese Lesezeichen schon so lange speichere, gab es im Laufe der Zeit darunter einige, die verwaist waren, weil die Quellserver längst abgeschaltet wurden. Deshalb gefiel mit Pinboards Ansatz, von allen Seiten eine Offline-HTML-Kopie in einem eigenen Archiv zu speichern.
Das hat auch lange funktioniert, aber irgendwann letztes Jahr hat sich der (scheinbar) alleinige Entwickler von Pinboard dazu entschlossen, die Plattform nicht mehr weiter zu unterstützen: Der Twitter-Import war kaputt, ebenso wie der Download des eigenen Archivs, Support-Mails oder Tweets wurden erst Monate später oder patzig und betrunken beantwortet. Da gingen meine Alarmglocken an. Etwas eigenes musste her.

Die Leseansicht von Wallabag

Ich hatte mir schon ein grobes Konzept überlegt, wie ich einen solchen Dienst selbst schreiben könnte, bin dann aber relativ schnell auf Wallabag und Archivebox gestoßen, die in Kombination 99% von dem erfüllen, was ich wollte. Vielen Dank dafür, pheraph und strubbl. Darum habe ich mich entschlossen, das Rad nicht neu zu erfinden und diese vorhandenen Lösungen zu nutzen und zu erweitern.

Das Pendel in Richtung selbst machen umgeschlagen hat letztendlich folgender Gedanke:
Generell gilt, dass leider bei jedem Platform-Wechsel dieser Dienste Informationen verloren gehen. Dies gilt besonders für Volltextarchive, welche selten plattformübergreifend importiert werden können. In der Regel läuft der Umzug der Bookmarks über eine JSON- oder HTML-Datei ab, die Links zu den Websites, einen Zeitstempel und eine Liste an Tags beinhalten. Alles andere ist optional. Selbst wenn der neue Dienst dann ein neues Vollseiten- oder Lese-Backup (Text-Extrakt) anbietet, kann dies oft daran scheitern, dass die ursprünglichen Seiten dann beim Neuimport nicht mehr verfügbar sind. Diese sind dann zwar noch im (hoffentlich vorhanden) Volltext-Backup des alten Services vorhanden, die Kette ist dann hier aber gerissen, weil das neue Tool keinen Zugriff auf das alte Archiv hat — dieses müsste man dann händisch durchsuchen. Auch dies ist ein Grund, letztlich all diese Daten selbst zu hosten und in einem Format vorzuhalten, das weitere Im- und Exporte ohne die Beschränkungen anderer Plattformen oder APIs nach sich zieht. Kurz gesagt: Mit Wallabags SQLite-Datenbank kann es mir recht egal sein, wo ich in der Zukunft einmal hin umziehen werde, weil ich einen Export-Parser selbst in SQL schreiben kann und volle, DRM-freie Kontrolle über alle Inhalte und die gespeicherten Texte habe.

Je länger ich mit diesem Thema beschäftigt habe, desto ausgefeilter sollte auch der auf Twitter versprochene Blog-Artikel sein. Und schließlich bin ich nun bei diesem Monster in bisher acht Teilen gelandet. In dieser Reihe von Artikeln will ich nun zeigen, wie ich bei der Installation und Konfiguration der Dienste vorgegangen bin und wie die verschiedenen Aspekte ineinander greifen. Ich hoffe, die Artikel helfen euch beim Anlegen und ihr könnt euch einige Recherchearbeit sparen. Wenn es euch gefällt, schreibt es mir gerne in die Kommentare, und wenn nicht, bitte umso mehr.