Podchain

[empaempa]

We have tinkered with an idea aimed at solving a central RSS-library problem: it's pretty much impossible to get hold of all podcasts out there. iTunes probably sits on about 95% of everything but we (the other podcast players) really can't access all that.

The basic idea is to put all RSS-links in a blockchain. If someone adds an RSS-link to our servers, your servers will be updated, too. We're in early talks with Chromaway.com, who is building a blockchain based product to keep databases in sync.

Why a blockchain? It's a buzz word, it will in itself create some interest. More importantly, the publisher will own their blocks and be able to modify them. And it will be publicly inspectable, adding to the openness we all want.

These are very early thoughts and maybe there's a better way of doing this - just wanted to put it out to get the discussion going :)

[geeknews]

OPML is easily manipulated so I disagree. Modifying it will not require podcasters to get a complicated bitchain account. A simple claim system with account verification through the email in the rss feed is all that would be needed. Pretty elementary stuff. Plus it's in a very easily readable format xml/

For the record I'm the CEO of RawVoice/Blubrry

[empaempa]

Ah, I suspected you were :)

The aim (as stated in the project document) is to have exactly that easy authoring system - as a podcaster you login with email/password and make your changes. No need to care about keys and whatnot. Not sure if you're mixing it up with Bitcoin wallets, which is a horrible user experience.

Download as OPML is no problem and a great idea.

I think this will be a lot clearer to everyone once I have had enough time to put together a prototype.

[GluedToTheScreen]

Thanks... the distinction in the format types of data output that might be obtained from the blockchain (vs construction of blockchain itself) is clearer to me now.

Perhaps a simplified functional flowchart of how things generally move around in the ecosystem?

[geeknews]

Sadly though a number of podcast host use a single email within their rss feeds. Both soundcloud and a few others use a catch email which is utterly stupid, so the email field within an RSS feed will not be the sure fire way of confirming someone owns a feed. There will likely need to be other provisions as well.

[GluedToTheScreen]

I've seen the same email for multiple feeds, too... so must be able to sort that out.

Is there a REASON soundcloud, etc, do that?

How do YOU handle that circumstance? one by one?

[empaempa]

Yes, this has been identified as a problem but if you like to claim your feed, at least in the case of Soundcloud, you can update your email. And we should provide easy tutorials on how to change your email on your Soundcloud podcast. Do you know any hosting service where change of email isn't possible?

We've also discussed adding the public key or some other identifier to your feed using a SM-field.

@GluedToTheScreen It's really hard to do a flow-chart that everyone understands. There is one in the Podchain document (not 100% satisfied with it, to be honest): https://docs.google.com/document/d/1HgN2gxmXQmyTvRKZ-wMxntWiy-baijVAi9S6l_j0V6E/edit

[geeknews]

I'll get the list there are 2-3 if my memory serves me correct. We have a claim process that allows for some 1 to 1 TLC for folks in that situation.

[cooganb]

@geeknews: Just as point of clarification--these discussions about blockchain technology get very heated. Please keep in mind we are keeping this an open space for brainstorming and hypotheticals.

A good rule of thumb I've learned is, rather than get angry or frustrated, get curious and assume good intentions.

On Wed, Feb 22, 2017 at 9:03 AM geeknews notifications@github.com wrote:

I'll get the list there are 2-3 if my memory serves me correct. We have a claim process that allows for some 1 to 1 TLC for folks in that situation.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/syndicated-media/sn-spec/issues/34#issuecomment-281677468, or mute the thread https://github.com/notifications/unsubscribe-auth/AHxGKXurFzKabo40jORWEradVaMZxWSGks5rfEAtgaJpZM4KhRpX .

[geeknews]

Not heated just good conversation :)

[empaempa]

I like being challenged on ideas, appreciate the feedback. This project has so many unknowns but also a lot of potential, done right. Curiosity is the way forward :)

@geeknews Would be great with that list. Or we can probably identify them by simply looking at our data (re-occurrence of email). Because it's a private/consortium type of blockchain, the partners can decide to change blocks as they wish but it's, obviously, not a recommended way of doing stuff. Are you aware of any hosts that doesn't allow adding custom fields AND not set email?

[iluxan]

@empaempa @geeknews and others - I'd like to open up a few "why would people do this?" and "how do we fix problems?" questions for discussion, that I think should be addressed possibly ahead of the tech. It's clear the tech will get worked out, but the process here, with no central authority over the system, could be more important.

I think ideally we should have these in the doc, but we could try to arrive at some consensus here.

As a podcaster, I would add my podcast to the podchain directory because... Possible options are:

• This would help my podcast show up in podcast players/apps where it's not currently showing at all
• This would help my podcast show up in podcast players/apps faster or in some way better than current process
• This solves another pain point/problem that I have

As a podcaster, I would take the time to update the RSS feed in the podchain directory because... Possible options are:

• Not doing this would cause a meaningful part of my audience to be unable to find my podcast

As a podcaster, how do I claim my feed if I have left my podcast hosting network/service, but my podcast is still registered on the old service?

These are other potential problems as well:

As a podcast owner, what do I do when I try to register my podcast, but it's already registered by someone else? (Could be an old network I used to work with, or just someone random.)

• What can I do to resolve this issue? Who can I contact?

As a malicious actor/spammer/squatter, what would prevent me from registering popular well-known podcasts? (This could be to redirect to a different URL that I control instead - i.e. taking over and pretending to be a different feed, or for another reason)

As an end user, how do I know which one of 10 similarly-named podcast feeds is the real ? (If spam gets through)

As a podcast app owner, how do I make sure only one "official" result is shown for each , instead of possible spam of multiple similar-sounding podcasts, possibly from similar providers? ...what do I do if a bad quality/wrong podcast is returned under the name of ?

[empaempa]

I think your first 3-4 bullets could be summoned up like:

• You control where your podcast is located
• Your podcast appears in all apps that use the Podchain. And fast (usually within a day).

Maybe not super clear in the doc but the current solution for claiming a block (each block contains one feed URL) in the Podchain is done by matching the email in the feed with the email you login with. Let's call this email-linking. There are alternatives to this, generally using custom fields like <podchain-id>123123</podchain-id> or similar.

If you leave your company and don't have control over your feed, you first have to deal with your old company to transfer the podcast rights to you. If you manage to do that, you can then change the email and resubmit the feed URL to the Podchain. Podchain will notice that the email have changed and you can now claim the block using your new email. If you then move to another host, you simply update your block with the new feed URL and apps will look in the new location.

Because of the email-linking-method, claiming well known URLs isn't possible unless you also hack the email. Protection against spam with very similar names comes down to the validation process. Every submitted feed URL are being validated before being accepted. What the validation looks like is an open discussion but could include things like requiring at least one episode that is longer than 10 minutes, a description that is long enough etc.

In the end, each service should strive to surface the best material to their listeners and is outside the scope of Podchain.

As noted above, the Podchain partners have the power to alter the data as they see fit and in extreme cases we can always put things right. I hope we never have to.

[GluedToTheScreen]

Things have been quiet, you said you would be head down on project for a bit... curious if you've learned anything or have an indication about next steps?

Have you considered adding just ONE more field to the base... a UUID? I probably don't understand the full direction but it seems to me a better KEY would, at the very least, simplify downstream maintenance (beyond the podchain).

[empaempa]

It's moving forward at half-speed - I have some other stuff cooking, too. You can follow progress here: https://github.com/syndicated-media/blockchain-feed-index

This week Chromaway have started on the blockchain and we aim to have it sort of working next week or so. Watch the repo!

A database entry aka blockchain transaction looks as follows right now:

{
  id: "some-uuid",
  publicKey: "some-public-key",
  feedUrl: "http://some.feed.com/url",
  title: 'Some podcast title',
  email: 'owner@email.com',
  deleted: true
}

Can that work, you think?

[GluedToTheScreen]

ahhh... THERE's the action; thanks for the direct link. Progress!

WRT format, glad to see a key (or two?) to manage things. I will have to review the proposed flow of things to understand actual use of the fields for any real comments, though.

I'm thinking of the VARIOUS STATES SOME TYPICAL FEEDS MIGHT PROGRESS THROUGH DURING THEIR LIFETIMES and how they are accommodated in the podchain. Gonna have to define TYPICAL feeds, I guess.

[empaempa]

Right now there are three states supported:

1. Active
2. Moved to another location, which simply is a new blockchain transaction (a new database entry that "overwrites" the old one, if you like)
3. Deleted

If you see any other states, please let me know.

[immartian]

love to offer some thoughts here later, based on our experience working on music blockchain https://github.com/Musicoin , which I believe sharing same problems with podcastings.

[GluedToTheScreen]

by all means... jump in when you can!

[empaempa]

@immartian Very interesting! Right now the podchain focus is to solve where all podcasts are and nothing else. That said, listenings and premium content are something we're thinking about long-term. Would be super fun to Hangout/Skype/Zoom and discuss.

[cooganb]

I'd love to be a fly on the wall for that conversation!

On Wed, Apr 26, 2017 at 5:14 AM, Mikael Emtinger notifications@github.com wrote:

@immartian https://github.com/immartian Very interesting! Right now the podchain focus is to solve where all podcasts are and nothing else. That said, listenings and premium content are something we're thinking about long-term. Would be super fun to Hangout/Skype/Zoom and discuss.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/syndicated-media/sn-spec/issues/34#issuecomment-297311417, or mute the thread https://github.com/notifications/unsubscribe-auth/AHxGKWtEVQ2KXYiv1KyDF34n3dXwpfhgks5rzwsAgaJpZM4KhRpX .

[GluedToTheScreen]

I took a quick look at Musicoin.org, @immartian. The tipping/tracking part applies directly to podcasting. Some podcasters avoid sponsors but would enjoy a means of support and use Patreon for this. Perhaps it's an alternative for them?

A LOT of attention these days is on TRACKING/REPORTING (mostly) free plays of podcast episodes... gathering DETAILED raw player stats... maybe reporting those back to a TRADE GROUP (?) to produce sanitized and accurate reporting of show performance, all to provide support for sponsorships/advertising.

Did a requirement like that come up in any of your musicoin dev discussions?

[cooganb]

Just read about this acquisition and thought I would share it:

Spotify Acquires Ethereum-Equipped Mediachain Labs

"The company aims to put ownership and rights to media, like music or books, on a blockchain-based distributed database. This would allow for creators to safeguard their copyrights and would enable the tracking of creative works as they spread online."

This sounds a lot like what's being discussed here. Anyone familiar with Mediachain?

[immartian]

Is there any way to share a channel between two slack teams. We had some interesting thoughts in discussion in http://slack.musicoin.org as well, really want to magnet the two efforts but keep a graceful distance to foster open-ending creations.

[empaempa]

Personally I think this is the way of the future. That said, I think it's important to take small steps, like first creating a blockchain with the whereabouts of all podcasts ;) This can later transform to whatever we see the next step is.

Let's create another issue where we discuss this broader, much more long term goal.

@immartian there are solutions for sharing channels between teams but I haven't found any for free...

[GluedToTheScreen]

Perhaps help for developers? https://cointelegraph.com/news/linuxs-hyperledger-invites-community-to-construction-of-blockchain-making-tool