# Flarum Web3 Extensions Full specification of Flarum's Web3 Extensions to be built. The overall vision is to allow a user to add one or more Web3 addresses to their user account, and then using these to log in, and to permission access to certain categories. ## Flarum Web3 Login > Note: This is extension 1. It is payable 500 USD(T) and 500 extra will be given to Flarum Foundation via OpenCollective or crypto, to further help development costs. A user should be offered ONLY a "Log in / Sing up with Web3" option. The option to Sign Up without a web3 address should not be offered, but logging in without one should. This is clarified below. Broadly, there are two types of Web3: [Polkadot](https://polkadot.js.org/docs/api/) and [Ethereum](https://docs.ethers.io/v5/). Both should be offered as a sign up and log in option. The options provided should support multiple wallets, as on [Singular.app](https://singular.app). Note that Singular.app currently only offers different option to log in with Web3 that pertain to the Polkadot side, for an example of Ethereum log in please see an Eth site like Opensea.io. ![](https://i.imgur.com/aqyNgLj.png) Once selected, the user picks one of the wallets provided by the extension in question. Once an account is selected, one of the following happens: - if the user already has an account, then he is asked to sign the username cryptographically, using the Sign function of Polkadot.js API / ethers.js, which is then Verify-ed on the server. - if the user does not have an account, they are asked to set up the basics as if registering a new account, but also sign their selected username cryptographically. - if the user already has an account but one without a web3 address attached, they should be given a profile option "bind web3 address" which follows the same signing process as above, allowing for option 1 to happen in the future Both of these user journeys have been developed in [this post](https://www.sitepoint.com/flarum-add-web3-address-to-user-profile/) previously. They can be replicated almost verbatim for the Polkadot side, whereas the Ethereum side differs slightly but is equally easy to do. The above journey allows a user to log into the forum with their web3 wallet(s) on desktop or mobile, but also to fall back to username/password when in a non-wallet environment, giving them the best of both worlds. ## NFT-gated Web3 Access > Note: This is extension 2, and has extension 1 as a dependency. It is payable 500 USD(T) and 500 extra will be given to Flarum Foundation via OpenCollective or crypto, to further help development costs. Once a user has connected their web3 wallet(s) to their flarum account, there should be a per-15-minutes permission checker on the back end, pinging an API that returns a full list of NFTs in a user's wallet. The API call looks like this: ``` someurl.com/?addresses=CgiiSCGqEc9bgSoFYT5WcUEsvWDG1XDZLKDgjabGAbb5sBK,HKugX5NJPenSiDcN94iN4ExAsq3TVrXgzQ2ieQrWMxpx2ov,0xB9b8EF61b7851276B0239757A039d54a23804CBb&chains=kusama,moonriver,moonbeam,karura&apikey=xxxxxxxx ``` Notice that the first two addresses in the list above are Substrate-format (Kusama chain) and the last one is an EVM-style address, hex. The format does not matter to the API, as long as chains are specified in the `chains` param, it will automatically check them correctly. The chain order does not need to match the address order. There should be an input in the extension's settings to enter an API key of the service providing this API. The key is optional, as some APIs might whitelist platforms and allow unlimited access. 403 will be returned if the API requires a key and there is none, so the extension should check this on Save and report back. The forum admin should be able to regex-match or direct-match NFT property keys and value to categories in the forum for read and write access. The API will return NFTs in the following format: ```json { "kusama": [{NFT1}, {NFT2}, {NFT3}, "..."], "moonriver": [{NFT1}, {NFT2}, {NFT3}, "..."], "moonbeam": [{NFT1}, {NFT2}, {NFT3}, "..."], "karura": [{NFT1}, {NFT2}, {NFT3}, "..."], } ``` where `[{NFT1}, {NFT2}, {NFT3}, "..."],` etc are of the simple type: ```json { collection: "string", nft: "string", key1: "string", key2: "string", ... } ``` ### Example Suppose that a user's API call comes back as: ```json { "kusama": [{ "collection": "aee71703935620325f-ZOOANIMALS", "nft": "https://singular.app/collectibles/11759298-aee71703935620325f-ZOOANIMALS-RHINOCEROS-00000016", "color": "grey", "size": "big" }, { "collection": "aee71703935620325f-ZOOANIMALS", "nft": "https://singular.app/collectibles/11759298-aee71703935620325f-ZOOANIMALS-RHINOSAURUS-00000016", "color": "black", "size": "medium" }, { "collection": "aee71703935620325f-ZOOANIMALS", "nft": "https://singular.app/collectibles/11759298-aee71703935620325f-ZOOANIMALS-REDPANDA-00000016", "color": "red", "wild": "yes" }], } ``` The matching that a forum admin can do can look something like this: - collection: `aee71703935620325f-ZOOANIMALS` - color: `red` - category: `jobs` - permission: `read` The above means anyone with a red NFT from the collection can access the forum's jobs category in read only mode. - collection: `aee71703935620325f-ZOOANIMALS` - match: `.*-rhino.*` - category: `jobs` - permission: `write` The above means anyone with an NFT related to "rhino" from this collection can write into the jobs section.