drewcook/arbor-ui

A collaborative, music-making NFT platform for artists and collectors, built on Ethereum.

Hi, I'm Drew (dco) 🤙🏼

I'm a fullstack developer working in Web3 🚀

Currently, I'm building Alkimiya Protocol with a stellar team! We are creating financial markets around blockspace primitives like Bitcoin transaction fees and Ethereum base gas fees ⏳

Some impact I've made previously:

• Full-time core contributor to the Aave Protocol, on the app interface and developer SDKs
• Built a winning ETHDenver '22 hackathon project with the Arbor Protocol, a collaborative music NFT platform with royalties
• Graduated from Zero-Knowlege University as part of Cohort 3
• Joined HarmonyZKDAO with an incubation project using ZK, allowing DAO members to contribute to and get paid through Coordinape
• Launched an NFT collection with Enlightened Lizards to tap into an existing micro-economy/community around a musical artist
• Have done smart contract auditing through the Secure3 platform, mostly defi projects
• I've even implemented dark mode on Vitalik's blog (Check out his tweet) 🆒

I really enjoy working on open-source projects and being a part of the Ethereum community 💪

When I'm not writing code, I write and produce music in my spare time

Check out my Audius page 🎸

---

arbor-ui's Issues

Convert the singular ERC-721 collection into ERC-1155 multi-token collection

Use ERC-1155 Multi-token Collections for NFTs

User Story

As a user, I should be able to see each Arbor project as its own collection with different token IDs representing versions of that project.

Acceptance Criteria

• The PolyechoNFT.sol contract should be renamed to ArborCollection.sol
• The collection contract should implement an ERC-1155 multi-token standard
  • Should use OpenZeppelin since we are already using their contracts
• The collection should include royalty splits
• The collection should work with NFT marketplaces like OpenSea and Rarible
• Should minimize gas costs as much as possible, improving the existing contract’s usage
• The contract is deployed on all the relevant networks
• The contract address is updated on all documentation
• The contract is verified on Etherscan and other block scanners

Notes

• EIP-1155: https://eips.ethereum.org/EIPS/eip-1155
• OpenZeppelin v4 implementation: https://docs.openzeppelin.com/contracts/4.x/erc1155

Is your feature request related to a problem? Please describe.

A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe the solution you'd like

A clear and concise description of what you want to happen.

Describe alternatives you've considered

A clear and concise description of any alternative solutions or features you've considered.

Additional context

Add any other context or screenshots about the feature request here.

Users should be able to update their avatar image

User Avatars

Users should be able to update and edit their avatar image. By default, we use a generator to create avatars when a wallet address connects to the app. A user should be able to update their avatar image in their profile page.

Is your feature request related to a problem? Please describe.

Users cannot update their images currently.

Describe the solution you'd like

There are a handful of more mature solutions that are out there, i.e. ENS avatars tied to their address, Twitter avatars if we decide to verify with socials, and even Blockie generated ones. Instead, a first step would be to allow a user to upload an image.

For storage:

One idea: Images should be stored on IPFS. User records in MongoDB should be updated to point to this IPFS url. The url stored in mongo should be one from an IPFS provider, i.e. cloudflare, ipfs.io, dweb.link. This would require the client to fetch externally for showing the image, but relies on decentralized infrastructure in a more web3 way.

Another idea, maybe better: User images should be base64 encoded and stored directly in mongo, which doesn't rely on fetching external data from a URL.

For design:

In short, mimic LinkedIn for the most part.

When the user hovers over the circular avatar in their profile, a lightly transparent overlay should show up with the text saying "Update Avatar". Clicking the avatar image in this state should open up a modal. The modal should have an upload button which asks the user's operating system and searches the file system for them to choose a file to upload. The modal will have a button that shows to "Update" and "Cancel" which closes the modal. Update button should either 1. upload to ipfs then update the mongo db record for the given user, or 2. Convert the image into base64 and store it in the user's record in mongo. We may want to advise on loading a 1:1 image. Furthermore, we should show a circle that will crop the image, where the user can drag the image around to find how they'd like to crop it, similar to LinkedIn or other social platforms, like Twitter, Facebook, etc.

Describe alternatives you've considered

Social avatars, ENS, and other generated avatars like Blockie. We may want to also prevent adult content and other explicit material from being uploaded, using a service/AI to scan for this and censor it.

Additional context

Add any other context or screenshots about the feature request here.

Show recent activity on latest 3 projects.

Feature

Please fill in these details describing the enhancement or improvement you'd like to see to the existing functionality within the UI. Please be as specific as possible.

What would you like to see improved or updated?

Show the most recently updated 3 project below banner on the homepage.

Card with a centered title "Recent Activity" , with a 3 column layout of ProjectCard components. These project cards should be from the most recent updatedAt fields in mongo.

Integrate Sentry for logging

Chore

Please provide details for the chore needing to be done. This should likely be technical debt or other updates that won't affect the existing functionality of the app.

What needs to be done?

We have an account with Sentry and integrated with our Heroku CI/CD. We have an existing branch and draft PR open here #109. This work should continue off of the previous work already done and in the same branch.

Sentry Dashboard: https://sentry.io/arbor-protocol/arbor-ui/

We should be logging all of our http requests to sentry, including errors, warnings, successes, etc. Here are a few resources to get started:

• Next.js package: https://github.com/vercel/next.js/tree/canary/examples/with-sentry
• Sentry docs: https://sentry.io/integrations/heroku/ & https://docs.sentry.io/product/integrations/deployment/heroku/
• Heroku docs: https://elements.heroku.com/addons/sentry

User profile should show projects they've collaborated on

New Feature

The user profile page should show not only projects they've created, but also projects they've collaborated on. This isn't clear currently on the current UI.

Describe the solution you'd like

There should be a new section added to the profile page that appears below the Projects section that displays project cards for each project the user has collaborated on. This will require some backend work to fetch all projects that a given user has collaborated on. Something similar to projects.find(p => where p.collaborators.includes(userId)). This may need to be a new next.js api page under projects/collaborator/[id].tsx with a GET method that does this. Then in pages/user/[id].tsx in getServerSideProps, a call to this route would be made and populate the props with this data so it can then be parsed in the UI component.

Things to do:

1. Create new route that gets project records that a given user ID has collaborated on
2. Wire up the user profile page to query for this data
3. Show the data in the same manner as projects they've created, using ProjectCard components, but as a new section with a new title and hr
4. Update Projects title to Creations
5. Title of new section should be Collaborations and subtext should be PROJECTS THIS USER HAS COLLABORATED ON. Should show the number of projects in parenthesis.

Additional context

Add any other context or screenshots about the feature request here.

Add in FAQs section to homepage

New Feature

Please fill in these details describing the new feature you'd like to see added to the UI. Please be as specific as possible.

User Story

As a new user of Arbor, or anyone who is interested in learning about the protocol, we should have an FAQs section about what the project is, what it does, how it benefits users, and any other information we may want to put in.

This is the first step in a more broad “user education” epic, which will eventually include a documentation site with Gitbook and a suite of helper videos outlining major features and how to use the application in several areas.

Acceptance Criteria

• The FAQs can live on the landing page located at https://arbor.audio.
• The FAQs should be accordion style, similar to [this section](https://phanft.xyz/#faq)

TODO:

• Determine the questions needed and the content for the answers

Is your feature request related to a problem? Please describe.

A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe the solution you'd like

A clear and concise description of what you want to happen.

Describe alternatives you've considered

A clear and concise description of any alternative solutions or features you've considered.

Additional context

Add any other context or screenshots about the feature request here.

Multiples solos plays audio for wrong tracks.

Bug Notes

In this project, when selecting a solo, an incorrect sample plays.

Expected Behavior

Seems like the behavior should either be to only allow one track to be soloed at a time, or if two tracks are solo'ed only those two tracks should be playing.

Steps to Reproduce

Steps to reproduce the behavior:

1. Solo lead guitar
2. Solo drums, you'll notice the sound switches from the solo of the lead guitar and drums to a solo of rhythm guitar and bass
3. Solo bass, and then it seems like it plays every sound?

OS & Device Information

Mozilla Firefox for Manjaro v103.0.2 (64 bit)

Separate routes for RecentProjectActivity

I have a few things as feedback on how this initially got implemented. I'd like the get them addressed in this PR as a follow-up.

The initial PR got merged in without my feedback at all, and the way the projects are getting are wrong - it should limit the results to 3. I think it needs to be moved to it's own route, and or the params passed in need to be ensured that they are working on the records correctly, or if they need to be translated to direct mongoose helper methods and moved to its own route, like /projects/recent, which always returns the latest three.

Originally posted by @drewcook in #229 (comment)

Add in view for what projects a particular stem has been used on

New Feature

There should be information shown as to how much a particular stem has been used across the ecosystem. It can be pulled to see how many projects use it within their list of stems.

Is your feature request related to a problem? Please describe.

Currently, there's no representation for the relationship between projects and stems, but vice versa from a stem to many projects, which will eventually be is possible.

Describe the solution you'd like

There should be a list of project cards, just like on a user's profile page, for all the projects that this stem has been used on. it should appear below the player on stem details page. https://arbor.audio/stems/62c2716bf8cc7ff069be960c

There should be an h4 header Collaborations with a subtext h4 of Projects this stem has been used on, and it can be just a regular body1 variant.

<Typography variant="h4" gutterBottom>Collaborations</Typography>
<Typography variant="body1" component="h5">Projects this stem has been used on</Typography>

There could also be the list view variant that was implemented in the stems page https://arbor.audio/stems

Implement in this same way: #183

Describe alternatives you've considered

List view: #183

Additional context

Add any other context or screenshots about the feature request here.

Abstract everything from top-level page/ components

Its cleaner if we move everything out from top-level page/ components and keep them as clean as possible, with only layout and server side prop concerns. So all these Box components should follow suit like RecentProjectActivity eventually.

Originally posted by @drewcook in #229 (comment)

ZK Social Proof Logins

New Feature

User Story

As a user, I’d like to verify my identity with a social account like Twitter or Github, but anonymously using ZKPs, and without revealing to the web app my true identity.

Acceptance Criteria

• A user is able to log in with a chosen social account
  • Twitter
  • Github
  • POAP
  • Reddit
• A user is known throughout the app and protocol by their identity hash rather than their wallet address. A user can tie multiple wallets to their social-backed identity/reputation.

Notes

We can use the Interrep system to verify users’ repuations.

• Interrep Github: https://github.com/interep-project
• Interrep Voting App: https://github.com/interep-project/voting-app

Is your feature request related to a problem? Please describe.

A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe the solution you'd like

A clear and concise description of what you want to happen.

Describe alternatives you've considered

A clear and concise description of any alternative solutions or features you've considered.

Additional context

Add any other context or screenshots about the feature request here.

Improve audio merging from the backend service

Enhancement

User Story

Currently audio merging is handled in a flattening service over https, this requires the user to upload the individual file blobs both to the flattening service and to IPFS during the metadata creation.

In order to remove the need for multiple uploads, we should handle the audio file muxing in browser.

Where we are currently sending the audio blob to the backend merging service, instead we should use ffmpeg to handle merging of multiple file types. This should also enable us to use all of the filetypes supported by wavesurfer. Once the merging is done, the user will still need to upload the flattened audio file to IPFS.

References

• FFmpeg Github
• Web Audio API AudioWorklet

Create list view for stems aggregate page

Stem Playback on the aggregated page

This enhancement should improve the UI design from the current grid-based view of stems to a list view, or add it in as a second viewing option. Since the grid-view already exists, it may make sense to add in a list view and a button group to toggle between the views.

What would you like to see improved or updated?

There should be a list view icon and a gallery view icon as a MUI button group that allows for toggling between the two different views. Each view should work with the same data and just be presentational components. Each list item, i.e. stem, should include the following:

• A play button on left hand side
• The title of the stem
• The background color should be the color of the type of stem it is (i.e. Drums, Chords, Melody, etc)
• The length of the stem, i.e. how many seconds
• When it was uploaded
• Who uploaded it

List icon: https://mui.com/material-ui/material-icons/?query=list&selected=FormatListBulleted

Grid icon: https://mui.com/material-ui/material-icons/?query=apps&selected=Apps

ButtonGroup: https://mui.com/material-ui/react-button-group/

Reference design for is roughly like Audius - similar to how each track in the playlist shows:

Other examples:

Improve ZK voting in other ways

Enhancement

Please fill in these details describing the enhancement or improvement you'd like to see to the existing functionality within the UI. Please be as specific as possible.

What would you like to see improved or updated?

User Story

As a user of the Arbor UI, I should be able to anonymously vote on several things throughout the app. Including but not limited to:

• Upvoting stems on a project’s stem queue for being used on the next available slot
• Upvoting popular Arbor projects
• Upvoting popular stems
• Remix competition community vote

Notes

Currently, there is an implementation for upvoting stems within a project’s stem queue, using Semaphore: https://github.com/semaphore-protocol/boilerplate

The stem queue voting code can be found here:

• UI - https://github.com/arbor-protocol/ui/blob/main/components/StemQueue/StemQueue.tsx#L77
• Smart Contract - https://github.com/arbor-protocol/ui/blob/main/web3/contracts/StemQueue.sol

Semaphore votes are not verifying correctly

Bug Notes

Currently, there is a call exception happening at the contract level for verifying the off-chain proof submitted from a verified member of a Semaphore group. The verifier smart contract does not seem to pass, even though it seems that the proof is being generated effectively with the right values, and that the member is indeed a valid member of the voting group, so should be able to signal within it.

NOTE: The failure is for sure happening in the _verifyProof() function.

Steps to Reproduce

1. Upload a stem to a project, not necessary if a project has a populated stem queue already
2. Cast a vote for that stem in the stem queue, or any stem in any stem queue for that matter
3. Observe failed call on transaction details

References

• UI vote call: here
• Contract vote call: here
• See failed transactions:
  • Polygon Testnet: here
  • Polygon Mainnet: here

Rebrand UI to use new logo assets

Enhancement

Please fill in these details describing the enhancement or improvement you'd like to see to the existing functionality within the UI. Please be as specific as possible.

What would you like to see improved or updated?

Use the new Arbor tree and waveform logos throughout the application where needed.

• Navbar
• NFT images
• Footer
• Favicon

We should be trying to get our fully loaded time below 1s (currently 3.2s)

Check https://gtmetrix.com

Currently our banner image is here http://arbor.audio/banner_bg.png

The banner should be a Next Image component instead of a background image.
https://nextjs.org/docs/api-reference/next/image

The image is almost 7mb and can take some time to download. We should optimize it.

There is a scrollbar displayed for me on google chrome and brave on Linux, this should not be visible, but the page should still be scrollable, this can be done purely in css.

Migrate off-chain group IDs from mongodb to on-chain

Bug Notes

Currently, project Id and steam Id are managed in MongoDB. But this is not the right way to store id off-chain. If we record from the database then we can not retrieve project & stem ids.

Steps to Reproduce

1. Create a new project.
2. Create a new stem in the project.
3. Observe all IDs only available off-chain.

References

Use on-chain storage for projects and index via subgraphs

New Feature

Please fill in these details describing the new feature you'd like to see added to the UI. Please be as specific as possible.

Is your feature request related to a problem? Please describe.

A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe the solution you'd like

A clear and concise description of what you want to happen.

Describe alternatives you've considered

A clear and concise description of any alternative solutions or features you've considered.

Additional context

Add any other context or screenshots about the feature request here.

Contributor docs.

Chore

We should have a docs page that outlines the contributing process. We should include any relevant code standards or policies, such as the naming format for PRs, requirements for using templates, requirements on test coverage and styling.

Test issue

Chore

Please provide details for the chore needing to be done. This should likely be technical debt or other updates that won't affect the existing functionality of the app.

What needs to be done?

...

Implement caching in browser / server for IPFS data

Enhancement

Please fill in these details describing the enhancement or improvement you'd like to see to the existing functionality within the UI. Please be as specific as possible.

What would you like to see improved or updated?

Currently all audio music blobs that represent both full projects/nfts and individual stems are stored on IPFS. This means that any time we load a project page, the client has to ping the IPFS provider for the audio files, and then load them into the audio players so they can be previewed. This means we are relying on a centralized IPFS provider for this, which isn't 100% reliable. And files take time to be served up and found in the network, which isn't fast. This is noticeable viewing any project page as the stems don't load quickly and sometimes not at all.

Thus, we should have a redundant storage solution so these blob files are readily available and we can load almost immediately when needed. We can solve this using an in-browser Redis cache. The cache is a basically a JS object of keys/values. We should store the actual blob data as the values, and the keys should be the stemID. For a start, the cache object should have two top-level keys nfts and stems. The keys for nfts should map to the ObjectID in mongo as a start, as well as with the stems keys. Then we could easily reference the cache for these when needed.

When writing to the cache, a new item should be added at two points in the workflows:

1. When a user uploads a new stem, after it loaded to IPFS and in mongo, it should be stored in the cache under the stems key. The key for the new item is the returned id from mongo after the record is created. The value is the blob data.
2. When a new NFT is minted. After the NFT is combined, stored into IPFS, stored into mongo, and minted on-chain, the next step is to store the blob data for the audio of the NFT as a new item in the cache, under the nfts key. The key for the new item is the returned id from the mongodb record. The value is the blob data.

Prevent minting an NFT if it has already been minted in its current state

Bug Notes

The NFT that represents the project in its given state should only exist once for the current version, or in 1155, there should only be one collection of that version. Currently, the user can mint an NFT from project C as it exists, say with two stems A and B. Another user can mint an NFT of project C with stems A and B as well. This ends up having two identical NFTs, just owned by different users. This should be prevented.

User Story

As a user, I should be able to mint a song into a token if there isn’t a token that exists with that exact combination of stems and collaborators. If a project has 3 stems on it and hasn’t been minted yet in that version, as a user, I should be able to mint that project. If a user comes along after me minting that project, and the project state hasn’t changed at all in the manner of new stems being added onto the project, then that second user should not be able to mint the project. In other words, there should only exist a version of an Arbor project at each state that the project has and no more than one per state.

“State” in this context means:

• The project with 2 stems from 1 collaborator
• The project with 3 stems from 2 collaborators
• The project with 4 stems from 2 collaborators
• The project with 5 stems from 3 collaborators
• etc.

A project could only have an NFT representing one of these states, nothing more, and no tokens with the same “configuration”, or “state”.

Expected Behavior

Please provide a clear and concise description of what you expected to happen.

Steps to Reproduce

Steps to reproduce the behavior:

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

---

References

Please add any references, screenshots, or links to anything that will be helpful to triage this bug.

---

OS & Device Information

Desktop (please complete the following information):

• OS: [e.g. iOS]
• Browser [e.g. chrome, safari]
• Version [e.g. 22]

Smartphone (please complete the following information):

• Device: [e.g. iPhone6]
• OS: [e.g. iOS8.1]
• Browser [e.g. stock browser, safari]
• Version [e.g. 22]

Additional context
Add any other context about the problem here.

Replace nested Card components with a top level <section> in RecentProjectActivity.

Another feedback item is how <Card> is used in this. It's applied as a top-level global component, then maps over
the projects and renders the appropriate ProjectCard, which is also a card. So this isn't ideal. The top level card
component, card header, card contents, IMO should be split up to a <section>, for the overall topmost component for
RecentProjectActivity, as it's used on the homepage, and the title can just be a typography h3 or whatever and the
subtext another typography centered. Then the cards don't have to be wrapped in anything after that. So this will
remove Card, CardContent, CardHeader from the component.

Originally posted by @drewcook in #229 (comment)

ZK Auctions for project NFTs

New Feature

Please fill in these details describing the new feature you'd like to see added to the UI. Please be as specific as possible.

User Story

As a collector on the web app, I should be able to bid on open auctions of Arbor project NFTs and bid anonymously using ZKPs. After a given auction time window, the highest bidder wins the ability to mint the given NFT and own it, and is paid for by the winning bid for that price. Bids are locked in prior to minting, to prevent users from spamming auctions but never minting the tokens.

The current fixed-price model will need to be refactored. The existing NFT smart contract will need to be altered to respect the current bid price instead, which will be available in a newBlindAuction.sol contract

Acceptance Criteria

• Leverage MACI or Semaphore to turn the fixed price buying model into an auction model
• Implement the voting and auction to happen in its own smart contract
• Collaborators can choose when to auction their song
• Bidders submit bids anonymously using ZKPs, the bid funds are deposited into the smart contract
• When a user is outbid, they receive their funds and the new bid becomes the current high bid
• After a given time, the current bid and bidder get’s approved from the token collection to be a minter, and is able to mint the token
  • This could happen automatically at the end of auction
  • Or, this could be a manual user action in the UI

Resources

• MACI - https://github.com/privacy-scaling-explorations/maci/tree/master/specs
• Semaphore - https://semaphore.appliedzkp.org/
• ZK Blind Auction House
  • https://github.com/heivenn/zk-blind-auction
  • https://zk-blind-auction.vercel.app/
  • https://talk.harmony.one/t/zero-knowledge-blind-auctions/18600

Is your feature request related to a problem? Please describe.

A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe the solution you'd like

A clear and concise description of what you want to happen.

Describe alternatives you've considered

A clear and concise description of any alternative solutions or features you've considered.

Additional context

Add any other context or screenshots about the feature request here.

While casting a vote, only show loading on stem being voted, disable others

Bug Notes

Currently, when clicking to cast a vote for a stem in the stem queue, all vote buttons are being disabled and loading. The text should also be improved to say 'Vote Pending' while loading. Also, the 'Get Vote Count' buttons don't add any value to this page, as the counts are read directly from the contract and display already.

Expected Behavior

Rather than showing the loading state on all buttons, only show the loading state on the stem being voted on, but disable the others. Just don't show the loading spinner in place of the text.

Additionally, for the stem being voted, add the text Vote Pending to the button as well as the loading spinner. So the final buttons should be disabled and read 'Vote Pending' with a loading spinner to the right hand side of it. The other buttons should be disabled and continue to say 'Cast Vote'.

This should be an easy change. The loading button is indeed also a disabled button. Just update the others to not show the progress indicator (loading) while the transaction is pending. The buttons should show disabled with the text.

Finally, remove the Get Vote Count buttons from the UI.

Steps to Reproduce

Steps to reproduce the behavior:

1. Go to a project's stem queue page
2. Connect wallet
3. Register for the voting
4. Cast a vote on a stem

---

References

Please add any references, screenshots, or links to anything that will be helpful to triage this bug.

---

OS & Device Information

Desktop (please complete the following information):

• OS: [e.g. iOS]
• Browser [e.g. chrome, safari]
• Version [e.g. 22]

Smartphone (please complete the following information):

• Device: [e.g. iPhone6]
• OS: [e.g. iOS8.1]
• Browser [e.g. stock browser, safari]
• Version [e.g. 22]

Additional context
Add any other context about the problem here.

Users should sign message to upload stems

Upload signing

User Story

Pretty straightforward, before a user uploads a stem to IPFS and onto our platform, a user must sign a message, verifying that they are a real person. This could be done using their existing Semaphore identity if they’ve created one already. Otherwise, we could prompt the user to create their identity at this step, which requires signing a message anyway, and using that identity.

Whether the signature comes from a new signature with new popup text, or if it comes from the previously signed Semaphore identity signature, we should check this signature prior to uploading.

Acceptance Criteria

• When a user is uploading a stem, when they click the “Upload” button, a Metamask popup should show asking to verify they are uploading a stem to IPFS and onto Arbor, asking the user to sign the messsage.
• We use the hashed message signature in some way, to verify that this is indeed an upload coming from a human
  • Whether this is in the backend Node service, or using ZKPs
• The upload continues only if the message is signed
• The upload should fail if the user doesn’t sign the message
• The upload should fail for bots and other avenues, like a Postman request

TODO:

• Figure out the popup text verbiage
• Figure out how to use the signature in the backend or with ZKPs for verification/authorization to upload

Relavent dev links:

• https://blog.chainsafe.io/how-to-verify-a-signed-message-in-solidity-6b3100277424
• https://web3js.readthedocs.io/en/v1.2.0/web3-eth-personal.html#sign

Is your feature request related to a problem? Please describe.

A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe the solution you'd like

A clear and concise description of what you want to happen.

Describe alternatives you've considered

A clear and concise description of any alternative solutions or features you've considered.

Additional context

Add any other context or screenshots about the feature request here.

Styles to match that of the 'How It Works' section, copied from `sectionHeading` and `howItWorksText` in RecentProjectActivity

Styles to match that of the 'How It Works' section, copied from sectionHeading and howItWorksText:

const styles = {
  recentActivity: {
    py: 10,
  },
  header: {
    mb: 5,
    fontSize: '3rem',
    '@media (min-width: 600px)': {
      fontSize: '4rem',
    },
  },
  subheader: {
    fontSize: '1.5rem',
    mb: 7,
    '@media (min-width: 600px)': {
      fontSize: '1.75rem',
      mb: 10,
    },
  }
}

The component JSX should be refactored to be as so:

return (
  <Box sx={styles.recentActivity} component="section">
    <Typography variant="h2" sx={styles.header}>Recent Activity</Typography>
    <Typography sx={styles.subheader}>Check out a few of the most recently updated projects on Arbor.</Typography>
    <Grid container spacing={3}>
	{projects.map(project => (
	  <Grid item xs={12} sm={4} key={project._id}>
	    <ProjectCard details={project} />
	  </Grid>
	))}
    </Grid>			
  </section>
)

Or if you're importing the styles to this file, then you can just reuse those variables stated above as the styles in sx.

Originally posted by @drewcook in #229 (comment)

Global Audio Player

Global Audio Player

The user should be able to playback and preview each stem or project from the same UI, as opposed to having to navigate to each individual stem or project details page to playback. This will involve building a player that fits near the bottom of the page, similar to Audius or Spotify. Users should be able to change pages in the app and not affect the audio playback.

Is your feature request related to a problem? Please describe.

A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe the solution you'd like

An audio player that stays on or near the bottom of the page, maybe the bottom right hand side quite small to provide more real estate for the rest of the UI, or maybe a combination of both with a minimize/maximize button.

https://app.stems.art just launched with one.

Describe alternatives you've considered

A clear and concise description of any alternative solutions or features you've considered.

Additional context

Add any other context or screenshots about the feature request here.

Improve and simplify StemQueue zk-vote process.

Enhancement

Currently, there are two tabs on the project details page, with a tab "Stem Queue" that opens the Stem Queue component, we should remove the Stem Queue tab, and instead move the functionality into the ProjectDetails component.

This is the stem queue tab we want to remove.

This is the stem queue page that we want to restyle into project details page.

A user opens a zk-vote enabled public project, they add a stem, this adds the stem with a dotted border to indicate it hasn't been approved yet. If the user is a member of the stem's voting group, they have the option to approve or deny the stem in-place on the project's details page.

Requirements:

• Remove "Stem Queue" tab from the project details
• All of the original functionality of the stem queue tab should be preserved in the project details page. e.g. Approving a vote, casting a vote, registering to vote.
• The UIUX should feel intuitive, open to discussion / suggestions on the details.