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.