Create Whiteflag-on-Fennel.md

[Romulus10]

Project Abstract

This grant application follows up on our Fennel Protocol grant, which was accepted in PR 748. Our work provides the Polkadot ecosystem with the tools necessary to build Whiteflag Protocol-based Substrate technologies that could protect civilian lives in conflict and ensure all actors are accountable to International Humanitarian Law (IHL). We are motivated to continue our long-term commitment to researching and developing Fennel Protocol--a Substrate chain built for the unique needs of Whiteflag Protocol's messaging specfication. We are grateful for the Web 3 Foundation's support, which allows us to innovate a timely, impactful, and humanitarian Substrate-based technology that leverages Web 3.0 to bring about a more peaceful future.

For which grant level are you applying?

• Level 1: Up to $10,000, 2 approvals
• Level 2: Up to $50,000, 3 approvals
• Level 3: Unlimited, 5 approvals (for > $100k Web3 Foundation Council approval)

Application Checklist

• The application template has been copied, renamed ( project_name.md) and updated.
• A BTC or Ethereum (DAI/USDT) address for the payment of the milestones is provided inside the application.
• I have read and acknowledged the terms and conditions.
• The software delivered for this grant will be released under an open-source license specified in the application.
• The initial PR contains only one commit (squash and force-push if needed).
• The grant will only be announced once the first milestone has been accepted.

[semuelle]

Hi @Romulus10, thank you for the application. Could you share a status report on M3 of your previous grant? We don't usually allow concurrent grants, so we will probably have to put this on hold until the previous grant is concluded.

[Romulus10]

Hi @Romulus10, thank you for the application. Could you share a status report on M3 of your previous grant? We don't usually allow concurrent grants, so we will probably have to put this on hold until the previous grant is concluded.

Hi @semuelle - absolutely. We had a feeling that would be the case but wanted to make sure we were ready to go for the next grant.
Our current third milestone consists of five deliverables. Deliverables 1 (peer retrieval), 2 (Encrypted Channels for IP Information), and 3 (General-Purpose Signal Generation) are all finalized with only some documentation and some final testing left to go. The two Whiteflag deliverables that lead us directly in to this grant are about halfway there, and we're running some final quality improvements to the existing features that'll tie in with the deliverables presented during this milestone.

[semuelle]

Thanks for the update, @Romulus10. Given the size of the grant, could you expand the specification of the deliverables a bit? It would help with the review to see where the time/money is spent, for example to see at a glance what it means for the system to be "updated for the full range of features" (which features have been implemented? Which still remain?).

In any case, I will put this application on hold for now. Can you please ping me here when your last milestone is accepted, just to make sure I don't forget to continue the review?

[Noc2]

Thanks for the application. I took a very quick look at it. My initial questions would be, why does the second milestone cost 65k (instead of 50k) for FTE 2 and 2 month and the first milestone 25 k for FTE 2 and 1 month?

[Romulus10]

Thanks for your comment @Noc2 - for further context, I'll direct you to my colleague @isaacadams, who began our work on the Whiteflag protocol and can comment here to provide some more serious detail on the increase. The 2 FTE marking for the second milestone was in error and should be 3 FTE, thank you for pointing that out.

[isaacadams]

Thank you @Noc2 for your comment. This is a great opportunity to also address the commont from @semuelle as I dive a bit deeper into what we have planned for this next phase.

M1 is a web dev job. Everyone on our team has experience to varying depths with full stack web development. We consider this work, although still challenging, the cheaper milestone. The web and mobile apps will always need attention (bugfixes, features, devops, etc.). What we will do in M1 is a very basic MVP.

M2 is a more expensive job. It requires whiteflag knowledge, rust and java knowledge, and experience with substrate to integrate the tools into the fennel protocol. We consider this a more expensive job and are giving ourselves more time to do it well. See more details below concerning M2.

• The primary codebase is rust. rust experience is expensive as it is both uncommon and has a steep learning curve.
• porting the whiteflag code involves both java and rust experience and whiteflag domain knowledge.
• I see potentially 3-4 stages of the java codebase port. I did the first stage in M3 of the first grant.
  • stage 2. planning, design consideration (rustify, consider error handling, use cases, validation), and refactor existing ported code and complete the port
  • stage 3. add encryption functionality to whiteflag messages by integrating our existing tools into the ported whiteflag code
  • stage 4. fully integrate into fennel blockchain and fennel applications
• in order to accomplish all of this, especially the last part which is integration, the developer(s) need experience with rust, java, blockchain (substrate), whiteflag, and full stack web development

[Noc2]

I’m generally happy to support it. But I think as I pointed out before, the treasury and community should at some stage also be involved. Additionally it would be nice to see some real traction/interest in the project (news article etc.).

[CorruptedAesthetic]

Thank you for your review David. We have met with a few treasury council members regarding this project and are awaiting further details on some common good parachain options. Behind the scenes, we are working with our partners with a few interested stakeholders. This next grant installment provides our technical team with the needed resources to proceed with critical engineering work important for our stakeholders. @semuelle Thank you for your review.

[semuelle]

Thanks again for the application. I also have a few more questions/requests.

• Can you expand a bit on what IPFS adds to the project and how it integrates into the architecture (e.g., do I need to run my own IPFS node to use it?)? Adding a key to IPFS or to the pallet are both one step each, so I don't understand how that improves the process.
• Can you share a bit more about what your established userbase looks like and what kind of outreach you are doing? I think the project is technically sound, the bigger question mark for me is how you convince people to trust your system and to start using Substrate.
• Given the price, I would like to see a user-oriented article, ideally including a step-by-step guide to using it. I'm sure that's something that might also be of use to you as well, if you don't already have something like that. The articles/documentation currently seem to mainly talk about the underlying protocol and its design.

[Romulus10]

Thank you @semuelle - I just made a couple adjustments RE: IPFS, which should give a bit more information on that front. In terms of your third question, we've been doing some audience/userbase-focused work and plan to have exactly that kind of user-facing documentation up and running fairly shortly.
We're working on putting some documentation together more fully addressing your second question, so you'll hear back on that one soon.
Thanks again!

[takahser]

@Romulus10 thanks for your grant application. I studied it and have some questions:

i) Do you have any wireframes for your webapp that you're planning to deliver as part of M1?

ii) I'd like to learn more about how arbitrary files stored on IPFS will be recorded on-chain. Are you going to reuse one of the pallets to integrate ipfs uris, similar as with NFT standards and meta information?

Quote:

The CLI and web-based frontend will be adjusted to support committing these large objects to IPFS and anchoring their location to a transaction on-chain.

iii) You mentioned the java implementation of whiteflag. Since the v1 has been released roughly 1 year ago, I'm curious to learn how the perception of the community is, so far. Who is already using it? Also, I'm curious to learn if the two implementations (substrate & java) would co-exist in the future or if you're even planning to deprecate the java implementation. Note: I'm not suggesting to do or not do any of that, I'm just trying to understand how you see the future of whiteflag.(:

EDIT 1:

iv) Overall, I think it's a quite solid project. However, the price seems a bit high to me for what you're planning to deliver. Would you consider lowering the price?

[CorruptedAesthetic]

In response to your questions related to traction and community building.

@semuelle, you asked, "Can you share a bit more about what your established userbase looks like and what kind of outreach you are doing? I think the project is technically sound, the bigger question mark for me is how you convince people to trust your system and to start using Substrate."

@takahser, you asked, "since the v1 has been released roughly 1 year ago, I'm curious to learn how the perception of the community is, so far. Who is already using it?"

This grant proposal is driven by humanitarian principles, aimed at serving vulnerable people in conflict and disaster areas. We will measure our traction by the kind of impact we can bring to these vulnerable people in need of resilient and accessible deconfliction mechanisms. Fennel Protocol provides such mechanisms in the form of Whiteflag-based communications, which ensures communications have unambiguous meaning, relevance, and reliability.

As highlighted in our first grant (which can be found here #748), we are working closely with the Whiteflag Foundation on furthering the adoption of Whiteflag Protocol. We are following the TRL guidelines and are currently focusing on launching a pilot, which we plan on designing and planning upon entry to the Substrate Builders Program in 3 months. We are following the TRL criteria in evaluating our progression; to this date, the Whiteflag Protocol is at TRL 5. The pilot will move Whiteflag Protocol to TRL 6 or TRL 7. You can find more information about the TRL evaluation scheme here: https://en.wikipedia.org/wiki/Technology_readiness_level. It is through systematic and precise progression along the TRL framework that we can increase the trust in our Substrate-based technological innovations.

Our team has been in contact with Amit from the Substrate Builders Program. This second grant is critical for the successful transition of this initiative into the Substrate Builders Program and the planning of our pilot; this grant funding helps us successfully bring this humanitarian effort to fruition.

In terms of traction and community engagement,

-We have signed Letters of Intent (LOIs) with the Whiteflag Foundation and Team fEMR. The Fennel Labs team is currently planning a pilot with Team fEMR. To maximize our impact with the funding we have been given, we have dedicated our organization’s resources to developing strong enterprise relationships that will allow our initiative to confidently grow for years to come. This second grant empowers us to continue working with our enterprise partners.

-We are working with a story telling firm to kick start a community engagement initiative at the start of our entry to the Substrate Builders Program in 3 months. This second grant allows us to reach this point, as well.

-In terms of the perception of the community, I will direct you to the comments made by Timo, who is a volunteer researcher for the Whiteflag Foundation #748

I hope this response answers some of your questions. My teammates plan on offering further responses to your other questions. Please do not hesitate to ask any further questions.

Thank you again for your support of this important initiative

[Romulus10]

@Romulus10 thanks for your grant application. I studied it and have some questions:

i) Do you have any wireframes for your webapp that you're planning to deliver as part of M1?

ii) I'd like to learn more about how arbitrary files stored on IPFS will be recorded on-chain. Are you going to reuse one of the pallets to integrate ipfs uris, similar as with NFT standards and meta information?

Quote:

The CLI and web-based frontend will be adjusted to support committing these large objects to IPFS and anchoring their location to a transaction on-chain.

iii) You mentioned the java implementation of whiteflag. Since the v1 has been released roughly 1 year ago, I'm curious to learn how the perception of the community is, so far. Who is already using it? Also, I'm curious to learn if the two implementations (substrate & java) would co-exist in the future or if you're even planning to deprecate the java implementation. Note: I'm not suggesting to do or not do any of that, I'm just trying to understand how you see the future of whiteflag.(:

EDIT 1:

iv) Overall, I think it's a quite solid project. However, the price seems a bit high to me for what you're planning to deliver. Would you consider lowering the price?

Thanks for your comment @takahser. I'll answer each development point here:

1. Absolutely. We're currently in the process of planning out wireframing for that delivery.
2. That's our plan - if we can integrate support effectively we'd rather reinvent as few wheels as we can while making sure that what we create perfectly fits our use case.
3. The intention is for the existing implementation to co-exist with ours, and interoperate as appropriate.

[semuelle]

In terms of your third question, we've been doing some audience/userbase-focused work and plan to have exactly that kind of user-facing documentation up and running fairly shortly.

Could you add a deliverable covering that to your application? Just for us to make sure it'll see the light of day at some point.
Also, could you add a bit more detail about Deliverable 2.1? Given that it takes up "a large portion of the time" of a 65k milestone, I would like to have some more insight into what this includes. Perhaps you can visualize or list what has and hasn't been done wrt the Whiteflag protocol?

[Romulus10]

In terms of your third question, we've been doing some audience/userbase-focused work and plan to have exactly that kind of user-facing documentation up and running fairly shortly.
Could you add a deliverable covering that to your application? Just for us to make sure it'll see the light of day at some point.

Absolutely - in fact, I added this to the deliverables in commit 9f1b666.

Also, could you add a bit more detail about Deliverable 2.1? Given that it takes up "a large portion of the time" of a 65k milestone, I would like to have some more insight into what this includes. Perhaps you can visualize or list what has and hasn't been done wrt the Whiteflag protocol?

We've got this planned already, so we'll move it up a bit to include it in the application.

Thanks again.

[takahser]

@CorruptedAesthetic thanks for the replies. I have a couple of follow-up questions.

• i) quote:

  to this date, the Whiteflag Protocol is at TRL 5. The pilot will move Whiteflag Protocol to TRL 6 or TRL 7.

  Ok, so my current understanding is, that the existing Whiteflag implementation on Java is not being used in production, yet.
  Also, could you elaborate on how you came to the conclusion that Whiteflag is currently at TRL 5? According to your shared link w.r.t. TRL TRL 5 means, that the "Technology (was) validated in relevant environment". How was it validated in your case?

• ii) quote:

  The Fennel Labs team is currently planning a pilot with Team fEMR.

  I'm not familiar with fEMR, could you elaborate on it or share a link that explains it?

• iii) quote:

  We are working with a story telling firm to kick start a community engagement initiative (..)

  Just checking here, am I correct to assume that the funding required for hiring the storytelling firm is not part of the grant funds you're asking for here?

@Romulus10 thanks to you also for your replies. I have a couple of follow-up questions here as well.

• iv) Are you planning to deliver these wireframes anytime soon? Usually, we ask grantees to deliver them before we'd accept a grant application.

• v) Since you'll be able to reuse large parts of the existing NFT pallets, am I correct to assume this would lower the estimated efforts needed quite a bit? If that's the case, it'd be nice to see it reflected in the price as well.

• vi) quote:

  The intention is for the existing implementation to co-exist with ours, and interoperate as appropriate.

  Sounds good. How exactly would that work, especially when it comes to persistence? Will the data be synced across the different blockchain implementations (Substrate/BTC/ETH) and a centralized db? If yes, how would you assure the consistency of the data?

Finally, I still feel like the price is a bit high. I compared the price of this application with the previous one, where you charged 5k-7k per FTE per month. However, in the current grant application, you charge 12.5k (M1) and 10.8k (M2) per FTE per month, respectively. Feel free to elaborate on this or also to lower the price.

[isaacadams]

Also, could you add a bit more detail about Deliverable 2.1? Given that it takes up "a large portion of the time" of a 65k milestone, I would like to have some more insight into what this includes. Perhaps you can visualize or list what has and hasn't been done wrt the Whiteflag protocol?

@semuelle the work to be done for deliverable 2.1 is as follows:

• references from last grant
  • here is the code ported from the previous grant: whiteflag v1 fennelLabs/fennel-lib#23
  • also check the wiki for more information about the port wf-v1-wiki
• finish porting edge case codec logic (see ~1)
• port remaining unit tests (about 15 from WfBinaryBufferTest.java and virtually all tests from WfMessageTest.java)
• refactor for efficient message creation (see ~2)
• implement
  • efficient message validation (see ~3)
  • error handling
  • json serialization
  • accounts (see ~4)
  • fully support all authentication schemes (see ~5)
• integrate existing encryption into wf implementation

To wrap up the milestone, the whiteflag code as it exists in rust have an encode/decode api which will be exposed through a rest api for a web app demo where unauthenticated users can play around with the whiteflag protocol messaging system.

1. Every message in whiteflag has a single character code (see MessageType.from_code() in types.rs). The message codes Q and T (request signal and test, respectively) require special edge case decoding logic (see the comment @ creator.rs)
2. Currently, the message header and body fields are created by calling their associated functions (see types.rs and definitions.rs). The array of fields for each definition should be treated as constants or static since they never change and are only ever read. Currently, they are currently methods which return new owned memory.
3. In the java implementation, strings are being validated throughout through the use of regular expressions.

• The regular expression patterns in the java implementation contained pattern symbols that rust does not support. Therefore, the implementation for validation was put on hold for the last grant. Those patterns will need to be reworked to ensure v1 consistency and compatibility with rust.
• As we approach validation for this coming grant, we want to implement it in a more efficient manner, making sure that Regex::new() is only ever called once per unique pattern.
• Furthermore, we want the implementation to be rusty, instead of following the object-oriented approach used in the java implementation.

4. An account is the equivalent of a user's on-chain wallet/address for whatever blockchain whiteflag is actively deployed. Part of implementing whiteflag on a blockchain is tying the concept of an account, as whiteflag sees it, and integrating that with the actual account/address that exists on the blockchain on which whiteflag is going to be deployed. The fennel protocol will be using its various pallets, namely identity and keystore, to define and provide functionality to an account for the whiteflag implementation.

5. The whiteflag protocol specifies two authentication schemes: internet resource and shared token (see 4.3.4.2 wf-protocol). These two schemes require the account implementation described in ~4, then logic which validates the authentication scheme for an account, and unit testing. Examples of these two schemes will be created for the purpose of a demo playground.

[Romulus10]

Hi @takahser - I'll answer some of those questions, looks like Isaac beat me to some of the Whiteflag-specific ones, then my colleagues have a couple more answers we've been working on.

* iv) Are you planning to deliver these wireframes anytime soon? Usually, we ask grantees to deliver them before we'd accept a grant application.

Absolutely. We're actively working on them this week, the plan is to have them available for use when we start the development process officially, so we'll have them deliverable ahead of time.

* v) Since you'll be able to reuse large parts of the existing NFT pallets, am I correct to assume this would lower the estimated efforts needed quite a bit? If that's the case, it'd be nice to see it reflected in the price as well.

We will be reusing parts of the existing NFT pallets, certainly, but they'll still need integration across our entire software distribution, as the actual delivery from our first grant expands into the chain-parallel as well as the strictly on-chain. We'll also need to make adjustments and expansions to our existing work to support appropriate use of IPFS beyond what current NFT standards strictly require.
I also want to be abundantly clear that the functionality provided by the IPFS mechanisms in Fennel Protocol will not be a reimplementation of existing NFT standards.

* vi) quote:
  > The intention is for the existing implementation to co-exist with ours, and interoperate as appropriate.
  
  Sounds good. How exactly would that work, especially when it comes to persistence? Will the data be synced across the different blockchain implementations (Substrate/BTC/ETH) and a centralized db? If yes, how would you assure the [consistency](https://en.wikipedia.org/wiki/Consistency_model) of the data?

Excellent question here - we're working on an evolving model for this involving mirrored transactions, but it's early in development. Currently, the standing implementations are seen as somewhat separate from our implementation due to the stakeholders involved, the implementation process, etc. As the Whiteflag 'system' continues to grow however we do see the Substrate implementation, due to the general focus on interoperability, as a sort of hub for the rest of parallel Whiteflag contexts. Because Whiteflag's biggest benefits arise from the fact that everything is done fully on-chain, we're not currently considering a centralized database model.

[CorruptedAesthetic]

@takahser Thank you for your questions.

We believe our initiative is well suited for the Web 3 Foundation’s non-profit mission. The Web 3 Foundation states, “Our mission is to nurture cutting-edge applications for decentralized web software protocols. Our passion is delivering Web 3.0, a decentralized and fair internet where users control their own data, identity and destiny.”

The non-profits Team fEMR and Whiteflag Foundation have missions that fit well with the Web 3 Foundation’s mission.

Fennel Labs is deeply committed to supporting the missions of the Web 3 Foundation, Team fEMR, and Whiteflag Foundation. Together, we believe these missions can forge the foundation of a strong, vibrant, and sustainable Substrate Web 3.0 technology ecosystem; consequently, we believe our success brings success to the Polkadot and Kusama networks. Our partners and our team are grateful for the Web 3 Foundation's support of this initiative, which is rooted in humanitarian spirit and principles.

The mission and vision of the Whiteflag Foundation:
“It is the Whiteflag Foundation’s mission to maintain, promote and support the Whiteflag Protocol that allows parties involved in conflicts and disasters to globally and securely communicate using free, decentralized and open source technology.”
“It is envisioned that the Whiteflag Foundation is a neutral organisation that provides adoption of the Whiteflag Protocol in being a worldwide communication standard within conflicts and disasters.”

The mission and vision of Team fEMR:
“We created a fast, open-source Electronic Medical Records system for transient medical teams in order to promote data driven communication in low resource settings.”
“To analyze and improve healthcare for nontraditional clinical settings worldwide using data collected by the fEMR system.”
In terms of your questions:

In terms of I,

I would like to underline the importance of discretion in our work; we work in small, systematic (albeit, sometimes understated) increments to ensure minimal risk in our adoption efforts of this technology. The researchers and scientists at the Whiteflag Foundation have carried out simulation testing of Whiteflag Protocol; due to this simulation testing, Whiteflag Protocol is at TRL 5. This was confirmed by Timo Schless, who is a researcher involved with the Whiteflag Foundation. For verification of my claim, please review the initial grant’s comments, which can be found here: #748. For your convenience, I have copied and pasted some (but not all) of the relevant comments by Timo:

Timo states,

“The protocol is a co-creation of the Royal Netherlands Air Force and Capgemini, and has been released into the public domain. Because maintaining, promoting and supporting the protocol is not the core business of both these organisations, the Whiteflag Foundation has been established for that purpose. Given the very specific context of Whiteflag (armed conflicts) most interaction is conducted directly with humanitarian and (non-)governmental organisations. For your information, there are some public references to Whiteflag available:

• mentioned in an interview with Deputy Chief of Defence of The Netherlands
• a session with UNESCO's Core Innovation Team
• NYU Centre for International Cooperation - Data for Peace and Security Sprint Session 3 on Whiteflag
• HPG Commissioned Report on Blockchain and Distributed Ledger Technologies in the Humanitarian Sector

The protocol is currently considered to be at Technology Readiness Level (TRL) 5: it has been validated in a relevant environment through a validation test with a number of non-governmental and government organisations on Ethereum Rinkeby as the underlying blockchain. However, Whiteflag is a low level technology that requires further horizontal integration with other technologies (e.g. the Fennel Protocol, decentralized identity technologies, etc.) and vertical integration (in existing or new software end-user applications) to mature and demonstrate higher TRLs. To that end we are, among other things, developing a Java library, are preparing to create an end-user application for TRL 6/7 demonstration, and we will support Fennel Labs with their efforts.

Furthermore, it is important to understand that the context for which the protocol has been developed (conflicts and disasters) does not allow fast and large scale adoption into existing information systems, but requires a thorough approach. Therefore, current efforts focus primarily on conceptual work to understand technical and operational implications and risks, while expanding the ecosystem and establishing a scalable basis for further growth. Most of the current conceptual work is done behind the scenes with a number of other organisations. This recent article gives a good impression of the ongoing efforts: Developing a Trusted Human-AI Network for Humanitarian Benefit.”

In terms of ii,

Here are some details about Team fEMR:

• Team fEMR was founded in 2014; “fEMR” stands for “fast Electronic Medical Records.”
• Team fEMR specializes in providing high performance teams with mobile medical data infrastructure for use in disaster, refugee, and low-resource medical humanitarian contexts. Team fEMR accomplishes its mission with both mobile mesh network and cloud-based applications.
• Fennel Labs has been working with Team fEMR since 2019, supporting their team and affiliated researchers in the building of a Substrate-powered, decentralized Electronic Medical Records System (EMRS); this EMRS is called “fEMR on Chain.”
• Fennel Labs has been working with the Substrate framework since 2019, researching and developing the best way to work with sensitive and critical data with the Substrate framework in use cases as those involving Whiteflag Foundation and Team fEMR.
• I personally have used Team fEMR’s technology in the field between 2016-2018 in my leadership of medical missions to Central America. Due to Team fEMR’s technological innovations, I increased my treatment capacity and efficiency.
• Team fEMR has deployed its technology worldwide and continues to sit at the cutting edge of rapidly deployable, low-resource setting EMRS technology.
• Please review the following media coverage for further information:

1. https://www.whf.london/blog/grassroot-innovation-in-humanitarian-health-from-student-work-to-disaster-response-how-improved-data-collection-could-impact-austere-and-transient-clinical-environments-globally
2. https://aws.amazon.com/blogs/architecture/how-femr-delivers-cryptographically-secure-and-verifiable-emr-medical-data-with-amazon-qldb/
3. https://ceng.calpoly.edu/connection/2022/02/computer-science-software-engineering-students-help-nonprofit-provide-crucial-medical-record-system-to-areas-experiencing-a-crisis/

• Here is a link to their website and demo web application: https://www.teamfemr.org/

For your convenience, I have copied and pasted a fragment from their 2022 performance report,

“fEMR On Chain is a fully HIPAA compliant next generation secure global electronic medical record product where providers need quick secure access to patient data, medical supply, and analytics without the burden of cumbersome software and hardware. Such a tool in this day and age is essential in providing streamlined efficient high-quality patient care through real time data capture and analytics. Pioneering the way forward in decentralized data for electronic medical records in the global healthcare arena, fEMR On-Chain aims to improve delivery of care across the globe. While HIPAA compliance today is considered the standard in the US for patient data privacy, fEMR On Chain is poised to offer the future of healthcare and patient data security through this cutting-edge technology by eliminating vulnerable centralized data storage. In an age driven by smart technology, instantaneous access to information and artificial intelligence, fEMR will offer simplified, secure and intuitive technology to local urban grassroots healthcare initiatives, global healthcare providers, first responders, as well as refugee and disaster management teams. Utilizing AI algorithms, fEMR will be able to help provider teams with early recognition of supply chain needs, patterns of disease and improve interventions in the field. Built for analytics, fEMR will empower providers, organizations and companies with the ability to process and interpret data in a more efficient and meaningful way to bring timely and effective interventions to patients. fEMR today stands ready to meet the growing needs of local and global healthcare with tomorrow’s technology.”

In terms of iii,

You are correct. I am working on another funding source for the story telling firm. We are awaiting approval of this W3F grant; once we receive this approval, I will begin working on another (non W3F open grant) funding for the story telling firm. We plan on entering the Substrate Builders Program, kick starting a community building effort, as well as engaging with the KSM/DOT treasury.

In terms of iv, vi, and vi

My engineering colleagues have answered these questions above.

In terms of your last comment,

My colleagues have provided more details regarding the engineering work required to complete this grant. Their reasons aim to justify the funding request of $90,000.

Lastly, W3F’s original guidelines suggested the initial grant be $50,000. The price of our first grant reflects W3F’s original grant estimation guidelines.

I hope these answer your questions.

-Mateusz

[takahser]

@isaacadams @Romulus10 @CorruptedAesthetic thanks a lot for answering my questions in such detail. I now have a much clearer picture of what you're intending to create. 🙏

Currently, there are only 2 things that are holding me back from approving your application:

• i) as pointed out in my previous comment, for UI-focused grants we'd usually require wireframes to be delivered before approving a grant application. I was happy to learn that in your case their creation is already in process, so I'd be glad if you could share them with us as soon as you're done with them.

• ii) as pointed out in my previous comment as well, I don't understand why the pricing deviates from your first previous grant in terms of FTE per month.

  I compared the price of this application with the #748, where you charged 5k-7k per FTE per month. However, in the current grant application, you charge 12.5k (M1) and 10.8k (M2) per FTE per month, respectively.

  Is there any specific reason for this deviation? If I'm not mistaken, this question hasn't been answered yet, but feel free to correct me if I'm wrong. Also, feel free to update the FTE rates and the final price or, alternatively, to elaborate on the deviation.

[CorruptedAesthetic]

@takahser

Thank you for your reply. I will respond to ii. I did include this response in my previous reply but it was tucked away at the end of my reply. I will offer more details here.

There are two reasons why we chose a lower pricing for each FTE per month for the first grant;

1.) We wanted to maximally follow the Web 3 Foundation’s grant proposal guidelines and suggestions. At the time that we submitted our first grant, the Web 3 Foundation suggested that a team’s first grant should be $50,000.

2.) We wanted to ensure our research and development work maximally benefited the Substrate ecosystem. The first grant built the Substrate infrastructure that teams would need to deploy a minimum Whiteflag implementation. We structured the first grant in such a way that upon its completion, the Substrate ecosystem would receive the Substrate infrastructure needed deploy a minimum implementation of Whiteflag communications (Whiteflag specification 2.5) (https://standard.whiteflagprotocol.org/v1/).

Our team chose to pursue lower pricing for each FTE per month for the first grant because we wanted to respect the Web 3 Foundation's grant issuing norms ($50,000 for a team's first grant), while also producing a valuable contribution for the benefit of the Substrate community (minimum Whiteflag implementation). The Web 3 Foundation did not list any norms or suggestions for the second grant; the pricing for each FTE per month that you see in the second grant is reflective of the time and expertise the engineers will contribute to successfully complete the second grant proposal's stated goals.

@Romulus10 will handle i.

[takahser]

@CorruptedAesthetic okay, thanks. Feel free to ping me again, as soon as the wireframes are ready. 👍

[hakan-w3f]

I believe Whiteflag-on-Fennel could not have been more timely. Taking into account that the UI can and will change based on the implementation, I'm happy to give one approval to this grant application as is.

[CorruptedAesthetic]

Thank you for your support @semuelle and @hakan-w3f . We are finalizing the wireframes and will submit them to this application soon.

[Romulus10]

Thank you for your support @semuelle and @hakan-w3f . We are finalizing the wireframes and will submit them to this application soon.

Follow up to this comment - we've just finished revising the UI we'll be delivering in this grant application. We've attached the wireframes here as a PDF - each page is one view mockup.

[CorruptedAesthetic]

Thank you for your support @semuelle and @hakan-w3f . We are finalizing the wireframes and will submit them to this application soon.

Follow up to this comment - we've just finished revising the UI we'll be delivering in this grant application. We've attached the wireframes here as a PDF - each page is one view mockup.

@takahser

My engineering colleagues have finished and submitted their wireframes. Please see Sean's post for the link to the wireframes you requested.

[takahser]

@CorruptedAesthetic thanks for the ping and thanks for delivering the wireframes. I'm willing to go ahead with it as well.

[CorruptedAesthetic]

Thank you for your support @takahser

[github-actions]

Congratulations and welcome to the Web3 Foundation Grants Program! Please refer to our Milestone Delivery repository for instructions on how to submit milestones and invoices, our FAQ for frequently asked questions and the support section of our README for more ways to find answers to your questions.

Before you start, take a moment to read through our announcement guidelines for all communications related to the grant or make them known to the right person in your organisation. In particular, please don't announce the grant publicly before at least the first milestone of your project has been approved. At that point or shortly before, you can get in touch with us at [email protected] and we'll be happy to collaborate on an announcement about the work you’re doing.

Lastly, please remember to let us know in case you run into any delays or deviate from the deliverables in your application. You can either leave a comment here or directly request to amend your application via PR. We wish you luck with your project! 🚀

[CorruptedAesthetic]

To everyone who spent time and effort reviewing and commenting on our grant proposal: Thank You! We are thrilled to have this opportunity and to continue to develop an innovative and important project that we are all passionate about. Our engineering team has kick started its work and is on its way to completing its first milestone.