If the blockchain is useful in those areas where [almost] no trust exists, Urbit has the potential to be useful for essentially everything else.
To give a concrete example, this would be useful for any Ethereum app that doesn't want to store data on a central server (which most cannot do whether for legal, security, or ideological reasons). The idea to me is that the internet wasn't built very well to run decentralized apps [which is definitely the case if you've ever tried building one without having to rely on central servers for caching, storing accounts, comments, etc.]. It's, imo, a nice complement to blockchain tech like Ethereum and Bitcoin. Long term once it's out and running I see dapps like Augur [a decentralized prediction market which I work on - http://augur.net] using it so users can securely store their private keys, report data, market data, trade history, etc. and easily go across/between devices as opposed to just using localstorage [which is a pain to migrate using] or fetching it from ethereum every time [which is very time consuming and has lots of overhead].
If we're going to seriously move in this direction of decentralization, at scale we need something like urbit.
No one else is really tackling the same set of problems.
Came across this quote on it by Alan Kay: "They have verve, and that's generally a good thing. In this case there are a lot of details that need to be grokked to make any reasonable comment. The use of combinators (a kind of dual of lambda calculus) harks back to an excellent thesis by Denis Seror at the University of Utah in the 70s that produced a safe, highly scalable and parallel implementation. I haven't looked at it more deeply (and probably should)." [https://news.ycombinator.com/item?id=11810177] - very cool!
There is no such thing as a trustless app, unless you are doing basic mathematical algorithms contained within the same system. Ethereum adds no value to Bitcoin because any useful apps you want to make NEED a centralize source to provide data to it. For example, if I want to make an app that sends coins to someone when bitcoin is at a certain price, I would inherently be relying on the trusted source, that provides the bitcoin price data. Similarly for sport payouts or property contracts, they all rely on the external centralized source for information. The only thing Ethereum can do, is basic operations contingent on values within the same system, otherwise you break the "trustless apps" veil.
Reread my post, I said almost. Nothing in life is trustless [for instance, solar flares could effect my computer's state], but you can get close. So we agree there
> Ethereum adds no value to Bitcoin because any useful apps you want to make NEED a centralize source to provide data to it.
This is called the oracle problem --- it's a difficult problem, but not intractable. Augur doesn't use a centralized source to resolve its markets, it has groups of reporters who do that [with a whole set of incentive structures surrounding truth-as-schelling-point and relying upon bonds to cause monetary loss to people attempting to "cheat" the system. Your cost to cheat the system will almost always be more than potential profit [unless there's only 1 market in a system with a ton of volume and no other activity, which means it's basically dead anyway and there are 2 backstop mechanisms surrounding this as well]. Anyway given infinite money anything is attackable / not trustless.
Second, you're missing _a lot_ of the benefits of Ethereum. It can control funds programmatically. To run a prediction market using bitcoin you have to hold customer funds, on Ethereum you don't [this is a huge opex]. On Bitcoin, you have to process the trades, on Ethereum you don't [hello more opex!]. On bitcoin you're forced to use a multisig 3rd party or have counterparty risk to trade prediction market assets, on Ethereum you don't. You have to resolve markets yourself [or with multisig of a handful of people, because bitcoin cannot support multisigs beyond 20]. People can't create their own markets and add liquidity to them on your platform if it's on bitcoin without trusting you either. Could go on and on, but _unless_ you're referring to a sidechain of bitcoin you can't do any of that.
As far as the example here: "For example, if I want to make an app that sends coins to someone when bitcoin is at a certain price, I would inherently be relying on the trusted source, that provides the bitcoin price data." is wrong. On Etherex on ethereum I can get data for he btc-eth price and do a transaction based on the exchange rate without trusting anything in the outside world
To give a concrete example, this would be useful for any Ethereum app that doesn't want to store data on a central server (which most cannot do whether for legal, security, or ideological reasons). The idea to me is that the internet wasn't built very well to run decentralized apps [which is definitely the case if you've ever tried building one without having to rely on central servers for caching, storing accounts, comments, etc.]. It's, imo, a nice complement to blockchain tech like Ethereum and Bitcoin. Long term once it's out and running I see dapps like Augur [a decentralized prediction market which I work on - http://augur.net] using it so users can securely store their private keys, report data, market data, trade history, etc. and easily go across/between devices as opposed to just using localstorage [which is a pain to migrate using] or fetching it from ethereum every time [which is very time consuming and has lots of overhead].
If we're going to seriously move in this direction of decentralization, at scale we need something like urbit. No one else is really tackling the same set of problems.
Came across this quote on it by Alan Kay: "They have verve, and that's generally a good thing. In this case there are a lot of details that need to be grokked to make any reasonable comment. The use of combinators (a kind of dual of lambda calculus) harks back to an excellent thesis by Denis Seror at the University of Utah in the 70s that produced a safe, highly scalable and parallel implementation. I haven't looked at it more deeply (and probably should)." [https://news.ycombinator.com/item?id=11810177] - very cool!