Mike Hearn [ARCHIVE] on Nostr: 📅 Original date posted:2013-09-05 📝 Original message:Hey Wendell, Interesting ...
📅 Original date posted:2013-09-05
📝 Original message:Hey Wendell,
Interesting idea you have there!
On Wed, Sep 4, 2013 at 9:47 PM, Wendell <w at grabhive.com> wrote:
> Obviously there are a couple of brain-dead approaches: We could track what
> users do in the app, and send the business a bill (with blockchain proof,
> of course).
>
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. 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. 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.
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.
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.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130905/bb1ec2e1/attachment.html>;
📝 Original message:Hey Wendell,
Interesting idea you have there!
On Wed, Sep 4, 2013 at 9:47 PM, Wendell <w at grabhive.com> wrote:
> Obviously there are a couple of brain-dead approaches: We could track what
> users do in the app, and send the business a bill (with blockchain proof,
> of course).
>
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. 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. 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.
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.
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.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130905/bb1ec2e1/attachment.html>;