This is my submission for the Hacktoberfest Weekend Challenge: Build for a Friend.
I built this for a friend who has a lot of photos and memories that are meaningful to them, but finding a particular one later can be surprisingly difficult.
They might remember the moment clearly:
"That evening when we went out."
"That photo with everyone."
"The day we were playing tennis."
But remembering a moment isn't the same as remembering a filename, folder, or date.
That was the problem I wanted to solve for them.
So I built MemoryBox — a personal memory archive where you can search for photos based on what you remember about the moment, rather than how the file is stored.
Instead of asking:
"What was that file called?"
you can ask:
"Show me the photos from our tennis day."
MemoryBox uses open-weight AI to understand uploaded photos, turn that understanding into semantic representations, and make those memories searchable.
🎥 Demo video: https://youtu.be/TgyCizkhFz4
🌐 Live app: https://memorybox-frontend.onrender.com/
The demo shows the complete flow: up a photo, having the AI understand it, and searching for the resulting memory using natural language.
💻 GitHub: https://github.com/asnamobin-hue/memorybox
The repository contains the Spring Boot backend, React frontend, Docker configuration, and Python embedding helper.
The core of MemoryBox is an open-weight AI pipeline.
Photo
│
▼
Qwen3-VL-2B-Instruct
│
▼
AI-generated image description
│
▼
Qwen3-Embedding-0.6B
│
▼
1024-dimensional embedding
│
▼
PostgreSQL + pgvector
│
▼
Semantic memory search
For image understanding, I used Qwen/Qwen3-VL-2B-Instruct.
For embeddings, I used Qwen/Qwen3-Embedding-0.6B.
Both model checkpoints are published under the Apache 2.0 license.
When a photo is uploaded, the vision model generates a description of what is happening in the image — including things like people, activities, objects, and surroundings.
That description is then passed to the embedding model, which converts it into a 1024-dimensional vector.
The vector is stored in PostgreSQL with pgvector.
When someone searches for a memory, the search text is embedded and compared against the stored vectors to find semantically related memories.
The application is built with:
The deployed version currently calls the models through Hugging Face inference. The application keeps the model layer separate from the rest of the backend, so the models can be changed without redesigning the entire application.
That separation was important to me because I didn't want the AI part of the project to become permanently tied to one proprietary API.
I chose open-weight models because I wanted control over the most important part of the application.
MemoryBox isn't just using AI to generate a nice description.
The model output becomes part of the actual data pipeline:
photo → understanding → embedding → vector search
Using separate open-weight models for those stages means I can inspect the models, change them, and experiment with different approaches without rebuilding the entire application around a single closed provider.
It also gives me a path toward a more private version of MemoryBox.
The current public deployment uses hosted inference because that made the project practical to deploy during the challenge. But the model checkpoints are available for local use, so a future version could move inference closer to the user's device or private server.
For a project dealing with personal memories, that possibility matters.
A closed API can be convenient, but I don't want convenience to be the only option.
Open models gave me a different starting point: build the application around models that can be replaced, inspected, and eventually run in an environment I control.
One of the searches I tested was:
"tennis"
The system was able to retrieve a memory from my uploaded photos that was associated with our tennis day.
The stored memory also contains the AI-generated description and its embedding, so the search isn't dependent on the original filename.
That was the part that made the idea feel real to me.
I wasn't searching for a file called IMG_1234.jpg.
I was searching for something I remembered.
The current search isn't perfect either. Some unrelated memories can still appear after the strongest matches.
That's one of the things I want to improve next rather than pretending semantic search is already perfect.
Getting the first version working locally was not the hardest part.
Getting it to work in production was.
I ran into:
At one point, photos were up successfully but the AI processing was failing.
I didn't know whether the problem was the vision model, embeddings, PostgreSQL, or deployment.
So I temporarily exposed the actual processing error through the application instead of continuing to guess.
That eventually led me to the real problem.
The embedding service was returning the vector in a nested form:
[[1024 values]]
while my Java code was expecting:
[1024 values]
The fix was small: unwrap the nested response before validating the 1024 dimensions.
Finding it was not small.
That experience taught me that getting something to work on localhost and getting it to work for an actual user are very different problems.
MemoryBox currently stores the uploaded image, the user's description, the AI-generated description, and the embedding associated with the memory.
The deployed application uses Render for the backend and PostgreSQL for the database, while model inference currently goes through Hugging Face.
So the current version is not yet a fully local/private memory vault.
I want to be clear about that because these are personal photos.
The open-weight model choice gives me a path toward local or self-hosted inference in a future version, but that is not something I want to claim the current deployment already provides.
This project started with a simple problem about finding photos.
It ended up teaching me much more about building an actual AI-backed application.
I had to understand how:
fit together.
I also learned that using AI isn't just about calling a model.
The interesting engineering is everything around it — choosing where the model fits, processing its output, storing it, searching it, handling failures, and making the entire pipeline reliable.
Most importantly, I learned that a small personal problem can lead to a surprisingly deep engineering project when you actually try to make it work end-to-end.
MemoryBox is working end-to-end now, but I don't consider it finished.
The biggest things I'd improve are:
For this weekend, I kept the scope realistic.
The goal wasn't to build the biggest AI application I could.
It was to build something for one real person that could actually be used.
This project started with a friend and a simple problem: having a memory in mind but not having an easy way to find the photo again.
That became MemoryBox.
How do you find a memory again when you remember the moment, but not the file?
That's the problem I wanted to solve for them.