Wie im letzten Post dazu schon angeteasert, wollte ich noch ein paar Worte dazu verlieren, wie ich in den letzten Wochen diesen Blog ans Fediverse angeschlossen habe. Der Code ist mittlerweile als eine Art Kirby-Plugin auf Github verfügbar.

Vielleicht ist der Code und dieser Post eine kleine Hilfestellung auf der Reise durch den Dschungel der mittelmäßigen Dokumentation zum Thema Fediverse, Mastodon und so weiter.

Weiterlesen →

Ich habe gestern eine kleine Fediverse-Übersichtsseite gebaut, auf der alle Follower, die den Blog abonniert haben aufgelistet sind. Natürlich wollte ich auch einen CTA auf die Seite packen, damit man direkt auch folgen kann, doch im dezentralen Fediverse ist das nicht so einfach.

Bei Twitter würde man ja einfach auf twitter.com/knuspermagierblog verweisen und jeder, der dort gerade eingeloggt ist, kann direkt den Button drücken. Da im Fediverse alle auf unterschiedlichen Servern unterwegs sind, klappt das nicht so einfach. Normalerweise müsste man das Handle kopieren, es im Interface des Servers, oder der App eingeben und danach suchen.

Um den Vorgang etwas zu vereinfachen habe ich auf diversen Seiten schon diesen Flow gesehen, bei dem man zunächst sein eigenes Handle, also z. B. pwa@norden.social in ein Textfeld eingibt und direkt auf eine Seite weitergeleitet wird, die zum eigenen Server gehört, auf dem man dem zu folgenden Account folgen kann. Was für ein Satz.

In meinem Beispiel käme man dann auf folgende Adresse, die auf einem OStatus-Standard basiert.

https://norden.social/authorize_interaction?uri=knuspermagier@knuspermagier.de

Remote-Follow-Flow

Jedenfalls wollte ich es auch und baute es daher kurz auf die Seite ein. Hier der Source-Code, falls ihr es für eure eigenen Fediverse-Seiten klauen wollt:

<form data-sup>
    <input type="text" name="handle" placeholder="pwa@norden.social">
    <button>Los</button>
</form>

<script>
document.querySelector('[data-sup]').addEventListener('submit', (ev) => {
    ev.preventDefault();

    const value = document.querySelector('[name="handle"]').value;
    const [_, host] = value.split('@');

    fetch(`https://${host}/.well-known/webfinger?resource=acct:${value}`)
        .then(r => r.json())
        .then(j => {
            j.links.forEach(link => {
                if (link.rel === 'http://ostatus.org/schema/1.0/subscribe') {
                    location.href = link.template.replace('{uri}', 'pwa@norden.social');
                }
            })
        })
       .catch(() => {
            alert('Account nicht gefunden!')
        })
})
</script>

Was passiert da?

Ich versuche gerade mit Überschriften zu arbeiten, um längere Posts etwas zu strukturieren, wie gefällt euch das?

Natürlich könnte ich es mir einfach machen, und direkt davon ausgehen, dass das angegebene Handle zu einer Mastodon-Instanz gehört, die diesem Remote-Follow-Flow immer gleich implementiert, dann müsste ich nur den Hostnamen heraussplitten und /authorize_interaction?uri=… dranhängen.

Der Vollständigkeit halber gehen wir hier aber auf Nummer sicher und machen es... standardkonform? Wir rufen die Webfinger-Adresse des Servers auf und fragen nach, was er denn so für Links zum angegebenen Handle im Angebot hat. Ist ein Link dabei, der dem OStatus-Subscribe-Standard entspricht, nutzen wir den und leiten den/die User:in weiter. Easy peasy.

DSGVO

Ich bin ein kleiner DSGVO-Nerd und frage mich jetzt direkt, ob diese Implementierung überhaupt legal ist. Immerhin macht das Formular einen Request zu einem Drittanbieter und man weiß ja nun nicht, ob der Mastodon-Server nun in der EU steht oder auch nicht. Eigentlich bräuchte man also bestimmt noch eine Checkbox, in der steht, dass man sich damit Einverstanden erklärt, dass man seine IP zu einem Drittanbieter, der im schlimmsten Fall in den Vereinigten Staaten liegt, schickt.

Andererseits schickt man seine IP ja in jedem Fall zu einem Server, bei dem man eh einen Account hat, der hat also eh alle Daten über einen. Ich würde das also erstmal als okay einschätzen, aber bitte macht mich nicht dafür verantwortlich, wenn ihr wegen eines Webfinger-Requests abgemahnt werdet.

(Allgemein wünschte ich mir, ich müsste mir nicht ständig, bei allem, über die DSGVO Gedanken machen, aber meine Agenturzeit während der “Unserer Webseite muss jetzt noch schnell dafür fit gemacht werden”-Welle hat mich wohl für immer gebrandmarkt)

Schamlose Eigenwerbung

Wie ihr seht, so ein kleiner Follow-Helfer ist gar nicht so schwer auf der eigenen Webseite zu integrieren! Folgt mir (oder dem Blog) doch auf Mastodon um… mehr davon zu bekommen.

Seems like it took two years for me to realize that PHP 8 came with support for Named Parameters. After dipping my toes in Objective C and, more recently, Swift, I really fell in love with those! I'm not gonna use them every time in PHP, but sometimes they may come in handy.

(Did I just write a blog post in English? I'm going international!)

Letztens schaute ich ein YouTube Video zu Empire Earth und anderen Strategiespielen, die ich damals spielte und hatte direkt wieder Bock. Also vor allem auf das im Video auch angerissene Rise of Nations.

Die gute alte Gaming-Phase, die alle paar Monate anklopft. Natürlich gibt es Rise of Nations noch bei Steam, für ziemlich teure 19€. Das ist ja, inflationsbereinigt, fast der Originalpreis!

Aber naja, es geht natürlich nur auf Windows. Der einzige Nachteil meines M1-Macs: kein Bootcamp mehr.

Immer wieder habe ich so einen Anflug, etwas spielen zu wollen und dann wäre ein Gaming PC schon etwas feines. Klar, ich hab ja auch schon Shadow ausprobiert und dafür sogar ne Glasfaserleitung verlegt, aber so richtig geil war es nie. Zudem ist es mit 30€ im Monat halt einfach sau teuer. Also, auf der anderen Seite kann man auch ziemlich lange 30€ ausgeben, bis man die 1.000€ für einen Gaming-PC verbraten hat.

Letztens hatte ich das Steam Deck für wenige Stunden ausgepackt und dann weiter verkauft. Vielleicht wäre das, mit einem Dock, auch einfach die richtige Lösung gewesen für meine seltenen und kurzen Gaming-Jieper. Was mich da allerdings gestört hat, war, dass ausgerechnet bei den Spielen, die ich spielen wollte, immer irgendwelche zusätzlichen Kniffe notwendig waren, damit sie unter Linux laufen. Klar, man kann Windows drauf installieren, aber das wirkt auch eher wie eine Bastellösung

Will man das Problem nun mit Geld bewerfen hat man das Problem, dass man danach eine hässliche große Kiste rumstehen hat, die Staub fängt und deren Komponenten alt werden, ohne, dass man sie wirklich benutzt hat.

Ich hab sogar kurz recherchiert, ob ich meinen Home Server (den PN51) benutzen könnte. Irgendeine Grafiklösung ist da ja integriert. Aber nein, die Anleitung, wie man den PCI Passthrough in Proxmox aktiviert sah mir schon wieder viel zu aufwändig und instabil aus. Sonst wäre meine Idee gewesen, eine Windows VM zu machen und Steam Link zu nutzen. Oder so.

Tja. Ich bin jetzt irgendwo gefangen zwischen „Gaming-Jieper einfach aussitzen“ und „doch Shadow benutzen und halt durch das Geruckel genervt sein“. Was ich noch interessant wäre, wär irgendwie ein kleiner Gaming-Würfel, so eine Art Steam Deck, ohne Display und Controller, wo ich einfach kurz Monitor und Maus anschließen kann. Aber halt mit Windows drauf. Anscheinend gibt es auch sowas, z.B. Beelink. Der neue GTR6 klingt auch echt gut, ist aber noch nicht verfügbar. Aber das wäre natürlich auch wieder ein Staubfänger, der einfach nur alt wird. Immerhin ist er klein!

Ich wünschte einfach, Shadow würde besser funktionieren und wäre billiger, oder flexibler zu bezahlen. 30€ im Monat für eine 1h Spiel-Session ist es einfach nicht, für mich.

Am Einfachsten wäre es natürlich, wenn ich nur Jieper auf Spiele hätte, die auf MacOS oder auf der Switch gehen.

Als vor ein paar Wochen die große Umzugswelle zu Mastodon begann, kam ich mal wieder auf die Idee, dass es sicher lustig wäre, wenn ich den Blog direkt anschließe. Bisher gab es kein Activity-Pub-Plugin für Kirby, was wahrscheinlich daran liegt, dass im Großen und Ganzen nur wenig Leute Kirby als Blog, oder sowas benutzen, wo es sinnvoll wäre, sowas zu haben.

Meine Finger juckten, ich hatte Lust das auszuprobieren, kann ja alles nicht so schlimm sein. Ich las also eben mal durch die ActivityPub-Spec und begann ganz vorsichtig ein paar Routen in meine Kirby-Installation reinzunehmen.

Nach dem ersten Herumprobieren fand ich auch schon den sehr hilfreichen Blogpost von Eugen, dem Erfinder von Mastodon. Im Blog schreibt er im Post “How to implement a basic ActivityPub server” genau das, was ich machen wollte. Mehr oder weniger.

Der Post behandelt erstmal, wie man eine Reply auf eine Nachricht schickt, ist aber etwas veraltet, denn mittlerweile enthält die Signatur auch noch einen Digest-Wert, aber insgesamt konnte ich damit schonmal gut arbeiten und das Grundkonzept verstehen. Zunächst widmete ich mich aber erstmal der Follow-Funktionalität, weil was bringt es mir, Content zu veröffentlichen, wenn ihn gar niemand sieht!

Im Nachhinein kann ich jetzt sagen, dass das ja alles gar nicht so schlimm ist. Natürlich habe ich beim Herumprobieren teilweise ewig gebraucht um die richtigen Bausteine so zu kombinieren, dass es funktioniert und in den nächsten Posts zu diesem Thema werde ich vielleicht noch ein bisschen tiefer darauf eingehen.

Gleichzeitig war das aber auch mal wieder so ein Projekt, bei dem ich es einfach beim Proof of Concept hätte lassen sollen, denn die letzten beiden Abende, wo ich versucht hab, es alles etwas “schön” zu machen, waren irgendwie mehr nervig, als unterhaltsam. Mehr dazu aber in den nächsten Tagen!

Bis dahin möchte ich aber erstmal ein bisschen ausprobieren, ob es denn nun wirklich funktioniert. Ihr könnt dem Blog unter dem Handle knuspermagier@knuspermagier.de in eurem Mastodon-, bzw. Fediverse-Client folgen. Probiert es doch mal aus!

Manchmal baut man doch etwas größeres als sonst in Kirby und man greift zu SQLite um Daten zu speichern. Ich bin ja relativ Dependency-Faul und denke mir oft, dass ich die paar Queries dann halt kurz selber schreibe, sobald ich aber dann zu einem Laravel-Projekt wechsel und dort Eloquent benutze, hasse ich mich dafür.

Zum Glück hat Fernando Gutiérrez ein kleines Composer-Projekt gemacht, mit dem man ganz einfach Eloquent installieren und nutzen kann. Danke Fernando, danke an das Laravel-Team, dass man Eloquent auch so nutzen kann.

Heute hatte ich mal wieder so ein typisches Problem, das am Ende tausend neue Probleme eröffnete, aber der Reihe nach:

Vor etwa einem Jahr kaufte ich einen Bausatz für einen Feinstaubsensor. Ich baute das auch alles erfolgreich zusammen, aber ich schaffte es nicht, das Ding ins WLAN zu kriegen.

Nun, fiel mir das Ding wieder in die Hände und ich entschied mich, es noch einmal an zu gehen, vor allem, da ich ja gerade Home Assistant aufgesetzt hatte und mich also über jeden weiteren Sensor freue. Mittlerweile hatte ich auch ein anders WLAN und vielleicht klappt es ja damit! Erfolg! Juchu!

Nun funktionierte der Sensor und es wirkte auch so, als würde er erfolgreich regelmäßig seine Daten an die Sensor.Community-Karte pushen. Für Home Assistant gibt es nun eine Integration, bei der man die SensorID eingibt und die dann die Daten entsprechend wieder zurück holt und speichert. Nachdem das erstmal gut lief, zeigte es nur noch “unknown” und “Sensor nicht verbunden” an, in dem Moment, als ich meinen Erfolg gerade vorzeigen wollte.

Probleme

Hier offenbarten sich mehrere Probleme:

1. Home Assistant ist nicht gut darin, einfach z.B. den letzten Erfolgreich abgefragten Wert anzuzeigen, wenn ein Sensor kurzzeitig mal weg ist
2. Der Sensor hatte zwischendurch ein paar Probleme, die Daten an den WebService zu übertragen, weshalb er dort aus der Auflistung entfernt wurde, was dazu führte, dass die Integration keine Daten abrufen konnte.

Das erste Problem kann man Lösen, in dem man wilde Sachen in YAML-Dateien schreibt, die irgendwie einen temporären Sensor erzeugen, der die alten Daten zwischenspeichert, oder so, aber ich wollte erstmal das andere lösen, damit das erste vielleicht gar nicht erst auftritt!

InfluxDB to the rescue?

Die Firmware vom Feinstaubsensor kann die Daten jedenfalls auch in eine InfluxDB speichern. Hach, InfluxDB, was haben wir schon alles gemeinsam erlebt. Wie viele Daten, die ich danach nie anschaute, habe ich schon in dir gespeichert, weil es so einfach ging. Ich installierte also kurz die aktuelle Version auf dem Home Assistant-Server und musste leider feststellen, dass Version 2 überhaupt nicht mehr so einfach und schnell funktioniert wie die alte Version.

Das mag natürlich daran liegen, dass ich mich nicht großartig damit beschäftigt habe, aber ich bekam es in fünf Minuten jedenfalls nicht hin, dass der Sensor seine Daten erfolgreich speichern konnte. Keine Ahnung, ob sich der write-Endpunkt irgendwie geändert hat und nun einen anderen Syntax erwartet, oder woran es lag. Auf jeden Fall gibt es nun Organizations und Buckets und das klingt schon schlimm genug.

Zum Glück gibt es noch InfluxDB 1.8 zum Download. Puh, Tag gerettet. Installiert, mit dem Sensor verbunden, Daten werden gespeichert. Durchatmen.

Nun bin ich also wieder zurück in Home Assistant und will gerade herausfinden, wie ich die Daten aus der InfluxDB nun in einem Dashboard anzeigen kann, als mir auffällt, dass… es mittlerweile wieder Daten aus der Sensor.Community anzeigt. Na toll.

InfluxDB als Sensor in Home Assistant

Auch wenn es jetzt erstmal wieder funktionierte, wollte ich natürlich auf Nummer sicher gehen und die Daten doch aus der InfluxDB ziehen. Das ist leider wieder etwas umständlich, aber was solls. Also zunächst muss man eine sensor.yaml erstellen. Ich benutze die Docker-Variante von Home Assistant, also lege ich sie dorthin, wo auch die configuation.yaml liegt.

Anscheinend kann man in dieser Datei diverse Sensoren definieren, die man nicht über eingebaute Integrationen im Klicki-Bunti-Interface erstellt hat.

Die Datei sieht bei mir so aus:

- platform: influxdb
  host: IP-Adresse
  api_version: 1
  queries:
    - name: feinstaub_pm10
      where: 'time > now() - 7d'
      measurement: '"feinstaub"'
      field: "SDS_P1"
      group_function: last
      database: feinstaub
    - name: feinstaub_pm25
      where: 'time > now() - 7d'
      measurement: '"feinstaub"'
      field: "SDS_P2"
      group_function: last
      database: feinstaub

Das erstellt zwei Sensoren. In die configuration.yml kommt noch folgendes:

sensor: !include sensor.yaml

influxdb:
  exclude:
    entity_globs: "*"

Keine Ahnung, wozu man den letzten Teil braucht, aber es steht so in allen Tutorials! Insgesamt aber nett, dass Home Assistant überhaupt InfluxDB-Support hat und man nichts extra installieren muss.

Wie auch immer, es funktioniert nun. Mal sehen, wie lange.