## Inspiration

Growing up, many of us dreamed of exploring the world of music. However, we soon discovered that pursuing this passion often requires significant financial investment in production, mixing, and additional instruments. 🎛️ Well-meaning adults frequently warned us about the instability and security concerns associated with a music career. The reality is that music can be challenging, and we want to change that narrative.

There are barriers to entry at every turn:

* 87.6% of all artists remain undiscovered.
* Out of 1.3 million registered artists on Chartmetric over the past year, 710,000 have yet to achieve any career milestones.
* Only 11% of independent artists can sustain a living through music.

Even signing with a record label doesn’t guarantee success:

* Labels typically take 50-90% of the revenue generated by an artist, often with fine print that includes hidden distributor fees and overhead costs.
* Remarkably, even with a major label, only 1 in 2,149 artists achieves commercial success.

With soundchain, we aim to empower aspiring artists to pursue their musical dreams independently while connecting them with a supportive community that believes in their potential. This platform is also perfect for hobbyists who have a polished piece sitting in their files, just waiting for the right moment to be released. Whether you’re looking to build a career in music or simply share your passion, we’re here to help you take that next step. 🔊

## What it does

soundchain is a decentralized platform that connects aspiring artists with music enthusiasts, enabling fans to discover and support emerging talent through unbiased music playback and NFT purchases in exchange for rights. Artists and "angel music investors" are matched through our music-forward playback system.

It's actually quite simple:

1. Artists upload snippets of their creative process (verses, beats, melody lines, anything in between). They set SUI-based crowdfunding goals to produce their song, and issuance terms for partners.
2. Potential supporters browse uploaded projects. They can view goals and decide to support projects based on the provided snippets. They buy-in to the potential of the project.
3. The Sui blockchain records the smart contract and creates an enforceable legal parameter for investors.
4. If the project takes off, initial investors can now resell their rights on secondary web3 markets. 🚀

## How we built it

We utilized the Sui blockchain for its scalability and performance, implementing smart contracts to handle transactions. The application is integrated/connected with google-auth and the Enoki developer portal. The platform was developed with a user-friendly interface mocked on Figma to ensure seamless interactions between artists and listeners. Our front-end is made using Next.js, typescript, and assets from libraries such as material UI.

## Challenges we ran into

This project was our team's first time ever working with any web3 products. We went from not understanding what blockchain even was to maybe understanding a little bit of how blockchain works. We faced challenges in the integration of blockchain elements into our front-end application since we weren't familiar with the technology. Additionally, navigating copyright issues and establishing fair revenue-sharing models for artists required careful consideration.

## Accomplishments that we're proud of

We think that we came up with a bangin' 🎸 idea that can really change the way funding in the music industry works. We also ensured that this product was realistic and viable for integration in the current state of the music industry.

## What we learned

SO MUCH !!!! All new ways of designing, methodologies of ideation, new technologies, and first-time experiences. We also learned the importance of community engagement in building a platform that truly serves its users. Understanding the pain points and publication process from both artists and listeners helped us refine our approach and identify key features that enhance the overall experience.

## What's next for soundchain

* Mint NFTs that provide a visual badge/proof of support for supporters.
* Implement tags for different types of projects including Songwriting, Lyrics, Rap, and Beats.
* Integrate tracking systems to measure expected revenue shares through traditional music streaming applications, allowing the smart contract to take a more active role in revenue sharing.
## Inspiration

With an ever-increasing rate of crime, and internet deception on the rise, Cyber fraud has become one of the premier methods of theft across the world. From frivolous scams like phishing attempts, to the occasional Nigerian prince who wants to give you his fortune, it's all too susceptible for the common person to fall in the hands of an online predator. With this project, I attempted to amend this situation, beginning by focusing on the aspect of document verification and credentialization.

## What does it do?

SignRecord is an advanced platform hosted on the Ethereum Inter-Planetary File System (an advanced peer-to-peer hyper media protocol, built with the intentions of making the web faster, safer, and more open). Connected with secure DocuSign REST API's, and the power of smart contracts to store data, SignRecord acts as an open-sourced wide-spread ledger of public information, and the average user's information. By allowing individuals to host their data, media, and credentials on the ledger, they are given the safety and security of having a proven blockchain verify their identity, protecting them from not only identity fraud but also from potential wrongdoers.

## How I built it

SignRecord is a responsive web app backed with the robust power of both NodeJS and the Hyperledger. With authentication handled by MongoDB, routing by Express, front-end through a combination of React and Pug, and asynchronous requests through Promise it offers a fool-proof solution.

Not only that, but I've also built and incorporated my own external API, so that other fellow developers can easily integrate my platform directly into their applications.

## Challenges I ran into

The real question should be what Challenge didn't I run into. From simple mistakes like missing a semi-colon, to significant headaches figuring out deprecated dependencies and packages, this development was nothing short of a roller coaster.

## Accomplishments that I'm proud of

Of all of the things that I'm proud of, my usage of the Ethereum Blockchain, DocuSign API's, and the collective UI/UX of my application stand out as the most significant achievements I made in this short 36-hour period. I'm especially proud, that I was able to accomplish what I could, alone.

## What I learned

Like any good project, I learnt more than I could have imagined. From learning how to use advanced MetaMask libraries to building my very own API, this journey was nothing short of a race with hurdles at every mark.

## What's next for SignRecord

With the support of fantastic mentors, a great hacking community, and the fantastic sponsors, I hope to be able to continue expanding my platform in the near future.
## Inspiration

We love to cook for and eat with our friends and family! Sometimes though, we need to accommodate certain dietary restrictions to make sure everyone can enjoy the food. What changes need to be made? Will it be a huge change? Will it still taste good? So much research and thought goes into this, and we all felt as though an easy resource was needed to help ease the planning of our cooking and make sure everyone can safely enjoy our tasty recipes!

## What is Let Them Cook?

First, a user selects the specific dietary restrictions they want to accommodate. Next, a user will copy the list of ingredients that are normally used in their recipe into a text prompt. Then, with the push of a button, our app cooks up a modified, just as tasty, and perfectly accommodating recipe, along with expert commentary from our "chef"! Our "chef" also provides suggestions for other similar recipes which also accomidate the user's specific needs.

## How was Let Them Cook built?

We used React to build up our user interface. On the main page, we implemented a rich text editor from TinyMCE to serve as our text input, allong with various applicable plugins to make the user input experience as seamless as possible.

Our backend is Python based. We set up API responses using FastAPI. Once the front end posts the given recipe, our backend passes the recipe ingredients and dietary restrictions into a fine-tuned large language model - specifically GPT4.

Our LLM had to be fine-tuned using a combination of provided context, hyper-parameter adjustment, and prompt engineering. We modified its responses with a focus on both dietary restrictions knowledge and specific output formatting.

The prompt engineering concepts we employed to receive the most optimal outputs were n-shot prompting, chain-of-thought (CoT) prompting, and generated knowledge prompting.

## UI/UX

### User Personas

![User Persona 1](https://lh3.googleusercontent.com/pw/ADCreHcPNSKWnt37BYEZkkTys193lo41ZemedLwl4tbr_OBXvYgZkLISUzuuXeuQBXyZBrlIye-u2maW5RcPK9RdPa3hI1RFZiEhHG1iuRirJkrtrvHZsbM=w2400)

*We build some user personas to help us better understand what needs our application could fulfil*

### User Flow

![User Flow](https://lh3.googleusercontent.com/pw/ADCreHeMI5gMUYaxxQCC7X-nvrs7085m0Z8Kjxszj53RVT6VPYqkCpHLgLr5LtO1HWIft0k7YL53qIzKE73q4V_CStSSFpRVsMLKK2FrH1BLIXmepZYIWTs=w2400)

*The user flow was made to help us determine the necessary functionality we wanted to implement to make this application useful*

### Lo-fi Prototypes

![Lofi Mockups](https://lh3.googleusercontent.com/pw/ADCreHf-E8p6OXBlCB1x_t78_ls43jR8Uh709LQhLrP1FmjP9sKSyEiVmcC7VqtnXrfiDeBlNcjHgWssIUE1DojQa-LxUC4EyDARPpCgGRKMbbH50oKTLR0=w2400)

*These lo-fi mockups were made to determine what layout we would present to the user to use our primary functionality*

### Hi-fi Prototypes

![hifi mockups 1](https://lh3.googleusercontent.com/pw/ADCreHcIY-iKuCfu-RLqIQo2W5Sav5xEPuJ8IRXId-_iDcXcgbSousCf0B6EKWJki3pCPREPyH0bDJbCXhbbZN4TcBp42B8pRRTfzIGj3k3pk6wyhrGayVY=w2400) ![hifi mockups 2](https://lh3.googleusercontent.com/pw/ADCreHffaIev4mI7swuOQ_UHkJxOvUI_FMsDuHASNRitEiE_006SQLxXEeAaArWyWc0mPNbyTMjbknn1VwiU3AV-OL1hGGnRPYnDjNXRz7Z3uS6Zr8hypis=w2400)

*Here we finalized the styling choice of a blue and yellow gradient, and we started planning for incorporating our extra feature as well - the recipe recomendations*

## Engineering

![Technologies](https://lh3.googleusercontent.com/pw/ADCreHejCSB2jA2J6vTYG1Dnc0HsXujeAYkax8eLmlSe2n3uLq9t-FsR0f9RhbcwuA-ZcvrdrCIoVieI26yjy-LoJeHT2xQp0BfRgNQzan4yEMZzaWtRZZg=w2400)
Frontend: React, JS, HTML, CSS, TinyMCE, Vite

Backend: FastAPI, Python

LLM: GPT4

Database: Zilliz

Hosting: Vercel (frontend), Render (backend)

## Challenges we ran into

### Frontend Challenges

Our recipe modification service is particularly sensitive to the format of the user-provided ingredients and dietary restrictions. This put the responsibility of vetting user input onto the frontend. We had to design multiple mechanisms to sanitize inputs before sending them to our API for further pre-processing. However, we also wanted to make sure that recipes were still readable by the humans who inputted them. Using the TinyMCE editor solved this problem effortlessly as it allowed us to display text in the format it was pasted, while simultaneously allowing our application to access a "raw", unformatted version of the text.

To display our modified recipe, we had to brainstorm the best ways to highlight any substitutions we made. We tried multiple different approaches including some pre-built components online. In the end, we decided to build our own custom component to render substitutions from the formatting returned by the backend.

We also had to design a user flow that would provide feedback while users wait for a response from our backend. This materialized in the form of an interim loading screen with a moving GIF indicating that our application had not timed out. This loading screen is dynamic, and automatically re-routes users to the relevant pages upon hearing back from our API.

### Backend Challenges

The biggest challenge we ran into was selecting a LLM that could produce consistent results based off different input recipes and prompt engineering. We started out with Together.AI, but found that it was inconsistent in formatting and generating valid allergy substitutions. After trying out other open-source LLMs, we found that they also produced undesirable results. Eventually, we compromised with GPT-4, which could produce the results we wanted after some prompt engineering; however, it it is not a free service.

Another challenge was with the database. After implementing the schema and functionality, we realized that we partitioned our design off of the incorrect data field. To finish our project on time, we had to store more values into our database in order for similarity search to still be implemented.

![interactions](https://lh3.googleusercontent.com/pw/ADCreHdDYpTiJoG9bTREKFJywBYrQoztexD9RXPK9jg1vNa0d8Ud9s7HAjRCnJZQodY2InKnEQyEF-iJIaexRGMlXAqdTtMLD8VIsHlFSNITrU3Ik0C2YKA=w2400)

## Takeaways

### Accomplishments that we're proud of

From coming in with no knowledge, we were able to build a full stack web applications making use of the latest offerings in the LLM space. We experimented with prompt engineering, vector databases, similarity search, UI/UX design, and more to create a polished product. Not only are we able to demonstrate our learnings through our own devices, but we are also able to share them out with the world by deploying our application.

**All that said**, our proudest accomplishment was creating a service which can provide significant help to many in a common everyday experience: cooking and enjoying food with friends and family.

### What we learned

For some of us on the team, this entire project was built in technologies that were unfamiliar. Some of us had little experience with React or FastAPI so that was something the more experienced members got to teach on the job.

One of the concepts we spent the most time learning was about prompt engineering.

We also learned about the importance of branching on our repository as we had to build 3 different components to our project all at the same time on the same application.

Lastly, we spent a good chunk of time learning how to implement and improve our similarity search.

### What's next for Let Them Cook

We're very satisfied with the MVP we built this weekend, but we know there is far more work to be done.

First, we would like to deploy our recipe similarity service currently working on a local environment to our production environment. We would also like to incorporate a ranking system that will allow our LLM to take in crowdsourced user feedback in generating recipe substitutions.

Additionally, we would like to enhance our recipe substitution service to make use of recipe steps rather than solely *ingredients*. We believe that the added context of how ingredients come together will result in even higher quality substitutions.

Finally, we hope to add an option for users to directly insert a recipe URL rather than copy-and-pasting the ingredients. We would write another service to scrape the site and extract the information a user would previously paste.