Create mission_list.md

[ggwpez]

Drafting the mission list to come to an agreement on what projects to commit on.

[ggwpez]

This looks like some game? Not a developer tool?

[ltfschoen]

the goal is to make it an end-to-end browser based Web3 game developer tool that integrates with game engines like p5.js, or even animations or 3D/VR/AR experiences (e.g. react three fiber, three.js, etc), with the Polkadot.js Extension, and ink! smart contracts. i think it should definately go under dApp.

At the moment it shows how to create a multiplayer browser based game using a traditional browser-based game engine like p5.js that integrates with Polkadot.js API (it request tips at the end of the game from the treasury based on your results) through to production, but it's not adequately decentralized at the moment, so the next step was make more of the gameplay progressively decentralized and to finish integrating the leaderboard ink! smart contract.

i previously had it deployed to Sia Skynet and was using Namebase to configure DNS settings so a Handshake domain name would redirect to it. So i'd like to make that more Polkadot-specific. Initially i was planning to use a pns.link domain name, but i haven't checked to see if they have that functionality working yet. I'd also need to store it somewhere else other than Sia Skynet since that got deprecated after VCs pulled funding and Sia Foundation took over rebuilding it. Maybe just store it at an IPFS CID pinned Pinata folder if possible.
Or maybe I'd replace all that with something like PNS.link, or Polimec and Apillion if possible. But i tried uploading a non-static Next.js website to Apillon and it didn't work.

i was also thinking of adding a source of randomness so it couldn't be gamed, initially i was going to use a future block hash for the source of randomness (see my XCMTemplate repo) since using randomness precompiles weren't adequate, but then i investigated using ZK as the source of randomness and studied ZK for about 6 months last year, but recently someone suggested I could use a Phala secure enclave for the source of randomness.

[ltfschoen]

if you see value in decoupling only the specific Web3 game developer tooling related aspects so we can use it in a tooling library please let me know.

[ltfschoen]

that repo has actual won two hackathons.

it got 2nd Place Visualisation Bounty Challenge for Build Polkadot: Network
Launch hackathon in 2020 https://polkadot.network/blog/build-polkadot-network-launch-bounty-challenges#visualization

and then i improved upon it in a subsequent hackathon doing things like making it multiplayer instead of single player and won Zeitgeist's Ecosystem Auxiliary application Bounty Sponsor Challenge for the Polkadot Hackathon: Europe Edition in 2023

[ggwpez]

Every project that we include in this list here is a promise from PoToC to maintain it. For now i dont see a good point for PoToC in doing so. If it evolved into a gaming DApp library or something similar than that would make a good point. But until then, it is not a developer tool but "a cute game that allows you to fly the DOT character through block gaps" as the hackathon stated.

[ggwpez]

This looks promising @ltfschoen, do you know if it used by others / has any adoption?

[ltfschoen]

i shared it on https://substrate.stackexchange.com/ once but i had a bug in it at the time that i've since fixed.
i haven't marketed it at all, i only shared it incase it'd help someone else.
the only adoption i'm aware of is that i was using it to generate a source of randomness from a future block hash for the Flappy Tips game https://github.com/ltfschoen/flappytips.
it has also got 3x stargazers https://github.com/ltfschoen/XCMTemplate/stargazers, and they don't appear to be bots, and one of them appears to be making substantial contributions to the Polkadot ecosystem.
if you have any feedback or suggestions i'm willing to take them onboard to try and turn it into something more useful, or integrate it into something else that exists

[ggwpez]

Okay i included it for now.

In general we should prioritize projects with adoption, since we dont have many resources now and need to focus them. So marketing it and getting people to use it is always good.

[ggwpez]

Please call me out if you think that my tools are not belonging to the list, i am biased in this regard 😄

[wirednkod]

I do not think that these are making the Tooling list.

[ltfschoen]

"NFT coretime" repo has a mixture of features at the moment.
It has some boilerplate Next.js client/server code in the frontend and server folders, but the tooling part of it is in its "nft" folder.
The intention is to move that across into my tooling repo https://github.com/ltfschoen/open-polkadot-js-library
I also plan to move the "Polkadot JS test" repo into that open-polkadot-js-library repo too

I actually only just added open-polkadot-js-library to the list here https://github.com/polkadot-tooling-collective/collective/pull/6/files#diff-eea8eb217055be150b68dd0d63742502210d872d3e54d1a592854396ceef38beR110, as previously I was using the DataHighway-DHX one, but i forked it and started modifying the fork instsead as i'm worried the DataHighway-DHX repo might disappear

[ltfschoen]

Agree the "RustTest" is mostly small rust examples to help me brush up on rust whenever i haven't done it for a while https://github.com/ltfschoen/RustTest

There are only a couple of Polkadot specific ones in the https://github.com/ltfschoen/RustTest/tree/master/projects folder, in the subfolders "endow" and "hash"

Ideally I'd separate them into a specific folder, and they'd serve as Polkadot interaction examples like the ones in this repo https://github.com/paritytech/polkadot-interaction-examples-rs

[wirednkod]

Is a CLI capable of making the list? If this was exactly the same but could be used as a dependency from inside another project - to me - that would make more sense to be in the list

[ltfschoen]

Is a CLI capable of making the list? If this was exactly the same but could be used as a dependency from inside another project - to me - that would make more sense to be in the list

couldn't we approve a library version of that, to incentivise the community to create a library version of the CLI took like you mentioned, or the creator could create it themselves if they have time

[ggwpez]

Yes its a good point. Libraries should always be preferred.

On the other hand, these tools do have adoption by developers within the Polkadot Ecosystem, so they already provide value in their current for.

[wirednkod]

I am pretty sure that the extension should not be considered as a tool.

[ltfschoen]

but we could use it as a resource to extract best practice tools/libraries for other wallets to use if those features are baked into the extension rather than already being imported from other existing tools/libraries?

[ggwpez]

I am pretty sure that the extension should not be considered as a tool.

Yes. Removed.

but we could use it as a resource to extract best practice tools/libraries for other wallets to use if those features are baked into the extension rather than already being imported from other existing tools/libraries?

Sure, but we should not promise to maintain the extension i think.

[TarikGul]

A few other tools that come to mind as well that we might want to consider:

asset-transfer-api
asset-transfer-api-registry
txwrapper-core

I think all of the following can be considered dapp, or core tooling. Maybe undecided then?

[TarikGul]

Great job! IMO this is a really good base to set the foundation for what's to come ahead.

[Tbaut]

Thank you for shaping this!

[joepetrowski]

Instructions like, "to add or remove projects, {make a PR, submit an RFC, something else}". I guess once merged it's no longer a draft and will be part of the proposal?

[ggwpez]

Yes instructions will be added, but i will wait until we have a process to not be flooded with mediocre applications.