## Inspiration

Bonsai was inspired by AI's ability to summarize things and how time-consuming it is to sift through all the emails I receive. We believe seeing a quick summary of the emails that matter will vastly improve your productivity.

## What it does

Bonsai is an app that summarizes your most important emails; and then sends a text. Users can also whitelist or blacklist topics, or translate email summaries into a language they are more familiar with.

## How we built it

Our backend utilized Python+FastAPI for its ability to quickly prototype and make software that gets the job done. Javascript+React was chosen for the front end for the same benefits. MongoDB was also very effective for us because we only needed to query by a primary key. The backend integrates with Twilio and Google Cloud Services to send text messages whenever an email is received.

## Challenges we ran into

Google cloud services suffer from overdocumentation. There is so much documented information that's superseded by newer protocols and the docs don't give you a hint that you are doing everything wrong. The client-side libraries also have code snippets but don't have any explanations of what the code in the snippets actually does.
Firefox also has rendering issues on Linux and Windows doesn't support SSL handshakes apparently. Because Bonsai relies on so many APIs, it's difficult for us to be sure your data is safe. This was difficult for us to fix during the time we had, so we decided to allow many security issues.

## Accomplishments that we're proud of

We took on a project with a big scope and accomplished every one of our non-negotiable goals.

## What we learned

It's important to read the entire documentation before you start programming. We learned that it's good to spend time on polish because you only have one first impression. Communication between team members is very crucial. We also reflected on our decision to skip pull requests so we could save time. We ended up losing time to merge conflicts.

## What's next for Bonsai

Bonsai's proof of concept is done. While developing the app, we realized it was much more useful than we imagined. A second version of Bonsai would be a game-changer for productivity. Fixing the security issues and refining the user experience is the next step in Bonsai's journey.
## Landing Page

<https://email-project-d4353e.webflow.io>

## Inspiration

When Covid-19 first struck our world, it seemed as if the amount of emails we as students received increased tenfold. Digital communication through emails became even more crucial than ever. Health updates, class deadlines, event links, etc. Everything was online.

However, we as students have exceeded our capacity to follow and process the amount of information we are receiving. Deadlines from classes became buried between emails. Important information gets lost, and as a result we are impaired in our ability to live in the new digital world.

As a group, we questioned how we could keep important information accessible. People were spending an unnecessary amount of time reading emails that weren’t important to them. Tree L;DR was created to increase productivity and organization when it comes to digital communication.

We saw a need for an organized and effective system which allowed students to spend more time focused on the important communication and less time on unimportant mail.

## What it does

Tree L;DR's mission is simple: We want important information to be accessible in an increasingly digital world.

When users sign up for the platform, they submit their phone number, chose email categories and login to their email. After logging into your email, Tree L;DR uses OpenAI's GPT-3 API to summarize and extract relevant information, such as action items and deadlines. Based on the user's chosen preferences, TreeLD;LR will periodically send the user texts. These texts will provide summaries and reminders with regards to the users preferred email categories.

## How we built it

Here is a high-level architecture chart:

![alt text](https://i.ibb.co/Gnz3qmx/TREEL-DR.jpg)

We build a landing page in Webflow to attract users and gather their sign-up information. We then use the Microsoft Identity Platform to let the user sign into their Outlook and acquire an access token for us. We keep the token and store the user information in Google Firestore. Every 5 minutes, a cronjob runs that identifies all of the users whose TreeL;DR digest is due (they can pick 1 hour, 1 day, or 1 week intervals). For each of them, we use the Microsoft GraphQL API to fetch the emails in their Outlook inbox received during the past interval. We extract the text and other information from the email and utilize carefully engineered prompts to summarize, categorize, and process the information from the emails using the OpenAI GPT-3 API. The backend retains all the emails from categories that the user is subscribed to and sends them the compiled TreeL;DR as a text message using the Twilio API. The service is free, but as a sign of their gratitude, users have the ability to give to one of a selected number of charities directly on our landing page, powered by the Checkbook API.

## Challenges we ran into

Our group ran into four main challenges when creating Tree L;DR

1. The first problem we encountered was that most managed Microsoft accounts need approval from an administrator to grant the "Mail.Read" permission for unverified apps. Since the Stanford-managed accounts fall under this category, we had to create our own personal Microsoft accounts to properly demo the program. We submitted the app for review and are waiting to be verified in the next few days, so we can make TreeL;DR accessible for anyone.
2. The second problem we had to overcome was ensuring that that the GPT-3 OpenAI API produced repeatable and consistent output. Because GPT-3 is a general language model, there is no way to programmatically instruct it to do a specific task. Instead, we had to engineer prompts and examples that we send with the email that we want to process, which ended up working great.
3. The third problem we solved was determining how to parse the GPT-3 responses. Because the GPT-3 output is free text, and is therefore unstructured, it was much harder to parse than we had originally predicted. On one hand, we created regexes which were flexible enough to match the format of the text. Then, we added rules for interpreting the sentences in natural language to get a more precise categorical answer.
4. For the sign up process we need to maintain state since we're redirecting the user to Microsoft before they get redirected back to us with their authentication token. Locally, we could do that with a session that uses the file system as a backend but during deployment we discovered that the Google App Engine's file system is read only, making this impossible. We looked at the available options and decided to use the Redis back-end instead, which ended up being a more scalable solution in the long term.

## Accomplishments that we're proud of

We managed to build a fully usable product of great complexity within only 36 hours and dozens of our friends already expressed interest to use it–we are extremely proud of that. Further, we had never used any of the API’s present in our project. For example, no one in our group had ever used OpenAI or Webflow before, and much of Tree L;DR is dependent on those technologies. We had to take the time to learn new technologies from scratch, and we’re really proud of how much our knowledge has grown since beginning this project.

Secondly, we’re proud of how we were able to find workflow harmony between the members of the group. Every member of the group had a different level of experience with regards to hackathons and creating projects, but we were all able to quickly find our perfect spot on the team.

## What we learned

Two of us had never competed in a hackathon before

We were all exposed to so many APIs as a group that we had never seen before

As a group, we all learned a lot about many different API’s such as OpenAI, Checkbook and Microsoft GraphQL that none of us had ever used before.

Caroline had coded before but had never created a project before, nor competed in a hackathon. She was able to learn a lot about front-end development by co-designing the website and learnt how to integrate APIs from end to end.

Santi was more versed in hackathons and primarily focused on determining how we could utilize GPT-3 to summarize and categorize people’s emails. He really enjoyed playing with the OpenAI API and discovering more about machine learning.

Fran had also never competed in a hackathon before and focused her time on co-designing the website and working on more front-end development for Tree L;DR. Additionally, Fran helped Santi use GPT-3 to optimize output.

Moritz spent most of his time working on the back-end of TreeL;DR. Even though he had never worked with several of these API’s before, he was able to fully integrate multiple different API’s into our project, allowing for an optimal product.

## What's next for Tree L;DR

We love Tree L;DR, and we’re so proud of it, but we still have a long way to go with it. Once this hackathon is over, we still have work to do. First, we want to get Tree L;DR verified so that users can sign up using their educational email. Secondly, we want to improve the performance of the app by multi-processing that we can handle large bundles of emails as the same time. Thirdly and finally, we want to improve the experience for the user while on our website. We want to create a whole members portal so that users can properly manage their preferences.
## Inspiration

Recently we have noticed an influx in elaborate spam calls, email, and texts. Although for a native English and technologically literate person in Canada, these phishing attempts are a mere inconvenience, to susceptible individuals falling for these attempts may result in heavy personal or financial loss. We aim to reduce this using our hack.
We created PhishBlock to address the disparity in financial opportunities faced by minorities and vulnerable groups like the elderly, visually impaired, those with limited technological literacy, and ESL individuals. These groups are disproportionately targeted by financial scams. The PhishBlock app is specifically designed to help these individuals identify and avoid scams. By providing them with the tools to protect themselves, the app aims to level the playing field and reduce their risk of losing savings, ultimately giving them the same financial opportunities as others.

## What it does

PhishBlock is a web application that leverages LLMs to parse and analyze email messages and recorded calls.

## How we built it

We leveraged the following technologies to create a pipeline classify potentially malicious email from safe ones.
Gmail API: Integrated reading a user’s email.
Cloud Tech: Enabled voice recognition, data processing and training models.
Google Cloud Enterprise (Vertex AI): Leveraged for secure cloud infrastructure.
GPT: Employed for natural language understanding and generation.
numPy, Pandas: Data collection and cleaning
Scikit-learn: Applied for efficient model training

## Challenges we ran into

None of our team members had worked with google’s authentication process and the gmail api, so much of saturday was devoted to hashing out technical difficulties with these things. On the AI side, data collection is an important step in training and fine tuning. Assuring the quality of the data was essential

## Accomplishments that we're proud of

We are proud of coming together as a group and creating a demo to a project in such a short time frame

## What we learned

The hackathon was just one day, but we realized we could get much more done than we initially intended. Our goal seemed tall when we planned it on Friday, but by Saturday night all the functionality we imagined had fallen into place. On the technical side, we didn’t use any frontend frameworks and built interactivity the classic way and it was incredibly challenging. However, we discovered a lot about what we’re capable of under extreme time pressures!

## What's next for PhishBlock

We used closed source OpenAI API to fine tune a GPT 3.5 Model. This has obvious privacy concerns, but as a proof of concept it demonstrate the ability of LLMs to detect phishing attempts. With more computing power open source models can be used.