Ein Freund von mir hat mich gestern gefragt, ob es möglich sein, einen Podcast zu produzieren, der nur von zahlenden Kunden gehört werden kann.
Da habe ich jetzt ein bisschen überlegt, aber mir fällt keine gute Lösung dazu ein. Sobald man einen RSS-Feed hat, und den beim Instacast/Downcast/… benutzt, wird der ja von überall erreichbar sein. HttpAuth Passwortschutz ist in den Clients nicht vorgesehen.
Das einzige, was mir einfallen würde:
Der Kunde muss zuerst auf die Seite gehen mit dem Gerät was er benutzen will. Dann merkt man sich die MAC des Gerätes und erlaub für genau dieses den Download der Audio-Datei. Alle anderen bekommen statt der Folgen nur ein MP3 das einem erklärt, wie man an die Folge kommt.
Ziemlich umständlich.
Habt Ihr andere Ideen dafür?
Ps: Und bitte jetzt nicht meckern das es hier um die Monetarisierung eines Podcasts geht. Das ist eine ganz andere Diskussion die man bitte in anderen Threads führen sollte .
Das Problem dabei: die Feed-URL wird von vielen Clients an den Hersteller geschickt um dort in einer Bibliothek zu landen, damit der nächste Nutzer einfach nur noch den Namen des Podcasts in der Suche eingeben muss. Schwups nutzen alle den Feed von Heinz.
Ich kenne mich da nicht so wahnsinnig aus. Bei Bits und so bekommt man ein Passwort und einen Benutzernamen, sodass jeder seine eigene Kombination für den Feed hat. Zahlt man nicht mehr, hat man auch keinen Zugriff mehr auf den Feed. Welche Clients da mitmachen, weiß ich nicht genau. Bei Instacast stand davon schonmal was im Changelog, glaube ich.
Unter Android scheinen AntennaPod und Podkicker auch mit einem Passwortschutz umgehen zu können. Scheint also doch besser unterstützt zu sein, als gedacht.
Das wird bei BuS wohl Basic Authentication sein. Das können einige Clients, Instacast z.B., aber nicht alle.
Die technischen Aspekte einer solchen Monetarisierung (ob die nun generell sinnvoll ist oder nicht würde ich mal ignorieren), finde ich sehr interessant.
genau das passiert bei „Die Hoppe Show“ der da selber was bastelt und wohl jeder User seinen Feed bekommt die aber auch eben alle in Instacast auftauchen
Was ich mich jetzt frage: wenn ein Nutzer eine Http Basic Auth URL ala http://user:password@podcastserver.de/feed.rss baut, landen die user:password dann auch bei Instacast? Wenn ja, kann man Http Basic Auth auch nicht machen. Sobald ein Schlaukopf die URL so eingibt, fällt das dann auseinander.
Dann bleibt nur die MAC des Gerätes registrieren Nummer, die ich oben beschrieben hab.
Das ist aber dann schon wesentlich seltener der Fall. Da sollte man mit dem entsprechenden Nutzer sprechen und ihm neue Zugangsdaten mitteilen.
Den Punkt habe ich nicht so richtig verstanden. Meinst du die Ethernet MAC Adresse? Wie genau soll diese ermittelt und später geprüft werden? Das ist ja nur innerhalb des lokalen LANs möglich. Ich bin kein Android/iOS Entwickler, aber IMHO dürfte so etwas ja nur mit einer eigenen App möglich sein.
Oder du baust gleich eine Erkennung ein ob eine Benutzer/Passwort Kombination häufig von verschiedenen IPs pro Zeitraum X abgerufen wird. Könnte man Datenschutzkonform auch über Hash Summen machen. Ebenfalls mit reinspielen könnte der User-Agent Wert. Damit würdest du dann auch die Weitergabe von Zugangsdaten ebenfalls erkennen.
ein User koennte von einer frisch erstellten BitcoinAdresse ein paar mBTC senden und dann via http://@podcastserver.de/feed.rss empfangen - das koennte man automatisieren und die Addresse kann keiner erraten. Mobil clients brauchten allerdings ein kuerzeren Token zum leichter eintippen hm oder QR code oder NFC oder mann laedt zuhause runter und sync aufs Mobil
haben nur ein Bruchteil der Nutzer da draußen Bitcoin. Das ist (momentan) total indiskutabel als Bezahlsystem für Podcasts. Es sei denn es ist ein Podcast rund um das Thema Bitcoin
Das behebt das Grund-Problem ja überhaupt nicht. Diese Feed URL wird von den Clients an deren Server geschickt und wandert in den Katalog rein. Der nächste kann dann einfach diese URL im Client finden in dem er den Namen des Podcasts in die Suche eingibt.
zu 1. aendert sich ja das dann schnell wenn es nur noch Content gegen Bitcoin gibt und 2 kann diese Waehrung als einzige schnelles Micropayment und 3 ist das eine sehr sichere und schnelle und direkte Art zu spenden.
Ich warte auf den ersten Client der das in software integriert und dann geht es ganz schnell