The future of cryptocurrencies is bright, there's now a large set of tools in the toolbox to use to build resilient, permanent applications for people to use. I'm really excited to see what people build in 2016, the cryptocurrency ecosystem has been growing rapidly in the shadows, and they're finally breaking into the mainstream.
https://www.reddit.com/r/ethereum/comments/46fz8f/ethereum_i...
Easy. Do not make sites and claim they are apps, when clearly they are acting as graphical terminals to a remote service.
An app should be something that runs locally, stores the result locally, and optionally stores things remotely as a backup measure.
The whole "lets do all the heavy lifting out there" approach is a throwback to the leased terminal era. And as best i recall, the personal computer became popular because accountants would rather run their spreadsheet (even if slower and with severe data limits) locally than have to grovel to the admins for mainframe time.
> IPFS probably isn't a good fit for private data, but public apps like a decentralized Twitter will probably use it for all of their data. Encrypting private data and storing it with IPFS will sometimes make sense.
This is actually a great example of where I can't see the IPFS model working, because not everything is black-and-white private-or-not.
For Twitter, for example, you have private accounts - this doesn't mean that nobody can see it, it just means that you need to have permission to see it. How do you implement an access control system that:
- Is mutable (ie. allowing new users to see your feed)
- Is private (ie. there is no public list of who can see your feed)
- Is revokable (ie. you can remove people's access to your feed)
... without having to re-encrypt everything using a secret set of keypairs every time the ACL changes, which is an unreasonable burden on resources?
I understand that you build applications on a different kind of architecture, and I'm all for usable decentralized primitives, but there have to be explicit solutions for these kind of 'business requirements' (whether commercial or not), for it to ever be able to "take over".
To decentralize private search, we'll build protocols for publishing your private data to cloud services that represent your interests. For some purposes, you'll publish data to services that keep your data isolated. You might even publish that data to your own machines. This works for email and cloud storage like Dropbox. Other purposes require data to be combined to add value, like recommendation systems and AI doctors. Services will compete with each other for your trust so you'll pick them. The bigger they are, the more useful they will be, so they're vulnerable to collapsing back into a monopoly. Anti-monopolists will give their business to competitors to keep them alive.
That is nice in theory, but not how it works in practice. Searching public data generally involves a significant amount of investment, both financially and effort-wise, to have anything approaching a usable search engine, even for relatively small sets of data.
In this context, IPFS is part of the toolkit for building decentralized applications. The architecture of these applications is fundamentally different from today's apps. Users control the data, not the application developer. Private data can live on the user's machine or some cloud service they trust to hold the data for them. IPFS probably isn't a good fit for private data, but public apps like a decentralized Twitter will probably use it for all of their data. Encrypting private data and storing it with IPFS will sometimes make sense.
To deal with mutable data, it depends what your goals are. If users don't need to agree with each other about the value of the data, they can store it however they want and maintain their own view of the world. If they need to agree on data that only one person can change, then you can use IPNS to manage mutable references controlled by one keypair. If users need to agree on data about their interactions with each other, then they need to use a decentralized cloud computer that can enforce rules on a historical record. We call these enforcement clouds "blockchains," and Ethereum is a blockchain that defines a process for defining new rules so application developers don't have to build their own blockchains.
Building decentralized apps with IPFS and Ethereum is the most exciting work I've ever done. It doesn't just improve the apps themselves, it fundamentally changes the economics of our industry. Most businesses are built on network effects, but decentralized apps don't bottle up the value of their networks: they give them to their users.
That's more like the world I want to live in. If you want to be a part of this change, you should join us at ConsenSys, or join the decentralization movement in general.