Futur Protocol

[morgueye4]

Futur & Fusion Protocol

Futur Protocol is at the forefront of reshaping the app store landscape. It introduces a decentralized app store, providing a platform that empowers developers and fosters community-driven innovation. This protocol, running on the Relai Network, is dedicated to transparency, security, and community engagement. As we focus on building a robust FuturStore, our aim is to transform the digital platform by offering a decentralized app store that prioritizes user autonomy and developer empowerment.

Grant level

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

Application Checklist

• The application template has been copied and aptly renamed (project_name.md).
• I have read the application guidelines.
• Payment details have been provided (bank details via email or Polkadot (USDC & USDT) address in the application).
• I am aware that, in order to receive a grant, I (and the entity I represent) have to successfully complete a KYC/KYB check.
• 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 (see the announcement guidelines).
• I prefer the discussion of this application to take place in a private Element/Matrix channel. My username is: @_______:matrix.org (change the homeserver if you use a different one)

[github-actions]

CLA Assistant Lite bot All contributors have signed the CLA ✍️ ✅

[morgueye4]

I have read and hereby sign the Contributor License Agreement.

[keeganquigley]

Thanks for the application @morgueye4 I have some initial comments:

• We don't support payments on ETH mainnet anymore, could you please change to one of these options?
• As much as I agree regarding the concentration of power and anti-competitiveness within big tech app stores, they have a massive userbase, brand recognition, and lots of control. How would you plan to effectively compete with them, or otherwise overcome the barriers to user adoption?
• Apple is notorious for removing apps with no notice, especially dApps with a revenue model, since they can't make 30% off of transaction fees. But in my mind, they still have a harder time shutting down apps individually than axing one dApp marketplace. In fact, big players such as Coinbase Wallet and MetaMask have already struggled in their own attempts to publish dApp stores in the US. What makes this approach better than releasing decentralized apps directly into the iOS App Store or Google Play Store?
• I admire the desire to work directly at the OEM level but again, I don't see Apple playing ball here. Or were you planning to only focus on the Android market?
• In my opinion, trying to create both a decentralized app store and a privacy protocol at the same time seems like a bold endeavor. Personally I think it might make more sense to focus on building a solid PoC with one or the other.

[morgueye4]

@keeganquigley Thank for the constructive feedback and intersting questions.

We don't support payments on ETH mainnet anymore, could you please change to one of these options?

Sure I have updated the address.

As much as I agree regarding the concentration of power and anti-competitiveness within big tech app stores, they have a massive userbase, brand recognition, and lots of control. How would you plan to effectively compete with them, or otherwise overcome the barriers to user adoption?

The strategy to compete with established app stores like Apple's App Store and Google's Play Store is multifaceted, leveraging various opportunities and addressing emerging challenges.

Regulatory Opportunities:

With the recent US antitrust case against Apple's App Store exclusivity, and the mandate for Apple to allow third-party app stores and sideloading, FuturStore will be well-positioned to capitalize on this shift. This regulatory change not only opens up opportunities in the US but also aligns with the trend in Europe, where Apple is expected to comply by April 2024.

Android's Open Ecosystem:

Leveraging Android's existing openness to third-party app stores, FuturStore will capitalize on the platform's flexibility. This approach is particularly attractive to users seeking alternatives and more control over their app choices.

Privacy and Security Focus:

Recognizing the growing concerns around privacy and security, especially with recent incidents of government snooping and backdoors in devices, FuturStore aims to address these issues head-on.

By partnering with OEMs and promoting privacy-focused operating systems like GrapheneOS, we aim to provide users with a more secure and private app experience.

US governments snooping on users via app alerts, check push notifications of users

They Found The iPhone Backdoor

Ads Targeted on What You Say? New Evidence

Decentralized Compute and Storage:

One of the pillars of the project involves implementing a decentralized compute and storage layer. This not only enhances user privacy but also disrupts the data collection practices of major platforms. Users and developers will have the choice to share or sell their data in sovereign data markets like Ocean Protocol, providing a more transparent and user-centric data economy.

Blockchain Technology and AI:

The entire strategy is made possible by leveraging blockchain technology, privacy-preserving technologies, and emerging AI capabilities. These technologies play a crucial role in ensuring the security, privacy, and innovation that FuturStore aims to provide.

Web3 User Experience:

The project emphasizes enhancing the web3 user experience on devices, offering features that go beyond traditional app stores. This focus on innovation and user-friendly web3 interactions sets FuturStore apart from conventional app stores.

Inspiration from Successful Models:

Taking inspiration from successful subscription-based models like Setapp (Setapp provides a subscription-based service that offers users access to a curated collection of apps for macOS and iOS devices), FuturStore aims to offer features like curated collection of apps. Setapp provides a subscription-based service that offers users access to a curated collection of apps for macOS and iOS devices. FuturStore envisions a similar multi-platform solution, providing users with a package of apps and or games.

In summary, the approach is threefold: FuturStore as a decentralized app store, privacy-focused devices through partnerships with OEMs, and a decentralized compute and storage layer. The changing regulatory landscape, especially Apple's policy shift, further reinforces the potential success of FuturStore in the evolving app store landscape

Apple is notorious for removing apps with no notice, especially dApps with a revenue model, since they can't make 30% off of transaction fees. But in my mind, they still have a harder time shutting down apps individually than axing one dApp marketplace. In fact, big players such as Coinbase Wallet and MetaMask have already struggled in their own attempts to publish dApp stores in the US. What makes this approach better than releasing decentralized apps directly into the iOS App Store or Google Play Store?

As mentioned above, the evolving regulatory landscape in US and Europe offers a unique opportunity and since third party app stores will be allowed by apple .

I admire the desire to work directly at the OEM level but again, I don't see Apple playing ball here. Or were you planning to only focus on the Android market?

Indeed, the primary focus of FuturStore is indeed on the Android market
especially the growing niche of Privacy concious users and web3 users on mobile.

In my opinion, trying to create both a decentralized app store and a privacy protocol at the same time seems like a bold endeavor. Personally I think it might make more sense to focus on building a solid PoC with one or the other.

I appreciate your insight, and you raise a valid point. I have updated the document to focus more on the Futur Protocol PoC at this stage

[keeganquigley]

Thanks @morgueye4 for making the changes. I will mark the application as ready for review and ping the rest of the committee.

[morgueye4]

Great. Thank you @keeganquigley for the feedback.

[takahser]

@morgueye4 I have a couple of questions as well:

• You're mentioning the relai network in your proposal. Can you clarify if this is still the same project as the grant you previously applied for? Also, What's the relation between FuturFusion and Relai Network as well as both products' development stages?
• Also, are you going to support both iOS and Android apps with your solution?
• What's the purpose of the ReviewApp extrinsic? How will it work and who will have the permission to call it?
• Could you add wireframes for the UI-based (e.g. Futur Console) deliverables?

[takahser]

@morgueye4 thanks for your helpful replies!

I think the timing is good for a solution like this. However, I wonder if you could add some more technical details, for example:

• where will the apps be stored?
• are you confident on whether all the extrinsics you're planning make sense? for example:
  • calling the DownloadApp extrinsic every time a user wants to download an app seems excessive to me; can't this be done off-chain instead?
  • is there any mechanism to prevent malicious apps from being published? afaik for apple and google usually a manual review would be conducted
  • is there any mechanism to flag malicious apps, once they're already published?
  • what's the incentive for a user to call the reviewApp extrinsic, since (I assume) they'd have to pay a fee?

[morgueye4]

Welcome @takahser thank you for the feedback and questions.

where will the apps be stored?

In the initial phase, the apps will be stored in a centralized manner, utilizing either Firebase or a self-hosted version of Supabase or SurrealDB. As we progress to subsequent iterations, we plan to incorporate decentralized storage solutions such as IPFS (with a pinning layer for long-term persistence) and possibly Filecoin. This gradual decentralization will continue until the network establishes its own compute and storage layer.

are you confident on whether all the extrinsics you're planning make sense? for example:
calling the DownloadApp extrinsic every time a user wants to download an app seems excessive to me; can't this be done off-chain instead?

The process operates such that, for a paid app, the DownloadApp extrinsic is invoked the first time a user downloads it, ensuring the developer receives the corresponding amount into it's developer account.

If a user has previously purchased and downloaded the app, subsequent downloads proceed seamlessly without the need for the extrinsic. However, we perform on-chain state queries to validate the user's prior purchase. As the system evolves, these checks may transition to more scalable solutions, potentially leveraging indexers and similar tools.

For free apps, users can simply download the app without any additional steps.

is there any mechanism to prevent malicious apps from being published? afaik for apple and google usually a manual review would be conducted
is there any mechanism to flag malicious apps, once they're already published?

Indeed, there is one mentioned in the application – the SAST/DAST (Static Application Security Testing/Dynamic Application Security Testing) module mentioned in the application.

Upon submission by the developer, an app does not undergo direct publication, instead, checks are conducted beforehand.

The SAST/DAST Module serves as a Static and Dynamic Analysis component, scanning submitted APKs for security checks. Initially, it interfaces with MobSF: Mobile Security Framework Web API.

In subsequent stages, we have plans to establish an incentivized marketplace for AI models that contribute to governance, security, and other aspects of protocol development. Manual reviews will also be conducted, and the integration of Web3 technology is fortunate, as it aids in this direction with a robust incentivized ecosystem.

what's the incentive for a user to call the reviewApp extrinsic, since (I assume) they'd have to pay a fee?

The rationale behind using an extrinsic for reviewing is to guarantee the authenticity of the review.
We aim to ensure that the feedback comes from users who have already downloaded the app, and we believe such information can be securely stored on-chain.
Initially, we are considering making the reviewApp extrinsic unpaid or very very cheap but user can review a very limited number of time (2 or 3 reviews or review update per app release for example).
Also It's important to note that the review model will evolve in alignment with the Futur Protocol.

[takahser]

@morgueye4 thanks for the follow-up comment.

As we progress to subsequent iterations, we plan to incorporate decentralized storage solutions such as IPFS (with a pinning layer for long-term persistence) and possibly Filecoin.

I suggest also looking into Crust - they leverage IPFS and they have a parachain, so it might be easier to interact with them when compared to Filecoin for solutions built using the Polkadot SDK.

Initially, we are considering making the reviewApp extrinsic unpaid or very very cheap but user can review a very limited number of time (2 or 3 reviews or review update per app release for example).

If they have to pay a fee (even a tiny one), the question becomes, where will they get the tokens from? I doubt that the average smartphone user would want to purchase a token just in order to review an app. Also, if you make it free, the question becomes if the user will authenticate themselves or if there's another mechanism that avoids sybil attacks.

In general I'd suggest to add a description to each extrinsic, since it's not completely clear right now which extrinsic is called under what circumstances. That includes the extrinsics already discussed in this convo.

[morgueye4]

@takahser welcome and thanks for the suggestions.

I suggest also looking into Crust - they leverage IPFS and they have a parachain, so it might be easier to interact with them when compared to Filecoin for solutions built using the Polkadot SDK.

I've explored Crust, and it appears quite interesting. I'm contemplating its use alongside IPFS, given their seamless integration and the pinning feature they offer. Additionally, Crust presents Crosschain Storage Solution, feature which becomes particularly relevant when Relai Network transitions to a parachain.

If they have to pay a fee (even a tiny one), the question becomes, where will they get the tokens from? I doubt that the average smartphone user would want to purchase a token just in order to review an app. Also, if you make it free, the question becomes if the user will authenticate themselves or if there's another mechanism that avoids sybil attacks.

The workflow for reviews is revised and involves off-chain signing. Users compose and sign their reviews using their private key within the mobile app. The signed review is then sent to the backend, where off-chain workers communicate with it. They assess pending reviews, conduct checks, and proceed to validate them, eventually including the valid ones on-chain.

In general I'd suggest to add a description to each extrinsic, since it's not completely clear right now which extrinsic is called under what circumstances. That includes the extrinsics already discussed in this convo.

I've also included descriptions for extrinsics in the application and at the same time DownloadApp is renamed to BuyApp for more clarity

[takahser]

@morgueye4 thanks for the updates.

The workflow for reviews is revised and involves off-chain signing. Users compose and sign their reviews using their private key within the mobile app. The signed review is then sent to the backend, where off-chain workers communicate with it. They assess pending reviews, conduct checks, and proceed to validate them, eventually including the valid ones on-chain.

That sounds better. However, I don't see any mechanism that would prevent sybil-attacks. Will the runtime check whether the signing user has actually downloaded the app before allowing a review?

Although I'm still not 100% convinced of the project, I do appreciate the work you've put into it, acknowledge that it's been already greatly improved from the first version and I also think the timing of this idea is good, so I'm willing to give it a chance.

[morgueye4]

@morgueye4 thanks for the updates.

That sounds better. However, I don't see any mechanism that would prevent sybil-attacks. Will the runtime check whether the signing user has actually downloaded the app before allowing a review?

Although I'm still not 100% convinced of the project, I do appreciate the work you've put into it, acknowledge that it's been already greatly improved from the first version and I also think the timing of this idea is good, so I'm willing to give it a chance.

Thank you. @takahser for the feedback and for giving a chance.

Will the runtime check whether the signing user has actually downloaded the app before allowing a review?

Indeed, downloads will be tracked and there will be check for reviews only users who downloaded apps or games will be able to review

[morgueye4]

Hi @takahser I have added some more details for the review process.

To ensure a secure and reliable identification system for users, we're employing a combination of the user's wallet address and the device UID collected during app usage. This method establishes a robust identifier even in cases where users change their wallet addresses.

Following that, on the backend, we will add validation measures to ensure the uniqueness of the combined wallet address and device UID, along with any other necessary criteria, including potential limitations on the number of reviews or similar mechanisms. Combining Device UID with other metadata is sometimes adopted practice for scenarios like this.

While this approach aids in mitigating the risk of Sybil attacks during the early stages this mechanism will be refined and enhanced as the project progresses.

Here are some high level diagrams :

review process

book upload

book purchase

@takahser , @keeganquigley , @semuelle,

I have also started working on a dedicated book reader app Kaggu that will allow user to read e-books purchased in the app store and it will also be added to the deliverables. Similar project exist in the Cardano ecosystem Book.io

It is planned also to include, like in some stores, music and movies, so creators will also be able to sell on Futur store.

So in a Nutshell Futur protocol will have marketplace feature for :

• Apps and Games
• Books (E-books and Audiobooks)
• Movies and Music

Here is a diagram for better overview of the Futur Protocol and the ecosystem it will serve:

• Traditional Android and iOS devices
• Devices issued through the Fusion Protocol will embed and adapted version of the Futur store
  • Smart phones
  • Smart TVs (LineageOS TV, Android TV,..)
  • Smart watches (leveraging Asteroid OS,...)
  • E-Readers

As a reminder the Fusion Protocol to come after the Futur Protocol, will be an incentivized partnership with OEMs akin to what Solana is doing with Solana Mobile with it's partnership with OSOM.

[Noc2]

I'm happy to go ahead with it as well.

[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! 🚀

[semuelle]

Hey @morgueye4. Could you fill out the KYB form (assuming you are applying as a company, otherwise please use this form)? It's a requirement for any grant.
Thanks! Let me know if you have any questions or issues.

[morgueye4]

I'm happy to go ahead with it as well.

Thank you @Noc2 and the team as well.

[morgueye4]

Hey @morgueye4. Could you fill out the KYB form (assuming you are applying as a company, otherwise please use this form)? It's a requirement for any grant. Thanks! Let me know if you have any questions or issues.

Sure @semuelle I just filled the request via the second link since the team formation is ongoing and the entity setup and location will be changed once the team is fully established

[semuelle]

Thanks, @morgueye4. Could you share the link with all other beneficiaries? If there is no entity, we have to KYC everyone who benefits from the grant.

[morgueye4]

Thanks, @morgueye4. Could you share the link with all other beneficiaries? If there is no entity, we have to KYC everyone who benefits from the grant.

Welcome ! Sounds good @semuelle I will share the link with the other team member.

[keeganquigley]

Thanks @morgueye4 good to go, much appreciated.

[morgueye4]

Thanks @morgueye4 good to go, much appreciated.

You are welcome @keeganquigley !