Podchain
empaempa opened this issue · comments
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 :)
Also, wherever the service lives, it can validate the feeds and warn for missing/misused fields, including the ones we're discussing here.
Chromaway just told me their product is aimed for release early 2017 but I'm trying to get in early to see if it can be used.
BTW: I'm by no means a blockchain tech expert so if anyone out there is, please let me know!
I don't know anything about Chromaway, and very little about blockchains. But I don't think you can validate something before another node adds?
And what's the idea for Podcasters, they have to keep a the signing key for updates? All those keys will be lost.
BTW: iTunes is very easy to scrape, and has an open api for searching.
We imagine an open-sourced service (living on podchain.org) where a publisher logs in and add their feed. The service validates the feed, give warnings and suggest missing fields (the ones we discuss here) and then adds the feed URL to the blockchain. The service would also offer to store the access keys for the publisher (but ofcourse let them choose not to and offer an download option).
As this service is open-sourced, anyone can install and run it as they see fit (we would probably also run it under the acast.com domain, somewhere). The blockchain technology from Chromaway (or other supplier) keeps all databases in synk, so we all are updated.
Scraping iTunes is not allowed or is limited and we like to tweak and improve our search as we see fit. Also, I think it's better to have all RSS-links publicly available than rely on Apple.
Have spent a week to deep dive into blockchain technologies (you all should, it's a very elegant thought). http://etherium.org is the best bet if we should use an open-sourced solution but it seems to be quite in flux at the moment.
I met the Chromaway-people at a bitcoin-meetup the other day and they'll grant us early access to their sync-db-using-blockchain-tech - hopefully this side of the year.
This is a wireframe of how I imagine the basic functionality of podchain.org
https://projects.invisionapp.com/share/YC9D2QL3S#/screens
Feedback appreciated!
@empaempa very interested in helping with this / doing any grunt work research. Any developments since November?
I like the idea of having a centralised place for an author to submit to, and apps to retrieve from, but personally I think the most complexity an author should be presented with is pasting a feed URL into a website. Blockchains require knowledge of private keys, validation nodes, etc, etc which could maybe be overkill for what we need?
I think what we want to aim for is:
- Decentralised in the sense it's not owned by a single entity that has a competitive interest in controlling the repository
- Easy for a podcast author to submit to
- Easy for podcasting apps and services to search
- Flexible enough so that later you could add things like an admin area for podcasters to update their info or change feeds, etc
There is also the issue that most apps like ours will want to keep supporting a user just being able to paste in a feed URL to a feed they can't find in that database, so there's the tricky issue of what to do when the author hasn't submitted their feed already.
Link above is misspelled ^^^ https://www.ethereum.org/
@cooganb No development has happened, the idea is still something we like to pursue at Acast and most likely will start working once I get back to work again (been away for a while, hence the late reply).
@rustyshelf Totally agree, please have a look at the wires l put together:
https://projects.invisionapp.com/share/YC9D2QL3S#/screens
...the last wire is if you want to download your keys.
The idea is to create a service at podchain.org where you manage your RSS link. The reasoning behind using a blockchain to propagate data to all interested are many - it's decentralized, it's secure, it's publicly inspectable etc. Please read up on blockchains, it sure is a fascinating technology!
This is a fantastic video about the basis of blockchains - give it 20 minutes, you won't regret a second:
I watched the video and now can better appreciate why blockchain makes or an excellent way to store the lookup tables for public podcast feeds. Thanks for sharing that.
I also looked over the wireframes, and one thing struck me: it's too much. There's really no need for the creator to "own" the listing. An RSS feed is either public or not available, so anyone should be able to add feeds. If there's a problem with the feed, display that information anytime someone asks (or tries to submit). If you want to send suggested fixes/inclusions, cool. Do that on screen, and give the option to email the feed owner (via the address in the feed). Any "fixes" must be done on the feed anyhow, so perhaps the project moves quicker if user-to-podcast registration is taken out?
(Please note: I manage some 700+ feeds, so I'm more than just a casual user. Keep that in mind when you berate me for my oversimplification of the issue!)
@evoterra Good point, reads and additions (CR in CRUD) of RSS-links should be open to anyone.
However, it's important that Updates (redirects) and Deletes (UD in CRUD) only can be made by the owner. I've been thinking to use the email in the feed to identify the owner. So, when a new link is added, a claim-your-block-mail is sent to the feed email with instructions on how to claim ownership of the block. At this point, I think the wires reflect a pretty good flow.
I have a kickoff meeting with Chromaway on the 15th of February between 10-12 Swedish time. If anyone is interested, I can setup a hangout so you can join. The goal is to design the blockchain-part of the puzzle.
The UI and server part will most likely be Node+React to keep things simple.
@empaempa I had to look up the meaning of CRUD. :) All of which are already built into the existing RSS spec (or at least current implementation). Specific to the points you raise:
-
Updates (redirects) =
<new-feed-url>, which is already in the feed and requires access to the feed to change. Can't change it: it's not your feed. -
Deletes = delete the RSS feed. If it's still accessible and points to valid enclosed media files, it should be included.
Yes, true they are included but I think it should be possible to register a redirect in the podchain, meaning that the federate partners will go directly against the new link instead of using the built in. This will also help everyone to keep track of how things change over time.
For deletes, same thing, I think you should be able to remove your feed from the podchain and the federated partners' databases.
These two actions will happen VERY seldom so I don't think it's a super hard UX-problem to solve. And, naturally, you don't have to update/delete anything in the podchain if you don't like. But if you do, there'll be benefits like not having to keep the old link alive and have it removed from all apps at once.
Talking about updating the URLs, I think it's more important to appropriately follow and update based on 30x redirects. The information about the podcast should be pulled entirely from the feed contents.
I think the only thing a podcaster would have to manage is allowing or blocking their podcast (either globally or individual destinations or destination types).
A blockchain only makes sense if there is a sustained interest in its survival that is shared by most of its participants. It requires active participation and foremost contribution in terms of computing power on a constant basis. If this does not happen a blockchain is vulnerable to takeovers and provides no security for the information stored.
Podcasters struggling keeping up their own sites and feeds and who are usually not very technical are not a good choice to keep such a critical infrastructure alive when the only service provided is a mere listing of an URL. Why should I be running dedicated software on machines facing the public internet just to keep storage of a single information alive while most people and apps turn to big established databases anyway? Also, people will lose their "wallets" losing the ability to change their entries later on.
Given the fact that control over your domain (or the domain of your podcast hoster) is enough to provide proper validation a blockchain might not present enough added benefit here. I see the point in having an open directory but I am not convinced a dedicated blockchain is the solution to this.
That makes sense. If the majority of podcasters were serious engineers, that might be one thing, but we're not. Most podcasters are hobbyists in both media and technology.
@timpritlove @lexicon2600 It comes down to the type of blockchain used. The idea is not to use a bitcoin-type of blockchain with miners and proof-of-work, but to use a consortium-private type of blockchain. I'm soon done with a project description where all this is explained. Stay tuned!
Looking forward to details as still not clear in my mind. Big picture, though, @empaempa:
Your podchain vision references a collection of podcast CHANNELS (only), their associated attributes, and how to manage them... but not ITEMS (episodes) or their details.
Is that right or not?
That is correct. No episodes or content will be stored in the podchain, only URLs to the podcast feeds. Maybe we will store its name, too, and possibly a rating (mature etc) but no metadata. This is to keep things as simple and open as possible.
I thought I understand this concept, until I watched the videos. :/
So here are the two questions I think must be answered in order to validate this (or most any other) idea:
- What is the benefit to the podcast-consumer (podsumer, as I like to call them)?
- What is the benefit to the podcaster?
This doc sure doesn't answer all the detail questions but I hope this document answers most general questions:
The exakt details on private and public keys and the way they're going to be generated, stored, revoked and what not is something Chromaway will help us figure out. It's very doable.
the write up helps, thanks. A chain of podcast RSS feed links will be collected, each owner can claim their feed (or "link") in the chain... and update it upon confirmation by managing nodes in the chain.
How is podfade handled?
If the owner updates, fine... but fading is sometimes disappearing. With or without good media left behind.
How does an abandoned feed get updated? (assuming someone learns about it and wants to correct the data)
Please elaborate on what you mean by "podfade" (I think I understand but not 99% sure). Give some examples.
EDIT: Found this, haha: http://www.urbandictionary.com/define.php?term=podfade I should have heard the phrase before but honestly it was a first :)
I don't think it's the podchain's responsibility to handle this and I'm not sure it's even possible given that the keys to the blocks are in the hands of the podcast publisher. There might be ways to flag blocks as faded...
Yes, @empaempa, key access was my point. I guess I have been looking at the podchain as an attempt to have an independent and authoritative source that somehow also maintained the current status... but I do see that is NOT in your spec overview.
SO, the podchain is a list of all podcasts... active and "retired"... the URL of which will be as current as the last time the owner updated it. We really know nothing else*.
*I did see reference to "no content or metadata" but also saw conflicting inclusion of name/title and explicit rating (which are metadata). Either way, the actual STATUS of the feed is unknown via the podchain, right?
Title is just for being able to search the podchain a little bit easier than using the full URL, but it's not needed for it to function. Rating is just an idea, to flag weird content (like hate speech and rasism). But it's discussable, it's really not the podchain's responsibility, it's something each podcast services should handle.
I think building in features like status (active/faded) and rating is risky business as it turns a fully open library into something opinionated.
If we decide to add these features, which I think is doable, there needs to be a lot of discussion on its exact implementation. Updates to the Podchain is, at the end, something the consortium nodes decide on - no matter who sits on the keys. I think, at least :)
Thanks for expanding on that... and I'm not necessarily suggesting the podchain should contain the additional info, it was just mentioned previously.
I'm just trying to understand the "value proposition" of creating and maintaining the podchain... to see WHO gets WHAT out of it.
From the doc: "Listeners will have more content, platforms and apps will have more data and publishers will submit their podcast once and be available everywhere." In my eyes it's a win-win-win.
Keeping it alive requires very little compute power and it's not an either-or-solution, it can live in parallel with current solutions.
If non-exclusive and min. footprint, why not? As a developer focused on organizing and presenting RSS data downstream (after publication), it becomes another source of hopefully complete and accurate feed data.
- Listeners will only benefit indirectly... this is not something they will use.
- Publishers will ultimately benefit by exposure via an independent data warehouse... a single, reliable, public place where their current feed URL can be found. This is more valuable for a new podcast (achieve wider, faster distribution) than a podcast that is already established.
- Developers will have an authoritative source to obtain a complete list of podcast feed URLs.
I can tell you #3 would have saved me a significant amount of ramp up time/effort. A startup might find this VERY attractive "seed data". It appears to me that, initially, devs are the primary beneficiaries of this effort.
IF an developer already HAS a database, though, then the VALUE ADD is reduced to (a) filling in gaps in their database, (b) maybe knowing when URLs change, and (c) learning about new ones when they come online. I'm not sure how that will work but, presumably, I can monitor the blockchain OR get notified when it has changed, and therefore update my app automatically... in near-real-time. Sounds good to me.
Tell me where this is wrong or what I'm not understanding correctly.
You're right on the money. Personally I also think it's important to have a shared library that isn't owned by one single, private company. After all, podcast is an open eco-system and we should work towards making sure it stays that way.
For already established podcasts it still can be beneficial. We can see that many apps out there doesn't have all our and other Swedish content available. I doubt there are many apps out there with more than 25% of all podcasts in their search. If we can get this together and get close to a 100% library, it can be huge win for all three parties - listeners, podcasters and platforms/apps.
Which begs the question of how the chain gets populated initially...
slurp from itunes API?
And with whatever start, how to backfill to that 100% target (which is the point of this endeavor)?
Along with the question of initial-population, could someone talk a little more about the consortium? If I'm understanding this correctly, it will be the backbone of Podchain...any more thoughts about how this will be sustainable?
@GluedToTheScreen Scrape iTunes is a start and we, at Acast, will put in everything we have. I hope other companies and organisations will help out, too. Personally I see this as a long term project. Maybe we reach 100% in a couple of years.
@cooganb As written in the document, I'd like to see that the consortium partners are a legal entity with vested interest in the podcast industry - but that's totally open for discussion.
Actually, we at Acast can keep this alive by ourselves and others simply benefit from the openness of the technology, but I do think there's some other organisations out there willing to help out. In the end, all you have to put in is a small server running a docker image :)
No single company should control the blockchain. The organization is going to need to find a way to insure it is 100% independent. The best way is to make syndicated.media a non-profit and supported by the participating podcast companies. There should be no way any company is seen to profit or gain influence from a group effort.
Building the list is pretty elementary, keeping it maintained with active and podfaded shows is another issue and coming up with those rules is going to be needed.
Absolutely, it's a consortium that controls it. I'm not sure any central, legal entity is actually needed (read: SM as a non-profit). I have a meeting with Chromaway tomorrow morning and one question is what identifies a consortium node. Most likely it comes down to a certificate and how these are generated is something to debate - can any partner generate a new and give to a new partner, must a majority of the partners agree etc.
Just had a great, two hour startup meeting with Chromaway. The consortium network is basically a list of public keys. Let's say I have key "ABC123", then the other nodes are configured to trust any message sent to them signed with key "ABC123". To become a partner of the consortium network all partners need to add the new partner's key to their list of trusted keys.
Note that you don't have to be part of the consortium to run a "listening node".
Chromaway's blockchain product is called Postchain (too similar to podchain!) and runs on NodeJS and Postgresql. We'll have to write a podcast-feed validator plugin for it, so no URLs that aren't podcasts are added.
You will be able to configure a webhook to listen for changes to the podchain and an API to submit new podcast feeds. We're working out the basics right now and will present our ideas along the way - all open to suggestions and improvements.
Our goal is to present a proof of concept in May.
I'm going to be honest here. I really do not understand why this has to be done in blockchain.. Is not OPML much more simple and well supported and not reliant on a third party.
Syndicated.Media has not yet addressed where this will reside, and if they will move forward and making syndicated media a non-profit. I have real issue with the ownership issues surrounding this whole project.
@geeknews The group has addressed this several times, on the monthly calls and on Slack. So far there has not yet been a strong desire to make that happen, and the majority of folks involved don't feel it's necessary to start enacting the changes that are being discussed. It's also been stated that this will be a main topic at the symposium being held in Boston. If it's something you feel strongly about, and want to make some headway on it before then, would you be up for leading the initiative?
@geeknews This has really nothing to do with OPML. It's a library of where all podcasts are in the world. Nobody will own it, anyone can securely download and inspect the library.
The only "ownership" in the setup is that only a consortium of organisations (and perhaps individuals) with a vested interest in the eco-system is allowed to vote on what goes into the library and what doesn't. Personally I think that's a good balance but certainly open for discussion.
Forgot: the individual blocks that count the feed URL will be owned by the owner of the feed URL given they claim it after it been added. So ownership is where it should be.
"Count" should have been "holds" - can't edit on mobile :/
This has really nothing to do with OPML.
I think @geeknews is using OPML as an example, since it's been used for this kind of application before. For example, this is how the BBC makes its master list of podcasts available to podcast catalogs.
We have private OPML feeds broken down by category that contain the entire 368k shows we have in our podcast directory, we have had them for 10 years. This my question.
Whatever is created has to be simple and have protections built in so folks do not submit there iTunes feed or website URL etc as what they can submit they will.
The basic idea behind any blockchain technology is beautifully explained here: http://anders.com/blockchain. Please view the video and play with the live examples.
Blockchain is a fancy word for a database. There are some important features, though, that sets it apart from an ordinary database:
- There is no master or primary in a blockchain, which you have with a sharded database.
- Entries are owned by the one who created the entry. An ordinary database is usually owned by one organisation.
- Anyone can download and inspect the entire blockchain. An ordinary database is usually closed or limited by an API.
- It's secure even though it's publicly available. If you get your hands on a database you can change it as you wish.
I think you can make the same comparison with OPML.
The two alternatives to proof-of-work (which the Bitcoin uses) that I've read about is Proof-of-stake and Proof-of-burn. After deep talks with blockchain nerds, I'm convinced that a consortium blockchain with a voting-for-consensus is the right choice for the Podchain. So no proof-of-work needed. There are some scary attack vectors if we use a public blockchain and proof-of-work.
A consortium with partners that have a vested interest in the podcast eco-system can afford running a node. They usually use AWS, Azure or similar cloud services that have a great up-time. That said, the blockchain technology handles that nodes go offline and come back, and keeps them in sync. There are some attack vectors, for example how trusted keys are sent between the partners. We need to discuss a method for this.
The benefits are, as state above, more content for listeners, more data for services and more control and reach - add once, be everywhere, for the publishers.
There will be a validation of everything that is submitted. Right now I'm thinking that you need to have certain fields in your feed and at least one episode that is longer than X seconds. Or you'll be rejected. The idea right now is that the validation is done during the voting process, that each node in the consortium performs this validation before it cast its vote.
Phew. Long answer! :D
@empaempa, that's a great overview of the "What?". What are your answers for the "Why"?
For example, one reasons blockchains exist is to deal with absence of trust (i.e. the Byzantine Generals problem). But it sounds like there will be a consortium that serves as gatekeeper, in which case a blockchain is just a difficult-to-access database.
Even blockchain gods will tell you that if you can use a relational database you absolutely should, so that's what I'm thinking of while pondering what a blockchain-based system buys over a boring-but-dead-simple download/API combo.
I think the technical "why" is answered above - no single point of failure, data is kept in sync, data is publicly inspectable and secure, publishers own and manage their feed URL records. The data should be available through an ordinary REST API, too.
The philosophical and political whys (my personal opinions):
- I think iTunes is a problem in the podcast eco-system just like Google is to the general web. No company should control such amounts of data. Historically Apple has played it nice and maybe the continue to do so, but they could easily disrupt the eco-system by closing their APIs. From a technical perspective it's a single point of failure. If we want to counteract this, we should come up with another solution rather than creating the same problem again.
- Having no authority or central database plays beautifully into the spirit of podcasts.
- Setting up a consortium that communicate via a technical protocol is much easier than negotiating how changes to the respective databases should be synced between the parties. Most likely we all use different types of databases.
...I might come up with some more during the day :)
Please quit using the word consortium to such time it is. The organization is a open working group, there is no organization or rules that would define an actual consortium.
As I said OPML accomplishes the same thing without the complexities of a bitchain. 99.9% of podcasters are going to hear that and there eyes roll back in there heads.
FWIW Apple is not the gate keeper never has been, sadly most devs have been lazy and used their API which is pure insanity. We have had a master list of shows and episodes for years. Because we invested the time and could never bank our business in the gratitude of Apple.
I use the word consortium because that's the word the blockchain technology uses. In this domain it's not meant as a legal entity, it's just blockchain nodes that trust each other. Feel free to come up with another word and I'll start using that :)
Good for you (which company do you work for?) that you have invested in this, we at Acast have, too. But we see that on this specific issue a collaboration between organisations in the podcast eco-system would be a huge win for everyone (listeners, publishers and services) and make it more stable.
OPML in itself doesn't have a syncing mechanism, it's centralized (it depends on your service to be available), podcasters have no say about their entry in the OPML - maybe by emailing you. If they're added to your OPML they're not automagically available in other services minutes later. These are all things a blockchain solves. How we present it to the world - via a docker image, a site, an API, as a downloadable OPML-file, is all implementation details.
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
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.
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?
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.
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?
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
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.
Not heated just good conversation :)
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?
@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 ?
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.
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).
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?
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.
Right now there are three states supported:
- Active
- Moved to another location, which simply is a new blockchain transaction (a new database entry that "overwrites" the old one, if you like)
- Deleted
If you see any other states, please let me know.
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.
by all means... jump in when you can!
@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.
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?
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?
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.
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...
Perhaps help for developers?
https://cointelegraph.com/news/linuxs-hyperledger-invites-community-to-construction-of-blockchain-making-tool