REAL.video update from the founder, plus some new FAQs

REAL.video is the free speech alternative to YouTube, where censorship is so out of control that YouTube is now banning videos about CBD oil and natural medicine. I started the REAL.video project several months ago when YouTube, without explanation, banned my entire channel (with 1,000+ videos). Now, I’m building a platform so that others can express their beneficial ideas for society without being silenced and censored by the truly evil oppressors who run Google / YouTube.

After a soft-launch of beta.real.video (with a very limited invite of a small number of content accounts), we’re now in “bug hunt” mode. We’ve got lots of bugs in the system, and some slowness in video processing, but all those are getting addressed day by day.

A new production build will go online sometime Wednesday, and it should feature several key improvements. Development will continue as we build more features through the remainder of this year. (Playlists is the No. 1 most requested feature, and that’s on our list.)

Notably, uploads, transcoding, storage and playback are working in most cases (but not all). New videos are being posted every few minutes, and our moderation team is approving them rapidly once they appear in the moderation queue. Currently, it’s taking about 30 minutes after the upload to appear in our moderation queue, and another 30 minutes to go live. That total delay of one hour should be drastically reduced to about 10 minutes or less in the near future.

In terms of video playback performance, we are nowhere near capacity. In fact, we’re still pegged at 0% of our capacity, meaning we haven’t even begun to stress the system in terms of simultaneous video views. Remember, we’ve built the system to handle over one billion video views per month.

Code Components

A couple of users have asked us why we’re using so many components from other companies to build REAL.video. For example, the login authorization component is from one company; the upload component is from another; the playback player is an open source component; the comment component is from Disqus (currently); the internal database component is a software-as-service provider, and so on. The simple truth is that building and maintaining all these components yourself, across all the multiple computing platforms (different browsers, operating systems and mobile devices), would require a budget of at least $100 million to build from scratch. We don’t have that kind of budget, so we’re using off-the-shelf components for rapid deployment and modularity. Trying to build all these components yourself would be as silly as trying to write your own browser, too.

These component providers are not in the business of banning customers just because they don’t like their content. Licensing components or online services is a lot like buying electricity: It’s part of the machinery that makes things work. Your local power company doesn’t censor you because you used electricity to post something they don’t like. Similarly, component providers and online service providers don’t usually censor their own customers just because they don’t like the speech in which those customers are engaging. (The one exception being GoDaddy which dropped hosting the Daily Stormer, an act that actually violated their own policies, by the way.)

The modularity of our design means that even if one component stops working, we can ultimately replace it with other components that accomplish the same task. If you’re constructing a building with a hammer, nails and wood, for example, and the wood provider decides not to sell you any more wood, you can find the same wood somewhere else. Just as importantly, service providers don’t want to earn a reputation for cutting off their own customers, or they introduce a whole new risk for customers who might be considering licensing their services. By cutting off customers they don’t like, they cannibalize their own business models and teach customers to shop somewhere else to avoid the risk of being cut off.

For nearly all service providers, they only cut off clients if they are engaged in blatantly illegal activity such as hosting ISIS terrorism websites, for example. We already ban videos that promote illegal activity, so that’s consistent with the rules that most service providers also honor.

Finally, everything on the internet depends on something else to work. There’s no such thing as a 100% self-operated internet entity. For example, routers and ISPs must route traffic from your site in order for content to be served to end users. The DNS databases must respect your DNS entries. Browsers must function, too, without discriminating against your web domain. Every website depends on a long list of other potential choke points remaining open in order to deliver content. The idea that a website can run in pure isolation, with zero risk of being cut off, is a fantasy. The internet is inter-connected, and the only way to bypass many various potential gatekeepers is to go peer-to-peer (p2p), which is part of our next expansion plan.

P2P functionality

We’ve also been asked about the P2P functionality we originally set out to achieve. While our current REAL.video system is a central server model, we’re also working on launching a P2P alternative website (with a different domain name) that will work in true peer-2-peer fashion. The challenge here is that P2P video delivery is not yet very mature, and it still requires a seeding server to serve most videos… at least until there’s a “critical mass” reached when millions of users are watching videos and keeping their browsers open to seed other viewers with P2P traffic.

Thus, P2P video serving is something I would consider to be experimental at the moment. We’re pursuing it, however, and we hope to ultimately have two parallel systems running side by side: A central server system (like real.video) and a decentralized P2P system (coming later). Interestingly, the more success we have with real.video, the more resources we’ll have to dedicate to a P2P experimental system that seeks to completely bypass the need for a central storage server.

Even then, however, you still need browser support, DNS support and other core functions to be able to find the website and view the videos. P2P doesn’t decentralize everything; it primarily decentralizes the bandwidth and storage (hosting) of the videos. However, the very existence of a web domain that points to all the videos requires some level of centralization and hosting for that domain itself. Thus, there’s no perfect, full-on decentralization scenario that’s feasible with today’s technology.

If you hear of something that might work better, let us know! In the mean time, visit REAL.video for a look at what’s being rolled out right now, and request your own account there if you’d like to have a free video channel.