4 ms·

Let's separate the use cases: we want a permanent, public web, and we want applications that don't die when servers get shut down. IPFS clearly solves the first

by natrius 11y ago

Let's separate the use cases: we want a permanent, public web, and we want applications that don't die when servers get shut down. IPFS clearly solves the first use case, so let's talk about the second. 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.

droffel 11y ago
I've recently been considering building an application that runs on a backend of Ethereum+Storj. The ability to store (and retrieve) data in Storj chain feels like a necessary component in getting a full DApp set up, right now I'm grappling with a concept that would (somehow) require the ability to provide users with a single-use key to download data from Storj. 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.
- DennisP 11y ago
  Also, the guys working on Ethereum's Swarm think they've figured out a good incentive system for it, and plan to publish an "orange paper" in the near future. https://www.reddit.com/r/ethereum/comments/46fz8f/ethereum_in_the_year_of_the_fire_monkey_can_you/ https://www.reddit.com/r/ethereum/comments/46fz8f/ethereum_i...
  - matthewbauer 11y ago
    That sounds a lot like FileCoin which was created by the IPFS guy.
deleted 11y ago
[deleted]
amelius 11y ago
Interesting. How do you envision the decentralization of search?
- natrius 11y ago
  Searching public data is already decentralized: anyone can run a web crawler and search engine. Search engines, recommendation systems, and AI assistants that use private data are harder to decentralize, but they're also where all the gains come from: I'm stuck with Google unless I want to move all my data somewhere else, and that's hard. 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.
  - joepie91_ 11y ago
    > Searching public data is already decentralized: anyone can run a web crawler and search engine. 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.
digi_owl 11y ago
> and we want applications that don't die when servers get shut down. 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.
empath75 11y ago
As someone who does devops for a living this feels like it could be a replacement for s3 inside an aws vpc, without connecting to anything outside of your private network. You could just have nodes register with consul when they come up.
joepie91_ 11y ago
You draw a distinction between public and private, specifically: > 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".

by natrius 11y ago

droffel 11y ago

I've recently been considering building an application that runs on a backend of Ethereum+Storj. The ability to store (and retrieve) data in Storj chain feels like a necessary component in getting a full DApp set up, right now I'm grappling with a concept that would (somehow) require the ability to provide users with a single-use key to download data from Storj. 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.

DennisP 11y ago
Also, the guys working on Ethereum's Swarm think they've figured out a good incentive system for it, and plan to publish an "orange paper" in the near future. https://www.reddit.com/r/ethereum/comments/46fz8f/ethereum_in_the_year_of_the_fire_monkey_can_you/ https://www.reddit.com/r/ethereum/comments/46fz8f/ethereum_i...
- matthewbauer 11y ago
  That sounds a lot like FileCoin which was created by the IPFS guy.

deleted 11y ago

[deleted]

amelius 11y ago

Interesting. How do you envision the decentralization of search?

natrius 11y ago
Searching public data is already decentralized: anyone can run a web crawler and search engine. Search engines, recommendation systems, and AI assistants that use private data are harder to decentralize, but they're also where all the gains come from: I'm stuck with Google unless I want to move all my data somewhere else, and that's hard. 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.
- joepie91_ 11y ago
  > Searching public data is already decentralized: anyone can run a web crawler and search engine. 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.

digi_owl 11y ago

> and we want applications that don't die when servers get shut down. 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.

empath75 11y ago

As someone who does devops for a living this feels like it could be a replacement for s3 inside an aws vpc, without connecting to anything outside of your private network. You could just have nodes register with consul when they come up.

joepie91_ 11y ago

You draw a distinction between public and private, specifically: > 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".