torben/chemenu
1
1
Fork 0
Code Issues 26 Pull Requests Actions Packages Releases 32 Activity

RSS-zu-Obsidian-Pipeline: Star-Flag-Poll über Nextcloud-News-API mit Adapter-Plugin für Paywall-Auth (Entwurf) #87

New Issue
Open
opened 2026-09-10 19:42:05 +00:00 by torben · 0 comments
torben commented 2026-09-10 19:42:05 +00:00
Owner
Copy Link
Copy Source

Herkunft: Aus einer Diskussion in der LLM-Wiki-Space-Session vom 2026-09-09/10, keine wikitool-Ausarbeitung.

Ausgangsproblem: Torben liest RSS über FieryFeeds (iOS) mit Nextcloud-News-Backend. Artikel, die den vollen Text erfordern (z. B. hinter Paywall wie Heise+), werden bisher manuell später am Desktop per Obsidian Web Clipper in den Vault übernommen — unbequem, weil das Lesen typischerweise abends im Bett passiert und der Clipper eine laufende Desktop-Instanz von Obsidian voraussetzt.

Skizzierter Ansatz:

  1. Trigger: Artikel in FieryFeeds als "Starred" markieren (normale App-Funktion, kein fragiles Shortcuts-Feature — FieryFeeds' Siri-Shortcuts-Support wurde vom Entwickler aus technischen Gründen größtenteils entfernt).
  2. Poll-Job (Cron, z. B. alle 10–15 Min) fragt die Nextcloud-News-API ab: GET /items/updated?lastModified=<ts>&type=2 liefert alle seit dem letzten Lauf geänderten Starred-Items.
  3. Für jeden neuen Artikel: Domain-Matching gegen eine Adapter-Registry (siehe unten), Volltext holen, zu Markdown extrahieren.
  4. Note mit Frontmatter (Titel, URL, Datum, Quelle) wird per Git-Commit direkt ins Vault-Repo geschrieben — bewusst nicht über Obsidian Local REST API oder eine Clipper-artige URI, weil beide eine laufende, erreichbare Obsidian-Instanz voraussetzen (das war der ursprüngliche Bequemlichkeits-Blocker).
  5. Erfolgreich verarbeitete Items werden per PUT /items/unstar/multiple (Nextcloud News API) entsternt als Fertig-Signal; bei Fehlern bleibt der Stern stehen und der Job meldet sich (z. B. ntfy/Pushcut-Notification).

Plugin-Infrastruktur für das Auth-/Paywall-Problem:

Adapter-Registry mit gemeinsamem Interface pro Domain (matches(url), needs_auth(), load_session(), login(), fetch(), extract()). Default-Adapter für unauthentifizierte Seiten (Readability/Trafilatura-artige Extraktion); domainspezifische Adapter (z. B. für heise.de) kapseln Login-Flow und Session-Handling (Cookie/Storage-State, verschlüsselt at-rest). Neue Paywall-Site = neue Adapter-Datei, Rest der Pipeline bleibt unverändert.

Offene Fragen:

  • Wo läuft der Poll-Job/die Adapter-Pipeline (Homelab-Container? bestehende Infrastruktur?).
  • Konkreter Login-Flow für Heise+ (Formularfelder, 2FA?) ungeklärt.
  • Speicherort/Verschlüsselung der Zugangsdaten (age/GPG?) nur als Idee, nicht entschieden.
  • Wie wird ein fehlgeschlagener Adapter dem Nutzer gemeldet — Kanal noch offen.
  • Wie wird der Git-Commit ins Vault-Repo ausgelöst (lokaler Runner mit SSH-Deploy-Key? Push von einem Server aus?) — ungeklärt.

Quellen aus der Recherche:

Hinweis zur Einordnung in diesen Tracker: Dies ist kein Chemenu-Stack-Thema im Sinne von instructions/dev/issue-tracking.md — es betrifft eine private RSS-zu-Obsidian-Automatisierung außerhalb dieses Repos. Keines der bestehenden area/*-Labels passt inhaltlich, daher bewusst ohne area/-Label angelegt. Als status/incoming ist das laut Konvention unproblematisch (die vier Pflichtlabels sind bei diesem Flag noch nicht fällig) — bei der Triage muss aber geklärt werden, ob dieser Tracker überhaupt der richtige Ort für das Thema ist.

**Herkunft:** Aus einer Diskussion in der LLM-Wiki-Space-Session vom 2026-09-09/10, keine wikitool-Ausarbeitung. **Ausgangsproblem:** Torben liest RSS über FieryFeeds (iOS) mit Nextcloud-News-Backend. Artikel, die den vollen Text erfordern (z. B. hinter Paywall wie Heise+), werden bisher manuell später am Desktop per Obsidian Web Clipper in den Vault übernommen — unbequem, weil das Lesen typischerweise abends im Bett passiert und der Clipper eine laufende Desktop-Instanz von Obsidian voraussetzt. **Skizzierter Ansatz:** 1. Trigger: Artikel in FieryFeeds als "Starred" markieren (normale App-Funktion, kein fragiles Shortcuts-Feature — FieryFeeds' Siri-Shortcuts-Support wurde vom Entwickler aus technischen Gründen größtenteils entfernt). 2. Poll-Job (Cron, z. B. alle 10–15 Min) fragt die Nextcloud-News-API ab: `GET /items/updated?lastModified=<ts>&type=2` liefert alle seit dem letzten Lauf geänderten Starred-Items. 3. Für jeden neuen Artikel: Domain-Matching gegen eine Adapter-Registry (siehe unten), Volltext holen, zu Markdown extrahieren. 4. Note mit Frontmatter (Titel, URL, Datum, Quelle) wird per Git-Commit direkt ins Vault-Repo geschrieben — bewusst **nicht** über Obsidian Local REST API oder eine Clipper-artige URI, weil beide eine laufende, erreichbare Obsidian-Instanz voraussetzen (das war der ursprüngliche Bequemlichkeits-Blocker). 5. Erfolgreich verarbeitete Items werden per `PUT /items/unstar/multiple` (Nextcloud News API) entsternt als Fertig-Signal; bei Fehlern bleibt der Stern stehen und der Job meldet sich (z. B. ntfy/Pushcut-Notification). **Plugin-Infrastruktur für das Auth-/Paywall-Problem:** Adapter-Registry mit gemeinsamem Interface pro Domain (`matches(url)`, `needs_auth()`, `load_session()`, `login()`, `fetch()`, `extract()`). Default-Adapter für unauthentifizierte Seiten (Readability/Trafilatura-artige Extraktion); domainspezifische Adapter (z. B. für heise.de) kapseln Login-Flow und Session-Handling (Cookie/Storage-State, verschlüsselt at-rest). Neue Paywall-Site = neue Adapter-Datei, Rest der Pipeline bleibt unverändert. **Offene Fragen:** - Wo läuft der Poll-Job/die Adapter-Pipeline (Homelab-Container? bestehende Infrastruktur?). - Konkreter Login-Flow für Heise+ (Formularfelder, 2FA?) ungeklärt. - Speicherort/Verschlüsselung der Zugangsdaten (age/GPG?) nur als Idee, nicht entschieden. - Wie wird ein fehlgeschlagener Adapter dem Nutzer gemeldet — Kanal noch offen. - Wie wird der Git-Commit ins Vault-Repo ausgelöst (lokaler Runner mit SSH-Deploy-Key? Push von einem Server aus?) — ungeklärt. **Quellen aus der Recherche:** - Nextcloud News External API v1-2 (Endpunkte `items/updated`, `items/star(unstar)/multiple`): https://github.com/nextcloud/news/blob/master/docs/api/api-v1-2.md - Nextcloud News Nutzer-Doku (Mark Read/Starred): https://nextcloud.github.io/news/user/ - FieryFeeds' reduzierter Shortcuts-/Siri-Support (Entwickler-Blog): https://voidstern.net/archives/3101 - Obsidian Web Clipper – offizielle Einführung (setzt laufende Obsidian-Instanz voraus): https://obsidian.md/help/web-clipper - Obsidian Web Clipper – Capture-Mechanik (Obsidian-URI): https://obsidian.md/help/web-clipper/capture - Obsidian Local REST API (Plugin, Alternative zur URI, setzt ebenfalls laufende Instanz voraus): https://coddingtonbear.github.io/obsidian-local-rest-api/ - Web-Scraping hinter Login mit Python/Requests+BeautifulSoup (Heise-Ratgeber, Beispiel für Session-Cookie-Ansatz): https://www.heise.de/ratgeber/Python-Websitedaten-nach-einem-Login-auslesen-4681895.html - n8n-Workflow-Beispiel "Send RSS feed data to webhook": https://n8n.io/workflows/159-send-rss-feed-data-to-webhook/ - Pushcut Automation Server (Alternative Trigger-Mechanik, in der Diskussion zugunsten des Poll-Ansatzes verworfen): https://www.pushcut.io/support/automation-server **Hinweis zur Einordnung in diesen Tracker:** Dies ist kein Chemenu-Stack-Thema im Sinne von `instructions/dev/issue-tracking.md` — es betrifft eine private RSS-zu-Obsidian-Automatisierung außerhalb dieses Repos. Keines der bestehenden `area/*`-Labels passt inhaltlich, daher bewusst ohne `area/`-Label angelegt. Als `status/incoming` ist das laut Konvention unproblematisch (die vier Pflichtlabels sind bei diesem Flag noch nicht fällig) — bei der Triage muss aber geklärt werden, ob dieser Tracker überhaupt der richtige Ort für das Thema ist.
torben added the status/incoming label 2026-09-10 19:42:05 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
area/corpus
Betrifft Demo-/Testbett-Frage, Inhalt und Umfang von kb/
 area/distribution
Betrifft Auslieferung, Upgrade, Versionierung einer Instanz
 area/kb
Betrifft kb/-Schema, Contract, Confidence, Lint, Wissensbasis
 area/process
Betrifft den Entwicklungsprozess selbst, nicht den Stack als Artefakt
 area/workflow
Betrifft Git, Merge, Branching, Publish, PRs
 kind/build
Spezifiziert, wartet nur noch auf Umsetzungszeit
 kind/decision
Wartet auf eine Betreiberentscheidung
 kind/defect
Befund: Doku und Realitaet, oder zwei Dokus, widersprechen sich
 prio/blocking
Blockiert oder beschaedigt laufende Arbeit - als naechstes
 prio/planned
Traegt bald Zinsen - eingeplant
 prio/waiting
Sinnvoll, wartet auf einen Ausloeser
 size/L
Mehrere Sitzungen oder offene Designfragen vor dem ersten Commit
 size/M
Mehrere Dateien, Contract- oder Instruction-Aenderung, eigener Testaufwand
 size/S
Eine Sitzung, ein Publish, klar umrissener Schnitt
 status/blocked
Wartet auf ein anderes, noch offenes Issue - nicht eigenstaendig bearbeitbar
 status/incoming
Vom Menschen angelegte Anforderung, unvollständig, muss durch den Stack komplettiert werden.
 status/unconfirmed
Gemeldeter Verdacht, noch nicht gegen tatsaechliches Verhalten geprueft - size/prio vorlaeufig
No Label status/incoming
Milestone
No items
No Milestone
Assignees
Clear assignees
torben
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: torben/chemenu#87
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?