Raw streaming urls don't get me any of that. URLs aren't just pointers to bytestreams. From a user sharing perspective, they're humans pointing to a unique thing. And what they're pointing to is often much more complex than a single raw file.

    https://mytube.com/$username/my_first_video.ogg

Sure, now the user would have to go through the additional work of editing URLs if they want to access this endpoint manually, but then this article's points come into play: if your users expect more functionality than what the World Wide Web does well - delivering content - then a native app is probably preferable for everyone involved (and, indeed, exists for sites like YouTube).

They're asking: what person or persons did this, what might I know them for, what do they look like, how popular are they, do they have a logo I might recognize? YouTube and Vimeo provide that information right next to the video, which is where people want it.

If a native app really is preferable, then I'm sure we'll see YouTube wind down their web interface once everybody stops using it. But my guess is that they'll still have an HTML version long after you and I are both in the ground.

And even with the URL alone, that's still significantly less opaque than YouTube's current method of https://youtube.com/$some_random_gibberish. At least someone could see something like https://mytube.com/j_random_hacker/how_to_computer.mp4 and guess that "j_random_hacker" is a username and "how_to_computer.mp4" is a video uploaded by that user.

This isn't much different from, say, reddit, where URLs are actually part of normal discussion; a redditor will talk about a subreddit called "/r/mylittlepony" or a user named "/u/Unidan" or somesuch, directly referencing paths (to https:/reddit.com/r/mylittlepony and https://reddit.com/u/Unidan, respectively). Granted, reddit's userbase is somewhat more tech-savvy on average than, say, Facebook's or YouTube's, but it shows that URLs are not necessarily opaque to typical users, and it's certainly not hard to even manually demonstrate such things to new users.

This also isn't much different from many (most?) news sites, which provide URLs that resemble the name of the article (with some adjustment to make everything lowercase, turn spaces into underscores, strip or substitute special characters, etc.).

Like a web browser?

There's no reason why a native app can't do this - in fact, many native apps for things like YouTube and Pandora and such already do this.

you want to share youtube comments with people? they are a significant value-add to you?

And here I'd concluded the comments section existed to allow pre-teens to practice their ability to make racist remarks.

No, it is not. Playback would get stuck, sound would go away for no rhyme or reason and what not. Better experience? - no - quite the opposite.

I got rid [1] of the native nuisance completely. And the experience of search, comment and history on native was simply terrible. Much lesser control on ad-blocking too, and really the ads on YT are sometimes seriously irritating.

[1] Evidence: https://twitter.com/marvindanig/status/598701509963083777

Evidence: ^

Well, if I click on the first link, a video doesn't play (that would be the case even if the link were to an actual MKV video). The second URL isn't even a hyperlink on news.ycombinator.com. But if I click on a valid YouTube link, a video plays nearly immediately.

And yet it's existed for years using p2p/torrents. So they're more like business fictions

Well said, you should tell this to Disney, MPAA, and MAFIAA so they'll stop trampling the rights of the commons by extending the length of copyrights everytime something profitable to them is about to expire. https://en.wikipedia.org/wiki/Copyright_Term_Extension_Act

The "4th option" is that you've got the causality completely backwards in your head: it just happens to be the case that the cultures where distributed tooling became important were the ones where it was necessary to promote an "all information is free" mindset, not that it's necessarily a part of distributed tooling that you take that mindset.

If we start with a centralized metadata server/peer tracker, a set of "base seeds" to keep videos alive, and a commenting system, we can still revoke access to individual videos (our app will simply not support peer discovery except through our tracker, we take down the seeds, comments, and tracker entry on a revocation) while distributing bandwidth for the viral videos that need it.

The point is germane.

Not at all, YT solved it many years ago with ContentID.

Now imagine having to install all the plethora of apps on every device, one for videos, one for music, 500 for different types of documents, etc. Instead, you install a (hopefully) standard-compliant browser, and done.

Sorry, there is some ambiguity in English about this. I am regarding a "solved problem" as a "problem" (i.e. classification) whereas you are regarding it as "no longer a problem" (i.e. interface). Yes, right now YouTube's interaction with the problem is highly limited (though not nonexistent), but if one is, say, trying to disrupt YouTube or talk about YouTube's history, one still classifies it as a problem in general that exists within YouTube's problem domain.

> Now imagine having to install all the plethora of apps on every device, one for videos, one for music, 500 for different types of documents, etc. Instead, you install a (hopefully) standard-compliant browser, and done.

I mean, I agree that it helps that particular problem somewhat to have a cross-platform virtual machine (the browser) and to distribute an executable (your JS app) on that machine rather than (or sometimes alongside) your content. This also creates its own problems, of course, like simpler browsers (spiders, text-only browsers) not being compatible with your website, as well as some new buggy issues when, say, the JS doesn't load properly. But HTML+CSS+JS is not new in this town and the cemetery has some gravestones -- like the fact that there aren't many desktop Java applications, the complete failure of the Java browser plugin, and the waning of the Flash plugin. It is peculiar among these only because its dreams are less lofty: not "write once run everywhere" but "write once, then write a (hopefully graceful) downgrade path if they do not support the features that I want to use."

I'm not sure I understand. AFAIK youtube currently makes money (from ads) and much of what people view is copyrighted music that isn't properly licensed, and which yt doesn't pay for.

Sure, some, music is taken off yt, and some content is properly licensed -- but are you seriously claiming that yt isn't (any more) making money from copyright infringement?

There's some digital content distributed via p2p legally -- and it'd not be a stretch that yt owes it's current market dominance to "flaunting copyright law" as the copyright lobby might put it.

If one relegated content (video, meta-data, comments) to torrents/magnet-links (there is an issue of loops in the links in content-addressed systems -- but with a pretty modest central server (cluster) serving up a few lists of magnet-links should be affordable)) -- I think it would be quite feasible to distribute digital media in way which the consumers shared in the meagre cost of distribution through mostly donating bandwidth.