We received some concerns about tracking and privacy when we launched IVDB.io. Here is our reply to answer for some of the concerns.
We have seen some concerns in the community regarding the release of our script database service (new URL: ivdb.io), and it’s use of “script tokens”. Hopefully, this will clear up some of the confusion and explain the rationale behind it.
We have been scripting videos for 1.5+ year now. In that period, we learned a lot about creating scripts, onboarding content sites to the interactive space, and challenges facing users who want to enjoy scripted content. As a result, we have created tools and processes to improve all of the aforementioned issues. We are closing in on 2000 scripts created by us and the number grows every day.
A seasoned user of the community (by now) probably finds the process of finding, downloading, and playing a video and a matching script easy enough. You have your favorite script forum, video player, content site, and maybe even a favorite scripter. You know the tech well and can enjoy scripted content without too much fuss. Our experience as a company is that a lot of new Handy owners struggle with this. The service is an attempt to streamline and simplify this for Handy owners. One benefit of an online scripting database is to not have to use script files at all. In the near future, we imagine a scenario where you just click play on a video, and our system will automatically get a script to go with your video.
In our experience, the threshold for many content sites (especially the smaller ones) to provide and invest in interactivity is too high. Either due do concerns related to the business side or lack of technical resources on their end. Our script database service and the accompanying APIs and utilities address some of these issues and should lower the bar to going interactive.
On the business side, existing content sites with interactivity support have different models. In most cases, one of the following:
With the exception of the “free to use and download” model, all other variants try to limit the interactive experience to paying subscribers and avoid the case where a subscriber downloads all available content on day one and then leaves the service.
We feel that the existing non-free models reflect the limitations of the existing non-Handy devices out there and are not what some of the script providers might ideally want. The closed script model that can be enabled with the use of tokens addresses this specific issue. It should also reduce the chance of script piracy for script providers, something that is not just an issue for content sites but also professional scripters out there.
The choice to provide closed or open scripts is up to the script provider. You can use tokens and get the benefits of ease of use while allowing your users to download the actual script content if you choose to. Nothing limits a script provider to one or the other.
There are community projects that provide similar functionality to the script database. This service does not attempt to kill any of those projects or the community in general. As a company, however, we are a lot more restricted on the type of content we can provide or direct users toward in order to avoid any legal issues. Pirated content (video, script, etc.) or content found inappropriate for whatever reason are off-limits.
We might look into opening up the script database to community-made scripts if that is something the community wants. A scripter could then sign up and use the service to access and distribute their work, potentially also to non-Handy devices. We could also offer access to our internal toolchain and resources to help in the scripting process. However, keeping pirated or inappropriate content out of the index could be more challenging with external scripters.