Keyper - Connect to User's Online Data But Remain Can't Be Evil

[malikankit]

Summary

We are trying to solve the problem of how third-party personal data management applications can connect to a user's data across different online services without compromising on their Can't Be Evil guarantees.

With the current data access flows (like OAuth, secret tokens) - if a third party app has to connect to a user's personal data across different online services - they have to compromise on their Can't Be Evil guarantees. The open issue then is - How to enable apps to connect to users' personal data without comprising on Can't Be Evil.

We are trying to solve this issue with Keyper - https://getkeyper.com - a desktop application that enables them to connect third party apps with their online data sources in a secure and auditable manner.

We strongly believe that Keyper's relevance to the Stacks application ecosystem. With the current data access flows available to apps, connecting to users' online data requires compromising on Can't Be Evil guarantees. Integration of Keyper with Stacks ecosystem will enable Stacks app developers to build personal data management apps without having to make these compromises.

This, in turn, will enrich the spectrum of Can't Be Evil applications available to end users.

In this application, we are seeking a grant to kick-off integration of Keyper with the Stacks ecosystem and iterate on Keyper to make it more useful to the Stacks community.

Background

What problems do you aim to solve?

TL:DR - How can third party personal data management applications connect to user’s existing personal data across different online services (eg. GitHub, Figma, Gmail and more ) without compromising on their Can't Be Evil guarantees.

The problem can be described with the following 4 points.

1) Users have their data spread out across various online data services like Github, Binance, Figma, Gmail etc. 2) Personal data management apps access a user's data and provides them with actionable insights, backup facilities, or data analysis etc. 3) The current paradigm of data access forces these applications to compromise on their Can't Be Evil guarantees. 4) With Keyper we introduce a new paradigm for personal data access that enable development of personal data management apps while maintaining their Can't Be Evil guarantees.

All the points above are detailed below.

1. End User

As an end-user, I have my online data across multiple online data services. For example,

• Code repos on GitHub
• Trading data on Binance
• Designs on Figma

2. Third-Party Personal Data Management Applications

I want to use third party applications to better manage my data. For example

• An app to analyse my GitHub productivity
  • An app to understand my Binance portfolio
  • An app to backup my Figma designs

And, I want to achieve these with applications that Can’t Be Evil

3. Current Paradigm and Its Problems

The current paradigm of user’s data access by a third party application involves

• The user handing over some security token to the app (explicitly as a personal access token or implicitly via an OAuth flow)
• The app then using these credentials to fetch data from the data provider

This paradigm introduces scope for multiple Can Be Evil opportunities

Issue a : No Auditability of Data Accessed

Firstly, unless the data provider is very proactive to provide audit trails or granular controls - there is no auditability or custom granularity to what all data is accessed by the app.

Issue b : Extra Development Cost and Exposed Data Flow

Additionally, the app developer has to build and maintain infrastructure to protect user credentials (typically this is done server side). This also requires them to manage and secure the data flow.

• If credential storage is done on the server side then user credentials lie on the app’s server - opening them to possibilities of hacks and abuses. In addition to that all personal data flows through the app’s server.

• Alternatively, if this is done client side the app can still ‘call home’ and pass on the user credentials to its servers.

  Both of these weaken the application's claims of Can’t Be Evil.

  4. Keyper as a solution

  With Keyper, we are solving this problem : with a new paradigm for personal data access by third party apps. With our proposed solution -

• End users can manage and leverage their online data better - with third party apps that access their personal data and are still Can’t Be Evil.

• Developers can build personal data management applications – Without sacrificing their Can’t Be Evil guarantees – Without having to maintain and develop infra to manage user keys, personal data flows et al.

  Relevance to Stacks Ecosystem

  In the context of Stacks applications, this is highly relevant. Internet users have and (barring a massive switch) will continue to generate a vast amount of personal data across Web 2.0 services. This data is typically accessible via OAuth and personal access token flows.

  Stacks apps - specifically personal data management applications - are cutoff from this vast amount of data unless

• they weaken their Can’t Be Evil guarantees - oh no!, OR
• leverage new paradigm(s) to access this data - oh yes!

How does it serve the mission of a user owned internet?

Keyper integrated in Stacks ecosystem will enable a new category of Can't Be Evil applications that empower end-users to better manage and leverage their online data.

Project Overview

What solution are you providing? Who will it serve?

Our Solution

Keyper is a local-first desktop application with the following key features.

1. Secure Wallet for Data Keys - Users store keys to each of data services that they use e.g. Github, Figma etc. Think of it as a Metamask but for keys to your data assets.

2. Data Bridge - Third party applications never see your data keys. A user explicitly connects a third party app with their Keyper. Once connected, the app makes data requests to the user's personal data via Keyper.

3. Audit Trail of Data Requests - Keyper logs all data requests and responses made across connected third party applications. Users can monitor these logs and take moderation actions as necessary. In a future version, users will also be able to exert granular control of the data accessed by the connected applications. Think of it as a firewall, but for personal data access flows.

What we have already built

We have an MVP for Keyper - as a desktop application that currently supports two data providers - GitHub and Figma.

Homepage : https://getkeyper.com GitHub Repository : https://github.com/getdatapod/keyper

We also have a sample third party app - Gitjam - that accesses a user’s GitHub data via Keyper and provides some basic stats about their code.

Gitjam Link : https://gitjam.netlify.app/

What do we propose to build with this grant?

We believe Keyper has a strong use case in the Stacks ecosystem. Over the next few milestones, we want to iterate Keyper to enable a strong integration with the Stacks ecosystem, so that Stacks app developers can build personal data management apps that are true to the Can’t Be Evil philosophy.

With this grant, we want to achieve with the following -

• Integration with Stacks libraries and flows
• A PoC Stacks Application - that will also serve as a Reference app for the community
• Documentation and hands-on tutorial for Stacks app developers

Specific deliverables follow in the next section

Who will it serve?

The goal of this milestone is to empower Stacks app developers to integrate Keyper in their apps.

The long-term vision is to serve end-users - to enable them with personal data management apps that Can’t Be Evil.

Scope

What are the components or technical specs of the project? What will the final deliverable look like? How will you measure success?

We want to deliver across the following 3 dimensions

1. Integration with Stacks libraries and flows

Rapidly iterate Keyper to better integrate with Stacks libraries and flows. This would involve understanding the Stacks technology better and taking feedback from the core and developer community.

To avoid feature creep, we are proposing a minimal viable deliverable. A Keyper submodule (we envision a TypeScript module within Keyper) that provides basic integration - for Stacks developers to integrate Keyper in their applications. We plan to incorporate more sophisticated integrations in future milestones.

2. Reference Proof of Concept application

A Stacks application that uses Keyper for personal data access. This serves multiple purposes

• Serve as a reference application for future Stacks apps that integrate Keyper
• A practical example to engage with the community for feedback loops
• Building this app will also feed into the first deliverable of upgrading Keyper for stronger integration with Stacks.

3. Documentation and tutorial for Stacks app developers

• Keyper API Documentation for Stacks Developers
• A step-by-step tutorial for 'How To Integrate Keyper in Your Stacks App'
• An FAQ with sections specifically targeted at Stacks developers.

Budget and Milestones

What grant amount are you seeking? How long will the project take in hours? If more than 20, please break down the project into milestones, with a clear output (e.g., low-fi mockup, MVP with two features) and include the estimated work hours for each milestone.

We are seeking a grant amount of $5000. This amount will go towards 4 verticals - research, design & development, documentation and community engagement.

The actual costs of the project over the next few months will be higher than this. But we have scoped this specific milestone to fit within the grant limit of $5000.

We have already bootstrapped roughly 200 hours on the MVP across research, design, development and testing. For the Stacks integration Milestone, we are planning 130 hours spread across 8 weeks.

1. Research (20 Hours)
2. Design and Development (60 Hours)
   • Iterating Keyper To Integrate With Stacks (30 Hours)
   • Proof of Concept App (30 Hours)
3. Documentation (30 Hours)
4. Community Engagement (20 Hours)

Team

Who is building this? What relevant experience do you bring to this project? Are there skills sets you are missing that you are seeking from the community?

We are a group with diverse skills united by the mission of enabling end users to better leverage their data.

Rishi Sidhu https://www.linkedin.com/in/rishisid/ Rishi has an 8+ years experience building product based startups. He is also the editor of a Medium publication and has written over 50 articles that have been widely appreciated. He brings Product, Design, Technical Writing & Backend Development skills to Keyper

Hritique Rungta https://linkedin.com/in/hritique Hritique is a full stack web developer who has built numerous applications using the MERN stack. He brings full stack web development expertise to Keyper.

Shubham Girdhar https://www.linkedin.com/in/shubham-girdhar-25361a46/ Shubham is the people's person on the Keyper team. He takes care of the feedback loops and community engagement. At Keyper, he brings marketing and evangelism skills to the table.

Ankit Malik https://www.linkedin.com/in/ankitmalik1/ Ankit is a blockchain engineer and researcher who has been active in the crypto space since 2015. He has designed Keyper's data flow paradigm and brings strong research chops to Keyper.

Specifically, we are missing and seeking the Point of View of the Stacks community. We are looking for feedback and advice

• from the core platform team : for better integration with the core philosophy of Stacks
• from the community - especially app developers - for better Keyper tooling and documentation
• on better outreach in the Cant Be Evil application ecosystem

Risks

What dependencies or obstacles do you anticipate? What contingency plans do you have in place?

Keyper is MVP at this point.

A key factor in Keyper's success is its Product-Market Fit - specially with developers on the Stacks ecosystem. We want to keep the development process iterative with intense feedback loops to make sure we are building what the community really wants.

Explaining the new paradigm

Since Keyper involves a new paradigm of data access - for both users and developers - it will require targetted efforts on educating both.

In a way, Stacks applications have this challenge too - explaining a new paradigm of application authentication and storage. And we want to learn from the Stacks community on how to smoothen a new paradigm for users and developers.

Community and Supporting Materials

Do you have previous projects, code commits, or experiences that are relevant to this application? What community feedback or input have you received? How do you plan to share your plan to the community over time and as the final deliverable?

Supporting Materials

1. Keyper Homepage : https://getkeyper.com
2. Keyper MVP Code Repository : https://github.com/getdatapod/keyper
3. Sample Keyper App : Gitjam : http://gitjam.netlify.app/

Personal Data Management Tools That Have Built As A Team

1. Twish - Better Twitter Search - https://twish.xyz
2. FigPickle - Backup your Figma Data - https://figpickle.datapod.app

We started the MVP - in order to scratch our own itch. We want to build personal data management apps without compromising on Can't Be Evil. As a next step, we have shown this to friends in the app development and crypto space.

We plan to share our plan with the community in the following ways

• Build and release publicly on the GitHub repository - and be active with feedback, issues and release updates
• Engage with the Stacks community on Discord, the forum and Twitter
  • empower them with better documentation and tooling
  • engage in feedback loops and
  • update them on the evolving roadmap, release updates etc.
• Evangelise Keyper across Twitter, Medium, Dev.to and related dev communities at this stage

---

[friedger]

Interesting! Here an unordered list of thoughts:

Do you have a link to the source code of gitjam? How does the keyper API look like?

This looks like an additional feature to integrate into the Blockstack App that is the authenticator for Blockstack users. Installing Blockstack app and Keyper looks like too much for end users.

If I understand the source code correctly, it is some kind of proxy to online data endpoints that require an API key. How would end users get their API key? The process of applying at github and other services as a developer and finding the API key is usually too much for end users.

Two-factor authentication for API keys should be handled as well.

How would end users evaluate apps whether they are trustworthy or not?

The keyper API is probably similar to what ryder and the new internet lab browser are planning to do for encrypted read/write file operations.

[malikankit]

Hey @friedger : Thanks for taking the time to read our application and for your questions.

1. Source code for Gitjam is at https://github.com/getdatapod/gitjam. It's a bit rough around the edges - so we plan to clean it up a bit - before making it public. I have added you in the access list though - anyone else wants access - happy to add :)

2. Correct. The API is pretty MVPish right now (with a couple of known security issues) but yes it is effectively proxy-ing in via Keyper. And then Keyper logs all the data requests / responses.

So, Keyper is technically the equivalent of a Proxy + Metamask + Firewall + Audit Log

---

3. The process of applying at github and other services as a developer and finding the API key is usually too much for end users.

• Agree and Disagree.

• I would say these data providers are roughly in two buckets - as of today.

Bucket 1 :

• The ones that make it really easy to fetch an API key.

  • GitHub, Figma, Binance ... are in this bucket.
  • Getting a GitHub token is pretty easy now. Try it out at https://github.com/settings/tokens
  • Infact, there are now third party apps that have 'bring-your-own-tokens' flows. Eg. https://coinstats.app/ - a paid application - asks you to fetch your Binance token yourself to display your portfolio.
  • I believe this bucket will increase as more and more apps want to show that they won't lock in your data - as a feature.

• For the former bucket, the process of adding an API key - right now - is comparable to setting up a Stacks account or using Metamask.

Bucket 2 :

• And of course, the ones that don't.

• This could be because of extra security OR just apps wanting to be very possessive with the data they have about you (hint hint - the walled gardeners).

• At this stage, we would like to target and build Keyper for Bucket 1.

---

4. How would end users evaluate apps whether they are trustworthy or not?

• This is a very big question. I mean the question of Trust. I think 'trust in an application' derives from a lot of signals - technology (what is the stack being used? can I review the source code? what tech principles are being used? are these guys known to be technically adept) + messaging (GDPR notes, privacy policy in place, doesn't look shady/shoddy) + social signals (reviews, testimonials, who else is using it)

• I would say, a place like curated app stores are better primed to solve The Entire Trust Issue with a community of curators/ reviewers.

• I don't think Keyper individually - can solve for the entire Trust Questions. What Keyper can do is feed into these signals and contribute to the Trust Puzzle. Some points of note ->

  • a) It can enlarge the spectrum of apps or capability of apps available on - say - existing Can't Be Evil app stores like Dapp.com, App.co. For example, StackFolio - which is an encrypted currency portfolio tracker on App.co - https://stackfolio.co/ - can now plug into your Binance data via Keyper - while still ensuring Can't Be Evil guarantees.

  • b) Second, it can feed into the reviews of these applications. Say, an app is sucking in more data than it needs to that will show up on the user's Keyper - and then it can show up in app reviews.

  • c) Thirdly, it can establish an ongoing Trust Relationship with control in the hands of users. Say, I decided to trust an app based on certain signals and then connected it to my data. That should not be the end of our "trust evaluations". It can be an ongoing process - where - as a user - I continue to review what data this app accesses - and then decide on my 'relationship' with this app - from time to time.

TL:DR - Keyper is one piece of the Trust Jigsaw Puzzle that we face with modern day applications.

---

5. This looks like an additional feature to integrate into the Blockstack App that is the authenticator for Blockstack users. Installing Blockstack app and Keyper looks like too much for end users.

• Yes, at the MVP stage that it is right now - this is a standalone desktop app. But in the short-to-medium-run : the possible home for this could be
  • a) a submodule within the Stack Authenticator app
  • b) a plugin into a Stack Authenticator app that supports plugins (Some day?)
  • c) browser extension
  • d) a desktop application
  • e) or a combination of above

with a core codebase being shared across these implementations.

---

6. Yes, Ryder looks really cool. :) Also, can you point us to any readings on this - the new internet lab browser are planning to do for encrypted read/write file operations . As a group - we are quite passionate about expanding the scope of Can't Be Evil and putting users more in control of their data. And it would be cool for us to explore more / collaborate / contribute.

---

[blocks8]

Review Committee Feedback from 10/6/2020: We'd like more information on your proposal.

Thank you for your submission! We'd like to learn more about the product traction to date. It definitely aligns with our mission of Can't Be Evil, but as mentioned by some peers, it's a bit of a question of how a user or app developer would integrate with Keyper to streamline their applications.

• Could you provide more information on the size and types of users using Keyper today?
• Would this scoped work deliver less friction to Blockstack app users? Or not until future iterations (as mentioned above that it's only desktop in the near term)?
• Have you gotten feedback from any Blockstack app developers on their interest in adding a product like this? Or would it just be for app users? Would love to hear feedback direct from users, you can tap into that network in Discord.

Looking forward to learning more.

[malikankit]

Hey @blocks8 : Glad to read that you find this aligned with the mission.

• Could you provide more information on the size and types of users using Keyper today?

• Yes, we are just getting started : so it's a group of our peers ( <20) who have tried out Keyper - and participated in feedback loops.

• We definitely want to streamline the experience for both Stacks app developers and Stacks app users.

  • With the first milestone - we want to streamline the XP for Stack app developers first - so there are some Stack apps integrated with Keyper in the first place for end-users - while simultaneously take feedback from the community on what the end-user experience should be like.

  • In a second milestone - we will be able to focus more on an XP for end-users - specially with reducing the friction of the experience.

• TBH, not yet. But yes, we will kick off engagement on Discord over this weekend - and start collecting feedback.

[ryanarndtcm]

@malikankit Hey there! would you be able to share where the discord conversation is? I have not been able to see it as of yet but not sure if I may have missed the channel that you are chatting in. Thanks!

[HariniRajan397]

Hi @malikankit, I have gone through the Keyper project. It is really interesting. As discussed in Discord with Girdhar , I am resharing my feedback and questions regarding Keyper below:

As per my understanding, Keyper is a Web 3.0 app built on the Stacks platform and the aim is to protect user's data that gets supplied to other third-party applications in Web 2.0.

Keyper is intended for 3 main purposes:

1) As a secure wallet for keys - I had the same question as Friedger , getting keys for individual applications and processing it will be a bit tricky, especially for those bucket 2 apps as you mentioned.

2) Keyper as data bridge- I don't have clarity here. Blockstack Connect and storage does the job of putting users in control of their data. I don't really understand Where exactly Keeper fits as a data bridge? Is it a plugin? I really need more clarity on this. If you can provide a simple workflow chart for app-developers vs app-users/ simple video will help.

3)Audit Trails - I really liked the concept of Keyper acting as a firewall but again as discussed, trust issues will be there. Despite the trustable data, I would say it is a good start for a privacy-focused web.

I also have the same concern as Friedger. Adding Keyper + Connect will become an additional overhead.

It will be great if we can have some mitigation for the above-discussed points. Otherwise, it's all good. Wish you all the best !!

[shubhamgirdhar92]

@ryanarndtcm Hey Ryan, We were preparing some resources for the developer/users, that explains the delay in initiating the conversation, We have shared all our links to the project on #dev-general channel. So now we are just waiting for the feedback :)

[shubhamgirdhar92]

@HariniRajan397 Hey Harini,

1. It is an inconvenience. But it is getting simpler.( Check @malikankit reply to @friedger --> https://github.com/stacksgov/Stacks-Grants/issues/24#issuecomment-705058355 ) . Also one only has to do this once per data provider.
2. Connect provides apps with authentication and storage powers. Keyper provides apps with the power to connect to users existing (mostly web 2.0) data sources without being evil. So it acts as a bridge between a blockstack app and user's data across GitHub, figma, gmail, twitter.
3. In its POC stage it is a local desktop app and all data requests get routed through your machine and audit data is logged on your machine. See diagrams(https://docs.google.com/document/d/1L6A6ciXa7dMqEJDlPUQSPcvTeHE1k1vdAaUVHXRuC3k/edit) One can review keyper's source code here (https://github.com/getdatapod/keyper).
4. Yes we are awaiting feedback on what the keyper integration of blockstack would look like. It could be a submodule or plugin within the blockstack desktop app.

[RaffiSapire]

Hi Shubham, Given we haven't seen any feedback over the past couple weeks indicating there's demand from the community for this product, we're going to close this issue. If you want to reopen the discussion and are able to provide answers to our previous questions, we're happy to reopen the dialogue or explore another project at any time.

[shubhamgirdhar92]

Hi Shubham, Given we haven't seen any feedback over the past couple weeks indicating there's demand from the community for this product, we're going to close this issue. If you want to reopen the discussion and are able to provide answers to our previous questions, we're happy to reopen the dialogue or explore another project at any time.

Hey Raffi, I am collecting feedback by DMing developers on the Stacks discord group, Some have replied, some are yet to reply back, I will compile all the feedback by this weekend and share it with you ( positive and negative both) and then we can probably proceed from there, Is that doable ?

[jennymith]

Hey Keyper team, thank you for sharing your progress on Keyper so far. This is a really interesting proposal and I feel like there will absolutely be a need for something like Keyper on Stacks 2.0 down the line. A couple thoughts/questions that need clarity:

• Although this is a tool that will ultimately empower privacy-focused end users, your primary audience at this stage is developers, right? If that's the case, where have you seen demand from Stacks developers specifically for this kind of product?

• To Harini's point, is it possible for Keyper to become a client side extension/plugin? If so, how could you help users differentiate Keyper from Connect?

[jdbender66]

Howdy Keyper! Thanks so much for your comprehensive proposal, and sharing so many technical details about Keyper. The MVP looks awesome, and it's evident you have done a lot of research and development on this project! Data storage and portability is most definitely a high priority for Stacks 2.0, and any applications that extend the power of a Blockstack ID would certainly be beneficial.

• You reference the philosophy of "Can't Be Evil" a lot throughout your proposal. I think I would like to that explicitly defined, for individuals who might not know the context behind the slogan. Obviously, it refers to an apps ability to access private data from users, but it can be a fairly broad conviction.

• You also reference the "new paradigm" frequently. I would also like to hear the significance of this transition more clearly outlined. Why is it such a dramatic shift from the way privacy is handled traditionally.

A couple questions:

• Would you view this as a developer tool, or and end user application? I know there is a big debate over whether metamask is a dev tool or user product, as it allows people to interact with dapps but is also needlessly complex in it's UX at times.

• Are there any Clarity smart contracts used in the application?

• What was the biggest obstacle you encountered thus far using Blockstack technology?

[friedger]

As a use case I could see using the google calendar api in OI Calendar (cal.openintents.org)

[muneeb-ali]

This is interesting. I especially like the audit trail aspect of it.

I wanted to quickly understand the solution but it's hidden away a bit in the description right now i.e., maybe pull that info out and add some diagram that shows the solution visually.

[malikankit]

Hey Keyper team, thank you for sharing your progress on Keyper so far. This is a really interesting proposal and I feel like there will absolutely be a need for something like Keyper on Stacks 2.0 down the line. A couple thoughts/questions that need clarity:

• Although this is a tool that will ultimately empower privacy-focused end users, your primary audience at this stage is developers, right? If that's the case, where have you seen demand from Stacks developers specifically for this kind of product?

• The response has been two-pronged. Based on reading just our description / post - the response has been lukewarm to moderate. However, whenever we have presented a demo of the app or someone took the time to dig deep into what we are building - the response has changed from moderate to "definitely useful / I want this".

Hence, to communicate Keyper more effectively, we are now adding some resources - plus a Keyper demo video. Also, for anyone who’s interested on this thread - we will be glad to do a 1:1 demo call + answer any questions you may have.

• To Harini's point, is it possible for Keyper to become a client side extension/plugin? If so, how could you help users differentiate Keyper from Connect?

Right. Connect it in its present form (and correct me if I am wrong) - provides app developers the ability to integrate with Blockstack authentication and data storage - in a Can't Be Evil manner. Keyper libraries enable app devs to connect to third party data providers - and stay Can't Be Evil.

An example in the context of a Blockstack application -

Connect enables Stackfolio to have Blockstack authentication and data storage to store user's portfolio. Keyper libraries enables Stackfolio to plug into a user’s data while staying Can’t Be Evil.

---

Keyper in its current form - is build for web apps - in general. It consists of - a) Keyper App - the local-first desktop app where users maintain their keys, review audit logs etc b) Keyper Dev Library - for developers to integrate with Keyper.

(Somewhat analogous to Blockstack Authenticator and Blockstack Connect)

What would Keyper look like specifically for Blockstack apps - an app? a plugin? or tighter integration with Connect/Authenticator - this is something we want to iterate and develop going forward.

---

[malikankit]

Howdy Keyper! Thanks so much for your comprehensive proposal, and sharing so many technical details about Keyper. The MVP looks awesome, and it's evident you have done a lot of research and development on this project! Data storage and portability is most definitely a high priority for Stacks 2.0, and any applications that extend the power of a Blockstack ID would certainly be beneficial.

Thanks for your response! Really glad you liked the MVP.

• You reference the philosophy of "Can't Be Evil" a lot throughout your proposal. I think I would like to that explicitly defined, for individuals who might not know the context behind the slogan. Obviously, it refers to an apps ability to access private data from users, but it can be a fairly broad conviction.

Right, that’s a good point. The primary guarantee that comes from using Keyper is - it enables app developers to confidently say -

Hey User, allow me to connect to your online data on another service, but because I use Keyper -

• You can see exactly what data requests I make in the Keyper app and revoke my access anytime you want.
• You can limit the data endpoints I can access from anytime within the Keyper app (note : this is a feature we haven’t built yet - but is on our roadmap)
• I don’t have access to your secret key. So I can’t go behind your back and access your data or pass the key to others.

And in this context, I Can’t Be Evil.”

There are some secondary positive side-effects too - that we have covered in the proposal.

• You also reference the "new paradigm" frequently. I would also like to hear the significance of this transition more clearly outlined. Why is it such a dramatic shift from the way privacy is handled traditionally.

https://getkeyper.com/docs/data-access-flow/

We made the above diagram to explain how web apps currently access your data versus the new paradigm of data access via Keyper.

Also, I can TL:DR this with a Blockstack app example - StackFolio (probably our favourite example at this point)

If StackFolio wants to access your Binance data

Current Paradigm You handover your Binance API key to Stackfolio. Stackfolio talks to Binance directly with this key and accesses your data.

Keyper Paradigm You handover your Binance API key to Keyper - a local desktop open source app. Stackfolio talks to Keyper and requests for Binance data via Keyper. Keyper logs all data requests by Stackfolio for you to review and never reveals Stackfolio your Binance API key.

https://getkeyper.com/docs/keyper-blockstack < for a visual explanation

A couple questions:

• Would you view this as a developer tool, or and end user application? I know there is a big debate over whether metamask is a dev tool or user product, as it allows people to interact with dapps but is also needlessly complex in it's UX at times.

This is very subjective, I agree. But I see Metamask as a end-user tool (wallet for your crypto keys) and Metamask libraries as something developers use to integrate their dapp with Metamask.

Similarly, in its current form, we envisioned

• Keyper - an end user tool - (wallet for your data keys)
  • that allows users to connect third party apps with their online data sources
• Keyper Dev Library
  • a JS module import - enables developers to build these third party apps that integrate with Keyper.

• Are there any Clarity smart contracts used in the application?

• No, we haven’t used Clarity yet.
• As of now, Keyper is built generically for all web apps.
• With this proposal, we are exploring how to best integrate into the Blockstack ecosystem.

• What was the biggest obstacle you encountered thus far using Blockstack technology?

• As a long term user of Blockstack apps, I find the philosophy great and the applications quite useful.

• The end of Graphite Docs - was a major heartbreak though :|. I hope apps find sustainable models to survive / grow in the long run - of course, this is not a limitation of the Blockstack technology.

• As a developer, I find the documentation and libraries quite straightforward to use. And they have improved / evolved a lot over time.

[malikankit]

This is interesting. I especially like the audit trail aspect of it.

I wanted to quickly understand the solution but it's hidden away a bit in the description right now i.e., maybe pull that info out and add some diagram that shows the solution visually.

Hey @muneeb-ali : Thanks for your interest.

TL:DR - Keyper allows third party web apps to connect to a user's existing online data in a secure and auditable manner.

In the context of Blockstack, this enhances the capabilities of what Blockstack apps can do - now that they can connect to user's existing data sources - while still remaining Can't Be Evil.

We added a quick visual explanation below - for how a Blockstack app - StackFolio in this case - can access a user's Binance data - without Keyper and with Keyper.

(Edit : Updated Link) : https://getkeyper.com/docs/keyper-blockstack

Also, here's a visual that explains the data access flow for web apps with and without Keyper.

[RaffiSapire]

Hi @malikankit we really appreciate the persistence in getting feedback from the community and all the work you've put into this application. We're please to approve the grant and see where this goes! Please can you email grants@stacks.org and we'll send you a contract so we can pay you the approved amount of $5,000. Thank you, we really appreciate your contributions!

[malikankit]

Thanks @RaffiSapire . Just sent an email referencing the above thread.

[RaffiSapire]

Hello! Thank you for all your hard work this year. We would love to send you a holiday note and some custom stacks stickers. Please email me at Raffi@stacks.org with you and your colleague's names/addresses if you'd like to receive one. I knw this grant didn't pan out but Stacks is what it is because of community members you!

[shubhamgirdhar92]

Thanks, @RaffiSapire, Sending you an email shortly.