Forem: Mitchell Cuevas

January App Mining Results: Meet The New Faces In The Top 10

Mitchell Cuevas — Tue, 22 Jan 2019 19:16:01 +0000

Congratulations to January’s App Miners! The latest run saw the addition of new App Reviewer, TryMyUI and 13 new decentralized Blockstack applications. Graphite stayed steady at the top while the rest of the top 10 saw more changes, meet some of the new entrants to the top 10 below and browse the full rankings here.

Meet the new faces in the top 10

DPAGE – Publish web content on the decentralized internet

“Combine videos, images and social media posts from the web to create webpages. Keep your pages private and encrypted or make them public.”

Create a free, censorship-proof web page in five minutes. Give https://t.co/8AjrnM0Gd1 a try!

— dpage (@dpageio) January 17, 2019

Sundly – Decentralized Personal Health Records

Sundly believes you should own and be in full control of your health records.

Friendly reminder: You can import your Apple Health records into Sundly https://t.co/BScyX8fCeU

— Sundly (@getsundly) January 21, 2019

Check out Sundly’s roadmap for more.

Mevaul – Private, Encrypted and Distributed storage that just works

“Built on Blockstack, Mevaul is a file storage and sync service that helps you store your personal and private files securely. It uses Blockstack and Gaia storage under the hood to give you true data privacy.”

My thoughts on Mevaul on @ProductHunt https://t.co/0zsDozrEWS pic.twitter.com/nvi3mTkxAG

— Akso (@theAkso) January 16, 2019

Check out Mevaul’s roadmap for more.

More decentralized apps are being built everyday – you’ll be meeting even more in next month’s run. If you want more security, more privacy, and data portability, every single one of these is worth a try.

Developers: Submit your applications by February 1st to be included in the next ranking. You can learn to build a dapp in an hour or less and start App Mining with the Zero-to-Dapp tutorial.

Lifetime earnings of January 2019’s top 5 applications

This post originally appeared on App.co.

The post January App Mining Results: Meet The New Faces In The Top 10 appeared first on Blockstack Blog - Blockstack.

Blockchains and Consensus Protocols: Liveness and Correctness are Inseparable

Mitchell Cuevas — Thu, 20 Dec 2018 16:03:06 +0000

In the world of blockchains, consensus protocols are widely discussed. However, it’s often hard to distinguish between competing protocols and evaluate them, especially because it is not always clear how a particular protocol solves a consensus problem, or how that particular problem relates to the practical concerns of blockchains (e.g., when is my transaction confirmed? what fork am I on?). In this post, I will outline the problem that consensus protocols are trying to solve, detail what a valid consensus protocol should achieve, and hopefully this will help convey which approaches to this problem are likely to bear fruit.

Roughly speaking, consensus protocols aim to achieve agreement between mutually distrusted parties. In networks like the Bitcoin network, nodes are attempting to reach agreement on what to include in the next block. In this network, blocks tell us what transactions have been broadcasted, and the order of those transactions. Other consensus protocols are usually similar — they tell clients the order in which operations should be applied.

As a user of a consensus protocol, you might initially think “Well, I’m not so concerned about the order and timing of operations, so long as I can guarantee those operations are correct.” Indeed, correctness is an important property. However, this property is completely linked to the order and timing of operations. To see why, let’s look at some example transactions.

T1: Public Key A transfers coin “Z” to Public Key B

T2: Public Key A transfers coin “Z” to Public Key C

T3: Public Key B transfers coin “Z” to Public Key D

Now, when examined individually, confirming that these transactions are correct is trivial. For transactions 1 and 2, a verifier need only confirm that the transaction was signed by the private key corresponding to A. This is achievable with rather boring cryptography, and has been a solved problem for decades. But examining these transactions individually isn’t interesting, and doesn’t provide a useful measure of correctness. I want to know whether or not I “own” coin Z, in the sense that nobody else can convincingly attempt to transfer that coin without my permission. What do consensus protocols have to say about this?

Well, importantly, in a consensus protocol, clients and nodes in the network reach an agreed upon view of the world, and that view of the world includes an ordering of transactions. Once we can order transactions, we can begin to evaluate whether or not they are valid at a specific point in time. For example, if a consensus protocol establishes that at Time 0, coin “Z” is owned by Public Key A, and that the transactions are ordered as T1, T3, T2 — then clearly T1 and T3 are valid, but T2 is not (because after T1 broadcasts, Z is owned by Public Key B, and no longer Public Key A). However, if the protocol establishes that the transactions are ordered T2, T1, T3, then only T2 is valid. Clearly, order and timing guarantees matter. Fortunately, this is exactly what consensus protocols attempt to provide.

Consensus protocols provide two guarantees with respect to order and timing:

Safety: As long as the protocol does not have more than some threshold of faulty participants, other participants cannot convince a client to accept an incorrect or invalid message.
Liveness: As long as the protocol does not have more than some threshold of faulty participants, other participants cannot indefinitely delay the acceptance of a correct message.

What do these guarantees usually mean in the context of blockchains? As we saw before, incorrect messages are nearly trivial to validate as such on the blockchain. Does that mean safety is a trivial property to achieve? Why is liveness important when it comes to timing of transactions, and the order of transactions? What does any of this have to do with forks?

To map this into the context of blockchains, we have to first understand what, exactly, blockchains are trying to achieve consensus on. The answer, it turns out, isn’t messages, or even transactions: it’s histories. A blockchain client is continuously trying to figure out which history of transactions is the “true” history. From the previous example of transactions, a client would need to conclude which of these two possible histories is the correct one:

History 1: Transaction 1, Transaction 3.

History 2: Transaction 2.

Nakamoto consensus uses Proof-of-Work mining and a “longest chain wins” metric to decide on which history is the correct history. And this history should match the expected history if all nodes in the network were honest.

With this understanding, we can now frame our two consensus guarantees as they relate to blockchains:

Safety: As long as the protocol does not have more than some threshold of faulty participants, other participants cannot convince a client to accept a history which is the wrong history,
Liveness: As long as the protocol does not have more than some threshold of faulty participants, other participants cannot prevent clients from accepting some history as the correct history.

Interestingly, when it comes to blockchains (though this is true of most consensus protocols), our usual understanding of properties like correctness, validity, ordering, and timing require guarantees of both safety and liveness simultaneously. This is just the nature of blockchains. If I want to be confident that I cannot be attacked via a “double-spend”, I need to know, first, that the transaction will be accepted in a timely fashion, and second, that once accepted, the transaction is very unlikely to be in an orphaned block.

This is why safety and liveness are inseparable properties of fault-tolerant protocols. Fault tolerant protocols use techniques to guarantee liveness which affect safety and vice-versa. For example, in Practical Byzantine Fault Tolerance (one of the most influential fault-tolerant consensus protocols– I recommend reading the ’99 paper from MIT), the two-phase commit mechanism used by replicas is what ensures that the replicas make progress, but it is also how new messages are accepted into the protocol history. If this mechanism were faulty, it would affect both safety and liveness. These properties cannot be effectively treated or proven in the absence of the other— a protocol which assumes liveness can be trivially safe. A protocol which waves away concerns about safety can always make progress.

If blockchains are going to revolutionize the way that people interact on the internet, and I believe they will, then the proper functioning of those blockchains is massively important. When evaluating the technologies and plans for various platforms, it’s essential to remember the fundamental problems that a blockchain is trying to solve. At a basic level, that problem is an old one: achieving consensus while tolerating some number of faulty or malicious actors. In both theory and practice, this means providing liveness and safety guarantees. However, these guarantees are inseparable, because the mechanisms for providing one always affect the other.

Now, when evaluating projects that are trying to make progress on new mechanisms for achieving consensus in support of open blockchains, projects that sufficiently treat these twin concerns are the most likely to bear fruit. Some projects like Stellar use consensus protocols in a federated model (non-open), but provide sound fault-tolerance guarantees. Algorand has also made significant progress towards building a fault-tolerant protocol, though the question of dealing with open-membership sets is still open. Our own blockchain design work provides fault-tolerance guarantees while also enabling open-membership through Proof-of-Burn mining. Progress on that work can be tracked in pull requests on our blockstack-core Github repository.

The post Blockchains and Consensus Protocols: Liveness and Correctness are Inseparable appeared first on Blockstack Blog - Blockstack.

December App Mining Results: Meet The Top Ranked Blockstack Applications

Mitchell Cuevas — Tue, 18 Dec 2018 19:50:06 +0000

The results are in: Congratulations to every team and founder that was a part of December’s App Mining Pilot run, you and your apps are an integral part of the Blockstack ecosystem and the decentralized internet. $100K USD has successfully been distributed in Bitcoin across eligible Blockstack apps according to December’s final rankings . Rankings were determined according to the App Mining algorithm which uses scores from independent App Reviewers.

App Mining has been rigorously designed to fairly fund developers that are building the best decentralized applications on Blockstack. We welcome the 16 new apps that joined the program since the alpha run and invite developers to register for next month’s payouts – the deadline is January 4th, 2019.

Please meet the top 10 earners for December below, the full list of results can be found on app.co.

1) Graphite: Encrypted, shareable, decentralized personal data

Website: https://www.graphitedocs.com/

App.co: https://app.co/app/graphite

Recommended for users of: Google Drive, Dropbox Paper, Office 365, Quip

Do you really want google reading everything you write? Every keystroke you make? Even the ones you delete? @graphitedocs https://t.co/ERGfjYw9VG

— George J Peacock (@Peacockg) December 15, 2018

2) Stealthy: Decentralized communication platform on Blockstack

Website: https://stealthy.im/

App.co: https://app.co/app/stealthy

Recommended for users of: Telegram, Whatsapp, Facebook Messenger, Secret, Google Hangouts

Here's what your #encrypted message looks behind the scenes on #Stealthy

The content is only visible to you and your @blockstack contact #decentralized #controlyourdata pic.twitter.com/xIScIeUq3Z

— stealthy.im (@stealthyim) December 6, 2018

3) Zinc: Work based identity & reputation system

Website: https://zinc.work/

App.co: https://app.co/app/zinc

Recommend for users of: LinkedIn

Zinc is LIVE and officially open for business With positive endorsements & the new website live, we look forward to welcoming #recruiters & #candidates onto the platform as we start to populate the #Zinc ecosystem https://t.co/pGOBmvqh0M #HRtech #blockchain #recruiting

— Zinc (@zinc_work) September 17, 2018

4) Afari: Group based, privacy focused social network

Website: https://www.afari.io/

App.co: https://app.co/app/afari

Recommended for users of: Twitter, WeChat, SnapChat, Peepeth

I'm using @afari_io, a decentralized social media platform built on @blockstack. Join me at https://t.co/edcc53K4uO!

— 𝔪𝔞𝔯𝔦𝔬 (@m4rio) November 5, 2018

5) BlockVault: Decentralized password manager for teams

Website: https://blockvault.site/

App.co: https://app.co/app/blockvault

Recommended for users of: 1Password, LastPass, LogMeIn, Dashlane

Woot! Woot! BLOCKVAULT just got hunted on @ProductHunt!

If PH is your thing, check out our page over here https://t.co/Gd2vDD4W3u

— BLOCKVAULT (@blockvaultdapp) December 9, 2018

6) SpringRole: Decentralized professional network platform.

Website: https://springrole.com/

App.co: https://app.co/app/springrole

Recommended for users of: LinkedIn, Angellist

We are at 35K users

— SpringRole Inc. (@springroleinc) December 4, 2018

7) Entaxy: Insight into your finances, without sacrificing your data

Website: https://entaxy.io/

App.co: https://app.co/app/entaxy

Recommended for users of: Mint.com, Prosper, Penny, Personal Capital

Entaxy: Insight into your finances, without sacrificing your data https://t.co/jcfG5pOis0 via @jack_neto pic.twitter.com/77vtWHS8KW

— Jack Neto (@jack_neto) April 4, 2018

8) Recall: Safely store and access your photos.

Website: https://recall.photos/

App.co: https://app.co/app/recall

Recommended for users of: Google Photos, Box.com, Flickr, Dropbox, Photobucket, iCloud

#TopHunts of Dec 7, 2018 on @producthunt Products by @MinhoKo120 @nhuphan0404 @jackveiga @alvesjtiago @teddy https://t.co/1tco04Wzb7 pic.twitter.com/jr585aJ0sg

— Top Hunts Daily (@tophuntsdaily) December 8, 2018

9) Misthos: Governance and financial management platform.

Website: https://www.misthos.io/

App.co: https://app.co/app/misthos

Recommended for users of: BitGo, Quickbooks

Shout-out to @misthosio on #FutureMoney on @konsensusry with @OmniFinn and @simonlutz21! #Bitcoin #MultiSig https://t.co/rzxyt3OT4a

— Max Hillebrand October 23, 2018

10) Blockusign: Encrypted Document Signing and Digital Notary – Powered by the Blockchain

Website : https://blockusign.co/

App.co: ** https://app.co/app/blockusign

**Recommended for users of: Docusign, Eversign, DocHub

Graphite + Blockusign: Encrypted alternatives to DocuSign and Google Docs. Here is a commentary video with founders @polluterofminds and @nicktheile on how to Create, Sign and Verify a contract w/o a 3rd party https://t.co/DreFlSNdPs @BlockstackApps @ProductHunt @DemocracyEarth

— blockusign (@blockusignapp) December 9, 2018

More decentralized apps are being built everyday so if you want more security, more privacy, and more data portability – give these alternatives and re-imaginings of centralized services a chance. Trying these upstart applications (and offering feedback if you can) is one of the best things you can do for the future of the internet and your own digital rights. Apps are added to app.co everyday, visit to sign up for receive an email update featuring new dapps added each week.

If you’re a developer, it’s the perfect time to join the program. Learn to build a dapp in an hour or less and start App Mining with the Zero-to-Dapp tutorial and then register for App Mining at app.co/mining.

12/19/2018, 3:53pm EST: This post has been updated to reflect a ranking correction described here_ in further detail._

The post December App Mining Results: Meet The Top Ranked Blockstack Applications appeared first on Blockstack Blog - Blockstack.

How App Mining Works

Mitchell Cuevas — Mon, 17 Dec 2018 11:02:32 +0000

Blockstack is broadening the meaning of “Mining”.

Traditionally the term ‘mining’ in cryptocurrency refers to the process of contributing compute resources to the network and earning a reward. On the Blockstack network, however, instead of just ‘mining’ through computation, developers can “mine” by contributing apps to the ecosystem and making applications the community wants.

Blockstack’s App Mining program rewards decentralized application development. This post takes a deeper dive into how the game rewards work.

This post was prepared together with Pietro Ortoleva, Efe Ok, and Ennio Stacchetti, game theorists and behavioral economists from Princeton and New York University. This entry describes:

How the scores from the App Reviewers (the entities submitting votes into the aggregation algorithm) are aggregated into a final score
A payment scheme for the best performing apps
Methods of evaluating the performance of the app review companies themselves after one year from the initial period

This post is a description of the general principles adopted for each of these steps. We refer to the technical report below for the details (including precise formulas) and a more complete technical analysis. You can also find a white paper and a few videos that provide further details.

Paper: An Aggregation Algorithm for Blockstack

The App Reviewers

Reviews of apps will be made by App Reviewers: Product Hunt, Democracy Earth, and a third one; for the purpose of this discussion, just as an example, we will use Usertesting.com. Each App Reviewer reports different scores, using different criteria that are combined into a final ranking, with the hopes of producing a more robust, less game-able version of App Mining. There presumably would be more App Reviewers added in the future, where this game design would remain applicable.

How to aggregate the App Reviewer scores into a final score

The Raw Data

From each app reviewer, we receive multiple scores, one for each criterion.

Step 1: Normalizing the Scores

By bringing the scores to the same units of measurement, they can be aggregated more meaningfully.

In the first step we take all the scores that we receive from all reviewers and normalize them: first, by subtracting the average raw score in each category, second by dividing by the standard deviation of the raw scores in that category.

This normalization avoids giving excessive weight to those app reviewers that tend to give more extreme raw scores.

The resulting normalized score of an app tells us to what extent the score of that app is above or below the mean score, measured in standard deviation units. For instance, the normalized score of 0 means that the corresponding raw score is exactly the average of all raw scores (of the same type). On the other hand, a normalized score of −1 means that the corresponding raw score is one standard deviation below the average raw scores of the same type (placing it roughly on the bottom 16% of all scores), and a score of 1/2 means that the corresponding raw score is one half standard deviation above the average raw scores of the same type (placing it roughly on the top 30% of all scores).

Step 2: Extension of Normalized Scores to Incorporate Missing Data

If there is missing data from an App Reviewer, this is the process for handling it.

At this stage of the procedure, we turn to those apps that have not received any votes in Democracy Earth, or were not evaluated on a given category or by a given app reviewer. As a general principle, we assign −1 as the normalized score of such apps for every score they miss. Given the nature of normalization we have introduced in Step 1, this means that these apps receive the score of the app that sits (in terms of its raw score) exactly one standard deviation below the average. Thus, the procedure punishes these apps, but does not necessarily give them the worst evaluation. (Moreover, some of this punishment is alleviated in Step 5, where we aggregate the normalized total scores of the apps through the evaluation periods.)

Step 3: Aggregation within the App Reviewers

In this step we aggregate the scores for an app within each App Reviewer to obtain “the” reviewer’s score of that app.

We now have multiple normalized scores for each app reviewer — recall that each app reviewer reports multiple raw scores in different categories. In the case of a potential App Reviewer like UserTesting.com, there may be four scores, one for each category. In the case of Product Hunt, we have two scores, one from the team and one from the community. In the case of Democracy Earth, we again have two scores, one measuring the “desirability” of the app, and one measuring the “attention” that app receives in the market. In this step we aggregate the scores that an app has received from any one of these reviewers into a single score to obtain “the” reviewer score of that app. We do this simply by taking a weighted average of the reviewer’s scores.

Step 4: Aggregation across the App Reviewers

In this step we aggregate the normalized scores that an app has received across all of the App Reviewers.

The objective is to do this in a way that reduces the impact of a single app reviewer score on the total score. In general, a main concern for the overall procedure is the potential for manipulation (such as vote buying, etc.). Our method reduces the incentives to do this by making such manipulations costly by means of adopting a nonlinear aggregation method across reviewers.

Put more precisely, instead of taking simply the average of the reviewer-aggregate scores determined in Step 3 above, we pick a function F to transform each score, and only then take the average of these transformed values. This will be the aggregate score obtained in this step. The function F is chosen so that it is strictly concave for positive (normalized) scores, and strictly convex for negative (normalized) scores. (See the technical report for the exact formula.) It has an S-shape quite similar to the one below:

The function F

To illustrate the point of utilizing such a function F, suppose App i wishes to increase its overall ranking by 0.3. Given the (convex) payment scheme we suggest below, this may be profitable. (For, small upward shifts in the mid ranks make relatively small monetary returns.) Now, suppose that the original (normalized) score of the app from a certain reviewer is, say, 0.2. Suppose for concreteness that the function F above 0 is the square root. Then, the formula above says that to increase its full score by 0.3, the app would have to increase its score from that reviewer by 1.81: recalling that scores are normalized and that 1 is the standard deviation, this means manipulating that score from that reviewer very substantially. Importantly, the higher the app’s original score, the more unfeasible is to manipulate the algorithm from a given reviewer. If, for instance, the score of App i from Democracy Earth (DE) were 0.8, then the app needs to increase its DE score to 3.2 (in standard deviation units) which, for all practical purposes, means buying the votes of the entire community.

On the other hand, with S-shaped functions like the one above it is a bit easier to have small manipulations for scores near the average scores. But given the payment scheme (see below), this may not be very profitable.

Step 5: Intertemporal aggregation, only for periods after the first

Since app developers will continue to improve their apps, and since the past and present evaluations of their app contains valuable information, we can continuously account for this with a “memory” function.

For the initial period, the algorithm stops here. For periods after the first, however, we introduce a “memory” for the algorithm, because the previous scores of an app may contain valuable information that one should not lose. We thus adopt a scheme of discounted aggregation of scores over time.

Specifically, we will discount previous scores by a factor of 0.8.

The algorithm at this stage works as follows. Suppose we are in the second period. Consider the scores of the app obtained in Step 4 above in the initial period, call it s(1). Suppose the score of this app obtained in Step 4 in the second period, is s(2). Then, we obtain a total score for period 2, Total(2) as

In general, to compute the total score for period m, Total(m), we use the following recursive formula:

According to this algorithm, older scores are accounted for, but discounted.

New Apps

In some periods new apps may enter the pool. It is important that the reviewers are made aware when a new app arrives, and that they make sure to include it in their evaluation process as soon as it arrives. This is crucial for the method that is applied for missing data pertaining to a new app.

In the case of new apps, the algorithm will compute a score for new apps as it this was the first period in the algorithm was run. Because the total scores of the other apps are normalized, it will thus be comparable, and new apps will not be disadvantaged.

The payment scheme for Apps

App developers must be paid out each month in accordance to their app’s ranking, where the higher your app is ranked the more you will earn.

We propose to use the following payment scheme. Blockstack sets total budget M, a percentage p, and a maximum number of paid apps n (which could be more than the total number of apps under consideration). Then, the scheme pays the fraction p of M to the first app; the fraction p of the remainder to the second app; and so on. In particular, the second best app is paid

while the nth app is paid

This proceeds until app n is reached and/or there are no more apps.

We adopt p=20% for the pilot of App Mining.

Dealing with Ties

It may happen that two or more apps would get the same final score, and hence tie for a position in the final ranking. In this case, the payments to the apps are equally distributed among the apps that are tied, and the total amount to be shared is the one that would have been paid to all these apps if there was no tie.

For example, recall that the first app receives a payment of p*M, and the second app a payment of p(1 − p)M. Now suppose that two apps are tied for the first place. Then the two apps share equally a total of pM + p(1 − p)M.

Criteria to Evaluate App Reviewers

The below criteria are suggestions for evaluating App Reviewers and could be used for voting or for further incentivization.

We suggest three criteria to evaluate the app reviewers. All three criteria have advantages and disadvantages. The community will be given the outcome of the rankings according to all three criteria – the third one being run both globally and by broad categories – in order to make their evaluations.

Criterion A: Agreement with the Final Ranking

A first possible criterion is to investigate whether a reviewer’s score is similar or diﬀerent to the final, aggregate one, obtained after 12 months. There are two reasons to consider this final score as a benchmark. First, it is the ranking resulting from the most information – it aggregates a number of diﬀerent reviews repeated over time – and may thus be considered the most accurate. Second, because these final scores will not be known until much later, it is harder for app reviewers to adapt to them beyond reporting their genuine evaluation of the app.

Thus, we can construct a score for each reviewer which is minus the sum of the square distances between the score of each app in each period by that reviewer, and the final aggregate score of the app.

There are two limitations of this criterion. First, because it punishes the variance with respect to a final score, it punishes reviewers with scores that are highly variable over time. For example, if the final score of an app is 1, a reviewer that reports 1 all the time has a higher score than a reviewer whose scores for that app alternate between 0.8 and 1.2.

The second limitation is that it discourages reviewers to use an approach that is very different from that of the other reviewers. For example, suppose that two app reviewers follow methodologies that lead them to be largely in agreement, while a third one tends to give uncorrelated scores. Then, the last reviewer is more likely to receive a lower reviewer-score, unless his method is better at predicting the final score.

Criterion B: Agreement with Objective Criteria

A second measure with which reviewers may be evaluated is by comparing their scores with external, objective criteria. For example, it could be possible to compute a score of diﬀerent apps based on external financing, or based on number of monthly active users. One can then compute whether each reviewers’ score in each period agrees, or not, with this final objective ranking.

This is constructed like Criterion A above, except that uses as a comparison point, instead of the total final score, the objective criterion (also normalized like in Step 1 of our algorithm).

As in the case of Criterion A, this criterion rewards reviewers with scores that have been highly consistent over time. It also rewards those who have been accurate in predicting the apps that are financed the most/least, or have the most monthly active users.

Criterion C: Spotting Top Apps

A third criterion to evaluate reviewers is their ability to spot great apps early. This could be a particularly desirable feature, as it may be particularly important for apps with great potential to receive funds early so that they reduce their risk of disappearing and continue to grow.

Consider the apps that are in the top 10% with respect to these total, final scores; let T denote the set of all such apps. We want to give credit to a reviewer that gives a high score to apps in this group earlier on. Thus, we can simply add the number of times in which a given reviewer places each app in T in the top 10% of its own aggregate ranking (computed in Step 3 of our algorithm).

Note that reviewers with scores that fluctuate a lot over time may (although need not) have an advantage according to this criterion. Note also that this measure does not depend on the actual score that apps are given either by the reviewer or in the final ranking: all that it matters is the ability to identify top performers, even if their relative rank is diﬀerent from the final one. This is markedly diﬀerent from the approach used in the other two criteria above.

Finally, let us note that this criterion can be applied to the whole set of apps, or it can be run category by category. The latter method could be particularly useful in that it may incentivize reviewers to spot the good apps even in categories that are not too popular, thereby ensuring that the available apps are consistently good across the board.

We hope this explainer was useful to you. If you would like to continue the discussion about App Mining, head over to the forum. If you are interested in entering your app into the App Mining program, visit app.co/mining.

Full Video Presentation

The post How App Mining Works appeared first on Blockstack Blog - Blockstack.

Learn to Build Decentralized Applications In an Hour: Introducing ‘Zero-to-Dapp’

Mitchell Cuevas — Fri, 14 Dec 2018 17:31:49 +0000

Learning to build a decentralized blockchain application doesn’t have to be difficult or time-consuming for developers. Using languages and frameworks they already know, Blockstack makes it easy to build decentralized applications that protect privacy, are inherently more secure, provide data portability, and more.

To help make getting started even easier, we’re introducing the ‘Zero-to-Dapp’ tutorial. The tutorial is a step by step sequence designed to help developers quickly understand the Blockstack platform, the benefits of decentralized architecture, and create a working decentralized application, all in just about an hour.

While working through the Zero-to-Dapp tutorial, developers will create a multi-page web app called ‘Animal Kingdom’. In the course of building the application developers without previous blockchain or decentralized application experience will:

Learn how decentralized applications (Dapps) are different from traditional web or mobile apps.
Explore the Blockstack Ecosystem and its powerful platform capabilities.
Discover the potential resources available through App Mining.
Build a multi-page web dapp using standard front-end frameworks.
Deploy and publish your application

In addition to learning a new approach and platform, developers who complete the Zero-to-Dapp tutorial and submit it to App.co get a free limited edition t-shirt (pictured below).

As you begin building we welcome you to join the Blockstack community, you can connect with thousands of other developers and the Blockstack PBC team via Slack and the Forum.

Start Now

The post Learn to Build Decentralized Applications In an Hour: Introducing ‘Zero-to-Dapp’ appeared first on Blockstack Blog - Blockstack.

Blockstack authentication server-side — node.js

Mitchell Cuevas — Fri, 07 Dec 2018 14:00:19 +0000

This post was originally published on Medium.com by George Bennet and is republished with permission.

The Blockstack authentication flow enables users to authenticate themselves in an entirely client-side fashion. This way, users can port their identity and private data without the need for third party authentication.

But… what if you need to authenticate with a server? Users may need to authenticate with third parties in order to access services that they trust. Luckily, Blockstack has all the methods required to support this use case.

Client set-up

The first half of the flow works exactly the same as the client-only flow described in the Blockstack guide. Your app will generate an authRequest with the necessary scopes and redirect your user to the blockstack browser. Your user will return to the callback URL with an authResponse JWT which contains all the information needed to authenticate the user. You’ll need to POST the authResponse to your server for authentication.

Server set-up

The authResponse token contains all the information needed to authenticate your user including a unique identifier, email address and the URL needed to fetch the user’s profile data.

First, we can use the blockstack.verifyAuthResponse() method to verify that the authResponse is valid
Then, decode the JWT to reveal the user’s unique identifier, email and profile URL
Then, perform a GET request to the profile URL to retrieve the user’s name

\*\* FOR DEMONSTRATION PURPOSES ONLY \*\*

import request from "request-promise" import { verifyAuthResponse } from "blockstack" import { decodeToken } from "jsontokens"

async function blockstackAuth(req: Request, res: Response) { const LOOKUP\_URL = "https://core.blockstack.org/v1/names" const authResponse = req.body.authResponse let token: any try { const valid = await verifyAuthResponse(authResponse, LOOKUP\_URL) token = decodeToken(authResponse).payload if (!valid || !token) { throw new Error("invalid authResponse.") } } catch (e) { return res.status(400).send(e) } const userJSON = await request(token.profile\_url) const userToken = JSON.parse(userProfile)[0].decodedToken const userData = userToken.payload.claim const userUniqueIdentifier = token.iss const userEmail = token.email const userFullName = userData.name // Some logic relating to the now authenticated user e.g. sign-up

res.status(200).send({ message: "all good!" }) }

Catch — clock skew

Time sensitive JWT authentication can suffer from clock skew, whereby the issuer’s time and the authenticator’s time is out of sync.

If you find that a blockstack authResponse is deemed invalid by your server, it might be because your server’s time is behind that of the server which issued the authResponse. ** The **blockstack.verifyAuthResponse() method will deem the ** ** futuristic issuance time as invalid.

To resolve this, at Zinc, we omitted the issuance validation of the blockstack.verifyAuthResponse() *method * ** in favour of a custom method which allowed for time discrepancy (or “leeway” by the JWT standard). We made use of the Blockstack component functions to re-construct our own **authResponse validation:

// blockstack.js methods await blockstack.isExpirationDateValid(authResponse) await blockstack.doSignaturesMatchPublicKeys(authResponse) await blockstack.doPublicKeysMatchIssuer(authResponse) await blockstack.doPublicKeysMatchUsername(authResponse, LOOKUP\_URL)

// custom issuance date validation method await isIssuanceDateValid(authResponse, {leeway: 30})

The post Blockstack authentication server-side — node.js appeared first on Blockstack Blog - Blockstack.

Free Blockchain Application Ideas

Mitchell Cuevas — Wed, 05 Dec 2018 16:00:44 +0000

Blockchain-based applications can offer a safe, secure, and more robust (even censorship resistant) experience for their users, but it is early days and there simply aren’t enough great ones being built.

At a basic level you can sign in to them with an identity you alone control, run the app locally on your device, save your data to your own private cloud, and connect with friends who are also doing the same…without relying on middlemen or centralized data silos. This allows for complete freedom and user-centricity, meaning if I don’t like an app, I can fluidly move to another app by taking my data with me. This also means that some apps won’t quite look like traditional “apps” since people using this infrastructure can reorganize themselves in any way they want.

To help incentivize app creators to build the future of high-quality apps, we recently launched App Mining. This means that every month is a new opportunity to earn a portion of what is currently $100,000 in monthly payouts across registered apps. If you’ve been thinking about it or have some extra time and want to contribute to the ecosystem, here are some app ideas we think would be useful and could be successful:

Decentralized Localbitcoins.com
Earn.com-like decentralized email client
Coin-operated file viewer
Decentralized Patreon alternative (information is not free! :-))
Podcast that pays podcasters
Spotify that pays artists
Dating app with specific communities
“Dunbar” Apps for your 1.5, 5, 15, 50, 150 friends
Social media where you save photos of your friends
Social media for people who are depressed (bring them from unnaturally unhappy to just naturally unhappy! ;-P)
“Blockstack experience” app (educational app about decentralization that walks you through the how and why of signing in with your Blockstack ID, shows your files in private gaia cloud, etc.)
App connecting community to campaign to make facebook’s algorithm public. Sign in to see progress, save files and communications in it.
Real Person Generator: KYC in a way that solves bot Sybil attacks but preserves privacy.
Blockstack Stacks token wallet app
Mixpanel for privacy-centric blockchain applications
App that connects you on one highly sensitive thing
Auditable, voluntary pothole filling
Personal therapy app where you can record your sessions privately
Scooters! Sign in to a scooter with my Blockstack ID and own your ride history in your Gaia private cloud.
This could allow many transportation networks to serve you in new ways.
Github without the centralized data silo
Slack without the centralized data silo
An app that uploads facebook’s data and repurposes it. I don’t want to just download my facebook data and delete facebook, I want to recycle it into a new app! Same for twitter.

If you have ideas for new blockchain apps add them to the public forum:

Add to the Forum

If you are building an app using Blockstack, sign up for app mining and earn money each month!

The post Free Blockchain Application Ideas appeared first on Blockstack Blog - Blockstack.