But from all I can tell this is just a good old website. Somebody has control over the domain name. Points it to servers of his choice. And the servers deliver content of his choice. What's decentralized about it?
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
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.
you can even mount ipfs as a readonly filesystem and cat that hash and get the content.
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.
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.
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.
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.
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
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.
Still tyranny of the majority (or of the influential stakeholders, actually), but it's a different issue.
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
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.
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.
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.
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.
(I believe someone stated DTube was running behind a CDN.)
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.
With IPFS+Filecoin and a few other parts, it
might become quite trivial to host your own
video content.
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
PS: Keep up the great work on IPFS!
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...
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.
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.
Currently, without monetization in place, popular content is easy to host while unpopular content is not. Monetization levels the playing field.
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.
Thanks :)
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.
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.
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
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.
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.