Hacker News Reader

> replacing HTTP URLs for naming content is necessary and nearly sufficient

It depends what you replace them with. I quickly skimmed your essays looking for any proposals, but didn't quite see anything.

The obvious thing is Freenet-style public signing keys, but while this helps decentralize distribution (a boon to a person who wishes to publish anonymously - upload and run), the standard centralized naming hierarchy will form, at least for introduction.

The well-known "HNS" /com/ will just be 8b844459891e8f1840bfc4200e758483 instead of the DNS 192.5.6.30 (a.gtld-servers.net). Likewise, after introduction a discussion board would be known as 659f177ebea794e4e74f0708d832f65e (even if it is Petnamed) instead of news.ycombinator.com.

Public signatures are simply one layer and not the full solution, in the same sense that hash trees of immutable content are only one part.

What is important is forking, which relies on the ability for differing forks to be intelligently reconciled in an automated fashion. I should be able to use a version of "HN" where a specific user is/isn't banned, and still communicate with you (presuming that you want to, rather than whoever is running the popular "HN" aggregation node), even if you yourself are using a third version.

I think it ultimately comes down to the data model supporting some concept of "merge points" rather than strict top-down immutability/persistence. With these merge points and rules specified by the endpoints' schemas according to the users' desires. But it's awfully hard thinking about this stuff since I also keep seeing how any specific approach can calcify and turn into similar prescriptive monoliths as we have today.

I don't know what the answer is. I agree with most of what you say. I think we have to experiment with things that could work in theory and see what works in practice.

A variant form of "Conquest's second law of politics" almost certainly applies to all innovation in this space: Any protocol that doesn't explicitly exclude Google sooner or later becomes Google.

It may be impossible to win this game.

How do you foresee the decentralized production of CPUs being achieved?

A bit of a non-sequiter, but I'll bite.

Replicating toolboxes. Or self-replicating benchtop factories.

Microcontrollers could be produced using dip-pen nanolithigraohy, or a few other techniques.

Of course we need decent open source atomic force microscopes first.

There will always be components that can't be produced on that kind of scale. In reprap parlance we call the "vitamins". An apt metaphor.

> need decent open source atomic force microscopes

If the LHC stuff pans out, we may need open source replicators. :)

> benchtop factories

This is feasible even using current production techniques. Just make smaller tools.

Open hardware designs are a bigger part of the problem, IMO.

We have open hardware designs including the RISC-V, the OpenRISC, and the SPARC, but we don't have desktop semiconductor fabs, nor will we in the foreseeable future.

An open-source, cheap AFM: http://hackaday.com/2015/01/13/cheap-diy-microscope-sees-ind...

The production of integrated circuits is very much dictated by economies of scale. The capital require is simply too large to justify the creation of a production line for a small run. If you crack that particular nut then you're going to be the next Bill Gates.

The capital required to currently produce top-of-the-line ICs is too large. But we're getting closer - people are building their own CPUs. E.g. there was the article of someone breadboarding a CPU in the 10's of MHz range recently. And there are plenty of FPGA projects, which while still depending on ICs manufactured by a central manufacturer substantially reduces their role.

How exactly do FPGAs do antything at all to reduce the role of central manufacturing?

The same way computers do: you can reprogram them instead of buying a new thingamajig.

This makes no sense. Computers are made of centrally manufactured components, and are regularly replaced by new ones as technology advances.

This applies to CPU's too and is in no way mitigated by FPGAs.

I use my computer to read books, for example. This eliminates the central manufacturing of books; when I want to read a book, I tell my computer to turn into a book, thus manufacturing one temporarily on my desktop until I'm done.

I use my computer to graph equations. This eliminates the central manufacturing of graph paper; when I want graph paper, I tell my computer to turn into graph paper.

I use my computer to make telephone calls. This eliminates the central manufacturing both of telephones and of telephone switches; when I want a telephone call, I tell my computer to turn into a phone, and it turns routers into phone switches.

I use my computer to watch pornography. This eliminates the central manufacturing of porn VHS tapes; when I want a porn video, I tell my computer to turn into a porn video.

I use my computer to store books. This eliminates the manufacturing of bookshelves, although to be fair, bookshelf manufacturing has never been as centralized as computer manufacturing.

I use my computer to do engineering design. This eliminates the central manufacturing of drafting tables, slide rules, and pocket calculators.

I use my computer to find out what time it is. This eliminates the central manufacturing of wristwatches.

I use my computer to send letters such as this one. This eliminates the central manufacturing of envelopes and postage stamps.

I use my computer to find out about Syrian children drowning in Turkey. This eliminates the central manufacturing of newspapers, although again, this may not have been as centralized as computer manufacturing is.

Perhaps this can help you to understand in what sense the original statement is true, as well as the sense you've already pointed out in which it is false.

That's a bit further down the line, but for now it's adequate to have end-users buy CPUs produced in a centralized manner, as long as they are able to control what those CPUs do by running free software on them.

Sandstorm is an interesting step in this direction. Not peer-to-peer but decentralized free-software.

https://sandstorm.io/

> Ultimately, it was a losing game, because of the inherent conflict of interest between software author and software user.

This is exactly what is broken with our current software business models. On-prem software is expensive to deploy and manage but gives users control of their data. SaaS software is cheap to deploy and manage but takes control of the user's data. We must find middle ground between the two models. A solution that takes the best of both on-prem software and cloud based SaaS services may be that middle ground, but it's going to require a globally federated cloud.

Here's an article from a few months talking about this concept: http://venturebeat.com/2015/05/09/goodbye-saas-hello-contain.... The basic premise is that ISVs should be able to deploy their stacks on-prem, similar to the way they deploy to their SaaS-based solutions today.

I've been kicking around a slightly modified vision for a new software model I call MSaaS for about 3 years now after spending an inordinate amount of time thinking about infrastructure trust. MSaaS is short for managed software as a service. The idea is to build a federated platform for storing/signing code and images used to deploy applications, infrastructure deployment targets which carry various levels of trust, and a method for payments and identity management for settling resource consumption, including development time.

First, MSaaS needs to have a means by which an ISV's software components, such as source code or images, can be placed an immutable data structure similar to a blockchain. IPFS' merkle DAG is one such example of a blockchain that allows for immutable, decentralized data storage with signing capabilities. It allows for a company to sign a given piece of code, stuff it, and the accompanying configuration information, into an immutable data store, and make it globally accessible in a trust-less manner (i.e. anyone can fetch it anonymously). Bits can be signed and/or encrypted using public keys where needed for privacy and security.

Side Note: IPFS has an interesting 'problem' with it in that if a node containing data goes away, it is lost from the network. That's actually acceptable here regarding the source code or images users would need to pull to run applications or services as the code could be pulled from one or more centralized repositories (Github) by a trusted authority, built into an image, re-signed and then placed back on the network on-demand. Keys/configuration bits could be shared in a similar manner, or handled a tad bit differently for backups.

Second, MSaaS will introduce the idea of multiple trusted deployment target endpoints, such as those provided by AWS, Digital Ocean, OpenStack running on-prem in a DC, or even your local computer. These deployment targets respond to cryptocurrency payments and provision themselves where the trust levels exist between parties (or depending on the use-case, don't exist) using the data stored in the previously mentioned merkle DAG/blockchain. The payments themselves represent identity in the form of signing keys (which can be related to the keys used to sign the code/images) and payment for resources, perhaps including a managed service provider along the way. For example, if your images need to be built from code, you enter into a relationship with XYZ Container Builders, Inc. and they become responsible for building and signing your images. Payment chains are used to tie these transactions together.

Finally, we'll need search engines to assemble all this together into a cohesive offering that anyone can join or use. Searches for trust, compute power, storage costs, network speeds, container specs, etc. can all be included in the results returned.

I would note that the first thing people usually ask when I talk about this stuff is "How can I trust XYZ provider with my data/code?". The answer is that you establish relationships with individuals who provide you software and/or infrastructure that is a fit based on your particular use-case's trust needs. If you have sensitive data you don't trust anyone with, then deploy the application on-prem in your own cloud and don't allow the software company to remotely manage it. If it's a CI test on a public repo, who cares who does that as long as consensus is reached on the outcome over time?

I'm working on an interesting project right now where the web application behaves like a typical SaaS solution, except that all of the customer's data is hosted on premises.

After the initial install, their local servers (and data) don't have to be touched, but the SaaS portion can be continuously improved. So far it's worked really well.

Your MSaaS idea sounds really interesting, especially the multiple trusted deploys. That's the crux of trusting deployed open source software.

There are others working on this now, here in San Francisco. I think it's the tip of the iceberg. The on-prem ISV market is fucking huge.

> This is exactly what is broken with our current software business models. On-prem software is expensive to deploy and manage but gives users control of their data. SaaS software is cheap to deploy and manage but takes control of the user's data. We must find middle ground between the two models. A solution that takes the best of both on-prem software and cloud based SaaS services may be that middle ground, but it's going to require a globally federated cloud.

I think something like remoteStorage can address this need.

https://remotestorage.io/

It's a federated, open storage protocol that has multiple server implementations that anyone can host. I think it has the potential to enable a new model for SaaS software where users, rather than service providers, own the data.