1. 7

I am not the author of this, but I think I know who is.

  1.  

  2. 4

    This touches on stuff I’ve been thinking about in the last week. @james: Is there more context for this? Are other folks thinking along the same lines? How did you find it?

    1. 4

      Author here. Full writeup at: http://pointfree.uk

      1. 1

        Have you spent any time with Apache CouchDB? There are a number of folks in that community that share opinions similar to those expressed in your writeup, and CouchDB’s feature set reflects that.

      2. 2

        I started thinking about it since I read the Telekommunist Manifesto

        It, along with what was happening at the time, inspired me to create Fire★.

        sadgit’s versioning distributed state machine is a fascinating idea. I am trying to think of all the primitives it requires.

        1. 1

          Frontend: Webserver configured to serve a GIT branch. Provides an API so that clients can commit.

          Backend: engine that synchronises between GIT branch endpoints according to user specified validation policies. Could also do it manually, merging is pretty routine for many.

          Peer location: Kademlia, GitHub, others, hopefully at the same time.

          Edit: Thanks btw, glad you like it!

      3. 3

        Once upon a time, HTTP and SMTP (among others) were good examples of a decentralized Internet. Anyone could run their own web server or mail server and be a little island unto themselves.

        1. 1

          What has changed that prevents this from occurring? Although I stopped running my own SMTP server on my home network because I found the delivery of spam to eat up too much of my bandwidth, nothing prevents me from doing this again. I will grant that deliverability may be tougher now than it was ten years ago.

          I run my own web, app, pubsub and db servers on my home network and deploy to them daily. I have recently started deploying a few projects to heroku and find it close to the descriptions mentioned in the gist.

          When I imagine the proverbial metaverse of Stephenson’s “Snow Crash”, I imagine it as a program whose execution spreads across every participating machine (like BitTorrent). I see the various areas entered as subprocesses that were created (or more likely, configured) by the local admin of that area (much like web servers are). I don’t see a total rewrite or unleashing of all copyright necessary to a acheive a truly collaborative internet. I think we’ve got a pretty good one right now and it will continue to evolve.

          17 years ago (or so), as the first dot com bubble was heating up, services and audience were over promised and overhyped. Our technology, hardware, languages, framework, etc were not able to live up to the hype sold around the famous disasters of that time. Right now, our tools, workforce, and culture have caught up to delivering on that original vision. And so, the next generations see what’s lacking and what it could be and get frustrated (the true catalyst of change).

          Right now, our technology is built largely around centralizing experience. Look to Facebook, github or amazon for examples of centralized experience. Look back at MySpace for am approach that more closely resembles the free form collaborative internet (In all its good and badness).

          Here’s my 10 year prediction: we are currently seeing development and traction of the technologies that will form the foundation of the next wave of collaboration. BitTorrent, block chain, git, html5, paxos/raft, functionally inspired approaches (if not actually functional languages) will be used to build the next levels of collaboration. We need to figure out new levels of decentralized trust to allow anonymous code execution on our machines (as JavaScript does today… perhaps). Even today, though, we can build subnetworks to test ideas like this out. Nothing has changed to prevent this, just some experiences that shun this openness have gotten immensely popular.

          1. 1

            The economics changed.

            It’s not an accident that things that shun openness got popular: they got popular because lots of money was invested in them, with the expectation of a return.

            It’s not impossible to make money off decentralised networks, but centralised products are a much safer bet.

            1. 1

              It’s the client server model. It’s too hard to deploy for normal people to have first class privately controlled network presence (webserver, smtp etc). The assumption that systems have to be consistent to work also makes it veeeerrry difficult to scale anything without a well monied central presence ie a company.

              We also have not always had such good tools and languages for collaboration as we have now. HTML5 is so rich. WebGL? Cryptocurrency? They’re enough to keep us going for a long time. Sure, Bitcoin is a bit hard to use but that’ll change as soon as something really needs it to change.

              1. 1

                Many ISP make it a violation of their policy to run your own HTTP server from your house.

                1. 1

                  Excellent point. I mentioned heroku mainly because, from my pint of view, I see AWS as something that can create the ability for is to run as much or as little of our own presence as we want. While I think “running my own server” has helped me greatly as a developer, I don’t think the important lessons about sysadmin I’ve learned couldn’t have come from managing a remotely hosted service.