Phase 7 - The Plan #554
Replies: 8 comments 35 replies
-
|
Transcripts.
A "proper" solution to dynamic ad insertion that does not break timestamp-based search engines (and other apps) would also be very nice. But realistically this is probably not something we would be able to reach agreement on in Phase 7. I have written a proposal here: #556 |
Beta Was this translation helpful? Give feedback.
-
|
Hi In Phase 7 I would like to see the following please. Podcast:VerifyOwnership PodFans Search Filters showing Country. PodFans Admin view enabling Podcasters to select their country. |
Beta Was this translation helpful? Give feedback.
-
|
Re-reading the spec for location, lat/lon is not mandatory either. Both the I'm not sure I see the benefit of a nested new tag, as opposed to multiple location tags with an additional context attribute ( |
Beta Was this translation helpful? Give feedback.
-
|
Fine by me if we don't need a new nested tag. I'm suggesting that the I'm also absolutely cool with documenting ways to get a "country" out of a lat/lon pair; which ought to be a simple and easy transformation. |
Beta Was this translation helpful? Give feedback.
-
|
Making them mandatory removes the ability to specify a fictional location like "Hogwarts", as shown in the spec. I don't know how many people are actually using this ability, but I'm wary about reducing existing functionality. As you alluded to, the question here is whether we support a new |
Beta Was this translation helpful? Give feedback.
-
|
"mandatory in the case of a real location" I'd really like to avoid cruft. A country tag offers so little functionality, and the country is available through this location tag which has so much possibilities. |
Beta Was this translation helpful? Give feedback.
-
|
Github discussions has a poll function. Maybe we can set a guideline for adoption where we can poll for decisions like this, with a minimum number of votes to pass (or have certain "super" voters like @daveajones that carry more weight). It's difficult at the moment to get a clear picture of who supports a tag and who doesn't, and maybe a poll can be useful for this? |
Beta Was this translation helpful? Give feedback.
-
|
I'd still like consideration for the proposals for notes and other rich data in chapters (which seem increasingly pointless to be a separate file with everything else we're cramming in the RSS feed). This would make Podcasting 2.0 chapters actually better for the audiences instead of merely a separate file that benefits almost no one differently after publishing. #400 |
Beta Was this translation helpful? Give feedback.
-
|
I see the Phase 7 list in the top post has grown, although it is not based on any of the suggestions above. Was their inclusion perhaps based on upvotes of the respective proposals? If so, I would like to draw attention to the following which has the next highest votes behind those already included: There might be some bias within this developer community toward Bitcoin that is not representative of the larger world, and this may be reflected by suggestions that we can solve the underlying problem behind my proposal by still using Bitcoin under the hood and converting dollars into Bitcoin when topping up a wallet. But that's a completely separate idea and is not what I'm proposing here. The proposal is to simply add plain old PayPal as one of the payment types in addition to Bitcoin. Is there any reason why we can't consider that? There's no mystery behind it, listeners would just use a familiar currency and a familiar payment method that they may have greater trust in, and which they may indeed already be signed up for, lowering their friction to participate in V4V. Having choice is a good thing, and this is a choice that is currently lacking in V4V. #538 (reply in thread) gives a concrete example of what the XML would look like: <podcast:value type="paypal" suggested="0.05USD" minimumPayout="5.00USD">
<podcast:valueRecipient address="paypal.me/person1" split="50"/>
<podcast:valueRecipient address="paypal.me/person2" split="50"/>
</podcast:value>No SDK is needed for the app developers to implement this, only logic to keep track of listen time and once it reaches the minimum payout, prompt the user to click the PayPal button which just launches the URL I respect what everyone is trying to do with crypto but let's just step back a bit and notice that listeners will probably welcome having a familiar option to go along with other payment options. |
Beta Was this translation helpful? Give feedback.
-
|
Maybe I’m misunderstanding what problem grouping value blocks by currency is trying to solve. If a feed has multiple For example, if person1 and person2 can accept GPB & USD, but person 3 can only accept USD, listeners in the UK will only see the recipients from the <podcast:value type="manual" suggested="0.05" currency="GBP">
<podcast:valueRecipient split="50" address="https://foo.co.uk/person1/{amount}{currency}"/>
<podcast:valueRecipient split="50" address="https://foo.co.uk/person2/{amount}{currency}"/>
</podcast:value>
<podcast:value type="manual" suggested="0.05" currency="USD">
<podcast:valueRecipient split="40" address="https://bar.com/person1/{amount}{currency}"/>
<podcast:valueRecipient split="40" address="https://bar.com/person2/{amount}{currency}"/>
<podcast:valueRecipient split="20" address="https://bar.com/person3/{amount}{currency}"/>
</podcast:value>If we complicate it further with multiple payment addresses per recipient, what’s unacceptable about this approach? <podcast:value type="manual" suggested="0.05">
<podcast:valueRecipient split="40">
<podcast:paymentAddress currency="GBP" address="https://foo.co.uk/person1/{amount}{currency}"/>
<podcast:paymentAddress currency="USD" address="https://bar.com/person1/{amount}{currency}"/>
</podcast:valueRecipient>
<podcast:valueRecipient split="40">
<podcast:paymentAddress currency="GBP" address="https://foo.co.uk/person2/{amount}{currency}"/>
<podcast:paymentAddress currency="USD" address="https://bar.com/person2/{amount}{currency}"/>
</podcast:valueRecipient>
<podcast:valueRecipient split="20">
<podcast:paymentAddress currency="USD" address="https://bar.com/person3/{amount}{currency}"/>
</podcast:valueRecipient>
</podcast:value> |
Beta Was this translation helpful? Give feedback.
-
|
Having a common currency is a prerequisite for computing splits, and in practice the feed owner gets to decide which currency, while other value recipients would be invited into the value chain using a currency that the feed owner decided on. The problem that is solved in grouping by currency rather than grouping by payment gateway is that since there are many alternative payment gateway options for the same currency and since the only prerequisite to calculating a split is the common currency, this opens up more flexibility to allow more recipients to participate in a value split even though they may have accounts through different payment gateways. Regarding your last example, I suppose you are wondering whether you can make this even more flexible by mixing all currencies together into a single block. I suppose you can, although in practice if every value recipient wants to choose a different currency, and you leave it up to the listener to choose the currency that has the lowest conversion fee, then only one lucky recipient gets any value, and perhaps not even the feed owner gets any value. There needs to be some agreement on currency in order for splits to work, and I think in the end it is probably up to the feed owner to make the decision. But technically speaking, there is nothing wrong with mixing multiple currencies into one block - as you've shown, it can be viewed as simply a more concise way of representing exactly the same behaviour as having multiple value blocks, except you don't have to repeat the split ratios again and again, which is a benefit. Maybe, then, you could even mix bitcoin payments into the same structure as well and reuse those same split ratios. |
Beta Was this translation helpful? Give feedback.
-
|
This is awesome. Now we have both SATs and Fiat payments in TrueFans I need to read this several times to get my head around how this might work. On all episodes, we show both the SATs value = SATs per minute x length of episode but we also show that converted into the local currency. The challenge is of course if paid for in Fiat the payment gateway takes 3% but that is not the case with P2P SAT payments however I can see the benefit of offering a FIAT payment option. |
Beta Was this translation helpful? Give feedback.
-
The only concern as an app developer is what if the listener consumes a vast amount of content and implies they are willing to pay for it but when it comes to actually making the final payment they decide not too or don't have sufficient funds. Taking payments per minute using SATS enables us to prevent this use case. Of course the user can set the V4V to zero and not pay at all. I am wondering if we can take a prepayment in advance. So the user has $10 on account and then when then minimum payment is met we can take the $5 and remind them to top up their account? In effect we are doing this with SAT's wallets. Users are storing 10K SATs in their wallet and then choosing to stream/boost using those SATs. Food for thought |
Beta Was this translation helpful? Give feedback.
-
|
I think fiat works for boosts, but for streaming I think it's better to convert fiat into sats, since it can be such a small amount per minute. Managing streaming fiat could be tricky. |
Beta Was this translation helpful? Give feedback.
-
|
I'd like to see the person tag improved upon. As well as the social tag on the channel level be implemented. |
Beta Was this translation helpful? Give feedback.
-
|
Would love to see person tag improved before PSP makes a big push to get wide support for it. |
Beta Was this translation helpful? Give feedback.
-
|
Some proposals for phase 7 consideration: |
Beta Was this translation helpful? Give feedback.
-
|
Buzzsprout, RSS.com, Podhome, TrueFans, and Episodes.fm have expressed interest in |
Beta Was this translation helpful? Give feedback.
-
|
I'm happy to execute it for Castopod as well, if @yassinedoghri is cool with it... |
Beta Was this translation helpful? Give feedback.
-
|
podcast:host is a no brainer and easy to implement by hosts with no user input. I could also get it pushed through the PSP 1.1 tags which is the next batch of tags to universally support. |
Beta Was this translation helpful? Give feedback.
-
|
I agree that the intent of this tag is super easy to implement. Perhaps I'm being too pedantic, but my only caveat is that maybe Platform/generator can cover self-hosted podcast RSS generator apps, as well as all the hosted apps. e.g. I use AWS to host my website, and Cloudflare as a CDN for my media, but I'm using a self-hosted version of Castopod. For analytics, all this can be interesting, although my understanding is that we mostly care about the platform/generator. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @daveajones In an attempt to help you before Phase 7 closes. I have tried to collate all conversations about new/proposed tags with subsequent links into this one post.
We have also created separate pages for artists and audiobooks. So if we detect medium=music we create an artist (publisher) page as opposed to a podcast (publisher) page.
I am not sure why we need this tag? We already have categories and keywords. Categories are defined taxonomies. We have recently added a new Music taxonomy from Wavlake and TrueFans show this when we detect meduim=music. We can collectively develop a new taxonomy for other categories like audiobooks, films, courses etc. Keywords are podcast creator ad-hoc lists. And if that doesn't work we have the free-form description field for show notes. 
Other tags for consideration based on GitHub conversations.
I think this is everything @daveajones I can see on GitHub for Phase 7. Hope this helps. Phase 8 might include
I hope I captured everything but if anyone can spot other things to add for Dave's consideration please list them below. |
Beta Was this translation helpful? Give feedback.
-
Time to start formalizing a list of what we want to be in phase 7:
publisher medium and feeds Publisher feeds #579 (enhancement)keysend address Add a new address type for lightning address (in valueRecipient) #576 (enhancement)chat Proposal: <podcast:chat> tag #502simplified license list (enhancement) Initial seeding of <podcast:license> tag values - optimization #603course medium Add Course to medium #577title attribute on remoteItem (enhancement) Enhancement Proposal: Title Attribute for RemoteItem #629add item as parent for contentLink tag Proposal: contentLink Enhancement (Revised) #614Beta Was this translation helpful? Give feedback.
All reactions