RSS spannender machen

 (matduggan.com)
15 Punkte von GN⁺ 2025-12-08 | 1 Kommentare | Auf WhatsApp teilen
  • Entwicklung einer RSS-Feed-basierten Web-Surf-Erweiterung, mit der Nutzer Inhalte unabhängiger Websites zufällig entdecken und bewerten können
  • Per Klick auf einen Button wird eine neue Website angezeigt; über Gefällt mir-, Gefällt mir nicht- und Melden-Funktionen entsteht eine Community-basierte Empfehlungsstruktur
  • Backend mit FastAPI und SQLite aufgebaut; unter Nutzung von Kagis small web-RSS-Liste werden rund 600.000 Seiten indexiert
  • Ohne Werbung oder Sammlung von Nutzerdaten bietet das Projekt einfach die Erfahrung, für kurze Zeit interessante Webinhalte zu erkunden
  • Ein persönliches experimentelles Projekt mit dem Ziel, die Ermüdung durch bestehende RSS-Reader zu verringern und das kleine Web-Ökosystem neu zu entdecken

Projektüberblick

  • Ausgangspunkt war die Wahrnehmung, dass die Nutzung von RSS-Readern belastend sein kann
    • Kritisiert werden der Druck durch sich anhäufende ungelesene Beiträge und die Ineffizienz einer rein chronologischen Inhaltsstruktur
    • Nutzer möchten zufällig auf interessante Texte stoßen
  • Inspiriert vom Empfehlungsansatz von TikTok wurde eine Struktur entworfen, die Inhalte kleiner Websites zufällig ausliefert
    • Wenn Nutzer Inhalte bewerten, steigt ihre Ausspielhäufigkeit je nach Anzahl der Likes
    • Es kommt ein einfacher Empfehlungsalgorithmus zum Einsatz, ganz ohne Werbung oder Sammlung persönlicher Daten

Funktionen und Nutzerfluss

  • Bereitgestellt als Firefox-Erweiterung, Download unter timewasterpro.xyz
  • Nutzer erhalten per Button-Klick eine neue Website und bewerten sie mit Upvote/Downvote/Report
  • Eine Kontoerstellung ist erforderlich; wenn eingereichte Links bei anderen Nutzern beliebt werden, steigt man im Leaderboard auf
  • Im Backend werden RSS-Feeds regelmäßig gecrawlt und in der Datenbank gespeichert
    • Alle 600 Sekunden werden 5 Feeds geprüft; Aktualisierungen erfolgen mit einer Frequenz von höchstens einmal pro Tag
    • Gemeldete URLs werden in eine Prüfwarteschlange verschoben, Likes und Dislikes werden gezählt

Technische Umsetzung

  • Die API wurde mit FastAPI geschrieben, die Datenbankverwaltung übernimmt SQLAlchemy
  • Für die Datenspeicherung wird SQLite verwendet
    • Schneller Start und einfache Backups machen es für ein Hobbyprojekt geeignet
  • Die Authentifizierung erfolgt über kontoerstellung per E-Mail mit Link-Verifizierung
    • Auch Passkey-Login wurde ausprobiert, war wegen der Instabilität von OSS-Implementierungen jedoch nur eingeschränkt nutzbar
    • Es wird JWT-Authentifizierung verwendet, die aus Sicht der Nutzererfahrung jedoch als ineffizient bewertet wird
  • Als Datenquelle dient die RSS-Liste des Kagi-small-web-GitHub-Repositorys

Design und Nutzererlebnis

  • Mit der Bibliothek System.css wurde ein Stil im Look von Apple System OS der 80er und 90er Jahre umgesetzt
    • Damit wird visuell vermittelt, dass es sich nicht um einen professionellen Service, sondern um ein persönliches Experiment handelt
  • Da Tastaturkürzel nicht nach Betriebssystem unterschieden werden konnten, wurden sie fest auf die Alt-Taste gelegt
  • In der manifest.json-Konfiguration der Erweiterung gab es Probleme bei der Vergabe browserspezifischer IDs
  • Da keine Analysetools eingebunden sind, wird Nutzerfeedback vor allem über direkt gemeldete Probleme gesammelt

Ausblick

  • Inhalte sollen künftig nach Kategorien eingeordnet werden, damit Nutzer bevorzugte Genres häufiger sehen können
  • Geprüft wird eine Funktion, die Inhalte mit einem bestimmten Maß an Downvotes in eine separate Queue verschiebt
  • Es braucht eine Struktur, mit der neue Nutzer anfangs vorrangig „gute Inhalte“ zu sehen bekommen
  • Gewünscht ist ein Ausbau unabhängiger Websites aus den Bereichen Fotografie, Wissenschaft und Handwerk
  • Derzeit sind rund 600.000 Seiten indexiert, der Quellcode soll nach der Stabilisierung veröffentlicht werden

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-12-08
Hacker-News-Kommentare

  • Die Vorstellung, dass man alle Inhalte lesen müsse, ist ein Fehler im Design der Reader-UI

    • Problematisch ist die Darstellung von RSS-Feeds als E-Mail-ähnlicher „Posteingang“

    • Man sollte eher einen Ansatz wie bei TikTok verfolgen, also einen „Fluss der Nachrichten (river of news)“

    • Entscheidend ist, interessante Beiträge kurz anzuschauen und den Rest einfach vorbeiziehen zu lassen

    • Auch Twitter hatte im Kern eine RSS-ähnliche Struktur — nur hat man dort einfach gescrollt, ohne Markierung als „ungelesen“

    • Deshalb sollte man den Zähler für „ungelesene Elemente“ besser deaktivieren. Der Wert von RSS liegt darin, was ich auswähle und lese

    • Wenn ein Beitrag wirklich gut ist, werden andere Abonnenten den Link am Ende ohnehin teilen

    • Ich bevorzuge eher den Posteingangs-Ansatz als den „Fluss“

      • Wenn man Feeds nach Kategorien sortiert, ist auch „alles als gelesen markieren“ nicht schwierig
      • Dafür abonniere ich Feeds sofort ab, wenn sie zu häufig posten. Blogs mit täglichen Beiträgen sind für mich nicht zu bewältigen

    • Ich wollte auch einmal ein System bauen, das im ganzen Web automatisch Inhalte nach meinem Geschmack findet

      • Am Ende habe ich erkannt, wie wichtig hochwertige Datenquellen sind, und bin zu dem Schluss gekommen, dass es reicht, nur einige wenige gute Leute zu abonnieren
      • Als ich dann noch einmal von vorn darüber nachdachte, merkte ich: Das war genau RSS — ein Konzept, das schon 2005 fertig war

    • Ich hatte vor ein paar Jahren eine ähnliche Erkenntnis

      • Weil ich gelesene Beiträge nicht nachverfolgen wollte, habe ich für jeden RSS-Feed einen Bot gebaut und nach Diaspora gespiegelt
      • Inzwischen bin ich zu Mastodon gewechselt, aber das Prinzip ist gleich — einfach scrollen und nur interessante Beiträge anschauen

    • Twitter war einmal so ein Dienst, heute ist es das nicht mehr

  • Manche scheinen RSS-Reader falsch zu benutzen

    • RSS ist kein Werkzeug, um wie bei YouTube-Kanälen alles zu konsumieren, sondern ein Tool, mit dem man Überschriften überfliegt und nur interessante Artikel liest

    • TikTok ist eher noch schlimmer — eine endlose Content-Stream-Struktur, die Menschen ständig festhält

    • Für solche Leute wäre statt eines neuen RSS-Readers vielleicht eher eine „Später lesen“-Liste sinnvoll

    • TikToks Recommendation Engine ist sehr effizient, weil sie Reaktionen auf Ebene einzelner Inhalte misst

      • YouTube lässt einen dagegen eines von mehreren Thumbnails auswählen und verliert dadurch Informationen über die 9 nicht angeklickten
      • Nicht der Algorithmus an sich ist das Problem, sondern worauf optimiert wird
      • Mein Reader zeigt wie TikTok ebenfalls jeweils nur einen Inhalt auf einmal, besteht aber aus von mir selbst eingereichten wissenschaftlichen Arbeiten oder Artikeln über LLMs

    • Man muss nicht vorschnell festlegen, dass jemand RSS „falsch benutzt“

      • Die Art des Konsums hat sich nur von „lesen, was gerade veröffentlicht wurde“ zu „das aufholen, was ich angesammelt habe“ verschoben
      • YouTube lässt sich nach demselben Prinzip nutzen

    • Früher habe ich bei NetNewsWire wegen des Badges für ungelesene Beiträge Unruhe verspürt

      • Wenn ich es heute wieder nutzen würde, würde ich den Badge deaktivieren und Beiträge, die älter als 2 Tage sind, automatisch als gelesen markieren

    • Ich nutze eine angepasste Version von tt-rss aus dem Jahr 2005

      • Manche Feeds lese ich von Anfang bis Ende, andere überfliege ich nur gelegentlich
      • Später würde ich gern einen algorithmischen Feed auf Basis eines Empfehlungssystems hinzufügen
      • Besonders gern würde ich einen dezentralen Empfehlungs-Feed ausprobieren, der auf mit Sternen markierten/getaggten Artikeln von Autorinnen und Autoren basiert, die ich gern lese

    • Die „ungelesen“-Markierung von Google Reader sah zu sehr nach E-Mail aus und fühlte sich dadurch wie eine „Aufgabe“ an

      • Es war eine UI, die das bloße Überfliegen von Überschriften nicht als lockeren Vorgang, sondern als „Arbeit“ erscheinen ließ

  • Viele Menschen benutzen RSS als Gattungsbegriff für Web-Feeds

    • Bei der tatsächlichen Implementierung ist dann die Frage, ob man RSS, Atom oder JSON Feed verwenden sollte

    • Podcasts setzen weiterhin standardmäßig auf RSS

    • Ich nutze nur JSON Feed

      • Dank seiner einfachen Struktur funktioniert es in den meisten Readern gut und lässt sich programmatisch leicht verarbeiten
      • Wenn ich selbst etwas erzeuge, verwende ich zu 100 % JSON Feed. Bei Atom habe ich keinen echten Grund gesehen, es zu benutzen

  • Die meisten Feed-Reader scheinen von Leuten gebaut worden zu sein, die RSS selbst gar nicht nutzen

    • Ich verwalte 211 Feeds in gut 20 Kategorien und habe 13.000 Cache-Einträge

    • Tatsächlich klicke ich nur bei etwa 1–5 % auf den Artikel und öffne den Haupttext

    • Stimme voll zu. Es gibt viele Reader ohne Filterfunktionen oder ohne eine Struktur, mit der man große Mengen an Beiträgen verarbeiten kann

  • Ein Vorteil von RSS ist, dass es frei vom Einfluss von Empfehlungsalgorithmen ist

    • Man bekommt nicht ständig nur bestimmte Domains vorgesetzt, sondern kann Beiträge aus verschiedenen Bereichen ausgewogen sehen
    • Das fühlt sich wie eine Rückkehr zu einem traditionellen linearen Informationsflussmodell an

  • Ich freue mich sehr über solche Projekte

    • Früher mochte ich StumbleUpon wirklich sehr, deshalb freue ich mich über einen ähnlichen Dienst

    • Es wäre schön, wenn jemand einen Nachfolger von DIGG bauen würde

    • Stimme vollkommen zu. Es weckt Nostalgie nach StumbleUpon, und gleichzeitig gefällt mir, dass man den inhaltlichen Fokus selbst wählen kann

    • Zur Info: Digg wurde kürzlich als Beta-Version neu gestartet

  • Ich mag die nicht-algorithmische Kuratierung von RSS, möchte aber keine auf „Spaß“ ausgerichtete Kuratierung

    • Eine Struktur, die wie TikTok auf „Engagement“ optimiert ist, möchte ich vermeiden
    • Ich nutze RSS wieder, um direkt mit Autorinnen und Autoren, die ich mag, verbunden zu sein
    • Wenn es später mehr Inhalte gibt, wäre eine wöchentliche Newsletter-artige Kuratierung, bei der ein Algorithmus die Inhalte komprimiert, vermutlich ideal

  • Ob die chronologische Reihenfolge von Inhalten erhalten bleiben sollte, hängt vom jeweiligen Fall ab

    • Ich habe mir auch schon UX-Lösungen dafür in RSS-Readern oder Podcasts vorgestellt, aber noch keine gute Lösung gefunden

  • Ich empfehle den Dienst Scour

    • Er rankt Beiträge nach ihrer Relevanz für die Interessen der Nutzerinnen und Nutzer

    • Man kann RSS-Feeds importieren oder in mehr als 15.000 Quellen suchen

    • Das Tool wurde dafür entworfen, Tausende „ungelesene“ Einträge zu vermeiden und nur gute Beiträge herauszufiltern

    • Klingt interessant. Ich frage mich, ob es eine Funktion gibt, mit der sich bestimmte Feeds auf eine Blacklist setzen lassen

  • Ich versuche, das Problem der Kategorisierung in RSS zu lösen

    • Da viele Feeds das category-Feld nicht verwenden, habe ich einen Crawler gebaut, der Hashtags in der Beschreibung parst

    • Um jeden Tag RSS-„inbox zero“ zu halten, abonniere ich Blogs ab, die zu häufig posten

    • Posting-Frequenz und Content-Qualität scheinen oft umgekehrt proportional zu sein

    • Ich abonniere RSS mit der App Karakeep

      • Sie speichert Inhalte automatisch und erzeugt Tags mit generativer KI
      • Man kann bedingungsbasierte RSS-Feeds erstellen, daher lässt sie sich gut zusammen mit bestehenden Readern nutzen

    • Auch meine Website bietet verschiedene Arten von Inhalten, aber da die meisten Reader category-Tags nicht unterstützen

      • unterscheide ich sie am Ende, indem ich dem Titel Präfixe wie [Blog] voranstelle