onflow/flip-fest

A backlog of all the available tasks to complete for Flow's FLIP Fest.

🚧 FLIP Fest has been completed! 🚧

To see the winners and all the amazing projects produced by the participants, see the winners.

---

Welcome to Flow's FLIP Fest

This event is being moderated through HackerEarth. If you interested in participating, please review all the details of the event and register through the link above.

What is FLIP Fest?

The Flow FLIP Fest is a two-month event that will engage and reward participants for creating innovative and effective improvements to Flow's Ecosystem. A FLIP is a Flow Improvement Proposal; a community-driven initiative to discuss and execute impactful improvements on Flow.

Teams or individuals can sign-up to tackle high impact projects through any of the issues listed in this repository. Core contributors to Flow will aid and guide you through your project as you work to deliver an optimal solution alongside other teams.

Rewards are given per issue for both high quality completion as well as a large reward given to the best solution per project. Read more about the rewards here.

Issues, Tracks, & Tiers

Issue Tracks

• FLIP: A 'Flow Improvement Proposal'.
• Infrastructure Tools: Tooling that provides services to other dApps in the ecosystem.
• Learning Tools: Tooling to help developers learn and onboard onto Flow.
• Local Development Tools: Tooling that optimizes the developer experience of buidling on Flow.
• Non-custoidal Wallet Providers: Teams interested in building production scale wallet providers on Flow.

Issue Tiers

• Tier 1: Large task, spanning 4 milestones requiring extensive work and/or knowledge.
• Tier 2: Medium task, spanning 2-3 milestones requiring a moderate level of domain knowledge.
• Tier 3: Small task, spanning 1 milestone, generally can be completed with limited domain knowledge.

Others

Getting Started

1. Sign up on HackerEarth.
2. Find a team through HackerEarth, our Discord server, or through GitHub. You may also complete a ticket by yourself, however collaboration is highly encouraged. Please construct and confirm a team with a team name via the HackerEarth platform.
3. Find an issue you or your team would like to do and post a comment on the issue with a link to your team's Hacker Earth Team Profile and tag all GitHub usernames of the members on the team.

For more details on logistics and process, read more here.

Milestone Submissions

Each project is divided into one or more milestones depending on the complexity. Read more about milestones here.

Instructions

Complete the required work on the respective milestone via any relvant repsoitory/repositories (make a new public one if required). Follow any relevant guidelines and including proper PR documentation on those repos. Once all the work for a milestone has been completed, summarize the work done across all repos into a single PR on this repository.

To be eligible for rewards, teams must submit a PR to: /submissions/issue-#/milestone-#/team-name

In this PR, please follow the template. Your point-of-contact (PoC, the assignee on the issue) will provide official feedback and/or approval every Thursday/Friday for the duration of the event.

Requirements

Each issue has its own requirements outlined inside the issue. Along with this, there are some high-level judging criteria outlined that should be followed.

Resources

Announcements & Updates

All announcements and updates regarding FLIP Fest will be delivered on Discord and GitHub.

Community

To discuss any specific issues or have general discussion on this event, please visit the discussions page!

Help

Your point-of-contact (PoC) will be the first person to contact for help regarding your specific issue. They may help you connect with others as needed to help you solve your problem. Outside of that, core contributors to Flow will be available on our Discord to answer any comments, concerns, or questions. They will also answer questions on GitHub through discussions, issues, and PRs. You can also use our directory to find potential members to connect with via any of the channels listed.

Useful Links

• Flow Developer Documentation
• General Resources Guide
• Flow Community Projects

flip-fest's Issues

CLI Feature: Project scaffolding

👋   If you are interested in working on this issue, please check out the Getting Started guide on HackerEarth!

Description (Problem Statement)

Currently, there are no local tools that support scaffolding a Flow project.

For newcomers to Flow, having a suggested folder structure, as well as boilerplate configuration will save them time while experimenting or kicking off their next project.

This issue proposes a lightweight scaffolding system to be built into the Flow CLI, enabling users to quickly generate a Flow project structure based on current best practices - example scaffold.

Experience Required

• Familiarity with Go
• Familiarity with the Flow CLI
• Familiarity with frontend development, JavaScript and the Flow Client Library (FCL)

Minimum Feature Set (Acceptance Criteria)

The command should:

• Provide a pre-configured flow.json and FCL configuration to connect to the emulator and FCL development wallet.
• Provide pre-stubbed Cadence tests and JavaScript integration tests (using flow-js-testing)
• Allow users to select their preferred UI framework (or none).
  • Currently, only React and Vue are supported by FCL
• Provide a.env.example file with emulator defaults
• Provide a default .gitignore

Milestone Requirements

1. Build and implement the basic infrastructure:

• Set up GitHub repository for example projects (mix and match stacks)
• Provide issue templates for users to submit their own example project
• Generate a default React project based on Kitty Items folder layout and commit to example repo
• Propose CLI command name, flags, and other UX details for the next milestone.
• Clone the example project from the CLI using a new built-in command and interactive command line UI similar to Create Nuxt App

Software Requirements

Maintainability

• The tools or libraries used to construct the solution should be well vetted and well maintained
• Code should be written in a way where it's easily extensible to new functionality and semantic enough for open-source developers to contribute to.

Testing

• All core logic should have unit tests.
• E2E tests for each feature implemented.

Other Requirements

Documentation

• The following pieces of documentation needs to be completed alongside the code for a successful submission:
  • A quick walkthrough guide for this feature with screenshot examples.

Code standards or guidelines

• Follow the general contribution guidelines.

Judging Criteria

• For all projects, technical & high-level judging criteria apply.

Resources

• General Resource Guide
• CLI
  • Repository
  • Design guidelines
• Create Nuxt App
• Example scaffold

New Tool: Build a Flow SDK

👋   If you are interested in working on this issue, please check out the Getting Started guide on HackerEarth!

Description (Problem Statement)

We are looking for teams interested in building and maintaining SDKs for Flow to make it easier for a broad range of developers to interact with the blockchain.

We welcome the introduction of any language SDK as a Tier 1 task with the exception of the following existing SDKs. If you intend to build in one these languages, we recommended you consider contributing to the existing repository (Tier 2):

• Go
• JavaScript
• Kotlin/JVM (Java)
• Dart
• Python - /issues/46 (Existing SDK)

New SDKs (Tier 1):

• PHP
• C#
• Ruby
• Swift
• Rust
• C/C++

Experience Required

• Experience in the language and/or framework being used to construct the SDK
• High level understanding of Flow's architecture (block production, transaction states, etc.)
• Understanding of gRPC
• Understanding of the Flow Access API

Minimum Feature Set (Acceptance Criteria)

Meet the SDK Guidelines

• View the SDK Guidelines and implement your SDK accordingly.

Extension (Optional) Feature Set

Additional Functionality

• Identify and create methods that abstract common patterns to make it easier for developers to employ these patterns in their dapp.

Milestone Requirements

1. Implement gRPC & propose an API based on the user stories in the SDK guidelines with rough implementation details on each method.
2. Implement all user stories that do not involve parsing Cadence code.
3. Implement the ability to send scripts and transactions with arguments.
4. Create tests, documentation, and optimize for performance and usability.

Software Requirements

• All requirements listed in the SDK Guidelines
• Production ready code: The SDK is expected to be used in production by third-parties and so it should be secure, performant, and ready to use out of the box with minimal configuration.

Other Requirements

Documentation

• The following pieces of documentation need to be completed alongside the code for a successful submission:
  • Installation Guide: How to get this application up and running.
  • Usage Guide: A highlight of all the features available and how to use them.
  • Contribution Guide: A thorough explanation of the codebase, where features are located, a diagram explaining complex interactions, etc. This is intended to be a primer for new contributors that would like to add or modify features.

Code standards or guidelines

• Create code guidelines based on the best practices of the language chosen - attempt to be as semantic as possible to that language. Follow these guidelines during development, and assess against them for new contributions.

Judging Criteria

• For all projects, technical & high-level judging criteria apply.
• How easy and comprehensive is the SDK to use for Flow developers?
• How many use cases does it cover?
• How complex is it to learn and use?
• How performant is it to use in production?

Resources

• General Resource Guide
• SDK Guidelines
• Current SDKs

Dev Wallet Feature: Improve OpenID implementation

👋   If you are interested in working on this issue, please check out the Getting Started guide on HackerEarth!

Description/Problem

Dapps should be able to define and request user information from FCL compatible wallet providers so that they can associate the account address with identity fields. Currently, during authentication, the only field the FCL development wallet returns is the address of the authenticated account and hardcoded values for scopes provided. Within the development wallet, we need a way manage OpenID scopes per account and return them dynamically during authentication if requested by the FCL configuration.

If any user information is being shared, show the user a prompt on which details are being shared with what domain (similar to an OAuth flow) via the authentication UI.

Experience Required

• Moderate level experience with Typescript & Javascript
• Some understanding of FCL and the communication patterns for FCL wallets

Minimum Feature Set (Acceptance Criteria)

Manage OpenID fields on all accounts

• All these claims should be supported and editable as the administrator of the dev wallet (via the 'manage account' screens) and be done so with good UI/UX principles in mind.

Implement Dynamic OpenID Spec Authentication Responses

• All specified fields are OpenID Connect Spec in particular under 2.4 Scope Values and 2.5 Standard Claims.
• Replace hardcoded values with relevant dynamic ones from the account itself

Extension (Optional) Feature Set

Support required OpenID fields. If a field in the configuration of service.OpenID.scopes is required (via the '!' operator), then do the following:

If the account exists during authentication:

• If all the required fields do not exist in the account:
  • Render and collect the fields that are required but missing
  • Return the data with all required fields
• If all the required fields do exist:
  • Return the data

If the account does not exist during authentication:

• Render and collect the required fields
• Save the collected data to the user's profile for future use
• Return the data

Milestone Requirements

1. Create wireframes to illustrate how you plan on showing and managing OpenID scopes in the UI.
2. Implement the management of OpenID fields on any account created in the dev wallet.
   1. An administrator should be able to modify any valid field to any value and have it saved to the account.
   2. A user should see which scopes are being shared with the dApp on authentication.
   3. The response from the wallet should contain values from the requested scopes (empty if not set).
3. Optimize the UX of the wallet and its developer usability and/or implement the extension feature
   1. Add documentation on OpenID to the dev wallet
   2. Ensure scopes are optimized to be easy to manage and display during development

Software Requirements

Maintainability

• Code should be written with good practices in mind and allow extensibility
• Follow existing code semantics and patterns in the existing repository

Testing

• This feature should have unit tests for core parts of the logic.
• Each user flow should have at minimum one end to end test.

Other Requirements

Documentation

• The following pieces of documentation needs to be completed alongside the code for a successful submission:
  • OpenID Usage: Help developers understand and use the feature set.

Judging Criteria

• For all projects, technical & high-level judging criteria apply.
• How effective is the UI/UX of the features implemented for developers and users to understand and interact with the OpenID fields?

Resources

• General Resource Guide
• Development Wallet
  • Repo
  • Current Hardcoded Implementation
• FCL
  • Wallet Guide
• Kitty-items
  • Example of dev wallet in local environment

VS Code Extension: Architecture improvements

👋   If you are interested in working on this issue, please check out the Getting Started guide on HackerEarth!

Description (Problem Statement)

The VS Code extension architecture could be improved so the extension becomes lighter and only handles the communication with the language server and the UI. This simplification would allow easier testing, less complexity and, better UX during the installation process. Currently, the extension requires the Flow CLI pre-installed in order to start and manage the emulator as well as to start the language server itself.

The proposed improved architecture would be for the language server to wrap the emulator by including flowkit dependency and start and manage the emulator state from there. The language server would then need to stream the emulator output to the extension for a developer to see in the output. The language server should also be bundled together with the extension as an npm module so it can be started directly from the VS Code.

Experience Required

• Experience with Go
• Experience with typescript/javascript
• Experience with writing tests

Minimum Feature Set (Acceptance Criteria)

• The CLI is no longer required for the VS Code extension to function
• The language server handles emulator state
• The emulator log is streamed to the extension and displayed in the output
• The language server comes bundled together with the extension and the installation process doesn't have any additional steps
• The functionality of the VS Code extension stays the same or is extended

Extension (Optional) Feature Set

• Tests are improved to provide code coverage > 70% and are mostly consisting of unit tests
• End to end tests are expanded to test all interactions
• Implemented a release pipeline for new versions using Github actions
• Implement code coverage reporting with Codecov (look at the CLI repo)

Milestone Requirements

1. Document the basic architecture for the extension improvements
2. Remove the CLI dependency from the extension and manage the emulator in the language server
3. Refactor extension codebase so it becomes a lightweight client
4. Make sure the release pipeline and tests are implemented

Software Requirements

Maintainability

• Code architecture should provide simplicity and a minimalistic codebase that is easy to understand and extend.
• The release process should automate releasing new versions to the marketplace and building all the dependencies.

Testing

• Tests should have good coverage and allow for future changes with confidence.
• End to end test with Cypress should test all interactions with the extension.

Other Requirements

Code standards

• Follow code standards and requirements already in place in the existing repository.

Test coverage

• Don't decrease code coverage.

Judging Criteria

• For all projects, technical & high-level judging criteria apply.

Resources

• General Resource Guide
• VS Code extension
• CLI / Flowkit
• Emulator
  • Repository
  • Documentation
• Language Server
• Extension architecture
• Github actions for the release process

CLI Feature: Command autocomplete

👋   If you are interested in working on this issue, please check out the Getting Started guide on HackerEarth!

Description (Problem Statement)

The CLI should provide command autocompletion to improve the UX. There has been some work already done to implement this feature but it requires more attention. More testing is needed across different shells. The current implementation doesn't allow users to autocomplete file names (ie. tab tab for the filename), it currently only works for command names.

Experience Required

• Experience with Go

Minimum Feature Set (Acceptance Criteria)

Autocompletion working on all supported shells with file paths still autocompleting.

Extension (Optional) Feature Set

Enable auto-completion by running a command without the user's need to manually configure.

Milestone Requirements

1. Autocompletion works on all supported shells
2. Testing suite in place

Software Requirements

Maintainability

• Code should be written with best practices in mind.

Testing

• Tests should cover all the code implementing this functionality.
• The feature should be tested on all shells supported.

Other Requirements

Documentation

• Documentation should be updated according to the changes made.

Code standards or guidelines

• Follow the general contribution guidelines.

Judging Criteria

• For all projects, technical & high-level judging criteria apply.

Resources

• General Resource Guide
• CLI
  • Repository
  • Design guidelines

Existing issue:

Command autocompletions · Issue #102 · onflow/flow-cli

Current implementation:

Command autocomplete by sideninja · Pull Request #203 · onflow/flow-cli

Incorrect info

Hey, I noticed that our team sheeeeeeeeesh wasn't included into submission results for issue "Multiple contracts per account#21", as we did achieve the first milestone here: #118 (comment).

Correction

I think we should be listed in submission results with Total team payout of 250$ (for the first completed milestone).

New Tool: Events indexing service

👋   If you are interested in working on this issue, please check out the Getting Started guide on HackerEarth!

Description (Problem Statement)

Most Flow applications, and especially dapps, need to respond to on-chain events emitted by Cadence smart contracts. Typically, an application will periodically query the Flow Access API for a specific set of events that they care about. When an event occurs, the application will update its internal state (e.g. a database) or notify its users of the on-chain activity. Many teams have integrated event tracking systems directly into their application infrastructure, but this is a common enough problem that it warrants a simple and general-purpose solution that can serve all teams.

Experience Required

• Familiarity with the Flow Access API and its event querying functions
• Good understanding of the Cadence event model
• Good understanding of design principles and UI/UX for developer tools
• (Optional) Experience with message queueing services such as RabbitMQ and Kafka

Minimum Feature Set (Acceptance Criteria)

Event Indexing

• A user can configure the events they wish to watch using a list of Cadence event IDs. The service will continuously monitor all events in this list. The event list can only be changed upon startup — the service does not need to support dynamic configuration (e.g. adding event IDs using an API call).
• The service should watch for events in every block. It can (and should!) use the GetEventsByHeight range to query multiple blocks at once.
• The service must not miss any events; if a failure occurs in a block, the event indexer should not proceed to the next block until all events have been fetched.

Event Delivery

• The service should deliver each event to an external consumer (i.e. a dapp backend) as a JSON payload.
  • At a minimum, the service should support event delivery via HTTP webhooks. In this scenario, the consuming application will provide an HTTP endpoint as part of the startup configuration. The consumer should respond with appropriate status consumes to indicate a successful or unsuccessful delivery — these status codes are defined by the indexer.
  • The service only needs to support delivery to a single consumer.
  • All events should be delivered in the same order they were emitted on-chain.
  • Each event should be delivered exactly once. The indexer will need to implement logic to ensure idempotency of events.

Extension (Optional) Feature Set

Message Queueing

• Some applications may benefit from consuming events via an event queue such as Apache Kafka or RabbitMQ.

Multiple Consumers

• Some applications may wish to set up multiple consumers and route specific events to each consumer. This is an optional feature because it should always be possible to start multiple instances of the event indexer, each configured with a unique set of event IDs and a unique consumer.

Milestone Requirements

1. Create wireframes and an architectural software diagram on your potential implementation of the minimum feature set.
2. Implement the minimum viable product (MVP) for the event indexing logic.
3. Implement the remaining minimum feature set and the event delivery (consumer) mechanism.
4. Prepare the final version of the application as a deployable artifact (e.g. Docker image), along with a basic example consumer application and accompanying documentation.

Software Requirements

Infrastructure

• The tool is runnable as a standalone deployment, ideally as a containerized image (e.g. Docker)
• The service adheres to the 12 Factor App methodology. In particular, the service should be configured by the environment (i.e. using environment variables).

Maintainability

• The tools or libraries used to construct the solution should be well-vetted and well-maintained.
• Code should be written in a way where it's easily extensible to new functionality and semantic enough for open-source developers to contribute to.

Testing

• All core logic should have unit tests.
• E2E tests for each feature implemented.

Other Requirements

Documentation

• The following pieces of documentation need to be completed alongside the code for a successful submission:
  • Installation Guide: How to get this application up and running.
  • Usage Guide: A highlight of all the features available and how to use them.
  • Contribution Guide: A thorough explanation of the codebase, where features are located, a diagram explaining complex interactions, etc. This is intended to be a primer for new contributors that would like to add or modify features.

Code standards or guidelines

• Follow the general contribution guidelines (borrowed from the emulator project).

Judging Criteria

• For all projects, technical & high-level judging criteria apply.
• Fault tolerance and reliability (i.e. does the service reliability deliver all events to the consumer?)

Resources

• General Resource Guide
• Flow Access API
• Cadence Events
• Example of a Flow event listener implemented in Go

New Standard: Decentralized identifiers (DIDs) on Flow

👋   If you are interested in working on this issue, please check out the Getting Started guide on HackerEarth!

Description (Problem Statement)

Decentralized identifiers (DIDs) are a form of self-sovereign identifiers that aim for a standard interoperable way of identifying and authenticating subjects inside decentralized systems.

From W3C: Decentralized identifiers (DIDs) are a new type of identifier that enables verifiable, decentralized digital identity. A DID refers to any subject (e.g., a person, organization, thing, data model, abstract entity, etc.) as determined by the controller of the DID.

Use cases: https://www.w3.org/TR/did-use-cases/

The Verifiable Data Registry in the image above would be Flow. All other components need to be defined/provided by authors.

This issue is meant to invite any and all who may be working with the DID specification, to provide these components for Flow-based DID subjects, the most obvious being Flow accounts, but this could also be applied to individual resources!

Flow could benefit from dedicated DID infrastructure for interoperating Flow identities with services outside of Flow, such as decentralized data storage and credential verification systems.

Experience Required

• Familiarity with DIDs and SPKI
• Good understanding of Flow's account and keys system

Minimum Feature Set (Acceptance Criteria)

• Define the Flow DID (url)
• Define the scope of a Flow DID document
• Create a DID issuer (service) for holders of Flow accounts (e.g. a set of public key(s))
• Create a DID document resolver (service) for Flow-based DIDs

Extension Feature Set (Optional)

This issue does not include or require the creation of a wallet for storing/verifying DIDs.

Milestone Requirements

1. Implement a MVP of the DID document resolver service for Flow accounts
2. Implement a MVP of the DID issuer service for Flow account holders. (Includes methods for updating DID document)
3. E2E test authenticating with a DID-based service using Flow DID document
4. E2E test securely updating a Flow-based DID document

Software Requirements

Maintainability

• The tools or libraries used to construct the solution should be well-vetted and well-maintained.
• Code should be written in a way that's easily extensible to new functionality and semantic enough for open-source developers to contribute to.

Testing

• All core logic should have accompanying unit tests.
• There should be an end-to-end (E2E) test for each feature implemented.

Other Requirements

Miscellaneous

• Flow users may want to retain anonymity, or at least plausible deniability that a particular Flow account is NOT attached to the corresponding DID document.

Documentation

• The following pieces of documentation need to be completed alongside the code for a successful submission:
  • Flow DID URL definition should be documented
  • Flow DID document should be documented
  • Methods for updating / modifying Flow-based DID documents should be documented

Judging Criteria

• For all projects, technical & high-level judging criteria apply.
• System is secure and handles edge-cases.

Resources

• https://www.w3.org/TR/did-core/
• https://www.w3.org/TR/did-use-cases/
• https://www.w3.org/TR/did-imp-guide/
• https://en.wikipedia.org/wiki/Decentralized_identifiers
• https://developers.ceramic.network/authentication/nft-did/method/

DID services diagram at-a-glance:

Emulator Feature: Bootstrap with default contracts

👋   If you are interested in working on this issue, please check out the Getting Started guide on HackerEarth!

Description (Problem Statement)

The emulator is currently bootstrapped with (original contracts):

• FlowFees
• FlowServiceAccount
• FlowStorageFees
• FlowToken
• FungibleToken

There are also other contracts that are very commonly used and it would be practical if emulator came with those as well (new contracts):

• NFT contract
• Marketplace contract

An emulator flag should be introduced -onlyBasicContracts (choose better name if possible) when it is true only the original contracts should be deployed. By default it should be false, so all contracts are deployed.

The output of the deployed emulator contracts, when you start the emulator:

Should reflect the change. Also this display should be improved for readability (one line per contract).

Experience Required

• Familiarity with Go - able to parse and read emulator repo
• Familiarity with Cadence - able to parse and read the deployed contracts

Minimum Feature Set (Acceptance Criteria)

When starting the emulator the default deployed contracts should also include the new ones by default.

When starting the emulator with a -onlyBasicContracts flag only the original contracts should be deployed

The output of the emulator when starting it up should reflect actually deployed contracts.

Software Requirements

Maintainability

• The tools or libraries used to construct the solution should be well vetted and well maintained
• Code should be written in a way that can be extended with new functionality and clear enough for open-source developers to contribute to.

Other Requirements

Documentation

• The existing documentation needs to reflect this change

Judging Criteria

• For all projects, technical & high-level judging criteria apply.

Resources

• General Resource Guide
• Emulator
  • Repository
  • Documentation

FCL Feature: Calculate the transaction hash

👋   If you are interested in working on this issue, please check out the Getting Started guide on HackerEarth!

Description (Problem Statement)

Right now, there's no way to get the transaction hash before it's sent to the blockchain. Pre-calculating the transaction hash will allow for error recovery if there are any network connection issues during the submission of the transaction.

Experience Required (Team Required)

• JS and familiarity with FCL, SDK send

Minimum Feature Set (Acceptance Criteria)

• Add this ability as a middleware to be executed/resolved right before transaction is sent
• It should wait for the callback function to complete before sending the transaction
• Implement an additional function that would supply the ability to go from the transaction voucher to the hash (txId) **voucher => voucherToTxId(voucher)**
• If the callback throws an error it should halt the transaction

Milestone Requirements

• Implement async function which calculates the transaction hash from data
• Implement voucherToTxId ****function that takes a transaction voucher and calculates txId hash
• Documentation - Add a description for this feature including sample code for usage in the existing API Docs

Software Requirements

• Code should be written with best practices in mind.
• Other Requirements - Error Reporting
  • Throw descriptive exceptions on errors
  • Prints a clear error message to the browser console
• All core logic should have unit tests. Include tests for success on valid data and failure

Other Requirements

• Documentation describing the utility functions and parameters

Judging Criteria

• For all projects, technical & high-level judging criteria apply.

Resources

• FCL API Documentation
• Voucher
• Existing Issue

CLI Feature: Hot commands

👋   If you are interested in working on this issue, please check out the Getting Started guide on HackerEarth!

Description (Problem Statement)

The flow CLI should be customized to provide easy access to common commands. The structure of the commands help screen is depicted in Figure 1. Initially deploy, run and init commands should have aliases.

Usage:
  flow [command]

Hot Commands:
  init       Initialize configuration
  deploy     Deploy contracts
  run        Start emulator and deploy contracts

Available Commands:
  accounts     Utilities to manage accounts
  blocks       Utilities to read blocks
  cadence      Execute Cadence code
  collections  Utilities to read collections
  emulator     Starts the Flow emulator server
  events       Utilities to read events
  help         Help about any command
  keys         Utilities to manage keys
  project      Manage your Cadence project
  scripts      Utilities to execute scripts
  transactions Utilities to send transactions
  version      View version and commit information
  config       Configuration commands

Figure 1. Command structure

Experience Required

• Experience with Go

Minimum Feature Set (Acceptance Criteria)

• Customize help screen to have "hot commands" section that includes all commands that have existing aliases
• Implement command aliases without duplicating the command code

Milestone Requirements

1. Meet minimum feature set

Software Requirements

Maintainability

Code should be written with best practices in mind.

Testing

Tests should cover all the code implementing this functionality.

Other Requirements

Documentation

• Documentation should be updated according to the changes made.

Code standards or guidelines

• Follow the general contribution guidelines.

Judging Criteria

• For all projects, technical & high-level judging criteria apply.

Resources

• General Resource Guide
• CLI
  • Repository
  • Design guidelines
  • Existing Issue

Playground Feature: Improve the resource explorer

👋   If you are interested in working on this issue, please check out the Getting Started guide on HackerEarth!

Problem

In the playground, the resource explorer is the tab the shows the resources inside each account. It is hidden initially and only shows up once you interact with an account's storage. But even then, it only shows up after you click an account, which usually decouples the view a transaction that updates the stored resources.

Furthermore, you can only see single account at once. If you want to view another account, you need to switch to it and probably lose the view, since second account doesn't have anything in its storage. Oops!

Example

Here we can see the resource explorer for account 0x02:

Account 0x03 doesn't have anything in its storage, so the view is not even rendered:

Solution

Create a better resource explorer! 😉

Here are some ideas for what you can do:

• Build a way to quickly inspect multiple accounts.
• Provide visual cues for different types of items in the storage(i.e. resources, capabilities, structs, etc). Maybe give them an icon, color, or both! 😎
• Show the user who resources have been created or updated after a transaction is execute.
• Autogenerate transaction or script templates for available capabilities, making it easier to write new interactions by simply clicking on a stored item and selecting the template.

Feel free to bring new ideas not listed above!

Experience Required

• Great proficiency with TypeScript and React (front-end)
• Good proficiency with GraphQL
• Good proficiency with Go (back-end)
• Good understanding of Cadence and its account and storage model
• Good UX/UI design ability

Milestone Requirements

1. Create wireframes for a new UI and interactions for the resource explorer.
2. Implement an updated UI for resource explorer with current set of features.
3. Add support for new features on both the frontend and backend.

Other Requirements

Code standards or guidelines

• Follow the general contribution guidelines.

Design guidelines

• New features should fit with the existing look and feel of the playground.

Judging Criteria

• For all projects, technical & high-level judging criteria apply.

Resources

• Playground frontend repository - https://github.com/onflow/flow-playground
• Playground API repository - https://github.com/onflow/flow-playground-api

CLI Feature: State management

👋   If you are interested in working on this issue, please check out the Getting Started guide on HackerEarth!

Description (Problem Statement)

The CLI should allow saving the current state and then later restarting from that point similar to how you can use git to move between states. This feature is mostly implemented in the PR branch but should be tested, extended with a test suite, and ensure the UX is great.

Experience Required

• Experience with Go
• Basic understanding of Flow blockchain

Minimum Feature Set (Acceptance Criteria)

A developer has commands to achieve the following actions:

• saving the state under a name
• restoring to the named state
• deleting a state
• overwriting a state

The state should be persistent between restarts

Extension (Optional) Feature Set

Interoperability with the Emulator GUI task.

Milestone Requirements

1. Finish the implementation and making sure it works
2. Write tests around the feature proving the functionality of it
3. Documentation of the feature

Software Requirements

Maintainability

Code should be written with best practices in mind.

Testing

Tests should cover all the code implementing this functionality.

Other Requirements

Documentation

• All the commands and the usage should be well documented.

Code standards or guidelines

• Follow the general contribution guidelines.

Judging Criteria

• For all projects, technical & high-level judging criteria apply.

Resources

• General Resource Guide
• CLI
  • Repository
  • Design guidelines
• The issue
• Branch with feature mostly implemented

New Tool: Block explorer GUI

👋   If you are interested in working on this issue, please check out the Getting Started guide on HackerEarth!

Description/Problem

There are no easy ways to inspect the current state of the Flow blockchain when running the emulator locally. This means it can be difficult to verify your smart contract logic during your development workflow. To solve this, we'd like to have a graphical user interface (GUI) that simplifies the network state into visual elements, allows for simple interactions, and is optimized for debugging and inspecting the Flow blockchain state.

Extension: This explorer should be able to connect to the emulator as well as any Flow network (Testnet, Mainnet, Canarynet) and be deployable.

Experience Required

• Familiarity with Go - able to parse and read emulator codebase
• High-level understanding of Flow's architecture (block production, transaction states, etc.)
• Good understanding of design principles and UI/UX for developer tools
• Good understanding of Cadence and its storage model

Minimum Feature Set (Acceptance Criteria)

Explorer

• View and search through all accounts, blocks and transactions on the network state.

Searchable logs

• View and easily search through the log output of the emulator.

Emulator controls

• Enable dynamically setting configurations on the emulator settings (ie. block times, system time, etc.).

Extension (Optional) Feature Set

Account & contract storage state

• View the resources, capabilities, and storage paths for any account that has been created.

Extended usage to other networks

• Deploy a hosted version that can offer the same feature set but on any Flow network..

REST API

• For the deployed version, create restful endpoints to serve data.

Milestone Requirements

1. Create wireframes and an architectural software diagram for your potential implementation of the minimum feature set.
2. Implement an MVP of the GUI that is able to demonstrate at least one of the items on the minimum feature set.
3. Implement the remaining minimum feature set to be fully functional in a bare-bones UI.
4. Improve and optimize the UI/UX of the final product and optionally implement the items from the extensive feature set.

Software Requirements

Maintainability

• The tools or libraries used to construct the solution should be well vetted and well maintained
• Code should be written in a way that can be extended with new functionality and clear enough for open-source developers to contribute to.

Testing

• All core logic should have unit tests.
• Each feature implemented should be tested by an end-to-end (E2E) test.

Other Requirements

Documentation

• The following pieces of documentation needs to be completed alongside the code for a successful submission:
  • Installation Guide: How to get this application up and running.
  • Usage Guide: A highlight of all the features available and how to use them.
  • Contribution Guide: A thorough explanation of the codebase, where features are located, a diagram explaining complex interactions, etc. This is intended to be a primer for new contributors that would like to add or modify features.

Code standards or guidelines

• Follow the general contribution guidelines.

Judging Criteria

• For all projects, technical & high-level judging criteria apply.
• How effectively does the tool help developers in the building process by making it easier for them to debug, inspect, and verify their on-chain logic?

Resources

• General Resource Guide
• Emulator
  • Repository
  • Documentation
• Inspiration:
  • Ganache on Ethereum: https://www.trufflesuite.com/ganache

Infrastructure Tool: Branded dollar creation

Description/Problem

People want to buy collectibles but may decide otherwise if they have to pay with the volatile FLOW token. Stablecoins solve this problem but you have to sell FLOW to get stablecoins. $oneFLOW works better than stablecoins by enabling a dollar equivalent balance backed by $FLOW tokens.

ICHI, a Flow partner, will launch Stable Flow ($oneFLOW), a token valued at $1. Stable Flow is minted in part with FLOW tokens and redeemable for fiat-backed stablecoins.

Developers will be able to easily build $oneFLOW into their apps for DeFi, peer-to-peer payments, charging for services, or enabling consumers to earn rewards for the value they create. In addition, $oneFLOW will be able to fund affiliate bonuses to these developers from the yield earned by the assets backing $oneFLOW.

Experienced Required

• Good understanding of Cadence and storage model
• Good understanding of Solidity
• Familiarity with smart contract application architectures
• High-level understanding of Flow's architecture (block production, transaction states, etc.)

Minimum Feature Set (Acceptance Criteria)

• oneToken Factory
  • A contract that acts as a oneToken deployment mechanism.
• oneToken Vault
  • A contract owned by oneToken Governance that holds assets, mints and burns ERC20 tokens, and controls the process flow during the minting and redemption process, including coordinating modularized components.
• Mint Master
  • A Mint Master uses any available information to compute the current minting ratio.
• Strategies
  • Trading contracts that invest funds in yield-farming contracts, receive other types of tokens and report balances of each type of token they hold.
• Controller
  • A global contract that executes the appointed strategies for a given oneToken Vault at the specified period of time.

Extension (Optional) Feature Set

• ICHI Governance Model
  • Global governance controls the oneTokenFactory and manages global parameters. Governance itself is external to the oneToken system.
• oneToken Governance Model
  • Governance of specific oneToken instances with user votes weighted by their holdings of the corresponding oneTokens in specific liquidity pools

Milestone Requirements

1. Create wireframes an architectural software diagram for Cadence implementation of the minimum feature set.
2. Implement an MVP of the oneFLOW token contract including mint master.
3. Implement an MVP of the oneToken Factory contract
4. Implement strategies for the oneToken Vault

Software Requirements
Maintainability

• The tools or libraries used to construct the solution should be well vetted and well maintained
• Code should be written in a way that can be extended with new functionality and clear enough for open-source developers to contribute to.

Testing

• All core logic should have unit tests.
• Each feature implemented should be tested by an end-to-end (E2E) test.

Other Requirements
Documentation

• The following pieces of documentation needs to be completed alongside the code for a successful submission:
  • Installation Guide: How to get this application up and running.
  • Usage Guide: A highlight of all the features available and how to use them.
  • Contribution Guide: A thorough explanation of the codebase, where features are located, a diagram explaining complex interactions, etc. This is intended to be a primer for new contributors that would like to add or modify features.

Judging Criteria
For all projects, technical & high-level judging criteria apply.

Resources
ICHI Documentation: https://docs.ichi.farm/
ICHI open source code (Solidity implementation): https://github.com/ichifarm

FCL Feature: Simplify `currentUser` syntax

👋   If you are interested in working on this issue, please check out the Getting Started guide on HackerEarth!

Description (Problem Statement)

Simplify the syntax of the fcl.currentUser function into a class or object.

Experience Required (Team Required)

• JS and familiarity with FCL fcl.currentUser

Minimum Feature Set (Acceptance Criteria)

• Upon successful completion the following should be true:

import {currentUser} from "@onflow/fcl"

// before
currentUser().subscribe(callback)
// after
currentUser.subscribe(callback)

// before
currentUser().snapshot()
// after
currentUser.snapshot()

// before
currentUser().authenticate
// after
currentUser.authenticate

// before
currentUser().authorization
// after
currentUser.authorization

// before
currentUser().asArg
// after
currentUser.asArg

Milestone Requirements

• Update fcl.currentUser() from function to Class or Object syntax
• Add/Update tests
• Update Documentation - Add a description for this feature including sample code for usage in the existing API Docs

Software Requirements

• Code should be written with best practices in mind.
• Other Requirements - Error Reporting
  • Throw descriptive exceptions on errors
  • Prints a clear error message to the browser console
• All core logic should have unit tests. Include tests for success on valid data and failure

Other Requirements

• Updated Documentation describing the code, and usage

Judging Criteria

• For all projects, technical & high-level judging criteria apply.

Resources

• Existing Issue

New Tool: Add Cadence support for IntelliJ Platform

👋   If you are interested in working on this issue, please check out the Getting Started guide on HackerEarth!

Description (Problem Statement)

Visual Studio Code and Vim are currently the only code editors that support the Cadence language. We want to expand this support to additional tools so that developers can write Cadence code in the editor of their choice.

For this task, your goal is to integrate basic Cadence editing features into the IntelliJ Platform, an IDE framework developed by JetBrains. Although IntelliJ itself is a Java editor, it is possible to write a plugin that adds Cadence language support to all IntelliJ-based editors (e.g. PyCharm, WebStorm).

Experience Required

• Great proficiency with Java
• Good understanding of Language Server Protocol (LSP)
• Good understanding of the IntelliJ SDK

Minimum Feature Set (Acceptance Criteria)

• Syntax highlighting

  The Cadence Visual Studio Code extension defines a grammar for the Cadence language, which is used to support syntax highlighting. You will need to port this grammar to IntelliJ.

• Semantic analysis and error checking

  The Cadence language includes an implementation of the Language Server Protocol (LSP), defined in the Cadence repository. LSP servers are used by code editors and IDEs, most notably Visual Studio Code, to implement language-specific editor features. You can find a full list of LSP implementations on the Microsoft website.

The Cadence Visual Studio Code extension uses the LSP to report syntax problems and semantic errors (e.g. type errors) back to the developer. You will need to integrate IntelliJ with the Cadence language server to report these same errors inside IntelliJ.

IntelliJ does not support the LSP out of the box; you will need to use a plugin such as this: https://github.com/ballerina-platform/lsp4intellij

Milestone Requirements

1. Implement syntax highlighting for Cadence in IntelliJ.
2. Implement semantic error checking using the Cadence language server in IntelliJ.
3. Expand your plugin so that is compatible with at least one other IntelliJ Platform-based editors (e.g. Goland). The more the better!
4. Finalize your submission and publish it to the JetBrains marketplace.

Software Requirements

• Your submission should be implemented in Java as an IntelliJ plugin using this guide: https://plugins.jetbrains.com/docs/intellij/getting-started.html
• The plugin should be installable from the JetBrains marketplace.
• The source code for your plugin should be available in a public repository.

Other Requirements

Documentation

• The following pieces of documentation need to be completed alongside the code for a successful submission:
  • Installation guide

Code standards or guidelines

• Follow the general contribution guidelines.

Judging Criteria

• For all projects, technical & high-level judging criteria apply.

Resources

• Cadence language server: https://github.com/onflow/cadence/tree/master/languageserver
• Cadence syntax grammar: https://github.com/onflow/vscode-cadence/tree/master/syntaxes
• LSP support for IntelliJ: https://github.com/ballerina-platform/lsp4intellij
• Creating Your First IntelliJ Plugin: https://plugins.jetbrains.com/docs/intellij/getting-started.html

Emulator Feature: Report gas used

👋   If you are interested in working on this issue, please check out the Getting Started guide on HackerEarth!

Description (Problem Statement)

There should be a way to see transaction gas (computation) usage.

Gas usage is not the same as transaction fees. Transaction fees are currently static, but in the future they will depend on the gas used by the transaction.

Executed transactions are currently logged like this (when in verbose mode):

The transaction executed line should also include gas usage.

To get the gas usage of the transaction, you can get started here. This field gets filled after the transaction is run. This information should be intercepted on the emulator.

Experience Required

• Experience with Go
• Some understanding of the Flow's architecture

Minimum Feature Set (Acceptance Criteria)

• When executing a transaction in the emulator gas usage should be visible in the emulator logs

Software Requirements

Maintainability

• The tools or libraries used to construct the solution should be well vetted and well maintained
• Code should be written in a way where it's easily extensible to new functionality and semantic enough for open-source developers to contribute to.

Testing

• Wherever possible unit tests should be written
• Meet testing guidelines of the repo

Other Requirements

Documentation

• Edit the current documentation to add a description of this new feature

Code standards or guidelines

• Follow the general contribution guidelines.

Judging Criteria

• For all projects, technical & high-level judging criteria apply.

Resources

• General Resource Guide
• Emulator
  • Repository
  • Documentation

CLI & Emulator Feature: Flow network snapshots

Description (Problem Statement)

The developer should be able to get a snapshot of the Flow mainnet/testnet blockchain at a specific time in history and inspect it locally using the emulator. This would allow developers to debug their contracts but also to compose on top of other existing applications deployed to the network. The CLI should be extended to support this functionality by implementing AN APIs to fetch the snapshot and then start the emulator configured to read from it.

Experience Required

• Experience with Go
• Understanding of the Flow's architecture
• Understanding of Cadence

Minimum Feature Set (Acceptance Criteria)

• The CLI supports fetching the snapshot from the Flow blockchain at a specified time (block height)
• The emulator is modified so it can start from the provided snapshot and allow read operations on it

Extension (Optional) Feature Set

• Interoperability with Emulator GUI for state inspection, loading the state and all other functionality possible with this feature

Milestone Requirements

1. Provide documentation on the implementation process and details
2. Implement snapshot fetching functionality in the CLI
3. Implement the emulator so it can be started from the provided snapshot

Software Requirements

Maintainability

• Code should be written with good practices in mind and allow extensibility

Testing

• This feature should have good test code coverage

Other Requirements

Documentation

This feature must be sufficiently documented in the CLI and the Emulator.

Code Standards, Guidelines

• follow code standards already in place
• follow the CLI guidelines
• follow contribution guide

Judging Criteria

• Technical & High-Level Judging Criteria apply
• How effectively does the tool help developers in the building process in making it easy for them to debug, test, and verify their logic?

Resources

• General Resource Guide
• Emulator
  • Repo
  • Docs
  • Original Reference Issue
• CLI
  • Repo
  • Docs

CLI Feature: Test suite

👋   If you are interested in working on this issue, please check out the Getting Started guide on HackerEarth!

Description (Problem Statement)

The CLI command layer isn't tested which leaves room for mistakes and regressions when releasing. Manually testing is time-consuming and should be automated. All the command methods in this layer have been extracted and should be included as part of integration tests, passing all the values as arguments and checking the result for validity. Results should also be tested for all different formats (JSON, text, inline). Tests of other components should also be improved and overall code coverage increased.

Experience Required

• Experience with Go
• Experience writing tests

Minimum Feature Set (Acceptance Criteria)

• Command layer tests should be written and have >80% code coverage
• Overall code coverage should be increased to >70%

Extension (Optional) Feature Set

• Improve overall test suite (how tests are written)
• Improve mixture of unit tests and integration tests (integration test need to cover all the interactions), unit test should test more edge cases

Milestone Requirements

1. Command layer tests with good code coverage
2. Overall code coverage increase

Software Requirements

Maintainability

The tests should be written with good practices in mind.

CI/CD

All the tests should work with our CI/CD pipeline.

Other Requirements

N/A

Judging Criteria

• For all projects, technical & high-level judging criteria apply.
• How effectively are the tests written?
• How does code coverage increase with the time it takes to run the full suite?

Resources

• General Resource Guide
• CLI
• CLI command layer
• Existing Issue

New Standard: NFT metadata

👋   If you are interested in working on this issue, please check out the Getting Started guide on HackerEarth!

Description (Problem Statement)

NFTs are more than just numbers and bytes — at their best, they are rich representations of digital goods that people around the world can fall in love with. The current Flow NFT interface, however, does not include a metadata standard that allows these representations to flourish. NFTs should be able to include structured data, images, videos and other types of data. What modifications should be made to the NFT interface to support a variety of metadata types?

The Flow community has been discussing an NFT metadata standard over the past several months, with representation from many of the NFT applications currently live on mainnet. In recent weeks, several developers have created a concrete proposal that has gained support from the broader ecosystem. We'd love for those developers to formalize their standard and launch it as part of the Flow FLIP Fest.

This ticket is a special one. Most of the groundwork has already been done, and we're hoping that the FLIP Fest can act as the catalyst that brings that work to life. The core Flow team has reached out to the developers who are already actively engaging in this problem, but we also welcome new contributions. This isn't a winner takes all bounty — we'll be issuing rewards to the people who make the most meaningful contributions to the final standard.

Minimum Feature Set (Acceptance Criteria)

Metadata Type Structure

The standard itself should define a generic type structure that allows a variety of metadata types to be defined directly in Cadence. This standard should be implemented in Cadence as an extension of the current NFT standard.

Metadata Type Examples

With the introduction of a new standard, it's important that developers know how to use it. Your final submission should include examples of common uses cases that demonstrate 6-12 different data types. For example:

• Bitmap images (e.g. JPEG, PNG)
• Vector images (e.g. SVG)
• Videos
• Metadata that is stored in a decentralized storage storage network (e.g. IPFS)

Milestone Requirements

1. Define a rough outline of your proposal. This can be a written document (i.e. a GitHub issue), but should also include Cadence code snippets that illustrate the core concepts of the standard.
2. Document your metadata as a Flow Improvement Proposal (FLIP).
3. Using feedback from those who review your FLIP, make any necessary changes and work with the reviewers to merge a finalized FLIP.
4. After the FLIP is approved, open a pull request into the Flow NFT repository that contains the following:
   1. Your extension to the existing NFT standard.
   2. 6-12 sample metadata implementations.

Judging Criteria

• For all projects, technical & high-level judging criteria apply.
• Flexibility — does your solution support a wide variety of NFT metadata use cases?
• Extensibility — can your standard be extended to support future use cases?

Resources

• Flow NFT Standard
• Flow Improvement Proposals documentation
• Existing NFT metadata discussion

Incorrect website link

Hey, I noticed that there are incorrect links in winners.md file for our flippers team, here: https://github.com/onflow/flip-fest/blob/main/winners.md#new-tool-block-explorer-gui-2.

• "Flowser Project Website" should be https://flowser.dev instead of https://bartolomej.github.io
• "Flowser repo" should be https://github.com/onflowser/flowser instead of https://github.com/bartolomej/flowser

Those were some older links, that should better be changed.

Flow Providers: Non-custodial wallets

👋   If you are interested in working on this issue, please check out the Getting Started guide on HackerEarth!

⚠️   This is a special project outside of the existing format of FLIP Fest and requires an application to receive a custom grant structure to work on it.

Description (Problem Statement)

Flow is looking for wallet providers to join the ecosystem.

Please review our RFP (Request for Proposal) document to understand the current ecosystem and its gaps new wallets should ideally fill.

Experience Required

• Previous or current experience on blockchain wallets and their use in production environments
• Team capacity to build, support and maintain support on Flow into the long term
• Strong design, technical, and legal experience within the team

Milestone Requirements

A custom structure will be set for successful applications on a case-by-case basis.

Application

Fill out this form.

Resources

• General Resource Guide
• FCL

Playground Feature: Markdown READMEs

👋   If you are interested in working on this issue, please check out the Getting Started guide on HackerEarth!

Description (Problem Statement)

Flow developers use the playground to learn, experiment, and share Cadence code. Often times, playground project links are passed around as examples and learning materials for others to use. However, the playground does currently do not provide developers with a way to describe what their projects do and how their code works.

The goal of this task is to add a feature to the playground that allows developers to add a written description to their projects, similar to README files in git repositories.

Experience Required

• Strong proficiency with TypeScript and React (frontend)
• Good proficiency with GraphQL
• Good proficiency with Go (backend)
• Good understanding of Cadence
• Good UX/UI design ability

Minimum Feature Set (Acceptance Criteria)

• There should be a section of the playground UI that allows the project owner to enter the following information:
  • A title for the playground project
  • A (brief) description of the playground project
  • A README in Markdown format.
• For viewers of the playground project, the README should render as HTML.
• The title and description should populate the page title and description metadata tags.

Extension (Optional) Feature Set

• Allow the project owner to include clickable links in the README to switch between accounts, transactions and scripts.

Software Requirements

• Your code (both frontend and backend) must prevent any forms of attacks on users. Markdown code should be always sanitized.
• Please follow the existing design patterns used in both the frontend and backend codebases.
• Whenever possible, consider using existing 3rd-party libraries (e.g. for Markdown rendering).

Milestone Requirements

1. Create wireframe mockups for the new UI.
2. Implement UI changes.
3. Add support for storing and loading the README data on the frontend.
4. Add support for storing and loading the README data on the backend.

Resources

• Playground frontend repository
• Playground API repository

JS Testing Feature: Multiple return values from interaction

👋   If you are interested in working on this issue, please check out the Getting Started guide on HackerEarth!

Description (Problem Statement)

The JS Testing Framework has two functions: sendTransaction and executeScript that currently return a single result from their execution. It does not have a good way of handling errors that should be caught and processed. This can cause issues with multiple interactions called in succession.

Experience Required

• Great proficiency with JavaScript
• Good understanding of Cadence and Flow JS SDK

Minimum Feature Set (Acceptance Criteria)

• Catch error inside interaction code and always return tuple [result, error].

• This should make it easier to assert the result of interaction using jest and other libraries.

• Flow Cadut interactions are already implemented in such a way (refer to this piece of code as an example - https://github.com/onflow/flow-cadut/blob/main/src/interactions.js#L55-L63) so it's mostly a refactoring task.

Extension Feature Set (Optional)

Parse error message and provide an error in form of an object, containing at least errorCode, message. If possible extract more information and format it in a human-readable and usable way.

Milestone Requirements

1. Meet the minimum feature set and optionally the extension.

Software Requirements

Maintainability

Code should be written with best practices in mind.

Other Requirements

Documentation

• Documentation should be updated according to the changes made.

Code standards or guidelines

• Follow the general contribution guidelines.

Judging Criteria

• For all projects, technical & high-level judging criteria apply.

Resources

• General Resource Guide
• Flow JS Testing
  • Repository
  • Flow Cadut

CryptoDappy Feature: localization (I18n) solution

👋   If you are interested in working on this issue, please check out the Getting Started guide on HackerEarth!

Description (Problem Statement)

CryptoDappy is a community-owned learning application for Flow. As our international audience grows, we would like to offer our learning content in different languages. Community members have already published some translated documents (e.g. Vietnamese version), but the basic functionality of changing the language on the Learning Hub has not been implemented yet. We're looking for a solution like this official Gatsby example, that uses the existing mdx files and allows for future language-specific mdx files to be added. The future translations will be handed in like this.

Experience Required (Can be done as an individual or as a team)

• Basic JavaScript: React, Gatsby

Milestone Requirements

• I18n solution & add language-selection dropdown in navbar

Software Requirements

• Testing

Other Requirements

• Documentation of the steps taken

Judging Criteria

• Quality of code implementation

Resources

• CryptoDappy Learning Hub repository
• Gatsby - Using I18n
  → This paradigm should be used as a guide for your implementation in some way

CLI Feature: Add view command

👋   If you are interested in working on this issue, please check out the Getting Started guide on HackerEarth!

Description (Problem Statement)

The flow CLI configuration command should be expanded with the view subcommand to retrieve values set in the configuration for all the resources.

Configuration syntax:

flow config view <resource>

Example usage:

`flow config view accounts` - would list all accounts
`flow config view deployments testnet` - would list all deployments for testnet
`flow config view accounts Foo` - would list all properties on the Foo account

Experience Required

• Experience with Go

Minimum Feature Set (Acceptance Criteria)

• Implement view subcommand with updated documentation and examples

Milestone Requirements

1. Meet minimum feature set

Software Requirements

Maintainability

Code should be written with best practices in mind.

Testing

Tests should cover all the code implementing this functionality.

Other Requirements

Documentation

• Documentation should be updated according to the changes made.

Code standards or guidelines

• Follow the general contribution guidelines.

Judging Criteria

• For all projects, technical & high-level judging criteria apply.

Resources

• General Resource Guide
• CLI
  • Repository
  • Design guidelines

Playground: Fix client-side errors in the playground frontend

👋   If you are interested in working on this issue, please check out the Getting Started guide on HackerEarth!

Description (Problem Statement)

The Flow Playground frontend app throws a number of console errors in product. Those errors shouldn't be there.

Each error is documented in an issue:

• onflow/flow-playground#163
• onflow/flow-playground#164
• onflow/flow-playground#165
• onflow/flow-playground#166

Your task is to eliminate these errors and, when applicable, refactor the code to avoid similar errors in the future.

Experience Required

• Familiarity with JavaScript
• Familiarity with React

Milestone Requirements

1. Eliminate each error referenced in the issues above. When applicable, refactor the code to avoid similar errors in the future.

Other Requirements

Code standards or guidelines

• Follow the general contribution guidelines.

Judging Criteria

• For all projects, technical & high-level judging criteria apply.

Resources

• General Resource Guide
• Flow Playground repository

Non-React FCL Usage: dapp example

👋   If you are interested in working on this issue, please check out the Getting Started guide on HackerEarth!

Description (Problem Statement)

While using FCL is possible in non-react example, we do not have many examples in the community of this usage. There are some issues with installing the FCL package directly due to packages used to support GRPC. This issue is to have teams work on examples that demonstrate usage of FCL in a full-stack example dapp in similar complexity to our other popular community example, Kitty Items and CryptoDappy.

Valid front-end frameworks are:

• Vue
• Angular
• Svelte
• We will consider other frameworks proposed.

Experience Required

• Experienced in JavaScript and the framework proposed.
• High level understanding of Flow's architecture (block production, transaction states, etc.)
• Good understanding of design principles and UI/UX

Minimum Feature Set (Acceptance Criteria)

Appropriate usage of all FCL APIs

• The example dApp demonstrate the latest and best usage of the most common FCL APIs via features in the dapp
• FCL discovery and non-custodial wallet features are used

Effective use of state management

• Demonstrate the best way to manage state while interacting with FCL in your chosen framework.

Well Documented & Optimized for Learning

• Features in the dApp are intended to demonstrate common patterns or use cases for dApp developers to use and learn
• Code is easy to read, semantic to the framework, and reflective of best practices
• Feature set of the dApp is comparable to the examples listed in the description.

Extension (Optional) Feature Set

Usage of other community tools

• Integrate additional tooling or services in the Flow Ecosystem into your dApp.
  • Examples include: Wallet API, Graffle, Moonpay, etc.

Milestone Requirements

1. A full stack dApp that can demonstrate FCL usage with clear documentation and usage patterns that meet the above requirements.

Software Requirements

Maintainability

• The tools or libraries used to construct the solution should be well vetted and well maintained
• Code should be written in a way that can be extended with new functionality and clear enough for open-source developers to contribute to.

Testing

• All core logic should have unit tests.
• Each feature implemented should be tested by an end-to-end (E2E) test.

Other Requirements

Documentation

• The following pieces of documentation need to be completed alongside the code for a successful submission:
  • Installation Guide: How to get this application up and running.
  • Usage Guide: A highlight of all the features available and how to use them.
  • Contribution Guide: A thorough explanation of the codebase, where features are located, a diagram explaining complex interactions, etc. This is intended to be a primer for new contributors that would like to add or modify features.
  • Deployment Guide: How to run your demo dapp in a production environment.

Code standards or guidelines

• Follow the general contribution guidelines.

Judging Criteria

• For all projects, technical & high-level judging criteria apply.
• How effectively does the tool help developers coming from the framework chosen onboard onto Flow and demonstrate FCL usage?

Resources

• General Resource Guide

Improve Existing SDK: Python

Description (Problem Statement)

​
This issue is relevant if you wish to continue the work on the existing Python SDK . If you wish to create a new python SDK, this is the right issue for you.
​
Currently, the Flow python SDK is not yet in a release-worthy condition, however, a significant amount of work has already been done:
​

• Cadence JSON parsing
• Sending scripts
• Getting script results
• Sending transaction
• CI framework and release flow
  ​
  The missing parts are:
  ​

1. More tests
2. A rework of the examples so they follow the user stories in the SDK Guidelines
3. Documentation:
   1. Installation
   2. Usage
   3. Contribution
4. Optimise for performance and usage
   ​

Experience Required

​

• Experience with python
• High-level understanding of Flow's architecture (block production, transaction states, etc.)
• Understanding of gRPC
• Understanding of the Flow Access API
  ​

Minimum Feature Set (Acceptance Criteria)

​
Meet the SDK Guidelines
​

• View the SDK Guidelines and implement your SDK accordingly.
  ​

Extension (Optional) Feature Set

​
Additional Functionality
​

• Identify and create methods that abstract common patterns to make it easier for developers to employ these patterns in their dapp.
  ​
  Some possible functionalities are:
  ​
• Transaction templates for common transactions (like creating accounts, transferring FLOW, adding keys, ...)
• Automatically fetching the reference block when submitting transactions so the user does not need to writhe extra code to do that.
• An event subscription mechanic
  ​

Milestone Requirements

​

1. Implement examples covering all user stories.
2. Create tests, documentation, and optimize for performance and usability.
   ​

Software Requirements

​

• All requirements listed in the SDK Guidelines
• Production-ready code: The SDK is expected to be used in production by third parties and so it should be secure, performant, and ready to use out of the box with minimal configuration.
  ​

Other Requirements

​
Documentation
​

• The following pieces of documentation need to be completed alongside the code for a successful submission:
  • Installation Guide: How to get this application up and running.
  • Usage Guide: A highlight of all the features available and how to use them.
  • Contribution Guide: A thorough explanation of the codebase, where features are located, a diagram explaining complex interactions, etc. This is intended to be a primer for new contributors that would like to add or modify features.
    ​
    Code standards or guidelines
    ​
• Create code guidelines based on the best practices of the language chosen - attempt to be as semantic as possible to that language. Follow these guidelines during development, and assess against them for new contributions.
  ​

Judging Criteria

​

• For all projects, technical & high-level judging criteria apply.
• How easy and comprehensive is the SDK to use for Flow developers?
• How many use cases does it cover?
• How complex is it to learn and use?
• How performant is it to use in production?
  ​

Resources

​

• General Resource Guide
• SDK Guidelines
• Current SDKs

Playground Feature: Multiple contracts per account

👋   If you are interested in working on this issue, please check out the Getting Started guide on HackerEarth!

Description (Problem Statement)

Flow developers use the playground to learn, experiment, and share Cadence code. The current playground model only supports a single account to have a single contract. We want to expand this feature to hold multiple contracts per account. This will require changes to the UI as well as the backend.

Experience Required

• Strong proficiency with TypeScript and React (frontend)
• Good proficiency with GraphQL
• Good proficiency with Go (backend)
• Good understanding of Cadence
• Good UX/UI design ability

Minimum Feature Set (Acceptance Criteria)

• Playground UI shows contracts per account and actions to be able to:
• Add, delete, and switch between contracts.
• Backend is able to support the UI and persist these contracts and accounts

Extension (Optional) Feature Set

Implement a variable number of accounts. The current number of accounts is limited to five but can be expanded to support fewer or more accounts as needed by the user.

Software Requirements

• All existing features must remain unaffected with the introduction of this feature.
• Please follow the existing design patterns used in both the frontend and backend codebases.

Milestone Requirements

1. Create wireframe mockups for the new UI that demonstrate how the feature will be added. Include a rough description of the backend changes needed to support the proposed UI.
2. Implement designed interactions, following existing style
   1. Implement necessary changes on the back-end side
   2. Implement necessary changes on the front end to consume the updated account information.

Resources

• Playground frontend repository
• Playground API repository

CryptoDappy Feature: NFT marketplace

👋   If you are interested in working on this issue, please check out the Getting Started guide on HackerEarth!

Description (Problem Statement)

CryptoDappy is a community-owned learning application for Flow. As of now, only direct NFT purchases from the main contract are possible. We want to give users the experience to list their Dappies (NFTs) for sale in order to sell them to other buyers, and give buyers a chance to purchase Dappies of other users. To achieve this, let the NFT-storefront contract be your guide.

Experience Required (Can be done as an individual or as a team)

• Basic JS (React), FCL, and Cadence knowledge
  → Can be obtained by completing the course on https://www.cryptodappy.com beforehand

Milestone Requirements

1. Frontend implementation (Week 1)
2. Smart contract implementation, documentation & video walkthrough (Week 2)

Software Requirements

• Testing
• Usage of NFT storefront contract

Other Requirements

• Documentation of the steps taken (creation of new mission on learning hub)
• Recording a video walkthrough of the code solution
• Creation of a Mission page on CryptoDappy Learning Hub

Judging Criteria

• Quality of code implementation
• Easy user experience
• Good and easy-to-follow documentation on the CryptoDappy learning hub (equally important as the other points)

Resources

• CryptoDappy application repository
  → The actual learning application as seen on https://demo.cryptodappy.com
• CryptoDappy Learning Hub repository
  → This is where the documentation goes
• NFT-Storefront contract
  → This contract should be used as a guide for your implementation in some way

closed

None

CLI Feature: Launch FCL development wallet

👋   If you are interested in working on this issue, please check out the Getting Started guide on HackerEarth!

Description (Problem Statement)

Currently, when developing Flow applications locally, the FCL dev wallet must be started as a separate Docker container on the user's machine.

While having a Dockerized version of the dev wallet may be useful without the emulator for specific scenarios, such as a testnet demonstration app, the overwhelming majority of the time, users will want to use the two tools together for local development.

Local development on Flow is complex. This effort seeks to remove the burden of startup and configuration of the dev wallet, removing one more source of configuration errors in local development.

This effort proposes bundling the dev wallet server as part of the emulator, and starting the wallet service alongside the emulator when working locally, removing the necessity for users to configure and run the dev wallet docker container manually.

Experience Required

• Familiarity with Go
• Familiarity with the Flow CLI
  Familiarity with the Flow Emulator
• Familiarity with bundling a JS client-server application into a discreet runnable program.
• Familiarity with WASM as a packaging format (bonus, not required)

Minimum Feature Set (Acceptance Criteria)

• Dev wallet is configured and runs on emulator startup
• CLI flag for starting the emulator without the wallet
• CLI displays FCL configuration information stdout (code snippet indicating how to connect FCL to the dev wallet service)
• Debugging output for dev wallet service (preferably as a tail or logs command similar to Heroku eg flow dev-wallet logs --tail)

Milestone Requirements

1. Create a mockup demonstrating the UI/UX for this feature
2. Add FCL dev wallet code to the emulator
3. Run dev wallet in a separate (or, supervised?) process on emulator startup
4. Users can work with the dev wallet without using Docker

Software Requirements

Maintainability

• The tools or libraries used to construct the solution should be well vetted and well maintained
• Code should be written in a way where it's easily extensible to new functionality and semantic enough for open-source developers to contribute to.

Testing

• All core logic should have unit tests.
• Follow testing guidelines on the respective repositories you need to modify.

Other Requirements

Error Reporting

• The dev wallet should report an error when it cannot connect to the emulator.
  • Prints a clear error message to the browser console
  • Displays what is expected (connection string for the emulator ...etc)

Documentation

• The following pieces of documentation needs to be completed alongside the code for a successful submission:
  • A quick walkthrough guide for this feature with screenshot examples.
  • Add usage to the existing CLI Docs

Code standards or guidelines

• Follow the general contribution guidelines located here.

Judging Criteria

• For all projects, technical & high-level judging criteria apply.
• The UI should be easy to understand for newcomers to Flow development.
• Extra points for functionality related to accounts not explicitly mentioned in this outline.

Resources

• General Resource Guide
• FCL Dev Wallet
  • Repository
• Emulator
  • Repository
  • Documentation
  • Original Reference Issue
• CLI
  • Repository
  • Documentation