(Updated Grant Proposal) Please find grant application attached
As required by document 107 that governs the Factom grant process, this is the thread for grant proposal FACTOM-GRANT-HASHNSTORE-001.The review process starts on 3rd May, so please refrain from starting public review or submitting questions before that time. If you notice clear errors in the proposal you can contact the author of the grant proposal directly.

More options

1. What specific date will you begin work on your grant?
2. What specific date will you be done with work on your grant?
3. Do you commit to providing regular updates on your grant in the grant tracking forum?
4. Please link to past grants your group has taken part in, if any.

You mention severals times in the grant that you have identified multiple synergies with MyFactomWallet, but you do not explain what these are. Could you give a description of what kind of synergies this well be?

I like these types of proposals, but do feel that this type of application needs specs first. We already have (or soon will have) a chrome extension working with DIDs doing similar stuff as your proposal (minus the ledger integration). People have talked about Factom mask in the past. We have 2 identity/spec related grant proposals in this round which both see the need for specs.

My worry is that we will end up with all kinds of application on top trying to accomplish the same things but not being interoperable with each other, which to me would be a waste of time, money and opportunity for the protocol.

1. We will start after our Developer complete some work for us. As mentionned in the proposal, we will start around the mid of June (~17th of June).
2. We expect this work to be spread over 10 weeks, so a bit more than 2 months. That would lead us to end of August/beginning of September.
3. We definitely commit to provide update even before we start to start producing any code (design choices for example).
4. This is the 1st grant we submit to the community.

More options

DavidK and I have discussed about our proposal. The Ledger support is currently limited in MFW and could be extended with the use of an extension such as facilitating the management of identities because Ledger Nano can only store one Identity chain ID and an extension could deal with several ones. Moreover, there are benefits for more seamless experience for defining automatically a specific EC address to pay with.

Beyond this, and after discussing with Valentin, there is no overlap with the extension he and his team is working on as they don't have Ledger support. It would be actually complementary.

In the end, the grant we propose would greatly facilitate the use of the Factom's Identity system for front-end solutions using a super secure device such as the Ledger Nano S.

Before submitting this proposal I have discussed with Valentin working on the DID extension you just mentioned. The Ledger support is currently not part of it. We agreed it would be good to combine them at some point. About The FactomMask proposal: DavidK confirmed me that they moved onto other projects.

Concerning the Identity Spec: the Factom Identity system we based our work on has been defined by Factom Inc. and is currently used by the FAT protocol, MFW, (possibly) OpenAPI. We (HashnStore) actually work with it too. And more important: it is already part of the Ledger firmware. This Identity system is here to stay I believe. And even if some changes should be applied to support a new identity system, I do believe it would be easy to integrate them into the extension.

Moreover, we are using in this proposal basic features of the Factom Identity system which I think will continue to exist (set of keys). The v2 DID spec that you propose in another grant intends to merge the 2 DID spec not to suppress one spec and to waste all the work which has already been produced by different ANOs. So even in your scenario (which is for now a grant proposal), I am confident that our work will not be wasted and could easily be used.

More options

Yes but identities in itself are not very meaningful. You need to interact and use these identities. The V1 DID spec of Factom Inc is for Harmony. It is not directly for public mainnet as of now (a DID document can end up on mainnet). The fctr DID spec is mainnet. Although we have a native identity system, DIDs will be the future, I am pretty confident of that.

So how are you going to make sure that your solution will be interoperable for signing data and voting for instance? Only doing identities on top of a ledger device isn't really meaningful. So are you providing a spec / FIP in advance before coming with a product?

Yes but identities in itself are not very meaningful. You need to interact and use these identities. The V1 DID spec of Factom Inc is for Harmony. It is not directly for public mainnet as of now (a DID document can end up on mainnet). The fctr DID spec is mainnet. Although we have a native identity system, DIDs will be the future, I am pretty confident of that.

So how are you going to make sure that your solution will be interoperable for signing data and voting for instance? Only doing identities on top of a ledger device isn't really meaningful. So are you providing a spec / FIP in advance before coming with a product?

There is already a lot of FIP/spec proposals which are going to be written : one for defining API methods, another one for defining a V2 DID. I am not sure why we should write another FIP. I hope you see the value of proposing an extension to manage a set of Identities (based on the Application Identity), to sign with one of your identities and to pay with an EC address in a seamless way using your Nano Ledger.

In a perfect wolrd, each party would have communicated on its needs for the DID standards from Day 1 and all the tools would have been based on this standard. But in the real world you need to work step by step : that is what has be done for MFW, the Ledger firmware, FAT, on-chain voting.... they did not wait for the DID standard to be released. What we propose is to continue to leverage and capitalise on this standard to have a complete set of tools based on it : with our extension you could set up identities, choose one to sign with, sign data and pay for EC with your Ledger. But to address your point we will be assessing the possibility to add the support of the DID within our Chrome extension for Ledger. If it is possible for a limited amount of time, we will make the effort for free. If not, certainly for a limited amount of FCT.

We have a service and a first partner which will directly interact with our APIs (integration and test phase currently) but we will extend our offer with the support of Ledger. Not necessary through a Chrome extension actually. But we decided to extend this feature to propose it to the community.

More options

Here is the last post to sum up our proposal + some extra features and information:

1- We propose a chrome extension with Nano S Ledger support following the Application Identity standard already leveraged by several tools within our ecosystem (FAT wallet, MFW, on-chain voting, Ledger). We do think it is important to complete the current ecosystem.
2- This extension will allow the user to create an identity on-chain, to fetch it with an identity on-chain and to link it with their Nano S Ledger, to sign data and to pay with a loaded EC address with their Ledger and to send this transaction to the Factom Blockchain in a seamless way meaning within the extension itself! (using OpenNode as an end point).
3- We will propose two signing features using these Application Identities: one will be signing any data through a Drag and Drop and another one will be to sign screenshot of webpages.
4 (extra feature) - We will implement the DID standard (create and fetch identities on chain) available at the end of this grant within our extension. For this part only, we will not stick to the initial schedule presented above as this concerns extra work and in order to be able to use the last DID standard available. Moreover, it will enable us to potentially collaborate with another ANO for this part.

Last but not least, due to the competitive nature of this grant round and due to the recent upward trend observed on the market, we take the risk to internalize some costs by reducing this grant from 2500 FCT to 2200FCT. We strongly think this kind of tool will easily be leveraged on the marketing side by promoting the easy use of the Factom Blockchain combined with the Nano S Ledger.