I think there is a good reason. Who wants to spend the time setting up and running a server? I happen to run my own, but it is definitely not something I would recommend to my friends and family.
Maybe someone will come along and create a super easy to install and low maintenance server platform, but if everyone uses that then it is still "centralized" in the sense that everyone is running homogenous setups. I think the key is that everything should be based on open protocols and formats. Email and the web are already there. Tent.io might be a good place to start for the social media stuff. That seems far more important than geographical dispersion of physical servers.
that's the idea
If you have a smartphone, it allows the carrier (=client) to access the device (=server) remotely.
Same for cable modems.
Maybe you also have a Wifi router. It is listening for HTTP requests because it has a "Web GUI". It is thus a web server, among other things. Maybe it also has a "backdoor" for remote login as reports continue to show this is common.
The idea is your devices are listening for incoming connections and they have data stores to serve on demand.
You may disagree but I would call these servers.
Many people manage to setup Wifi routers at home.
And with a modem or smartphone, there is almost no setup. You just turn it on and it starts serving.
So, I'd argue that "running your own server" is actually something anyone can do.
Maybe the real barrier to "running your own server" is only just confusion over terminology.
In fact, these are solved problems, and implemented in e.g. Freenet as far as I know.
There is a developer release available already: https://freedomboxfoundation.org/ All packages are included in Debian Sid.
It's so obvious that the current freedombox website is targeted at computer geeks only and not general people. It is not 'super easy to install' if it's not granny-proved.
1) your internet connection endpoint
2) your wireless router
Plus, as another poster already stated, email servers retry several times to deliver a message (as required by the spec), so the email just waits in the senders queue until your power is back, and then arrives, a few hours late.
You know, this is exactly how the internet works, today. You can do it if you want. You will find that you're gonna have to spend some (some would say a lot of) time to amass enough knowledge to become self-sufficient. But there's no big technical issue, there only is a mindset issue. Do you actually want to spend the time, face downtimes and low speeds that having a real internet would incur, or do you want to remain in your comfy walled garden ?
I'm sure what you really meant was "It's time to decentralize the services we use".
> We put a man on the moon
"We" as in "The government and countless private contractors, all with an unlimited budget", not as in "We the people". The centralization you see today is just the same thing.
This is how the internet is designed, and you can already do this today. In my case, I host my own dns, email, and my own webpages, locally on my home connection. You just have to be willing to learn, and willing to do. Once you've learned, the actual "do" is rather trivial.
[edit: forgot to list dns in the first version]
That's great that it works for you. But there are lots of people who are perfectly capable of doing this who don't want the hassle (let alone the huge numbers of people for whom this is completely impossible). I spent most of my youth screwing around with computers and learning a lot about how all this stuff works and it was great fun. Now that I'm getting older, it is frankly growing tiresome. The last thing I want to do on a Saturday-- when I should be playing with my kids and enjoying life-- is fuss with some file server that is acting up, preventing my wife from posting vacation photos. I've got enough work to do around the house so as it is. I don't need to be on call 24/7 for IT infrastructure support.
My point was: "there is no change to the internet at all necessary for this to happen".
The original comment to which I replied implied that the commenter believed the internet needed to change in some way in order to decentralize. My point was it was already, and still is, natively decentralized. What is preventing "decentralization" is convenience, and lack of knowledge, not the underlying architecture of the internet.
Well many can, but far from all in the context of hosting from home. If you are stuck behind NAT at home then you can't without paying for server resource externally and that is going to be more of a problem over the coming years as IPv4 increasingly becomes a problem and IPv6 (despite recent acceleration) taking a fair long time to become ubiquitous.
> In my case, I host my own dns, ..., locally on my home connection.
What do you do for secondary DNS? Some services respond differently to "address found from name, but server not responding" than they do to "couldn't lookup name".
One particular problem I've seen reported relatively recently is bounced mail when the senders ISP replaces "could not contact DNS server to lookup address" to "I know, I'll show them my own error/adverts web page": of course the user's MTA doesn't know anything about web pages and tries to connect to the host address provided to send mail and is told to go away (either no mail service found or there is one but it refuses mail for that recipient). If you had a secondary then the lookup would pass to there so the right (but currently non-functioning) address would be given to the MTA, it would fail to connect and drop the message back into the queue for a later retry.
It is rare it makes any difference these days (many agents that were sensitive to this, such as mail servers, no longer are because it is quite common for small arrangement not to have secondary DNS and for ISPs to break DNS in the name of making an extra penny here or there) but it is still worth having an externally hosted secondary DNS host even if everything else is a single point of failure for all (hosted on one box on one link). For a small home concern it needn't cost more than ten or fifteen $/year either to run your own bind instance in a inexpensive VPS or to use a specialist DNS service.
I run most things from home too, but have external resources (a backup location and a web service that occasionally needs more bandwidth then the outgoing link at home can comfortably provide) so my secondary services sit out there with them.
Actually, no. I run NAT on my firewall/router, and still host the services. It just takes tweaking the Linux iptables rules to run externally visible services, while still running NAT in general. Again, a "knowledge" and/or "convenience" issue, but not a technical issue.
> What do you do for secondary DNS?
I use Afraid.org for secondary DNS, but if my home link is down (hasn't happened yet...) then the service (email/web) is also down so I'm just "offline" until the link comes back up.
By "stuck behind NAT" I was meaning a NAT or 6-to-4 arrangement that is not under your control (so you can't configure port forwarding). This isn't all that common in the US or EU aside from mobile and satellite based providers (and you aren't likely to run servers off them!) but elsewhere it is more of an issue and will eventually become so everywhere where IPv6 take-up doesn't pick up fast enough.
> so I'm just "offline" until the link comes back up
I'm not sure what effects are common now (if any) but historically some services responded differently to the two downtime situations "DNS lookup worked, but I can't connect to that address" and "DNS lookup failed" - some MTAs used to be more likely to bounce rather than requeue for instance - so I always recommend topologically distant secondary DNS even for a single server+link situation. If you branch out later (for instance I currently have most things at home but a few bits external which I don't want down if my home link blips) you already have it setup so don't have the extras work to do. Also secondary DNS is required by the relevant RFCs, so if nothing else do it for that reason (I know you already do, I've added this bit for other readers should they stumble here in future).
Or, as others have stated, use one of the dynamic dns mapping services.
Control of TTL values is on example. Most registrars use 4 hours these days but it used to be that 24 hours was the value used by most (with not option of anything else). That can be a minor convenience if you expect to move things around much. I have all mine set to 5 minutes (not a great idea for anything high traffic, but nothing of mine is). If you know what you are doing running a small DNS service is no great hardship at all (though it is surprising how many people don't get it right). Custom dDNS is another reason you might want this (though I think some registrars and specialist DNS hosts offer this for little or no cost these days).
In my case it costs nothing as the three bind instances I run live on geographically separate machines that I already have for other reasons (home line, external web service, backup location) - if you have no external resources already then you'd need to pay for somewhere to host a secondary server of course (cheap, reliable enough, and fast enough VPS services are common so that needn't be much cost - though a specialist DNS services needn't any more expensive these days either and will likely be more scalable than anything we setup manually).
There really isn't much of a performance hit by recursively resolving DNS - it all gets cached anyway.
[1] http://unbound.net/ (other servers may also work for this purpose)
[2] It protects against a resolver that lies, but race conditions (e.g. NSA/QUANTUM) are not affected. Hopefully, DNSSEC itself protects against poisoned results, regardless of the method.
Because I have frequently seen provably-wrong results from other resolvers, and some highly-suspicious results from 8.8.8.8 on occasion (though I haven't checked particularly often).
The point being, unless you're proving the results with DNSSEC (or similar), you can't trust any source.
I use and recommend doing both, as there's very little downside to running your own resolver.
* ISPs discouraging or even prohibiting servers, due to bandwidth or other concerns.
* Laziness/generally complacent attitude. I think this is a deeper issue than the first one, since a change here may make ISPs reconsider. A lot of people just don't want to learn about how to setup their own server for email/webpages/etc. and would willingly give control to someone else despite the privacy/freedom implications of doing so. In other words, they value "easy" over control, privacy, and freedom. The same reason walled-garden DRM ecosystems have been so successful.
I'm strongly in support of a decentralised and more "user-centric" Internet, where almost everyone has their own servers and websites, and knows more about how things work, but I think there has to be a huge shift in social attitudes first.
Unless people are willing to start paying software developers directly en masse for decentralized locally run versions of products we currently get for free it isn't going to happen. We're even getting to the point where platforms where you could conceivably do that are being killed off.
What would be a game changer is the equivalent of Android for servers. A proper standard environment with app interoperability, and potential to create app stores, just for server code instead.
The counter-parties that encryption will supposedly neutralize are commercial entities doing monitoring for advertising (or other purposes) and government surveillance. Commercial entities have all sorts of ways to collect said information (ie. by compelling you to opt-in in exchange for services). The government has a long history of successfully breaching encryption when it's motivated to do so.
The solution is to leash these powerful entities with regulation. Elect Senators with the courage to curb the intelligence community -- it was done before after the excesses of the Vietnam Era.
I very much agree with this philosophy in general, but when government and corporate interests are fighting their political battles with tech by designing software to exploit you, there is no option but to push back on multiple fronts.
Even if you had a turnkey solution (it doesn't exist yet) to self-host emails & stuff, the companies selling it wouldn't be able to get good search engine rankings.
The web giants have no interest in solutions that don't require them to host your data (so they can serve you advertising or hosting plans). Even small shops are usually based around a Service As A Software Substitute (SaaS) business model and don't give a crap about you not depending on them when you start their application.
With sufficient transparency and checks/balances, wouldn't a partially centralized internet be acceptable?
It's not an easy solution by any stretch of the imagination. If you can come up with a realistic solution then please let us know and we will help implement it.
Nothing is stopping you from hosting servers at your home or place of business (except maybe specific ISPs), isn't this how the internet was originally?
It's not impossible, its just very very unlikely in the context of current economic realities. Those that are currently begrudgingly trusted have time and time again proven themselves so untrustworthy that debates on Hacker News are about not about if, but how thoroughly they should be able to fuck the end user over and justify it with "because money".
With sufficient transparency and checks/balances, wouldn't a partially centralized internet be acceptable?
Finding an alternative seems like the path of less resistance. The people running the checks and balances have proven themselves only interested in the money of the untrustworthy above and their own intrusiveness.
Limiting trust doesn't just protect against malicious or targeted attacks - it also helps with plain old bugs. In general, limiting access and trust to what is actually needed is a good engineering practice.
Or, simply: we gave up on /etc/hosts.equiv (and .rhosts) a long time ago, and it would be a bad idea to repeat that kind of design mistake.
I for one do not want to be lumbered with maintaining my family's collection of micro services, making sure they are working OK, not compromised, and fully patched security-wise, and so forth. Its bad enough being expected to disinfect their laptops every other time the fail to follow my advice on being careful what they browse.
People who don't understand how systems work often jump to decentralization as a solution to any problem. I'm not sure why. Maybe they've been burned in the past by a centralized service, and think the best solution is to remove what they perceived as their roadblock: the centralization.
Our current situation is nothing like traveling. You sit in your home, or in your car, or at your work, or in a park, or on an airplane, and you can access anything you want anywhere in the world, instantly. There's virtually no time between wanting to read your letter and receiving it. It's fast, it's easy, and it's uncomplicated. And you don't have to prove your identity if you've done it once in the past 30 days. Do you realize how that is possible? None of that is due to decentralized services. Every single service you use on the web is provided via centralized services. And they work beautifully.
Your wireless card listens for access point probes. It hears one from the AP it wants, and it connects. The AP begins the process of creating an encrypted connection. It checks that your credentials are valid, or passes the request up to a RADIUS server, that holds all the valid credentials of all the users. It then establishes the connection. Your host polls for a DHCP server asking for a lease, and the DHCP server, diligently making sure no leases have a conflict, gives you all the local network information you'll need. Your client sends a DNS request to the DNS server, which resolves, caches, and returns your request by polling the closest possible upstream DNS server, giving you a result that's geographically closest to you. Your browser initiates a connection, across your AP, across the cable modem, across the DSLAM, across the POP, across the MAN, across the many myriad routers, switches, traffic filters, interlinks, to finally get to the load balancers that maintain a balance of requests between the web servers of your destination. The HTTPS session is established after you verify the server is who they say they are, and then you tell the server who you are over HTTP, finally asking for your letter, and receiving it. And each route long the way has its gateway configured and routing tables filled with curated BGP tables so that they know exactly where to send your data to get you from a cable modem in Indiana to a datacenter in Brazil.
What would happen if we replaced every one of those centralized services with a decentralized model?
For one thing, you'd have less bandwidth and higher latency. All the devices on the internet would be constantly communicating, trying to find consensus, trying to update routes, trying to search distributed rings (my personal favorite topology) to find peers, connect services, authenticate trust relationships, query data, update indexes, etc. To say nothing of the potential for disruption of networks by various attacks or the difficulty of troubleshooting a random network failure in a massive decentralized network.
For another, storing data on your own host in your own home is taking 100 steps backward. As a very simple comparison, it's like taking your valuables out of a safe deposit box in an FDIC-insured bank and putting them on the front dash of your car. Even besides the security concerns, if you have a fire in your house, there goes your data! It's just a really dangerous idea to put data you care about in a place that's easily available to thieves and isn't backed up to an offsite location and maintained by professionals. That's what centralized services were meant to provide. It makes no sense to try and support those scenarios in a decentralized way, because the very idea of decentralized services is contrary to high-availability data.
Final thought: we put a man on the moon with centralized services. If we had done it using decentralized services, it would have taken a lot longer than it did with a lot more work, for exactly the same result. Sometimes it just makes more sense to be centralized.
>[big description of how the internet works]
As has been pointed out elsewhere in this thread, the internet was designed from day 1 to be decentralized. None of your examples count as "centralization" at the society level. There are millions of DHCP servers etc. The exception is DNS, which was a centralized replacement for the original decentralized mechanism of hosts files - an understandable decision as software techniques for decentralized consensus were unknown at the time. Fortunately we can now correct this, with Namecoin or similar.
>All the devices on the internet would be constantly communicating, trying to find consensus, trying to update routes, trying to search distributed rings (my personal favorite topology) to find peers, connect services, authenticate trust relationships, query data, update indexes
You seem to have a very detailed idea of how a "decentralized" internet would work at the technical level. Sounds like you're describing a global meshnet, as imagined today. Obviously we do not currently have the tools to develop an efficient global meshnet. However, just because you cannot personally imagine one doesn't mean it isn't possible.
>FDIC-insured bank
Must have missed something - what's Facebook's FDIC equivalent? I wasn't aware that coughcloudcough services had a regulatory body that would compensate me if they failed to do their job.
>It's just a really dangerous idea to put data you care about in a place that's easily available to thieves
I agree. How exactly is a hard drive in my basement more accessible to thieves than a data center (a much juicier target) run by people of unknown competence and ethics? Of course, if you're paranoid about your house burning down, there's nothing stopping you from putting an encrypted, uuencoded zip of your files on pastebin.
>the very idea of decentralized services is contrary to high-availability data
Bittorrent: Faster, cheaper, and more robust than a central server.
>we put a man on the moon with centralized services
Really? I thought we did it by funding a whole bunch of aerospace companies to design and build different pieces. Sounds pretty decentralized. "But the funding came from the government!" The funding came from taxes, which came from millions of people, who would not have had that money were it not for the economy! Now there's a whopping great decentralized system for you. Shall we switch to a planned economy? Would that be more efficient?
The best way to make a system do what you want is design its ground rules from the get-go such that it self-organizes that way.
The current situation is akin to having to travel to some centralized letter-reading facility in order to read letter mail. Your grandma sends you a letter in the mail and you have to go to a central facility downtown, then prove your identity, and then they hand over the (opened) letter.
We put a man on the moon more than 40 years ago. We must be able to sort this out.