If one wanted to launch a new podcast today and make it Nostr-native what would be the best way?

Reply to this note

Please Login to reply.

Discussion

Can nostr relays store large files? Or would integration with #IPFS be a better option?

The Satellite.earth CDN is a good option https://satellite.earth/cdn

I still don't understand how cheap it is. How??

Operating at a loss maybe?

There's a small margin on AWS S3 pricing. I expect they've done some maths and are expecting lowish bandwidth use and spreading the cost of data transfer across users.

Probably better to integrate with IPFS. For simplicity you could use Filebase

ipfs is trash

How is it trash?

I would post it on flare.pub. I think it would cross post to highlighter.

zap.stream + flare.pub

Nostr native I'd talk about just opting into a system that has no gates hmmm nostr is pleb san antonio is pleb af

Nostr Nests if you want audio only. Zap.stream if you're doing video. Publish to Fountain or Wavlake.

and npub.pro for the podcast specific website .. ready ghost themes !

Are you just throwing app names at me?

:-) .. how can I do that ! .. there is a specific theme for padcasts on npub.pro .. it may not be fully functional but promising ...

I'm asking for the ideal solution, not something that "works for now" (I'm not saying that kind:1s with URLs on them aren't the ideal solution), so I'm interested in what nostr:npub1arkn0xxxll4llgy9qxkrncn3vc4l69s0dz8ef3zadykcwe7ax3dqrrh43w is doing. Do you have more information?

Not I don't, hope he chimes in to share

Wait a minute .. a podcast page is NOT essentially for listening to the podcasts .. I mean how many times we go to https://www.noagendashow.net/ to listen to Adam Curry ! Even if there is a play option , people would still listen on Fountain or Wavelake - because no one listens to just one podcast and the features available on say #Fountain can't be ( and shouldn't be) replicated on individual podcast website... Feature creep and overlaod ..

A podcast page is simply for the die hard fans , to may be get the transcripts , merch or bonus content .. and show links to the popular podcast aggregators ..

Every podcaster is on social . . What I thought of npub podcast theme is that all the conversations that a podcaster is driving - to say promote the show ( on #nostr) should be available to fans on podcast page ..

In addition , anyone should be able to set up a podcast page - even if the podcast is on say Spotify .. I mean Rogan can't move his content to #nostr podcasts but nothing stops him joining nostr to promote his content .. we want to give him a free page .. so that his Spotify die hard listeners arrive at nostr .. to interact .. and like him to millions of padcasters locked into Apple , Google and elsewhere ..

GM nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6. Today you can upload a podcast audio file to https://fanfares.io and it will be lightning-gated; each person must pay for it via lightning before they can listen. Once it is unlocked, it belongs to your pubkey and you can listen any time. As a podcaster, you must use Alby to receive zaps, and listeners must pay via Alby, which is a major weakness of the current FanFares platform we will be fixing.

We are working on a big version 2 of nostr:npub16lvpp8hyxetuuczk4kjx2vqxhwmyruc72r59ysmgrsnjg5rcz8kqk07j3k which will be able to utilize any lightning provider in addition to a bunch of awesome new nostr+podcasting features, and when we launch it we will have to migrate the existing lightning-gated podcasts because v2 will be using the new kind 31338 from the audio track PR https://github.com/nostr-protocol/nips/pull/1043 . We will try to make this migration as seamless as possible.

FanFares doesn't currently create an RSS feed for you, so it is currently intended to be used by those who have an existing RSS feed and want to direct listeners to an exclusive piece of paid content with their free content.

If you publish kind 1 notes with media urls, npub.pro will create an RSS feed from that for you.

Always happy to go into more detail. Thanks for the inquiry.

I see, so the answer is the kind 31338? Both fanfares.io and npub.pro could both become RSS bridges sourcing from people's 31338 events instead of kind 1, and publishing a podcast could become a thing that doesn't require a platform, you just publish events and later you use any bridge out there to provide an RSS feed -- until podcast players start connecting to relays directly instead of using RSS (there is a PR to AntennaPod already, we just have to change the kind number and event format).

I'm not interested in the Lightning-gated stuff for now, and I think that will be the last thing someone publishing a podcast will worry about, since podcast players won't support it, but I think in the future that could become interesting too.

Kind 31338 is vastly underspecified.

"Audio events" is super generic. An audio message is completely different from a podcast episode and both are even more different than a song. I think it's awful that these things got lumped together in the same NIP.

We will support whichever kind is used for podcasts to provide RSS feeds until apps start fetching from relays directly. I agree podcast is very different from generic "audio" or a "song", because for starters these days it's very often a video...

Does it mean every podcaster ( who want to be nostr compliant and use npub pro ) will need to reload all their older content to nostr ?

Why not support RSS-feed and allow zapping to the address in the feed? For example, the author item is there (an email-address). Maybe there’s a place to put the zap address directly or just use the email-field and associate it with the author’s zap address.

https://www.rssboard.org/rss-specification#hrelementsOfLtitemgt

RSS is kinda bad.

But that’s the “standard” at the moment. Could be worse such as Spotify, Youtube etc. gatekeeping most of them.

Why not allow something and improve later. There are millions of existing podcasts waiting to be zapped )

If the expectations are podcasters would duplicate their content here - that is NOT a help to podcasters ! Who are we doing it for ?

Indeed. That’s why I was suggesting using RSS-feed directly. The fastest and the easiest adaptation.

#nostr should provide a way to consume rss ( like any other aggregator ) .. let the content be where it is ..

And also a social layer to capture all the conversations around episode , podcaster , merch , promotions - the podcast website through npub pro ..

People should be able to listen to any podcast through supporting clients - such as #Amethyst .. comment on them ..zap them .. or they may use more sophisticated clients such as Fountain .. for say subscriptions .. history etc ..

Maybe we didn't need Nostr in the first place, everybody could just have blogs and provide RSS feeds!

Reader clients could keep track of all the blogs you followed and aggregate all the RSS feeds in a unified feed.

And then in order to comment on other people's posts we would post to our own RSS feed and send an HTTP request to the original poster so they would notice and read and display our comment with a link to our blog?

And people didn't even have to host their own servers, they could just rely on commodity blog providers that would host things on their behalf! This could have been huge!

And the best part: it's all HTTP and HTML, so we know it will be loved by all developers and scale to millions!

https://indieweb.org/Webmention

Join us and help make this dream a reality!

🤣🤣

I see your point .. just wanted to clarify if we are trying to bring in millions of podcasts - to give nostr social users a richer experience -- OR - the goal is to create "podcasting 3.0 - nostr edition" ..

Both are sacred goals !

On second thought - I guess it is better to fix podcasting (once for all ) rather than doing a duck-tape .. cuz broken system is anyway working with likes of Apple and Google .. It is not that people dont have access ... might as well strive for something good !

I'm not disallowing anything, I think it's great that some people want to enhance RSS, but that isn't my goal at all.

nostr:nprofile1qqsd0kqsnmjrv47wvpt2mfr9xqrthdjp7v09p6zjgd5pcfey2puprmqpzemhxue69uhhyetvv9ujuurjd9kkzmpwdejhgqfrwaehxw309aex2mrp0ykhvetjd9nxjety9ejx2umrdphk7mrfdenjuatnqyt8wumn8ghj7mn0wd68ytnwdahkuetn9e3k7mg0jpfq2 is built like this:

RSS > Nostr on top

Npub Pro sort of turns the flow optionally into this:

Kind 1 notes > RSS > Nostr on top

FanFares is only using the kind 31338 events for lightning gated podcasts, which won't exist in a typical RSS feed. So the podcast would have a free episode that talks about/links to the gated episode. This is what podcasts already do when they are posting "subscriber only" content.

Generally, our approach is adding nostr on top of podcasting 2.0, not trying to replace it.

I see, but what I want is a way to replace it.

I know but that's a huge paradigm shift for not only podcasters but every person who listens to them. I think the winning strategy is to build on top of podcasting 2.0 with nostr. We have some great ideas we are building out. I think everyone is going to like it. Except maybe you 😆🫡 haha

Everything that is gonna coming out of this thread is so promising…👀

I agree with you nostr:nprofile1qqsrhuxx8l9ex335q7he0f09aej04zpazpl0ne2cgukyawd24mayt8gprfmhxue69uhhq7tjv9kkjepwve5kzar2v9nzucm0d5hszxmhwden5te0wfjkccte9emk2um5v4exucn5vvhxxmmd9us2xuyp, there are many possibilities with bridging RSS. FanFares will be loading all audio type events for people to discover.

The current sources of income for podcasters are sponsorship and fiat subscription. Both of these sources can be censored by monetary authorities.

If a creator is getting paid in Bitcoin, then they don't even have to dox themselves in order to get paid.

Value4value has made a start with this in terms of tipping. At FanFares, we are building on top to make audio content purchasable. Similar in many ways to buying a CD or record. Creators used to earn a lot of money when we had that system. It was basically a process of you pay for it and then you get it. They didn't have to put ads in their content to earn a living.

How is fanfares.io doing Lightning-gated content? Is it a platform-specific proprietary thing or a supposedly-interoperable Nostr thing?

Right now the lightning gate is proprietary. In the future it will be totally different architecture, totally open source, DVM-based, and handle purchases via zaps.

But about npub.pro, will it take the content of media URLs and serve them in the correct RSS fields that podcast readers will get it?

It should, if not that's a bug, check https://cd-demo.npub.pro

Ohh sht something is wrong with previews there

Every Nostr client should make podcasting as easy as posting a message.

This was my exact thought last night. But if it is not RSS is it really a podcast?

My thought was to host the audio files on Nostr.build and map my RSS to it. It least then I'm only paying for one host.

If I'm not mistaken podcast index accepts a field for social was thinking about plugging in the jump.Me link to my profile.

As far as "Nostr native" just post the link!

Zap.stream & fountain

kind 1 and Base64

and no you have to follow nip-73 😅

I have the same question but for a radio station 🤔

Nostr.nests

Since a radio station is a live thing and not a feed of discrete episodes NIP-53 (livestream) sounds ideal. It's supported by zap.stream, Amethyst, Nostrudel, Nostur and maybe Coracle. There is an always on radio by nostr:npub12hcytyr8fumy3axde8wgeced523gyp6v6zczqktwuqeaztfc2xzsz3rdp4 there already.

You all are giving a lot of not nostr-native answers.

Indeed I haven't seen one Nostr-native answer yet.

I just don’t know if it’s going to happen man. Images seem like the logistical and legal hurdle to overcome first before audio.

Do any relays support uploads of media (regardless of serving protocol) yet?

Why would you want a relay to host multimedia content and deliver it? What are the benefits of that? To me, it seems like an added barrier to entry for a would be relay operator, if they had to host gigabytes to terabytes of video, audio and images. I know they don't *have* to, but relays existing that do that would really put a damper on usage of relays that don't.

I think it makes more sense to pick an existing censorship resistant protocol that is capable of distributing the media itself, and using nostr for the notification and discussion side. Something like, a torrent is published and a note is generated and published with a magnet link and description, and discussion happens in it's replies. I happen to be building exactly this right now as a solution to these and other problems, and if a relay operator wanted to also operate a hosted seedbox they could do that alongside their relay. Maybe I'm biased on this, but I didn't undertake my endeavor and then decide it was a good idea, I thought it was a good idea before I started building.

nostr:npub1unmftuzmkpdjxyj4en8r63cm34uuvjn9hnxqz3nz6fls7l5jzzfqtvd0j2 is getting about as close as Nostr-native as we can get I think right now with fountain and the podcasting index

no one mentioned https://fanfares.io/ it's still early maybe, few podcasts more attention

Binary blob pasted into a kind 1 note.

Your welcome!

What do you mean nostr native? How would the media file be hosted? Right now I'm seeing media delivered via HTTP everywhere media is shared on Nostr, so would a delivery mechanism of the media itself over some other protocol, but notification and discussion of the media be exclusively over nostr, be a valid answer to your question?

Yes.

Well then I think the best way to solve this would be a tool that enables content creators to publish a torrent and then a note notifying followers of that content, and discussion about it happening in the replies to that content. I think this could be a censorship resistant way to distribute video content, podcasts, music, even images, and it separates hosting of media from relays, it makes the barrier to entry to hosting your own content very low, and allows basically anyone to begin hosting content for others and so democratizes content hosting. I think this is such a good idea in fact that I'm currently building software that does this as we speak.

you are building a nip-35 client, like DTAN, the reply are on another kind, not kind 1.

I am not building a nip-35 client. I do not like the torrent specification in nip-35. I don't actually need a specification for an event type for this, and IMO most applications seeking to use nostr don't either. I am building what I'm building without submitting a NIP and without any application specific protocol implementations at all. This is something that a user should be able to subscribe to content producers with any existing nostr client and view with existing client software, such as an external torrent streaming application.

I don't like the specification for several reasons, first is that there are application specific tag definitions in the spec. A general torrent spec should not have an IMDB specific tag. It seems this is built with a particular application in mind to support someone's torrent client for piracy (and I'm all for piracy but what I'm building is not a piracy specific tool) and not for generally sharing torrents.

That said, I'm probably going to give users the option to publish their torrents as kind 2003, but in MVP initially, and later by default, notes will be published kind 1.

It was Just to inform that things exists, probably if you these problems, you should write about

How do you bring in millions of ( episodes) that are already hosted in providers such as podbeans ! Will they need to upload the content to torrents ?

If they want to do that yes.

Blossom is better than torrents for this use case.

It’s easy to host audio on satellite and write on habla. Don’t know about clients