Application from the Parami Protocol

[DorianRust]

Grant Application Checklist

• The application-template.md has been copied, renamed ( "project_name.md") and updated.
• A BTC address for the payment of the milestones is provided inside the application.
• The software of the project will be released under the Apache license version 2.0 as specified in the terms and conditions.
• The total funding amount of the project is below CHF 30k at the time of submission.

[CLAassistant]

All committers have signed the CLA.

[Noc2]

Thanks for the application. It looks like an interesting and complex project. However, could you restructure the milestones differently and focus on concrete technical deliverables? For example if you implement a DID solution: is it implemented as a substrate pallet or ink smart contract, what are the exact functions of it, do you unit test it and how is it different from existing DID solutions. Also we usually don’t support things like running a Testnet or mainnet or the deployment as a parachain.

[DorianRust]

@Noc2 Thanks for the suggestions. I've updated the applicaton.

[Noc2]

Thanks for the update. This looks much better. I have a few follow-up questions:

• How is your DID solution different from other existing implementations, for example see the did pallet?
• How is your oracle module different from other existing implementations?
• What programming languages are you planning to use for the Web UI, Wallet App and Social Integration? In general, could you specify these parts a little bit more detailed. I think we would be interested in supporting the development of these features even if your DID or oracle solution isn’t unique.

[DorianRust]

@Noc2 Thanks for your advice.

The Parami DID will be a production-ready and domain-specific DID solution. We will add a referral system and embed users' ad preference into DID attributes. To optimize, the DID's storage will be split into an on-chain part and a distributed storage part(like IPFS).

The Oracle will be similar to existing implementations at first, focusing on asset prices. Later we will engage ad-specific validation into it, like an anti-spam check, visibility validation, and so on. For instance, we are considering introducing headless browser and computer vision to validate the display of ads.

We will mainly use typescript and Vue.js to implement the Web UI, and react is the alternative tech stack.

To enable the combination of Wallet App and social platforms, we will rely on the open platform functionality provided by social platforms, such as WeChat MiniProgram, Facebook APIs, and Telegram Bots. The Wallet App will be available on these platforms as applets or built upon the open APIs of these platforms.

[Noc2]

Thanks for the update. I’m willing to go ahead with it and I will share it with the rest of the team.

[BenWhiteJam]

@DorianRust thanks for the application, just wanna make sure you are aware of the RFC for a DID working group paritytech/substrate-open-working-groups#2 maybe that would be of interest to you?

[mmagician]

1. Your milestones describe the substrate part of the architecture, but what about integrating it with the Access and Background services, as shown in your diagram? Is this part already done?

2. It seems like eventually the project will require a centralised party to maintain the Message Queue and other components, correct? Who's responsible for running these services, is it your team?
   What's the business model there, i.e. how do you incentivise the participants to maintain such Access and Background services?

3. We will create a Substrate module that will act as the price oracle to provide real-world prices of different kinds of assets

What kind of assets are of interest to your project? The way you present your project, I don't necessarily see how oracles fit into the bigger picture of what you're trying to achieve.

4. Social Integration

The way that currently apps & websites show ads is by tapping into the ad manager's platform, by using some kind of an SDK. Are you planning to provide a generic solution (plug-and-play SDK?), or is the integration into WeChat going to be custom-built?

[DorianRust]

@mmagician Thank you for your attention, glad to answer you:

1. Your milestones describe the substrate part of the architecture, but what about integrating it with the Access and Background services, as shown in your diagram? Is this part already done?

=>They are not implemented yet. The details of implementation might change as the project progresses In fact they are blockchain infrastructure or kind of public-available services. They interact with Parami and are not part of Parami's services.

2. It seems like eventually the project will require a centralised party to maintain the Message Queue and other components, correct? Who's responsible for running these services, is it your team? What's the business model there, i.e. how do you incentivise the participants to maintain such Access and Background services?

=>Sorry for the misleading. These components will be a public-available service, not maintained by the Parami team. There is no incentive to do so. They are added to the architecture diagram to better reflect the integrity of Parami's design.

=>The Access service is a description of Parami users' and advertisers' interactions with Parami, such as users viewing ads on various social channels, withdrawing revenue, or advertisers posting ads and injecting money. It only provides the abstract access service, the business logic implementation is done in Substrate.

=>The Background service includes many components, but they are not maintained by the Parami team; IPFS is well-known decentralized storage, and Parami mainly interacts with Substrate offchain workers; Message Queue is an event subscription mechanism provided by Parami to the public, and developers or advertisers can subscribe to it through Message Queue. The Message Queue is the event subscription mechanism that Parami provides to the public so that developers or advertisers can be informed of the events on the chain through the Message Queue. RDS also means the same thing.

3. What kind of assets are of interest to your project? The way you present your project, I don't necessarily see how oracles fit into the bigger picture of what you're trying to achieve.

=>In fact, advertisers may be divided into two types: those with their own token and those without their own token. The former needs to use oracles to get the price of their own token (e.g. the exchange ratio between AAA and platform token PRM). For those advertisers who haven't issued any tokens, they will buy platform tokens through their own advertising budget but settle the standard in fiat currency. Furthermore, the price data from oracles is needed as calculation parameters when distributing advertising funds.

=>In addition, the Oracle will be also used to validate the display advertising on social platforms

4. The way that currently apps & websites show ads is by tapping into the ad manager's platform, by using some kind of an SDK. Are you planning to provide a generic solution (plug-and-play SDK?), or is the integration into WeChat going to be custom-built?

=>The future SDK will be mainly for IM platforms such as Wechat, Telegram, and Discord. We will try to provide a universal solution, but for now, it looks like the integration into each IM will be a little different.

[mmagician]

1. Could you clarify what you mean by public-available services? Someone still needs to run & maintain these.

2. We will create a Substrate module that will manage ads metadata, including traditional ads metadata and rewarding settings

Could you expand on this milestone please? What exactly is included in the ads metadata & reward settings?

3. I can't see very clearly how you advertisers would benefit from your solution. Normally, advertisers pay an ad manager for having their ads displayed, and the manager provides some statistics (# of impressions, interaction duration, clicks, etc.) based on which they charge the advertisers. For this purpose, the managers need to track the end-users' interactions - how is this achieved in your solution? I don't see any point in your milestones which mentions this.

4. Finally, how do users benefit & how are they onboarded onto the platform? Is DID creation a separate process? How is that DID linked to the app (WeChat or other)?

[DorianRust]

@mmagician Thank you for your reply, nice to answer you:

1.Could you clarify what you mean by public-available services? Someone still needs to run & maintain these.


=> For example, IPFS has many public-available gateways. They are maintained by community or some cloud service provider, like Cloud-flare.

2. We will create a Substrate module that will manage ads metadata, including traditional ads metadata and rewarding settings. Could you expand on this milestone please? What exactly is included in the ads metadata & reward settings?

=>Ads metadata might include topic, link URL, advertiser, placeholder text, ad period and so on. Reward settings will include profit sharing settings, and bonus rules, especially the total Ads fund, basic reward (may be affected by the native token users staked)and bonus according to the tag and rank score from all the former ad interactions.

3.I can't see very clearly how you advertisers would benefit from your solution. Normally, advertisers pay an ad manager for having their ads displayed, and the manager provides some statistics (# of impressions, interaction duration, clicks, etc.) based on which they charge the advertisers. For this purpose, the managers need to track the end-users' interactions - how is this achieved in your solution? I don't see any point in your milestones which mentions this.


=>The aspect we are focusing is ad in IM, which means the ad payment rule is different from the traditional one (Which you mention we call it AD 1.0). In the new scene, the media is not a website or an application, but a group or a channel. The group owner will share the potentially attractive AD to their group or channel. When the users click this AD link they will go to a landing page, which maybe a brief image introduction or a video with some interaction. We will provide the SDK here to track the users statistics and upload the necessary information upon to the chain.

The benefit is quite clear:

    a. The advertiser will be able to track all of his ad fund.

    b. The advertiser could make use of all the previous ad data to reward users(Here we will use zkp to keep privacy while distributing reasonable reward)

    c. User will get benefit and scores from all the advertisers, just like a crowd-sourced scoring. In this way the non-target user will get less after they get low score in particular aspect.

4. Finally, how do users benefit & how are they on-boarded onto the platform? Is DID creation a separate process? How is that DID linked to the app (WeChat or other)?


=> Users will create their DID in IM with a referred code. That means there will always be a friend to help you how to deal with the DID and you will share profit to the referrer whenever you get reward in the platform. Users can create their DID in IM explorer and link their Wechat ID (in Wechat it is an unionID while in others it is just account ID). After that users could update their DID admin key for security. If you create your DID out of the IM platform, you can linked your DID to the app by just scan a particular QRCode generated in the IM with wallet dapp.

[Noc2]

Just for your information @DorianRust: you need to resign the CLA, because we updated the terms recently.

[DorianRust]

@Noc2 Ok, thanks for your reminder

[mmagician]

1. The group owner will share the potentially attractive AD to their group or channel

So sharing an ad will be a conscious action? Does the group owner receive any reward for sharing the ad?

2. We will provide the SDK here to track the users statistics and upload the necessary information upon to the chain.

This doesn't seem to be part of your deliverables. Could you please integrate the SDK, and outline all its functionality? I imagine that creating the DID from the IM will also be handled by the SDK.

3. Regarding your previous comment:

The Access service is a description of Parami users' and advertisers' interactions with Parami, such as users viewing ads on various social channels, withdrawing revenue, or advertisers posting ads and injecting money. It only provides the abstract access service, the business logic implementation is done in Substrate.

I don't understand this. Which software/infrastructure components are going to play the role of Firewall, Auth etc. from these Access services?

4. So if I understand correctly, ads and ads metadata are stored separately? Am I right in thinking that the metadata is stored on-chain - and if so - why? On-chain storage is quite expensive , to quote from Substrate Developer Hub: [...] the fundamental principle of blockchain runtime storage is to minimize its use. I guess that some metadata needs to be stored under the runtime storage, but perhaps you might want to re-think including all the fields that you mentioned (topic, link URL, advertiser, placeholder text, ad period). Same for reward settings.

5. And then what is the format of the actual ad? Is it just an image? If I got your concept, this will be stored in IPFS, correct? What tool will you use to write data to IPFS, and will it happen directly from Substrate or from the SDK (i.e. the WeChat MiniProgram)?

[DorianRust]

@mmagician Thank you for your attention to our project, glad to answer you:

1. So sharing an ad will be a conscious action? Does the group owner receive any reward for sharing the ad?

=> Yes, of course. As a traffic owner, he may also be the DID referrer, that means any user will share profit with this referrer whenever he gets profit. Sharing an ad could be done consciously or a robot tool. They can build this profit sharing connection by constructing a new group or making use of the existing group.

2. This doesn't seem to be part of your deliverables. Could you please integrate the SDK, and outline all its functionality? I imagine that creating the DID from the IM will also be handled by the SDK.

=> The SDK will be two versions, one is for the users and the other is for the business. I guess maybe we will deliver the SDK for users firstly. The SDK will provide DID management like DID creation, DID update and DID read. If you are a traffic owner, the SDK will help you manage your community, like community registry and member management.

3. Regarding your previous comment: I don't understand this. Which software/infrastructure components are going to play the role of Firewall, Auth etc. from these Access services?


=>Sorry for misunderstanding, Firewall, Auth etc are not a service that the parami team needs to maintain.

4. So if I understand correctly, ads and ads metadata are stored separately? Am I right in thinking that the metadata is stored on-chain - and if so - why? On-chain storage is quite expensive , to quote from Substrate Developer Hub: [...] the fundamental principle of blockchain runtime storage is to minimize its use. I guess that some metadata needs to be stored under the runtime storage, but perhaps you might want to re-think including all the fields that you mentioned (topic, link URL, advertiser, placeholder text, ad period). Same for reward settings.


=> Yes, sorry for make you confused. The reward setting may store on chain for most of them are digit, others like link URL and placeholder text will be stored offchain for these content need to be scalable.

5. And then what is the format of the actual ad? Is it just an image? If I got your concept, this will be stored in IPFS, correct? What tool will you use to write data to IPFS, and will it happen directly from Substrate or from the SDK (i.e. the WeChat MiniProgram)?

=> The actual ad will be a link with short description in the group and a landing page with a image or short video with some interactions in the IM explorer. We may not build any tools for writing data to IPFS because all the media source are static and no requirement to change and update. We may provide some existing tools to upload the media source for advertisers and generate the source link to bind to the AD, that is OK. In WeChat MiniProgram, the SDK will mainly be responsible for fetching data from IPFS instead of writing to it.

[DorianRust]

Sorry for disturb you again @Noc2 and @BenWhiteJam, as @mmagician mentioned we update the application and add more details about our project. Please check it and approve again, thanks a lot.

[mmagician]

Thanks @DorianRust for all the changes. I'm not fully convinced about the solution for a few reasons: inconvenience for users to need to explicitly sign-up; SDK that seems non-universal, but rather targeted to a specific app (WeChat). Nevertheless, I am happy to give it a try, I hope you can come up with a functional solution and prove me wrong :)

[DorianRust]

Thanks for your comments and suggestions for Parami @mmagician. Actually in our solution, the user only needs to register one time and does not need to log in continuously. It is simple and imperceptible. Secondly, we are not only for WeChat but all other social apps. Users spend much more time using these apps than all other applications in total. It would be more meaningful here if there is support for web3 application plugins. The SDK will be split in to a general part and platform-specific part. The platform-specific part is responsible for handling user identification.

[github-actions]

Congratulations! As part of the Open Grants Program, we want to help winning teams acknowledge their grants publicly while observing the foundation’s guidelines. To that end, we’ve created a badge for grant-winning teams. Here is a link to the download and guidelines.

Once you complete your first grant milestone, would you be interested in collaborating on an announcement about the work you’re doing? If so, then please get in touch with us at [email protected] prior to making the announcement (at least two weeks notice is preferred) so that we can coordinate on timing and content.

Please don’t announce the grant publicly before you finished at least the first milestone of the project.

[alxs]

Hi @DorianRust. Care to share a quick status update on the project? It looks like it hasn't been active for a while https://github.com/parami-protocol/parami. If you're no longer interested or not actively working on it, we would terminate the agreement.

[alxs]

This grant is being terminated due to inactivity. Feel free to apply again if you're still interested.

[DorianRust]

Hello @alxs, sorry for the late reply. We’ve been working intensively on the dev side, please kindly check our GitHub repository (https://github.com/parami-protocol/parami-blockchain). It seems that you have been following the wrong link. The Parami team has been actively work on the project as one among the Web3 Foundation granted projects. Could you please inform us the process to get back to the granted list? Thanks Alxs.

[alxs]

@DorianRust I've opened a PR to reverse your termination. I think it should manage to get 3 approvals from the committee, in which case you'll still be able to deliver this grant. Nevertheless, it remains overdue so I'd ask you to please submit an amendment as soon as it is accepted to include an ETA or adjust the duration.

[DorianRust]

Hi @alxs, thanks for the quick and informative reply. It’s highly appreciated that the committee would reconsider the termination. We will submit the the amendment ASAP with ETA and carry on the work in either case. Keep in touch.

[DorianRust]

Hi @alxs, sorry for the late reply. This is the adjusted ETA:

Milestone Dāna(June 8 - July 8 Completed)

Number	Deliverable	Specification
1a.	Substrate chain	Build Parami ParaChain based on Substrate3.0.0, the core modules that have been developed include DID pallet, ADS pallet, NFT pallet and Bridge Pallet.
1b.	Substrate chain	Provide the following RPC interfaces for Parami Wallet, including setup DIDs and ads, and APIs that allow transfer assets via DID
1c.	Substrate chain	Setup and launch Parami testnet, which has been running stably for about a month. Parami testnet has has become a parachain to Rococo. Please refer to (https://polkadot.js.org/apps/?rpc=wss://rococo-rpc.polkadot. io#/parachains/parathreads).
2a.	Substrate chain	Completed the bridge development between ETH ERC20 and Parami chain. Please refer to https://github.com/parami-protocol/parami/tree/main/pallets/bridge
2b.	Substrate chain	Complete NFT pallets, please refer to https://github.com/parami-protocol/parami/tree/main/pallets/nft
3.	Parami wallet	Parami wallet has supported Telegram and WeChat. Users can login to Parami wallet in the social software to complete the binding of social ID and DID identity, implement token transfer in/out and transaction query functions. Please refer to: https://github.com/parami-protocol/wallet_server
4.	ad3-maker	encode/decode the avatar of Telegram or Wechat users, and create the binding of DID and social user's identity image. Social users can transfer token through the avatar. Please refer to: https://github.com/parami-protocol/ad3-marker

Milestone śīla(July 8 - August 8 Partially Completed)

Number	Deliverable	Specification
1a.	Substrate chain	Develop Offchain-worker to verify ads and incentives, rewards and withdrawals, etc.
1b.	Substrate chain	Support Social coin and introduce NFT support for advertisers.
1c.	Substrate chain	Refine oracle implementation. Engage ad-specific validation into it, like an anti-spam check, visibility validation, and so on.
2a.	Explorer	Build Parami Chain explorer, and provide block and transaction query support;
2b.	Parami Wallet	Wallet development, optimization of new functions, improve the smoothness of users using wallets, and enhance users' experience; (finished)
3.	Parami AMM	Implement Parami AMM, support AD3, Social coin.
4.a	Test	Testing Guide
4.b	Document	Parami developer documentation support, including node deployment, API design instructions, wallet usage guidelines, etc. (finished)

Milestone Vīrya(Not Started Yet)

Number	Deliverable	Specification
1a.	Substrate chain	Develop on-chain governance logic to build a more decentralized platform.
1b.	Substrate chain	Develop prices pallet to provide the real price of Token;
2a.	Parami Wallet	Parami wallet supports blind signature algorithm, which are used to obtain reward evidence for users; the data layer supports homomorphic encryption algorithms to provide privacy protection of users' data.
2b.	Parami Wallet	Integrate zero-knowledge proof technology for users' private data update, verifiable computaion of reward amount and the implementation of anonymous transactions to fully archive privacy protection.
3	Tool	Docker-Compose Substrate node

[alxs]

Thanks @DorianRust, looks good. Could you amend the application file via PR? You can also split the payment across the different milestones. And please include deliverables 0a-d as in the template in all milestones, and 0e at least in the last one.

[didateckck2013]

Hi @alxs, I have amended the application file via PR, could you pls help me to review?