They are absurdly low. Like less than 100 users a day for anything that isn’t a exchange.
Many of these dapps have market caps in the hundreds of millions with a few dozen users per day.
EDIT: I should have said "may be inventing". It's my opinion of a >50% chance that Vitalik's work will lead to something significant, for example. Some people will disagree and that's ok too.
Look at email and http. I can use any client I want to access email/web. Outlook, Thunderbird, Chrome, Firefox. We already had this sort of utopia. Anybody could spin up an smtp server or web server. But that involved a little too much friction. So Google and Microsoft offered ready to use email. And Facebook and Wordpress offered up ready to use web sites. Google and Microsoft could probably wall off their garden and people would just jump in, instead of run. Facebook went from jabber to proprietary. RSS has died and been replaced by the Twitter follow. Find me one non geek that cares about Mastodon/GNUSocial/OStatus/ActivityPub at a philosophical level.
When people talk about blockchains they either too narrowly focus on currency application or substitute it for the word database. Quite often on HN you see people comment "what does this really get you that a normal database doesnt."
Blockchains should be used when the goal is to distribute trust, allow non-oligopoly institutional verified participation, and minimize fraud. But we live in a world where _most people are perfectly comfortable just trusting the easiest to use Institution._
One application of blockchain potential that repeatedly comes to my mind is cab hailing. Instead of the Uber/Lyft duopoly, ideally there would be a "hail a cab" protocol, just like smtp/http. Something that works between any client that chooses to be compatible. Many many competing institutions could run their copy of the ledger: a ledger that holds driver, passenger, and client app trust ratings, route information, load trends, predictive driver placement, event schedules, all while facilitates payment. Any client could choose to ignore any part of the distributed database it wants, like Mastodon. Why is this better than the current situation? Because I could use Lyft to call an Uber driver. Cross app compatibility, standard hailing protocols, COMPATIBLE TRUST. Innovation in the client side features would skyrocket. When the protocol updates, everyone benefits. And because ride hailing doesnt depend on a social graph, unlike communication tools, lock in to one particular institution is much much lower. I hail a stranger, not a friend. I can swap my driving dispatcher app or cab browser at any time, just like I am free to flow freely between Chrome and Firefox. And unlike how I cant browse the facebook/uber database with anything besides facebook/uber made apps.
But no one cares. The majority of the world is ok just trusting and paying 2-5 institutions to handle trust and money transfer and data security in any one particular space (banking, communication, ride hailing.) We have already seen email and sms give way to fbmessenger, whatsapp, snapchat. IRC gave way to Slack. We have gone from a world where clients are inter-operable, to silod. We seem to want this. And until the benefit of cross compatibility and distributedness reemerge and permeate into general culture, Non-cryptocurrency uses of blockchain will be few and far between. Because the big institutions can offer something thats already "good enough." When something is good enough, people dont go looking for better. Blockchain and mobile app developers need to give the general public a UNIQUE benefit, and a reason to care, switch, and stick with open systems.
(Another interesting application of blockchains could be to the yelp/foursquare/tripadvisor/opentable/dining-rewards/loyality space. One protocol to handle menus, reviews, and reward points, instead of a separate incompatible reward app and shitty non mobile website for each damn restaurant. Another, and different component of trust in this ecosystem would be verification of authenticity vs spam.)
(Another application of blockchains, shared accounting systems between cooperating firms. General contractors and sub contractors all working off one distributed database for all ERP: general ledger, finance, forecasting, budgeting, cost management, change management, orders, invoices, contracts, ach, settlement, project schedules, purchasing, inventory, time and attendance, manpower, deliverable, shipping, materials, manufacturing, drawings, BIM (revit) etc, union tracking, payroll, training, safety tracking, SHARED analytics! In this scenario, the threshold for trust can be lowered ala https://azure.microsoft.com/en-us/blog/announcing-microsoft-... As of right now, if the general uses primavera or plangrid, you use primavera or plagrid. The subcontractors end up using a litany of incompatible tools across isolated projects. Each ERP and accounting system uses dual entry and every firms duplicate each others efforts. Massive redundancy, coupled with very foggy visibility into whats actually going on. Interoperable ERP with shared triple entry accounting would be a worldwide gamechanger. But construction isn't sexy enough for most of Silicon Valley fad chasing, and the scale of Enterprise ERP is too massive for anyone but the big dogs. I dont see SAP, Oracle, and Microsoft opening up their products to each other anytime soon.)
The two aren't mutually exclusive. The best startups combine the two: solve real problems via what's hot and attain virality and investment attention.
My great idea is to make a blockchain version of HN and instead of karma you get HNCoin, just need a 100 million dollars and a top-100 userbase...
I am having trouble wrapping my head around the implementation, not theory, of blockchain (ledger entry based on previously hashed ledger entry).
Like, how is the beginning of the ledger created/determined? Is that just a nonce/IV?
How is each entry calculated and/or verified based on the previous entry?
You calculate the hash of each block (which includes the hash of the previous block) and check if it matches the hash in the next block. Each block also includes the difficulty of the network at the time to prevent mining more than x block per hour. The difficulty describes the "format" of the hash of each block, e.g. the hash in hex format needs to have 50 times 0 at the beginning.
So, fundamentally, is everything just how many zeros prepend the "unique" hex string (for proof-of-work)?
Imagine that a mass-produced tech item from China came with a QR code certificate authenticity, which the end user could scan to check that the item had been made by a specific factory and a specific company. (The company could also add extra metadata to a blockchain to detail how the goods travelled and which are the approved importers).
The QR code should presumably have extra information in it which ties it to a serial number baked into the silicon of the purchased item, but there are other ways (based on double-spend prevention) that you could confirm a given QR code hadn't merely been duplicated.
Nothing stops entities from entering false or unintentionally-incorrect information into the database.
Honestly, all these supply-chain or authenticity tracking use-cases must have been dreamed up by people who have never worked a simple retail job in their life. If they had, they'd know databases tracking reality very easily (and inevitably) diverge from reality - the store inventory DB says you have two items in the back, but a half hour of searching confirms that is a lie. Stores even have a painful, labor-intensive process - called "taking inventory" - to fix the errors in the DB for a single physical store!
Also, this concept is absolutely not unexplored. It's so popular that Bizonacci made a parody video about it, and several billion dollars of imaginary market cap are allocated to coins working on it.
Issues I see: - Does every phone now need to store the entire log? Otherwise, who do you trust to give you the current state? - What prevents me faking a log? Why would people be doing constant work on the chain to prevent it?
As for how much data the phone needs to store, I was imagining running something equivalent to an SPV client:
https://bitcoin.stackexchange.com/questions/4649/what-is-an-...
https://bitcoin.stackexchange.com/questions/48420/what-hardw...
Alternatively the app can request the digitally signed proofs from the blockchain via a semi-trusted 3rd party gateway, with the advantage that you can choose your gateway at any time, and the gateway can't forge the cryptographic proofs that your client is checking for you.
For example, if you buy a product from Manufacturer 1 whose web address is manufacturer1.example.com, you could visit that site and find a page with a QR code containing their public key (wallet address), which the app could scan. Once you've marked that public key as trusted, the app could check that the corresponding secret key was used to sign the data on the QR code you received on your certificate of authenticity.
The tricky part is sending a transaction to the network which says "I have received the product with the following serial number...", but the QR code on the certificate could contain the secret key for a wallet which has been pre-loaded with just enough funds to send a microtransaction to the network.
The irony is that for a “blockchain startup” to succeed, it must be solving a problem that exists independently of blockchain, for which “blockchain” is simply an implementation detail. There is most likely a way to solve the same problem your blockchain startup is solving without blockchain. If there is not, I would suggest you might be solving a non-problem.
Adopting “blockchain” in any public way forces you to focus on a deceptively non-critical aspect of your business. The more you integrate your product with blockchain, the more your company depends on the success of crypocurrency in general.
For example, consider you’re building a marketplace for Wordpress themes backed by cryptocurrency. You end up creating a convoluted scheme to fit your desired solution to the problem, when a simple network of payments on existing infrastructure would suffice (and indeed has sufficed for years before blockchain). In focusing on blockchain as a payment or distribution mechanism, you are causing your product to depend on the success of the blockchain ecosystem as a whole. You need people to use cryptocurrency in general, so they can use it on your marketplace without friction. Put another way, unless your product is truly category-defining, nobody is going to learn how to pay with ethereum just to use it. The success of your product depends on the wider adoption of cryptocurrency in general.
So as a blockchain startup you are betting on two things. One, that your company can succeed in solving the problem it sets out to solve (a risky bet in itself). And two, that the larger blockchain ecosystem will evolve as a wider market of people adopt it and know how to use it with your product. Your success is tied to two independent variables instead of just one. That seems like an unnecessary risk IMO.
HN hates blockchain, so I doubt you will get a very good answer here. I am blockchain admirer but I just don't see a lot of use cases on such an insecure device outside of perhaps social media where you control your own data. Reading the blockchain, sure.. writing to the chain? Not ideal.
I've yet to see the first person in my personal network reaching a state of being able to make a living from mobile apps (and obviously, I'm excluding the survivor-bias stories from the media here).
Personally, I had an app that was on its way to allowing me to transition to focusing on mobile app development full time. But it turns out you need a license to perform money transference, which was what my app was... and luckily Google shut me down before I got into high volume and any legal trouble.
To your point: my second app was a super expensive (for me) colossal failure.
I know another guy who nets about $200k USD making puzzle apps, though that also includes web apps started in the mid 2000s.
I made plenty of money in mobile app development before. My secret? Work for a large company that does business to business apps that do large 4000-10000 device deployments that are willing to pay 6-7 figures on an implementation.
Chasing after $0.99 purchases is a fool’s errand and winning at that game is no more assured than winning the lottery.
There is too much luck and handing over control to appstores or betraying your users involved to reliably make money on your own apps.
Also, developer salaries for companies that are hiring for mobile are always high
About four years past. That ship has sailed. The top apps are now all from the big players.
