Wir freuen uns eine weitere Entwicklerin in der Runde begrüßen zu dürfen: Mit Jeanette sprechen wir über ihre App Podcat und welche Herausforderungen es mit sich bringt Apps zu schreiben und vor allem zu warten.
Zum Thema Twitteraccount deutsch oder englisch, ich würde einfach in die Bio rein schreiben “english/deutsch” so dass man weiß, dass Ihr Beides sprecht und Beides akzeptieren.
Blogbeiträge tendenziell eher englisch oder, wenns die Zeit zulässt(und je nachdem wie wichtig es bei nem Thema wäre) auch zweisprachig.
Vielleicht gibts sogar Leute in der Community, die einzelne Artikel übersetzen würden…
Ich habe mir im Jahr 2018 zum Thema Audiokommentare zu Podcasts einige Gedanken gemacht und die auf der Ganzohr 2018 in Form einer Barcamp Session vorgestellt und mit den Teilnehmer:innen diskutiert.
In aller Kürze die Idee: Jede:r Podcast hätte nicht nur eine Webseite und einen Feed, sondern auch einen Fediverse Account den Podcast, jeden Contributor sowie eine weitere für jede Episode des Podcasts, entweder in selbst gehosteter Instanz im Fediverse (analog einer eigenen Mastodon, Pleroma oder Pixeltube-Instanz) oder bei einem 3rd party hoster (analog einer E-Mail-Adresse bei einem E-Mail Provider). Damit könnten private (DMs) und öffentlichen Kommentare in Form von Toots abgeben. Das ActivityPub Protokoll lässt Erweiterungen zu, sodass Audio-Schnipsel verlinkt sein könnten, ebenso wie der Timestamp innerhalb der Episode, auf den verlinkt wird. Die initialen Hosting-Aufwände (und Kosten) liegen damit bei der Kommentator:in, die Podcaster:in kann den Toot samt attachments in die eigene Infrastruktur replizieren und damit für die Lebenszeit des Podcasts persistieren.
Meine Notzen, in denen ich die Anforedrungen der Diskussionsteilnehmer:innen gesammelt habe, habe ich damals verbloggt.
Die Probleme, die sich mir gezeigt haben und warum ich im Rahmen meines Podcasting Social Networks Panoptkum das Konzept nicht weiter verfolgt habe:
Sehr schöne Folge und danke für Euren Podcast und liebe Grüße aus Wien
Ich denke der Ansatz das per Fediverse zu lösen wäre schon der richtige Weg, es muss ja nicht jeder Podcaster gleich seine eigene Instanz betreiben. Afaik hat @eazy in Fyyd.de auch schon mal Kommentare auf der Basis gebaut… (wobei ich das Feature grade nicht wieder finde).
Ich denke man muss die Konzepte dahinter für die User halt so weit wegabstrahieren, stellt sich halt die Frage wie man das mit dem Login am besten löst: Discovery via E-Mailadresse (so das man als App nachschlagen kann, wo der User seinen Account hat) gibts ja im Fedivierse nicht, oder?
Gibts eigentlich schon ein ActivityPub Plugin für Discourse?
Ansonsten: Ich finde das Thema JSON sollte man mal irgendwann nochmal aufarbeiten – ich denke das kommt bisher etwas zu schlecht weg, teilweise weil einfach das Wissen fehlt. Also es gibt natürlich für JSON genauso Möglichkeiten das Schema zu definieren wie für XML, und es gibt natürlich auch JSON-Stream-Parser, bei denen man nicht die komplette Response erst mal in den RAM laden muss.
Aber hängt natürlich auch alles vom Anwendungsfall ab: Bestehende XML-Feeds abzulösen ist natürlich quatsch, aber wenn man ein neues Format anfängt, insbesondere bei RESTful APIs macht das in meiner Erfahrung schon Sinn das JSON (als Default) zu nehmen, grade weil die gemeine Entwickler da weniger Fehler im Schema Design macht, da Listen und Dicts schon Teil der Spec sind – und man nicht die üblichen Patterns kennen muss… und es gibt bei JSON im Vergleich zu XML oft nur einen Weg gibt Dinge umzusetzen, einfach weil die Basis-Datentypen so wie sie auf json.org definiert sind halt grade die richtige Menge treffen. Wer Typen braucht kann sich ja mal JSON5 oder GraphQL SDL anschauen – aber wie gesagt: Das wäre dann eigentlich eine eigene Podcast Folge, kA ob sowas hier in den Podcast-Feed passt.
Bei den Claims (https://fyyd.de/settings/claims) kann man den eigenen Podcast an einen Mastodon-Account binden. Wenn nun eine neue Folge erscheint, wird ein Toot dafür abgesetzt.
Antworten auf diesen Toot sind dann Kommentare, die auf der jeweiligen Episoden-Seite eingebunden werden, wenn denn Dein Account die Antwort mit einem Sternchen versieht. Das wäre dann das Moderationswerkzeug 
Sehr coole Folge mal wieder 
Feedback in Text-Form:
Audio Kommentare
Die Thematik finde ich sehr spannend!
Ich glaube, dass darin ein großes Potential liegt, was man eben an Clubhouse oder an den schon vorher sehr beliebten Sprachnachrichten ablesen kann.
Da gibt es aber einige fiese Knackpunkt weswegen das Thema wahrscheinlich noch nicht großflächig angegangen worden ist. Die UI/UX für Kommentierende und die anschließende Auswertung durch die Podcaster:innen ist wahrscheinlich das größte Problem (Podcaster:innen “Workflow”).
Ich fände es fantastisch wenn man das irgendwie mit Mastodon lösen könnte, für realistisch halte ich das aber nicht. Schließlich muss man die Hürde so gering wie möglich halten und die UX von Mastodon ist m.M.n. für durchschnittlichen Hörer:innen viel zu groß. Alles Account-gebundene muss man irgendwie vermeiden, damit fallen dann leider auch Messenger raus die praktischerweise schon die UI für die Aufnahme implementiert haben.
Das Problem mit zu viel Feedback ließe sich mit einer künstlichen Begrenzung der Anzahl an abgegeben Kommentaren lösen (“Mailbox voll”) ohne dass man den eigenen E-Mail Account unbenutzbar macht. Das würde vielleicht auch die Hörer:innen motivieren Feedback überhaupt abzugeben (künstliche Verknappung). Wenn der/die Podcaster:in schon etwas an Feedback abgearbeitet hat könnte man Slots wieder freigeben.
Fände ich spannend da mal beim Roundtable drüber zu sprechen.
JSON vs. XML
JSON Feed kommt von den Entwicklern hinter NetNewsWire und Micro.blog, ich gehe mal davon aus, dass die ungefähr wissen was sie tun 
Dass bei Podcasts jetzt aber angefangen wird die Formate zu vermischen ist eine seltsame Entwicklung. Denn JSON Feed ist ja als vollständige Alternative zu XML-Feeds gedacht, wenn ich das richtig verstehe. Irgendwann brauchen wir dann Feed-Konverter-Gateways die zwischen XML und JSON umwandeln weil die einen nur das eine und die anderen nur das andere wollen/können …
Hey, Podcast-Feeds sind nicht nur menschenlesbar, wie @ericteubert sagt, sondern in der Tat auch menschenschreibbar. Hoaxilla ist so ein Beispiel. Bei Wissenschaft auf die Ohren mache ich es auch so. Klar, da passiert mir auch mal ein Copy-Paste-Fehler. Aber der ist dann kurz nach dem Prüfen auch wieder in wenigen Sekunden repariert. Und bei so einem kuratierten Feed mit enclosures aus den unterschiedlichsten (teilweise Feedlosen) Quellen wüsste ich wirklich nicht, wie ich das anders machen sollte, schon gar nicht mit weniger Aufwand.
Schöne Folge! Danke Euch.
Hiho,
vielen Dank für die schöne Episode. Das mit den Audio-Kommentaren fände ich auch sehr interessant :).
Zu dem “XML vs JSON”-Thema, habe ich dann auch in unserem Podcast, bei dem es um REST ging auch mal was gesagt. Oh, und das was Rich Hickey dazu sagt kann ich auch nur unterschreiben.
Freue mich schon auf die nächste Episode :).
Ihr habt euch im Lezten Podcast viel gedanken um die “sicherheit” einens Rückkommentar kanals gemacht. ich denke jedoch es ist problematisch. der aktueller stand für 95% der Podcast ist sie haben eine Kontakt Email Adresse. An diese kann jeder Alles verschicken SPAM gibt es also schon. und auch heute währe es möglich so eine Adresse einfach zu mit großen dateien zu fluten.
deshalb würde ich sagen feedback per podcatcher ist genau so gut / schlecht wie email.
wenn ich einen solchen tag spezifizeren würden würde ich ungefähr folgendes erwarten:
<feedback type="email" url="mailto:foo.bar@examle.com" reference-id="episode 123" max-size="20mb" accepted-formats="text,audio,video" />
<feedback type="http-post" url="https://example.com/feedback/upload.php" reference-id="episode 123" max-size="20mb" accepted-formats="text,audo,video" />
für die http-post variante würde ich folgende parameter “definieren” die jeder client übermitteln muss:
metadata_json metadaten soweit vorhanden, client, version, episode, abspielzeit, kapitel-nr, reference-id(aus dem tag) , name&email des commentators - warum json wenn doch XML das “bessere” format ist? json ist robuster/ stabiler das generieren und parsen ist einfacher. und damit erwarte ich weniger kaputte formate.
message plaintext of the Message entered in the podcast client.
file das attachment der audio / video datei.
bei http-post wird anhand des status codes ermittelt ob der upload erfolgreich ist.
generell kann der feedback tag mehrmals vorkommen 1) pro feed. pro episode um eine episoden spezifische referenz-id mitzugeben. und natürlich auch noch doppelt um feedback für jeden typ zu defineiren.