Options for How to Claim an App for App Mining


#1

This thread is to discuss different ways that an app maker can claim an app to register for App Mining. After they register, they can setup different ways to add their Bitcoin address, etc.

Risks

The main risk here is that we need to make sure that app rewards are going to the appropriate entity, and not being ‘claimed’ or stolen by someone else. For example, we can’t let any member of the public simply say they own XYZ app, and then receive the rewards. Similarly, we don’t want a situation where a developer or contractor or someone at the company actually registers for the rewards, but sets their own personal BTC address and takes the rewards for themselves. This latter problem is harder to solve, and likely requires some manual verification.

MVP approach

The first method we’re implementing is a simple form that sends an email to Xan for follow-up. There will be some copy on this page to communicate what App Mining is, maybe with links to further docs. This form will likely live on app.co. The required fields would be:

  • App name
  • URL
  • Contact Email

Any others?

Then, Xan can follow up with those people, and he’ll manually add them to a spreadsheet or similar.

Do we need an engineer for due diligence to make sure this app is using Blockstack auth? Seems like anyone could simply use the app to double check that you can log in with Blockstack.

Longer-Term solution

It seems we’ve agreed that most App Mining interactions will take place through app.co. This is where we’ll display app rewards to the public, but it’ll also be home to the maker portal for app owners. This is where you can configure your BTC address, as well as manage your app.co listing.

The question here is how to verify that a user is actually an owner of an app.

DNS verification

An industry standard for proving ownership of an app is to add a TXT record to the DNS for your domain. The user will have some step in their setup flow where we provide a string that they need to set in their DNS. Then, our server will fetch the domain’s DNS and verify that the TXT record is there. This proves that the user owns that domain.

The risk here is that some developer or contractor with DNS access claims the app and takes the rewards.

Email verification

This is similar to the above, because if you have DNS access for a domain, you can send an email from it. However, this approach is easier for non-developers. It also makes it easier for some evangelist or contractor to use their company email to claim rewards.

A benefit here is that we can manually ask for email verification from someone ‘higher-up’ at the company, ie the CEO.

Google Analytics access

We can ask apps to give us access to their GA profile. This gives us the benefit of being able to use their metrics and share them with app reviewers.

Conclusion

I think the MVP approach works well for the short-term, so we can get an initial batch of apps, and get closer to our OKR of 100 registered apps. We can also do more high-touch verification early on, before the program scales out.

In the medium to long term, I think we should do a 2-step verification process - DNS and manual high-touch email contact to the CEO or another executive. The latter I find important for making sure the rewards are actually being distributed to the company. It also gets us in contact with leadership, which can lead to cross-promotion and partnerships.

Please share your thoughts, or give other ideas about how we can go about this. Thanks!


#2

I would love to see a manifest verification rather than a DNS verification. Sure, you have a similar problem to DNS in that a contractor could update this, but at least you know the update is coming from someone with access to the core code and can deploy said code. And avoiding DNS when Blockstack wants to at some point replace that just makes sense to me.

I would NEVER consider GA as something you should require or ask for. For those who don’t use GA (and none of you should, shame on you if you do!), there may be a pressure for them to install Google tracking code just to meet a requirement.

To me, the best bet is the manifest update. At some point, if and when code is hosted on Gaia or Atlas, it’d be great to use that as the proof mechanism.