A good old website? No.

We don't need the domain, you can take the https://github.com/dtube/production repository, ipfs add -r it on ipfs, and use DTube this way -> https://ipfs.io/ipfs/QmRWPnY8h7Eg4v74GtKT6UBy2kUAN139QwYPUrg... (few bugs but it works apart from /home not being rendered on first load, you need to click the logo)

What is decentralised:

- The website (its fully static and can be hosted on ipfs)

- The video storage (IPFS)

- The account system / commenting / voting / subscribing (when you do that, it directly creates the transaction on the blockchain)

What isnt decentralised:

- The upload endpoints (upldr*.d.tube). You can legitimately avoid it if you have a local IPFS node running and you add files yourself, however it's really not convenient for users.

- The search endpoint (asksteem.com). This is used for the search, tags browsing, and related videos.

- Server side rendering stuff for robots only (we enabled that recently)

P.S: I am the founder of DTube

Upload endpoints can be decentralised if you're willing to put a little effort in.

By removing the certbot role from the ansible config and adding a locally running debian 9 vm as a upldr host in the inventory file.

You can run the ansible script and it will provision a full upldr node, you'd then have to edit your local hosts file to point upldr1,2,3,4,5&6 to the IP of the VM.

Then running your local copy of dtube any uploads will be sent to those nodes will be processed on the upldr host you created.

This is all untested but it should work fine, nginx might throw some cors issues but those are easily remedied.

I've been meaning to try it out for a while but life has been doing its thing

https://github.com/dtube/deploy

P.S. I do ops things for DTube.

How do you suggest decentralizing the upload endpoints without forcing users to install IPFS locally?

The upload endpoints come with their own ipfs nodes, it's how the file gets added to the ipfs network.

You could put the file into ipfs via another method and then using the upload feature of DTube specify the hash, so if someone is willing to let you upload to their node then you can do things that way.

Here does "decentralized" also mean "censorship-resistant"? In light of YouTube censoring perfectly legal videos for wrongthink, I think it could be a big win for you to also come out as only censoring when there's a legal basis.

Videos can be hidden in the UI but only via enough downvotes from the community, even then the video and its hash is still on the blockchain and available via ipfs.

Not to diminish the technical accomplishment here, but that sounds like the very definition of tyranny of the majority.

Not to say that our current systems of manual moderation are perfect, but at least it's a step removed from mob rule, with recourse usually available if a video is wrongly flagged for simply expressing unpopular opinion.

If a video tries to express unpopular viewpoints at DTube, it would seem impossible for it to ever get listed again without waiting for the tides of public opinion to turn, which could take much longer if these kinds of moderation systems become prevalent and the majority could silence the voices of the minority so directly.

Decentralized moderation is a hard problem, and I don't claim to have a good solution myself, but I'd rather take centralized services over decentralized ones with moderation implemented as rule by majority with no recourse. That seems like a dangerously slippery slope towards dystopia.

Especially if the majority are all named "sybil"

https://en.wikipedia.org/wiki/Sybil_attack

Particularly with how popular it is to use bots to Facebook Like, Retweet Twitter, Upvote Reddit, etc. I'm a little worried about being hidden from search when you get too many downvotes, because I personally could probably create a downvote bot army in a day and I'm not really even that interested in it.

On steem, your influence (the power of your downvote) is weighted by the amount of stake (the currency) you have, precisely for that reason.

Still tyranny of the majority (or of the influential stakeholders, actually), but it's a different issue.

Yeah, on Steem it doesn't take a whole bunch of people to disagree with your opinion... you just have to piss off one person who holds a ton of Steem ;)

Will you open source (non minifed javascript sources) DTube?

yes, during 0.7 version, after writing docs on all active repos

the popularity of this thread on hackernews makes it obviously needed, and im quite certain with our popularity we would get quality pull requests from the community

I am blown away by this. I can't figure out where you guys are worse off than youtube, other than that you have to play some content catchup. Otherwise, seriously, what am I missing.

> The search endpoint (asksteem.com). This is used for the search, tags browsing, and related videos.

But search (discoverability) is precisely where one of the biggest problems with YouTube lies. The trouble is that YouTube has enormous power over content creators by its centralized search portal only.

Discussion: https://news.ycombinator.com/item?id=15528942

The blockchain gives us some decentralized discoverability. The new/hot/trending listings come directly from the blockchain, and cannot be altered by us. It follows the reddit ranking algorithm.

But yes I agree. Us controlling related videos and the search engine, is basically the same as YouTube. If we want to make a video popular, we can, and that's bad.

Sadly decentralised search for DTube would be a very interesting project, but not something we are willing to spend months of developer time on. If we ever see a good enough decentralised solution for search, we will adopt it, even if it reduces our quality a little.

ipfs.io it's part of a centralised DNS system(.io cctld) so when ipfs.io goes down I assume your website will go down as well?

ipfs.io is the public gateway ran by Protocol Labs staff. There are dozens of other available gateways (we used like 8 gateways total before, and we decided to stick to the most performant ones). We still use infura.io for the videos too.

We have our own gateway that we use for pictures (snap1.d.tube).

These IPFS gateways are a bit like a CDN system. The same file will load through any gateway. example https://ipfs.io/ipfs/Qmb14Qr2Jk55SDu3dtUNccZw7GDpzCHa8VeoZok... is the same as https://snap1.d.tube/ipfs/Qmb14Qr2Jk55SDu3dtUNccZw7GDpzCHa8V... or through any IPFS gateway.

Long term we plan to get rid of these gateways, by using js-ipfs in our player. Works, but not really stable as of my last try (memory leaks that cause the tab to crash after X minutes). With js-ipfs (native javascript IPFS node), we can load files directly from all nodes that have the file pinned, without going through gateways.

Also if you run ipfs locally and use the localhost:8080 gateway, then it's also going full p2p.

That's just the http gateway so that those of us who are stuck in the stone age can view stuff on ipfs. All that content is still available as long as someone has the content pinned somewhere.

run a local ipfs node and replace the ipfs.io part with your IP, it will work fine.

you can even mount ipfs as a readonly filesystem and cat that hash and get the content.

If you install ipfs-companion browser extension, it will automatically turn all ipfs.io/ipfs/ links to links to your locally running gateway.

It actually replaces all links of the form /ipfs/<valid hash> , regardless of the domain.

By that definition I can't really think of many truly decentralized protocols. At some point you have to find an entry point into the "mesh", it's a chicken-and-egg problem. I believe that bitcoin seeds nodes IPs using the DNS system for instance (IIRC it used IRC before that), bittorrent uses torrent websites to share torrents/magnet links etc...

Once you've managed to connect to a node you can usually explore the topology of the network and find other peers so you only need the centralized resource temporarily to bootstrap new nodes. I'm not too familiar with IPFS but I imagine it works in a similar way.

Disclaimer: I work for Protocol Labs on IPFS

Yeah, "Bootstrapping" a distributed network requires some sort of entrypoint. There are a couple of solutions, I'll share what IPFS is using.

First we have mDNS for local discovery. When you start a IPFS node, it starts announcing it's addresses over the local network. So this solution is pretty decentralized, as it'll connect with any node it can find. This doesn't work over the backbone though.

Secondly, we (Protocol Labs) run a couple of "bootstrap" nodes. They are normal IPFS nodes, but they run behind DNS and a static IP. Then in the standard distribution of IPFS Core (go-ipfs and js-ipfs) we hardcode the addresses. So when you start your node, it connects to the bootstrap nodes, which then shares which nodes they are connected with, so everyone ends up connected. This ends up introducing a bit of centralization, but because they are normal IPFS nodes, the community could agree to also connect to other bootstrap nodes, the only thing needed is a static address (optional really, but "Good to have") and a IPFS node running there.

Lastly, we have Signalling servers for webrtc and websocket connections (mainly for js-ipfs in the browser). This basically acts as a centralized endpoint for nodes to find each other. This is probably the most centralized solution to the bootstrapping problem.

Yup, DTube, like most projects related to STEEM still have a high degree of centralization. This reddit comment gives a good evaluation of DTube: https://www.reddit.com/r/dtube/comments/7ysdn1/how_distribut...

So most parts of it could at their core be used in a distributed fashion, but are actually accessed via CDNs. E.g. you could use ipfs-companion[0] to alter all instances of ipfs.io URLs to point to a local IPFS daemon that is connected to the IPFS network in a distributed fashion.

I did just that and streamed a video on DTube via a local IPFS daemon and the result was pretty underwhelming, since it took quite some time for the video to load, but I don't dare to evaluate why that is so. After that it does have the nice benefit though that the same video streams instantly on any other machine in my home network!

In a transitional phase to a distributed web I'd expect a lot of websites to employ a similar approach of using CDNs at first (since not everybode has local nodes running), but its sad to see that some of the flagship projects like DTube aren't even open source (and I have no idea if they ever plan to be) and/or have a distributed version available.

[0]: https://github.com/ipfs-shipyard/ipfs-companion

> I did just that and streamed a video on DTube via a local IPFS daemon and the result was pretty underwhelming, since it took quite some time for the video to load, but I don't dare to evaluate why that is so. After that it does have the nice benefit though that the same video streams instantly on any other machine in my home network!

Could be that you just started the IPFS node and it didn't really have any time yet to connect to a large enough number of peers.

But yeah, as you said, the benefit is that after the fetch from the internet backbone, the content now lives much closer for the next time.

Disclaimer: I work for Protocol Labs on IPFS

No I don't think that was it. I had ~700 peers connected. I guess due to DTube using CDNs in front of IPFS most content is probably only available from very few actual nodes.

PS: Keep up the great work on IPFS!

DTube doesn't actually use a CDN in front of any gateways. You can see this yourself in the Network tab of the developer tools in your browser.

Thanks :)

I meant the gateways (ipfs.io and ipfs.infura.io) with CDNs, because they certainly exhibit most of the charactaristics of a CDN.

My guess would be that distributed internet will never work.

Sure for popular content like Google.com. or the top 1000 of YouTube will work. But the rest will always crawl to a stand still, since the content will always be on a far away or slow node...

It just needs an incentive to have others host your content, AKA FileCoin. You've always gotta pay a little bit to keep your sites up.

That does however essentially reverse the cost of operations.

Popular content is free to host while content that isn't popular is costly to host.

The more unpopular your content the higher the cost becomes.

I'm not sure if I follow. This is from Sia, so it might not be the case with IPFS + FileCoin, but the cost for finding a host is the same for everyone. The hosts themselves determine their own price, and they're given a rating determined by the amount of storage they have + uptime + bandwidth. Users can then choose who hosts their content by looking at their rating versus cost.

Currently, without monetization in place, popular content is easy to host while unpopular content is not. Monetization levels the playing field.

On IPFS popular content is cached, a website like youtube will most likely not have to pay hosting for any parts of it's website or popular videos if they were to run on IPFS.

Content that is not popular enough to remain in the IPFS caches will require filecoin or some other form of paid hosting to keep it around, thusly increased cost.

Ah, that makes sense. Yeah, popular sites could probably get away with having no hosts, except for their older posts + user-generated content.

I think it's worse than that, there needs to be an incentive for businesses to own and support it for non-enthusiasts.

How could Apple or Google or Amazon or Facebook make money by promoting a distributed internet?

> How could Apple or Google or Amazon or Facebook make money by promoting a distributed internet?

Perhaps unprofitability is a feature, not a bug.

Individuals can choose to seed content they care about (given an effective UI), which means the content will be available as long as enough people care about it. “Enough” does need to be a sufficiently small number.

I disagree. I don't want a large company controlling most of the IPFS nodes.

> In a transitional phase to a distributed web I'd expect a lot of websites to employ a similar approach of using CDNs at first (since not everybode has local nodes running)

I'd like to think so, but a more cynical take is that efforts like this to trade on 'distributed' will either (and most likely) fail or, if they do get traction, ditch the distributed backend once it's served its purpose as a selling-point to attract early adoption.

TBH, I'm not sure how big of a future video "platforms" will even have. With IPFS+Filecoin and a few other parts, it might become quite trivial to host your own video content. With that the focus could possibly shift to platforms like Patreon, and if the payment parts of that can be commoditized (via things like Stellar and SatoshiPay), maybe even back to the good old website. One can only dream...

    With IPFS+Filecoin and a few other parts, it
    might become quite trivial to host your own
    video content.

Using Filecoin means you are not hosting it yourself.

Oh, of course, my bad. I mean't to express "have your content hosted without a central party gatekeeping party".

This solution might make a lot of sense as a build-up process.

However, until DTube release a client so that the network can build, it's just a centralized video platform using IPFS and STEEM as storage backends. Unless clients are made available, it might as well use S3 and Postgres.

If it uses IPFS as a storage backend, then why is it faster to watch the video on the website then via IPFS as hobofan did? This seems to be an indication they store that data on a server all the time.

By default, when making requests to the HTTP gateway, it'll cache the content requested until a GC runs. So it's possible that the local node you're using, have not seen the content before so it needs to go out and fetch it while the gateway d.tube uses, already has the content fetched and only needs to serve it.

Of course, the second time you load the content (or if another node on your local network already loaded it) via a local node, it'll be much faster than the public gateway d.tube is running.

Disclaimer: I work for Protocol Labs specifically on IPFS.

Furthermore, being behind a CDN, the CDN might be caching some resources at their edges for additional performance improvement.

(I believe someone stated DTube was running behind a CDN.)

the domain is not needed to access the content as the content is actually one the STEEM blockchain.

1. the content text and meta data is on the STEEM blockchain 2. Dtube is storing the videos etc on IPFS

so by reading the STEEM blockchain, we can get the content even without DTUBE.

Dtube is an app, just another one to talk to the STEEM blockchain and they make revenue by taking a small part of the revenue from the content creators.

This is exactly right. Most of the people who I asked the same question does not even understand the implication using any DNS names. I think decentralized if the new buzzword that everybody is throwing around especially crypto guys for no good reason.

Fwiw, in a hypothetical design, you could use DNS as a means to delivery for those who are not running IPFS. It would be fully decentralized via IPFS (ignoring any flaws there), but still be centralized for adoption and those not needing decentralization.

The content is available in a dozen sites and apps that access the same Steem blockchain.

The video content comes from ipfs - if you run a local node and install the browser extension to redirect requests from gateway.ipfs.io to your local node - then you have no dependence upon a single service.

If it's a DAPP you could theoretically save the .html file and just open it locally. If they've implemented some of the logic on the back end, then you can't... unless what they're doing is public and you can pretty much implement your own client.

I can save the html of any website. How does that make it 'decentralized'?

HTML that makes use of an API or content delivery service won't work if that service is unavailable. DNS-based service discovery is centralized, and so are most services themselves (at the level of the operating organization, even if the servers themselves are distributed across geography or providers). Downloaded HTML also can't connect to a service that disables CORS[^1], unless you do additional work to serve the HTML from a spoofing server or to a spoofing client. It's typical for API services to disable CORS, and content delivery services to prevent hotlinking.

HTML for a DApp, and IPFS, connect to a local Ethereum node. The local node uses a P2P (decentralized) connection[^3] to the Ethereum network. It therefore relies on the availability of the network, but not of any single org. (Your ISP can still disconnect you, though, at the physical layer or several other layers.)

[1^]: https://en.wikipedia.org/wiki/Cross-origin_resource_sharing

[2^]: https://github.com/ethereum/wiki/wiki/JavaScript-API

[3^]: https://github.com/ethereum/devp2p/blob/master/rlpx.md

So first, you cannot save the html of any website like this. A lot of websites generate the content you'r browsing dynamically via a backend. Others will query APIs that will only answer to their domain (CORS).

What I'm saying is that a dapp can be contained into your .html and query the different APIs or the Ethereum network via your own clients/nodes.

Can't the same be said about apps?

You download Google Chrome. For all you know it's phoning home all your passwords to Google in a way they can decrypt and they can empty your bank account.