The most significant risk that could jeopardize the success of our project is getting everything to run on the board. As will be explained below, we are adding 2 new features and moved some part of website to being hosted on the board, which means we will need more resources on the board itself. To mitigate this risk, we will have an MVP up and running ASAP to test on the board. This way we can see if we will need to upgrade to a different board or if our raspberry pi 4 with 4gb ram is enough.
This week we decided to make some pretty substantial changes based on the design presentation feedback:
- Add 2 new features to increase scope of our project: (1) an timer feature and (2) an mp3 like feature where users can upload songs to their device and can play them from their device.
- We decided to move part of the website from being something we hosted to being hosted on the device. The website had 2 main purposes: (1) configure your device by passing in your VM endpoint and (2) everything else such as setup instructions, data privacy policies, and docker containers. Everything in (2) is strictly static, meaning that the same content can be used by every single user, so we are still going to be hosting this part. However, we decided to move (1) to being hosted on the actual device for each user. By doing it this way, we eliminate all 3rd parties, including ourselves. If we had kept (1) on our end, it would require us or a 3rd party to store user info (we chose Clerk which is a 3rd party but if we had implemented auth ourselves we would have had to store user info) which is against what we want to do. By doing the configuration on device, we eliminate the use of any 3rd party system and then the user owns all parts of the system which is our intended goal.
- We held a meeting with David Brumley and he gave us some advice regarding how to define privacy. Based on his feedback, we will be adding a terms of service agreement to our website to give users visibility into how their data is being used. We want to make it explicit to them that we nor any other 3rd party has access to their data or information at any point, including that their data is not being stored, their data is not being reused to train any models, etc. We need to make it very explicit that they own all aspects of the user experience.
- We also made the choice to have the users setup SSL encryption on their VMs (with instructions on our end). By doing so, we are not prone to man in the middle attacks between the devices and the VMs when making endpoint requests, which was a point of concern. After this is done, we can ensure that all privacy is being maintained with regards to the data transfers.Based on these changes, this is a rough estimate of what we want our schedule to look like in the upcoming weeks:
- Week 1-2: finalize design report, get rid of auth and move configuration to a separate device hosted website, start working on dockerization containers, start testing speech to text and text to speech.
- Week 3-4: Polish out UI and have it fully working, finish ToS, have dockers ready and on website with instructions, test individual components
- Week 5-6: test everything e2e, setup instruction guidebook
- Week 7: slack time to finish up anything we didn’t finish before. This accounts for unforeseen circumstances and pivotsWeek specific report:
- Part A(David):Our product has one main global factor that it affects. It is that our product ensures privacy to the user. While in the US this is mainly a data privacy issue as our government is most likely not actively using our data to control us, in other parts of the world this could be helpful against more controlling governments and therefore offer physical protection. In areas where there is no freedom of speech or less of it, a voice assistant in the house can be a danger if the data is sent out to an unknown location.
This product could also be of assistance in protecting government officials or anyone with confidential information. Because most voice assistant companies are in the US, there might be some mistrust for foreign people, especially those with confidential information being spoken in their houses. Our product ensures that all the data is kept within the user’s control, so that people from across the world can feel free to say anything they want and have it not be sent to a US server.
- Part B: (Kemdi Emegwa)Voice Vault aims to preserve the right to privacy and the right to consent while still allowing users to leverage state of the art artificial intelligence. By allowing the user to host their own model whether that be on the cloud or on their own local server, they gain the ability to dictate how their data is stored/used. At a time when AI/ML advancements have come perpendicular to user concerns about data privacy, our lightweight solution can bridge the gapPart C (Justin Ankrom): Voice Vault minimizes environmental impact by reducing energy consumption and electronic waste. It runs on a low-power 4GB RAM Arduino 4 board and has local storage via microSD which reduces dependence on external servers for storage, lowering the system’s carbon footprint. Its customizable design extends hardware lifespan by allowing upgrades instead of full replacements, reducing electronic waste. By supporting self-hosted LLMs, Voice Vault eliminates reliance on large-scale data centers, further decreasing energy consumption.
