2017-04-15, 17:44
Sorry for the geek-out.
Up front: I'm all for DRM support in Kodi. But there are risks. Good news, they are quantfiable risks. Bad news: quantifying and mitigating them is probably more difficult than writing code.
The risk isn't the DRM itself, so much as the "indirect" constraints / impacts on the existing functionality of the Kodi integration that the provider might enforce, impose or expect the Kodi developers to deliver. Considering they'll be more familiar with what they can do with a standalone website or a standalone TV plugin that's vetted (either of which maintains the watch lists etc on their own system and doesn't interface with an offline library at all), they might have their own ideas on what their plugin can (and can't) do when talking to an OFFLINE provider-agnostic solution with a local database that's not hosted in the cloud.
What they may expect already when doing implementations for smart TVs:
And if they develop the same functionality, can it lead to abuses of the Kodi platform like:
I'd suggest the Kodi team needs THREE levels of oversight required:
1. A compliance/legal/contractual level to ensure that the DRM content and the plugins providing it are constrained in their ambitions for their plugins
2. A technical level, which ensures that commercial plugins adhere to the specifications and limitations provided by (1) are enabling their plugin won't break functionality OR vendor agnosticism.
3. A Kodi design principles team, which ensures that they don't get dragged down rabbit holes.
Simple example: suppose a provider of DRM streamed content is happy to develop a Kodi connector but they provide the Kodi team with a baseline specification they work to when creating other connectors for other platforms but that spec implies Kodi can't just have that content exposed to end users through two source-agnostic "Movies" and "TV Shows" libraries, it has to implement a per-vendor namespace, to allow a plugin for a specific platform to look after its content only, e.g. decide what is and isn't a TV show, what is and isn't freely provided, what is covered by the subscription, what's PPV or time-limited, and so on.
Up front: I'm all for DRM support in Kodi. But there are risks. Good news, they are quantfiable risks. Bad news: quantifying and mitigating them is probably more difficult than writing code.
The risk isn't the DRM itself, so much as the "indirect" constraints / impacts on the existing functionality of the Kodi integration that the provider might enforce, impose or expect the Kodi developers to deliver. Considering they'll be more familiar with what they can do with a standalone website or a standalone TV plugin that's vetted (either of which maintains the watch lists etc on their own system and doesn't interface with an offline library at all), they might have their own ideas on what their plugin can (and can't) do when talking to an OFFLINE provider-agnostic solution with a local database that's not hosted in the cloud.
What they may expect already when doing implementations for smart TVs:
- Telemetry based restrictions, e.g.
- Netflix restricts the number of simultaneous uses of an account that can initiate playback unless you hit a button to upgrade your account.
- Region locking / country based content filters.
- Netflix restricts the number of simultaneous uses of an account that can initiate playback unless you hit a button to upgrade your account.
- Content being available one week and not available the next, or free this week and PPV next week (Prime and Netflix, I'm looking at you)
- Movies and TV Series categories, and "watched lists" that ONLY exist in their their own platform
- UI interruptions before playback - e.g. pay-to-play acceptance buttons for PPV.
- Assumptions/ requirements (on their side) for Cinavia protection, commercial DVD/BluRay codecs, region locking etc (as is the case on consumer devices with optical drives)
And if they develop the same functionality, can it lead to abuses of the Kodi platform like:
- Interrogating the system configuration to see what other plugins are installed
- Metrics: logging what's been watched in their plugin is fine, allowing them to track what's been watched from a LIBRARY would be a very neat way to indirectly spy on what content the competition's providing.
- If two competing providers offer the same film at the same time, one offering it as PPV and the other including it in the subscription, how do you represent that in the UI?
I'd suggest the Kodi team needs THREE levels of oversight required:
1. A compliance/legal/contractual level to ensure that the DRM content and the plugins providing it are constrained in their ambitions for their plugins
2. A technical level, which ensures that commercial plugins adhere to the specifications and limitations provided by (1) are enabling their plugin won't break functionality OR vendor agnosticism.
3. A Kodi design principles team, which ensures that they don't get dragged down rabbit holes.
Simple example: suppose a provider of DRM streamed content is happy to develop a Kodi connector but they provide the Kodi team with a baseline specification they work to when creating other connectors for other platforms but that spec implies Kodi can't just have that content exposed to end users through two source-agnostic "Movies" and "TV Shows" libraries, it has to implement a per-vendor namespace, to allow a plugin for a specific platform to look after its content only, e.g. decide what is and isn't a TV show, what is and isn't freely provided, what is covered by the subscription, what's PPV or time-limited, and so on.
