Hacker News new | past | comments | ask | show | jobs | submit login

Hey, Hi! Haven't had the time to try Streamus when it was still active, but kudos on the extension!

I was wondering, how stupid would it be to bundle youtube-dl with a NWJS/Electron app and make a user accept an EULA where you have a disclaimer that you're not responsible for anything, and have the app function like Spotify but using youtube-dl to fetch the DASH m4a/opus audio files off of YouTube and play them, thereby removing ads and minimizing data usage...

I am in the process of making such an app, but not a lawyer, so not sure how well it'd go... It would be open source...

Hey :) Thanks.

I don't think you'd encounter any legal issues. You're not using YouTube's API to retrieve anything. That said, it's pretty easy to imagine how they could neuter the product if it grew large enough. It'd go down similar to AdBlock vs ad-network. Both sides constantly adding/changing keys, challenge responses & answers, etc.

You can put in place all the contractual provisions you want with the user but your relationship with the user is irrelevant. It is your relationship with the host/owner of the content that matters.

Streamus attracted Google's ire because it bypassed ads and separated out audio and visual content. Both of these attributes look to be features of your proposed app. On that basis it is likely to attract Google's attention.

Having said that, it's likely that they wouldn't bother pursuing you until your app became popular, as was the case with Streamus...

Sorry, just to clarify -- Streamus did not bypass ads. The minimum allowed video player is 200px * 200px, their ad network doesn't run on that small of a player because advertisers were unwilling to pay to have their ad shown that small. I was initially accused of this by their legal department, but if you read through the entire e-mail chain, you'll see they eventually relent and admit that advertisements are not an issue.

Additionally, I did patch in support for video content (and wrote a huge post on the tech. challenges of it: https://medium.com/@MeoMix/beautifully-buffered-bytes-ff798e...), but that proved insufficient.

YouTube took the view point that Chrome extensions should function similar to mobile apps not like browser tabs. They indicated they wanted the music paused whenever the main UI window minimized. I argued that would be like pausing YouTube when you click between tabs. They disagreed and terminated my API access.

what would be an acceptable amount of cache storage for such an app, would you think?

because one thing I don't like about streaming is that the content can be gone next time you want to hear it. I use youtube-dl to save videos (or often just the audio stream) because of this.

If you leave out the video stream, they're quite tiny (in context of modern storage). A quick scan of my saved .opus files, shows the same rough ~1MB/min filesize that 128k mp3s have (except with way better quality of course).

For simplicity, I wouldn't cache anything. Run youtube-dl with the JSON dump option to get all the sources, find the best source, put the URL into a <audio> element and that's it. At least that's how I'd do it.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact