tablelandnetwork / funding Goto Github PK

View Code? Open in Web Editor NEW

0.0 0.0 0.0 1 KB

The home for Tableland's public facing grants, bounties, funding opportunities, and associated discussions

funding's People

Contributors

Watchers

funding's Issues

Reputation tracking for Pfp owners or DAO members

Objectives

Note: tableland is currently working on the functionality needed to complete this grant. This doc will be updated as that work is completed. For Grants that you can start work on immediately have a look at our [Grants & Funding Page.

Many DAOs (and NFT owner groups) struggle a bit with how to track reputation, roles, and access control in the community. With Tableland, a developer can create an open reputation tracking system where many different types of tooling can be built.

Tableland is currently only supported on Rinkeby testnet everything in this Grant will be built on top of Rinkeby. The NFT collections can be chosen by the developer. The result of this grant will be an open source example application that is possibly showcased by Tableland.

For this grant you will create a Tableland table where each row represents an NFT within a collection. You will then give access to vote(i.e. +1) on NFTs to anyone who owns an NFT in the collection.

The rules around voting are as follows:

An address can only vote on an NFT once.
An address must own an NFT in the collection to vote. If the NFT they own is sold, their votes will still be counted.
An address can’t vote for an NFT that they own.

This grant includes building a way to View the NFTs in collection you choose, which will include the UI to vote for the NFTs, assuming you are an owner. Non-owners can simply view the NFTs. You can choose any NFT collection that is on Rinkeby, example:

opensea.io/collection/azuki-god

This part is key: As an NFT is upvoted, the border of the NFT changes to indicate that it’s been upvoted. How this border changes up to you, have fun with it and make something cool!

Timeframe

From the time of accepting this grant to meeting the final deliverable should be no more than 40 days.

Milestones

Milestone 1

Overview

The amount of Rinkeby ETH for this grant is limited so the number of NFTs we will have to work with and the rules of the border will depend on that.

For this milestone you will need to select an NFT collection that exists on Rinkeby that you want to use. For this you will work with the Internal DRI to purchase at least two of the NFTs. Ideally this purchase can be done via Opensea’s rinkeby testnet.

You will also need to define what the different borders are and how they will change with votes. Depending on how many of the NFTs we can control the border will need to change with only one vote, hopefully we can get closer to 10 NFTs and make the border changes more interesting.

Docs and critical links

Acceptance criteria

There is an NFT collection selected to work with the application, and the Grant winner and Internal DRI both own at least one.
The different borders are defined in a way that lets the Internal DRI can see them and approve them.

Milestone 2

Overview

For this milestone you will need to create the voting table(s) in Tableland. This will involve defining the table schema(s) in a way that enables all the business logic described above in the main overview.

You will also need to construct the table updates and inserts access control. As of this writing the features needed to do this are a work in progress. This will depend on the outcome of that work, but the completion of this milestone will involve writing a script that creates the needed tables, and writing a smart contract that handles the access control. The Internal DRI will be able to help you with this, and a generic template of the smart contract should be available.

Docs and critical links

Acceptance criteria

Table(s) needed for the application are created.
Access control work is completed.

Milestone 3

Overview

In this milestone the application that enables owners of the NFTs to vote, and the public to view the collection will be completed. This application will be similar in structure to those found at https://github.com/tablelandnetwork/example-apps. The application will be deployed to IPFS via Textile Hub or a similar persistent IPFS endpoint service.

Docs and critical links

Acceptance criteria

The Internal DRI can deploy the application locally.
There is a README.md document that describes deploying the application and how the application works from a high level.
The application is publicly available via a persistent IPFS endpoint.

Award amount

TBD

Integration Guide: Pinata

Bounty

One bounty of 0.1 ETH to be given out to the project that creates an effective and well-designed integration guide for demonstrating the use of Pinata with Tableland.

Pinata builds tools and infrastructure for all creators to easily create and manage content on IPFS. Tableland is a network and relational metadata protocol for EVM chains like Ethereum. Built for developers, NFT creators, and web3 visionaries. Developers use familiar SQL tables to read and write dynamic NFT metadata or application data–all orchestrated by token networks like Ethereum.

Objectives

Create a fully flushed out documentation style integration guide, showcasing how Tableland can be used in conjunction with Pinata.
You’ll get access to an early API and be asked to self-onboard and explore the APIs to understand the Tableland product, plus you will be required to onboard to Pinata/SDK on your own.
The main output should be a Playbook document, similar to this example, plus a short (5min) recorded video showcasing the integration (e.g. on Loom).
Bonus, we ask that you document any bugs or rough edges discovered during your experience.

Timeframe

~4 hours

Apply

When submitting your application, please include at least one publicly viewable example of prior experience working with Pinata APIs.

After you’ve applied via GitCoin, feel free to ping us on Discord so we don’t miss it. Review wait times vary, but anticipate 1-2 weeks in most cases while the Grants committee reviews your proposal.

Embedded dynamic content in written immutable media

Objectives

Demonstrate content tables on Tableland by allowing content creators to embed Tableland table data on a webpage with predefined styling. The content creator will own the Tableland table and be able to update it, hence allowing a static blog post to have dynamic content.

The outcome of completing this grant will be a web app that is hosted via Textile Hub of via IPFS in some way. For examples of existing Tableland web apps look to https://github.com/tablelandnetwork/example-apps. The web app you will be making will be a “dashboard” that allows the user to create Tableland tables with a specific choice of schema, then populate them with data via a form. The web app will also allow you to copy an embed script that works similar to how you can embed youtube videos. The user can then put the embed script in the webpages as they see fit.

The 2 types of schema we want to support:

“List”: This table will have the following columns (title, url, content, style)
For each row in one of these tables the embed script will create an item in an html list where the content of the title column is bold text, and if url is specified the text will be an anchor tag to that url. The content column value will follow the title and be plain text. The style column will be either ol or ul, this will indicate to the embed script what kind of html list to use.
“Table”: This table will allow the user to select what columns they want to create, and it will be displayed as an html table. The user will add and remove rows as they see fit, and every cell value will be interpreted as a String which becomes plain text when the embed script renders it on the page.

The embed script will have a url custom to the table being embedded. The script itself will be hosted via IPFS, this can leverage Textile Hub. You have freedom to write the script as you see fit, but it should sanitize the values and ensure that no mirrored xss or csrf attacks are possible.
The queryable table name and the type of schema may be set using querystring parameters, but if you have a different idea feel free to implement however it works best.

Timeframe

From the date this grant is awarded to the completion and delivery of all milestones should be no more than 21 days.

Milestones

Milestone 1

Overview

Dashboard application can be used to create and update Tableland tables.

Docs and critical links

https://github.com/tablelandnetwork/example-apps.

Acceptance criteria

Internal DRI can deploy the dashboard locally.
Internal DRI can use the dashboard to create a Table.
Internal DRI can use the dashboard to update a Table.

Milestone 2

Overview

The embed script is hosted and when put into html it creates and renders the appropriate view of the table data.

Docs and critical links

https://support.google.com/youtube/answer/171780?hl=en

Acceptance criteria

Internal DRI can embed the script on a page and see data from Tableland

Milestone 3

Overview

Full application is hosted and deployed via Textile Hub or available through IPFS **

Docs and critical links

Acceptance criteria

Any person with a Wallet equipped browser can use the app to create and embed dynamic data into immutable media (i.e. a website).
The Internal DRI has all of the code necessary to deploy the app as they seem fit.
A written description of how to deploy and any nuances to using the application is available in a readme format.

Award amount

TBD

Create owner controlled music NFT commenting

Objectives

Enable NFTs (examples: https://sound.xyz/ https://opensea.io/collection/music) to come with user commenting that is connected to the NFT and stays connected when the NFT is sold.

Tableland is currently only supported on Rinkeby testnet everything in this Grant will be built on top of Rinkeby. Songs can be chosen by the developer, potentially out of the public domain. The result of this grant will be an open source example application that is possibly showcased by Tableland.

An application should be created that allows song NFT owners to add to the song’s comments. If the NFT is sold the existing comments continue to be attached to the NFT, and the new owner can add more comments if they so choose. Note: sound.xyz currently has a feature where your comment may be replaced if you sell your nft.

The application should be a web app that can be served statically from Textile hub or an IPFS gateway of some kind. Example apps using react and vue can be found in tablelandnetwork github repository https://github.com/tablelandnetwork/example-apps. Feel free to choose any client you like, but the deliverable for this grant should include working instructions to deploy relatively easily.

The comments should be related to a specific time in the song. For example: an NFT owner might want to create a comment at the 1 minute and 37 second point in song that is specific to the lyrics at the point. You can have some leeway in how these comments are displayed, but people viewing the song should be able to see all of the comments. Comments should be sorted by track time to start, a future project may involve “favoriting” or “liking” comments and sorting based on number of likes.

The application should allow playing the song. The player should have a timeline that shows the time that is currently playing and indicate the times in the song that have comments. A user should be able to click on these indications and see the comments near that time.

example: 👇

Timeframe

From the time of accepting this grant to meeting the final deliverable should be no more than 40 days.

Milestones

Milestone 1

Overview

Create architecture/planning document that includes written description and an overview diagram of how the application will interact with Tableland, Ethereum, and/or any other actors or services. You may find it useful to create a look-and-feel design mockup as well, but that is not required.

Docs and critical links

Example network diagrams (optional) https://www.lucidchart.com/blog/network-diagram-templates
Example ERD diagrams (optional) https://www.lucidchart.com/pages/templates/erd

Acceptance criteria

Create one or more documents that clearly convey your plans for the inner workings and general layout of the application. Please ask questions and communicate regularly with the internal DRI for this project during this phase.

Milestone 2

Overview

Create dataset for use with initial development of the client. Depending on the outcome of milestone 1 you may either create mock responses to whatever services you plan to use or actually create the Tables, NFTs, etc... that will be used with the initial application.

Docs and critical links

This Rinkeby faucet seems to consistently work well. https://rinkebyfaucet.com/ You can get 0.1 ETH every 24 hours if needed. If you determine you need significantly more than that contact the internal DRI for help.
The tableland SDK docs are a great resource to build scripts that will create data in the tableland network https://docs.tableland.xyz/building/javascript-sdk. To start you may want to take the schemas defined in the planning docs from milestone 1 and write out a few simple JSON (or other format) documents that you’d like to see be returned from calls to Tableland. After that you can use this data to either create and populate the data in Tableland, or make a mock function that returns the data to your application.
Opensea has quite a few music NFTs to explore. If you have any novel ideas on how the music NFTs will work feel free to get creative. An example can be found here: https://opensea.io/collection/calvin-harris-x-emil-nava
Notice how the [Technofish 4 item](https://opensea.io/assets/0x179c356a86067418a245a11d24f252e780f1939c/35500020007) Details Token ID (I believe opensea uses tokenURI to get the link uri) link points to [JSON metadata](https://api.niftygateway.com/harrisnava/35500020007/). {"description":"TECHNOFISH 4 - The journey through hypnagogia.","background_color":"ffffff","external_url":"https://niftygateway.com/#/","image":"https://res.cloudinary.com/nifty-gateway/video/upload/v1616544002/A/CalvinHarris/TECHNOFISH_4_ow7eot.png","name":"TECHNOFISH 4 #7/50","animation_url":"https://res.cloudinary.com/nifty-gateway/video/upload/v1616544002/A/CalvinHarris/TECHNOFISH_4_ow7eot.mp4"}
Within that metadata there is an animation_url prop. This is the video and music.
For this grant you will probably want to have the tokenURI point to a Tableland gateway which will return the metadata. This metadata will likely include the addition of the comments the grant is focussed on (NOTE: Opensea doesn’t know what the idea of comments are, but the application you build will).

Acceptance criteria

Developer controls a wallet that has a balance of Rinkeby.
Tableland data, that is either mocked or hosted in tables, is available to be used by an application.
Any NFTs that will need to be deployed to Rinkeby are either deployed, or the responses from calls to Rinkeby regarding these NFTs are mocked. e.g. the NFTs for the song(s) the application will interact with exist.

Milestone 3

Overview

Create client side of the application. This will probably be the bulk of the work.

Acceptance criteria

An application that this grant’s internal DRI can deploy locally and see the working application with the Chrome, Brave, and Firefox web browsers. There should be no errors logged to the console during usage. There should be a test suite that includes at lease 70% coverage of the application code. If the developer can’t get testing and coverage setup due to an external dependency that is out of their control they can request to have this criteria waved by the internal DRI.

Milestone 4

Overview

Final Milestone: If milestone 2 included mock data, finish building out publishing the final dataset to their respective networks. Deploy the application and provide a url the public can access. Create a document outlining how the application deployment works. Create a written document that describes your experience building the application on top of Tableland.

Acceptance criteria

URL to hosted application that is open to the public.
Code base that can be deploy by following instructions written in a readme within the application repository.
Private written document that describes your experience building with Tableland. This should include anything specifically enjoyed, pain points that made building more difficult, and ideas for improvements.
Video recording of a screen share where you walk through using the application. Video would be no more than 5 minutes.

Award amount

Award based on complete delivery.

Create a SQLite-to-Solidity-String query/mutation generator

Objective

I enjoyed most of the DevEx of integrating Tableland with a recent Hackathon project (https://github.com/brandinate/Brandinate-Monorepo/blob/main/contracts/contracts/Brandinate.sol), but there was one part of the DevEx that really killed me - and that's the frequent and very error-prone string.concat query/mutation generation in Solidity for emitting on events.

I'd love a Tableland-hosted UI for generating these queries from variables, kind of like Open Zeppelin's Contract Wizard

Implementation

I'd like to implement this myself either in JS or Go.

Timeline

2 Days - A UI mockup for variable input, dropdown for choosing SQL verb, table, conditionals, etc
3 Days - The actual SQL statement to Solidity string.concat converted

Award

2,500 USDC or equivalent, maybe a Tableland NFT as well

PS

Please comment below if interested in funding this tool! Will work out specific requirements with this atomic contract template.

Finally, we could mint a Fixed-price contract on OpenQ for the escrow.

Thank you!

Integration Guide: Lit Protocol

Bounty

One bounty of 0.1 ETH to be given out to the project that creates an effective and well-designed integration guide for demonstrating the use of Lit Protocol with Tableland.

The Lit Protocol provides decentralized access control for connected web3 experiences. Companies, creators, and DAOs use Lit Protocol to grant access to content, software, and data using tokens, NFTs, and blockchain identity as keys. Tableland is a network and relational metadata protocol for EVM chains like Ethereum. Built for developers, NFT creators, and web3 visionaries. Developers use familiar SQL tables to read and write dynamic NFT metadata or application data–all orchestrated by token networks like Ethereum.

Objectives

Create a fully flushed out documentation style integration guide, showcasing how Tableland can be used in conjunction with the Lit Protocol.
You’ll get access to an early API and be asked to self-onboard and explore the APIs to understand the Tableland product, plus you will be required to onboard to the Lit Protocol/SDK on your own.
The main output should be a Playbook document, similar to this example, plus a short (5min) recorded video showcasing the integration (e.g. on Loom).
Bonus, we ask that you document any bugs or rough edges discovered during your experience.

Timeframe

~4 hours

Apply

When submitting your application, please include at least one publicly viewable example of prior experience working with the Lit Protocol.

Integration Guide: Ceramic Network

Bounty

One bounty of 0.1 ETH to be given out to the project that creates an effective and well-designed integration guide for demonstrating the use of Ceramic with Tableland.

Ceramic Network is a decentralized data network that brings unlimited data composability to Web3 applications. With Ceramic's permissionless data streaming network, you can store streams of information and ever-changing files directly on the decentralized web – and share updates with anyone in the world. Tableland is a network and relational metadata protocol for EVM chains like Ethereum. Built for developers, NFT creators, and web3 visionaries. Developers use familiar SQL tables to read and write dynamic NFT metadata or application data–all orchestrated by token networks like Ethereum.

Objectives

Create a fully flushed out documentation style integration guide, showcasing how Tableland can be used in conjunction with the Ceramic Network.
You’ll get access to an early API and be asked to self-onboard and explore the APIs to understand the Tableland product, plus you will be required to onboard to the Ceramic/SDK on your own.
The main output should be a Playbook document, similar to this example, plus a short (5min) recorded video showcasing the integration (e.g. on Loom).
Bonus, we ask that you document any bugs or rough edges discovered during your experience.

Timeframe

~4 hours

Apply

When submitting your application, please include at least one publicly viewable example of prior experience working with the Ceramic.

Create modifiable asset functionality as the user plays

Objectives

Main objective is to allow the image of a user’s NFT to change as they move through a Loot game.

Tableland is currently only supported on Rinkeby testnet everything in this Grant will be built on top of Rinkeby.

To start, see the NFT Metadata example in the Tableland docs. You can configure your game to change those responses based on how the user is playing the game.

For an idea how the game could function consider both the Loot Extension example app and the Loot Character associative NFTs.

Details:

The Loot Extension example app For some background on Loot: A Loot Bag is an NFT that has 8 properties (Weapon, Chest Armor, Head Armor, Waist Armor, Foot Armor, Hand Armor, Necklace, Ring). Each bag has a unique set of these properties.
The Loot Extension example app lets the player choose loot bags to play with (Note: you don’t need to own the bags). For each of the 8 property types within a Loot Bag the player can choose which bag to select from. The game defines 4 rankings (Strength, Speed, Stealth, Charm) and the associated numeric values for all of the possible Loot Bag property values. Note: the values of these 4 rankings were invented by the extension developer. Once the player has selected a specific bag for each property type, there is a total value given for each of the 4 rankings. This grant will involve building a more complex game that has “challenges” that requires certain values for certain rankings in order to complete the challenge.

The Loot Character NFTs are an image that is a combination of 8 png “layers” that each correspond to one of the 8 items in a Loot Bag. The actual png images making up the layers are available here and here. To see them in action you can look at LootCharacter.com.

This Grant: When a user wants to play game you will be building they will first mint a token (NFT) in a Smart contract you have deployed and connected to a tableland table as explained in the Docs linked above. This NFT is a “Player”, for lack of a better term. The metadata of the Player NFT is stored in tableland and as the player plays the game the metadata will change. Specifically a mashup of png layers will be created based on the way they use items from the 3 Loot Bags they are playing with.

This may all seem complicated, so lets talk through a specific example of how playing the game would work:

The user is either prompted to mint a Player NFT, or choose a Player that they already own. (NOTE: they can have more than one).
The user chooses three bags of loot to play with.
The Player selects a challenge. You should give the challenge a cool name and description that fits with the Loot’s adventures based theme. You can determine how much you want to tell the Player about whats required of the Challenge at the outset and during play.
The Player is somehow shown that in order to complete the challenge they need some (or all) of their rankings be in a given range. For example: To complete the “Mountain Crossing Challenge” they might need Speed above 4 and Strength above 1. Keep in mind that these values can be negative and a challenge could involve have a value below a given threshold.
The Player selects which bag to use for each of the 8 properties of a Loot Bag (Weapon, Chest Armor, Head Armor, Waist Armor, Foot Armor, Hand Armor, Necklace, Ring) with the goal of getting all of their ranking totals to be within the range for the challenge.
This part is key: As the player changes their loot bag selections, a Loot Character is shown with the png layers that map to the selected bag’s chosen property. I.e. if bag #1 is chosen for Weapon, Chest Armor, Head Armor, and Waist Armor, and bag #2 is chosen for Foot Armor, Hand Armor, Necklace, and Ring. The Loot Character image you see will be made of 4 png layers from bag #1 and 4 png layers from bag #2.
Once the Player has specified properties of bags that meet the challenge, they see text and a button appear that indicate that they can complete the challenge and update their Player NFT image with the Loot Character layer mashup image.
Clicking the button will trigger the updates needed to the Tableland table that is storing their Player NFT metadata. This means that when they look at their player NFT they will see the mashup image.

Timeframe

From awarding of this Grant to the all milestones being delivered will be no more than 40 days.

Milestones

Milestone 1

Overview

Generate and deploy the NFT smart Contract to Rinkeby, and deploy a version of your application that allows minting of a Player NFT.

Docs and critical links

Acceptance criteria

Able to interact with your application and Mint a Player NFT by either deploying the code locally or navigating to a public URL.
Must verify the Smart Contract and minted NFT exists via rinkeby.etherscan.io/.

Milestone 2

Overview

A user is able to play the game and see the changes to their Player NFT on etherscan.

Docs and critical links

Acceptance criteria

A user can select which Player they want to use.
A user can select a challenge and see what rankings are required.
A user can select 3 loot bags to play with and as they select different bags they see the loot character mashup change.
When the criteria are met they can update they Player NFT’s metadata.

Milestone 3

Overview

The game is deployed to Textile Hub or via IPFS somehow.

Acceptance criteria

The game can be played by anyone with a web browser that has a Wallet setup. Note: Should support Chrome with Metamask and Brave, anything else is optional.
Instructions for deploy locally and to IPFS are written in a readme.

Award amount

TBD

Integration Guide: Arweave

Bounty

One bounty of 0.1 ETH to be given out to the project that creates an effective and well-designed integration guide for demonstrating the use of Arweave with Tableland.

Arweave is a new type of storage that backs data with sustainable and perpetual endowments, allowing users and developers to truly store data forever – for the very first time. Tableland is a network and relational metadata protocol for EVM chains like Ethereum. Built for developers, NFT creators, and web3 visionaries. Developers use familiar SQL tables to read and write dynamic NFT metadata or application data–all orchestrated by token networks like Ethereum.

Objectives

Create a fully flushed out documentation style integration guide, showcasing how Tableland can be used in conjunction with the Arweave.
You’ll get access to an early API and be asked to self-onboard and explore the APIs to understand the Tableland product, plus you will be required to onboard to the Arweave/SDK on your own.
The main output should be a Playbook document, similar to this example, plus a short (5min) recorded video showcasing the integration (e.g. on Loom).
Bonus, we ask that you document any bugs or rough edges discovered during your experience.

Timeframe

~4 hours

Apply

When submitting your application, please include at least one publicly viewable example of prior experience working with Arweave.

Integration Guide: The Graph

Bounty

One bounty of 0.1 ETH to be given out to the project that creates an effective and well-designed integration guide for demonstrating the use of The Graph with Tableland.

The Graph is an indexing protocol for querying networks like Ethereum and IPFS. Anyone can build and publish open APIs, called subgraphs, making data easily accessible. Tableland is a network and relational metadata protocol for EVM chains like Ethereum. Built for developers, NFT creators, and web3 visionaries. Developers use familiar SQL tables to read and write dynamic NFT metadata or application data–all orchestrated by token networks like Ethereum.

Objectives

Create a fully flushed out documentation style integration guide, showcasing how Tableland can be used in conjunction with The Graph.
You’ll get access to an early API and be asked to self-onboard and explore the APIs to understand the Tableland product, plus you will be required to onboard to The Graph/SDK on your own.
The main output should be a Playbook document, similar to this example, plus a short (5min) recorded video showcasing the integration (e.g. on Loom).
Bonus, we ask that you document any bugs or rough edges discovered during your experience.

Timeframe

~4 hours

Apply

When submitting your application, please include at least one publicly viewable example of prior experience working with The Graph.

Create NFT gallery metadata owned by each user

Objectives

Build a Tableland app that serves as a an NFT viewing gallery. Your app should be deployable to an IPFS based solution like Textile HUB, or similar. To get ideas how Tableland applications work you can browse through the existing example applications here.

Tableland is currently only supported on Rinkeby testnet everything in this Grant will be built on top of Rinkeby.

Anywhere in Web3 where users need to create their own galleries, those settings (the metadata) are probably being stored off-chain.

A simple example is in OpenSea, where you have the ability to hide specific NFTs from your collection.
More advanced examples include Oncyber.io where you can build a 3D space that showcases your favorite NFTs.
Or, JPG.space where you can not only showcase your favorites, but add additional data (metadata) to them for display.

Instead of storing that user generated preference list offchain, do it with a table! Simply create a schema for the users and then generate a new table per user right in your apps. That table can be assigned to the user (so they own it and can edit it) but not allowing them to change the schema. Then, your app just needs to consume whatever the users has added to their gallery settings.

Timeframe

From awarding of this Grant to the all milestones being delivered will be no more than 40 days.

Milestones

Milestone 1

Overview

Design and document the application. If you have any cool ideas feel free to get creative, or if you want to keep it simple that’s ok too.

Docs and critical links

Acceptance criteria

Create a list of pages that your application will have.
Create a set of mockups that show what the application will look like to a user.
Create a document that describes what the schemata of the tables in your gallery will be. If you prefer you can skip the document and just provide the SQL statements that will be used to create the table.

Milestone 2

Overview

Build your application using Tableland via Rinkeby Testnet. This will be the bulk of the work. As mentioned above you can look through the example applications to get a sense of how your application should be structured. One of the key aspects of a Tableland application is that it should be serve-able as a static site, and able to be deployed to an IPFS style URI. The user’s browser will need to be compatible with a Wallet, Chrome with Metamask and Brave should be supported at a minimum.

Docs and critical links

Acceptance criteria

Provide a code base that can be deployed locally by the Internal DRI.
The application works as expected using both Chrome + Metamask and Brave. On top of working correctly, at no point during usage should any application errors show in the console.
A README.md file should explain how to deploy the application, and using the application should be intuitive enough to not need an explanation.

Milestone 3

Overview

Permanently deploy the application to either Textile Hub or another IPFS gateway.

Docs and critical links

https://docs.textile.io/hub/](https://docs.textile.io/hub

Acceptance criteria

The application is publicly available.

Award amount

TBD