Hey Mike! On Sep 5, 2013, at 10:26 AM, Mike Hearn wrote: > It might be simpler to not think of it as an app store, but rather see it as > a set of affiliate schemes. To get placed into the apps section you can say > that the business must have an affiliate scheme in place (i.e. open to more > than just you) and then you use the normal mechanisms of affiliate codes and > so on. > If you refer a lot of users to that business, you get the referral bonuses. > Affiliate schemes are a common way for open source projects to monetize - > e.g. Firefox development is largely paid for by search engine referrals. It's > compatible with the ideals of openness because their income relies directly > on their traffic, and there are several competing search engines the projects > can play off against each other to get the best prices. Also, users expect > search engine integration these days, so they'd be sending search traffic > regardless.
In the long term, I think this makes perfect sense. After all, that's really what the first option is at its heart. About search engines, that's also a great point. We've thought about doing this, but my concern was that the ecosystem on the whole is too young and fragmented for this to make much sense. Until for example speciality search engines for Bitcoin products and services manifest (I'm sure they are coming), I suspect the results might be a little vague and unsatisfying. I really see Hive's app platform as a stepping-stone to more mature things. Hopefully several companies like BitPay end up offering both great affiliate programs and search engines very soon. Until then, that's why something like sending transaction fees directly from the user's wallet is even on the table. > The apps don't have to be offline. They can (and probably should) be online, > so the businesses can retain control of their features and brand. Yes, I should clarify. We do want businesses to be able to have that control. However we also want to do a kind of submission/review process in order to ensure some user experience continuity and also to monitor for potential exploits. The plan is ultimately to have a public repository for applications, maintained by us. We will review the pull requests of third parties and the Hive app will always try to pull the latest (approved) updates. Does that make sense? It's centralized responsibility and potential risk if we cannot keep up with demand, but again -- we want to try the approach, at least while starting out. > The main downside, of course, is it distorts technical judgement. You can get > projects pushing certain businesses heavily not because it's technically the > best thing for users, but because their income depends on it. That's absolutely true, but at the moment the only thing I can really say is that we'll cross that bridge when we get there. ;-) > One alternative funding model you could explore is allowing users to bid on > assurance contracts for feature development. This means you think up a bunch > of improvements you could make, then allow users to pledge Kickstarter-style > towards their development. The upside is it allows the community to direct > development, and users feel directly involved and not exploited. The downside > is, no recurring income you can use to support yourself whilst engaged in > other endeavours. Funny you should mention it! I just mocked this idea up last week, though I assumed a cruder system of "voting" to an address that corresponds to a feature -- literally, voting with your wallet (for your wallet, ad infinitum). I watched your talk about assurance contracts and other "hidden" features, but am not entirely sure that I understood it enough to know how it would work in this context. Sorry for the persistent hand-holding requests, but some advice would be very welcome. >> 2) Although our BitcoinKit.framework supports both bitcoind and bitcoinj, we >> will be using bitcoinj with an integrated VM for the time being. The main >> draw is SPV, although to be honest we would prefer to support the network >> more via something like Peter Todd's partial UTXO sets idea (hint hint, >> anyone?). > > Bear in mind that regardless of how much you want to support the network, > it's ultimately your users resources that will actually get spent. That's why > I'm a bit skeptical of any schemes that rely on random end users donating > lots of cpu time or bandwidth to the network. If they want to do it, partial > UTXO sets and other interesting ideas are worthwhile, but I guess most users > won't. I think Bitcoin will over time be more and more like Tor where relays > are run on dedicated servers by people who have some modicum of knowledge and > community involvement. If it is a real burden for the users, that's the best argument I've yet heard. However, my impression from Peter's post was that it would be fairly painless for them. I guess there's also the question of diminishing returns: Is the network value of a full "user" Bitcoin node less than one run on a dedicated server? Will it eventually be? I don't know enough about that to comment, but I do know that in the Tor example, exits are chosen based on some criteria (I think, available bandwidth?). Is there a parallel in Bitcoin? (Probably best as a separate thread...) Thanks for your thoughts, Mike. -w
signature.asc
Description: Message signed with OpenPGP using GPGMail
------------------------------------------------------------------------------ Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58041391&iu=/4140/ostg.clktrk
_______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
