My Life Memory

An independently designed private memory atlas that connects places, routes, photos, and notes into a searchable map for revisiting personal life experiences, with direct MCP access.

Comment

Inspiration

This project was originally designed for my life as a student in South Korea. Because I have AuDHD, I can easily lose track of classrooms in unfamiliar environments, and uncertainty around schedules and physical spaces can make me anxious. At the same time, I have always had a habit of recording and planning my life. I therefore decided to begin with my own needs and build a program that could preserve places, routes, photos, and personal memories.

I believe that, just as a person has multiple facets in a three-dimensional world, a place or a memory is not an isolated coordinate. It is also connected to routes, photos, events, and other memories. Through these related pieces of information, a person can receive more kinds of prompts and rediscover an experience from different angles.

The visual style and interaction logic were inspired by some of the psychology and design knowledge I had encountered, together with my observations of everyday life. In this application, I wanted instrumental rationality to work together with emotional design.

Alongside the minimal and continuous interaction design, I added MCP functionality. This also reflects my original intention: “to make remembering faster and easier, while reducing cognitive load as much as possible.”

What it does

My Life Memory is a private map and memory-recording tool. Users can save places directly on a map or create a new place by importing a photo with GPS metadata. They can organize locations with differently colored stars and attach photos, written memories, and related information to each place.

The application also includes route recording, a personal memory list, location statistics, account management, and MCP access. These features are connected across the frontend, allowing users to revisit a saved experience through AI conversation, coordinates, map overviews, dates, or content-based views without moving between separate systems.

Users can generate an MCP access token directly inside the application. Even when a question does not use the exact words stored in a note, MCP can combine structured signals from place, time, personal-place relationships, events, and routes to search for relevant evidence inside the user’s own archive.

Every research result is returned in one of four states: supported, ambiguous, not-found, or candidate-review. Only supported results may contain related records, coordinates, routes, or image references. When the available evidence is incomplete or ambiguous, the system does not fill the gap with unrelated records. Instead, it may ask the user to confirm a privacy-screened short title, explicit name, generic clue, or neutral ordinal option without exposing candidate note bodies, dates, coordinates, scores, or internal identifiers.

MCP remains read-only, so an AI client cannot create, edit, or delete memories. This keeps ownership and editing authority over the archive with the user.

How we built it

Before the official Submission Period began, I had already developed the original product concept, visual language, and a working foundation, using ChatGPT as a discussion partner throughout the process. The existing project included the core map, place stars, memory notes, route recording, foundational interface, normalized user-scoped storage, synchronization foundation, account lifecycle, and core privacy controls. It was functional, but still needed reliability improvements and a more capable way to research the archive.

During OpenAI Build Week, I extended the project with server-owned media retention, date-range export, local-time-zone handling, rich-text and media reliability improvements, and an evidence-grounded, user-controlled read-only MCP research layer with strict ambiguity handling and privacy boundaries.

I independently defined the product direction, visual design, UI/UX, interaction design, feature decisions, test expectations, and acceptance criteria. Under my direction, Codex served as the primary implementation tool for writing and refactoring code, debugging, testing, documentation, and deployment verification. It felt more like an external engineering brain than simply a code-generation tool.

GPT-5.6 supported product and architecture review, privacy and interaction analysis, test planning, and preparation of the competition demo. GPT-5.6 is not embedded in the web application; compatible AI clients can instead connect to the user-controlled, read-only MCP.

In the visual design, I wanted the project to have both minimalist and retro-futurist qualities. I used large areas of gray and off-white, generous negative space, and restrained typography to preserve the clarity of a practical tool, while adding details with a printed texture and a sense of fantasy. I wanted it to feel both like a rational tool for recording life and something capable of carrying the emotional nature of memory.

The colorful stars in the interface are the core of the visual system. Each star represents a point of light within a personal memory, while its color helps the user distinguish between places, events, and different kinds of memories. Traditional retro-futurism often contains a great deal of complex decoration. I kept its ideas of outer space, computer terminals, and imagined futures, then simplified them into stars, input fields, typography, and interaction feedback so they could become part of a quiet, modern personal tool.

The project currently uses:

  1. React 19, TypeScript, Vite 6, and Tailwind CSS 4 for the frontend.
  2. Leaflet, React Leaflet, and MapLibre GL JS for maps and routes, with OpenFreeMap and VersaTiles Satellite as map sources.
  3. EXIF metadata for importing GPS coordinates from photos.
  4. Supabase Auth, PostgreSQL, Row Level Security, and private Storage.
  5. TypeScript and Deno Supabase Edge Functions for registration, account deletion, the Memory API, MCP, token management, and media-retention tasks.
  6. Local stdio and cloud Streamable HTTP MCP transports that share one validated contract of nine public read-only tools.
  7. GitHub Pages for the frontend and Supabase for the backend.

Both MCP transports publish the same shared tool manifest and validate requests against the same input contract before any archive query is executed.

On the backend, places, memories, routes, and settings are stored in separate normalized tables so they can be synchronized, searched, and managed more accurately. Row Level Security keeps every account inside its own data boundary. Users generate MCP tokens inside the application, while the backend stores only their SHA-256 hashes. The cloud MCP service verifies each token hash, resolves it to a single user, and reads only that user’s archive through an internal Memory API. Neither the frontend nor the MCP client receives the service-role key.

To move beyond simple keyword search, Codex and I designed MCP retrieval as a compositional, evidence-first process. It decomposes each request into structured signals such as public geography, date constraints, personal-place relationships, event targets, nearby scope, and route intent before searching the archive. Private expressions such as “my home,” “my office,” or “my school” are resolved only inside the authenticated archive. Only an explicit public geographic name is sent to public place resolution.

Every public research response conforms to one of four strict structured states. Only supported can contain evidence passages, records, coordinates, routes, or image references. Ambiguous clues remain candidates rather than facts. The service may show only a privacy-screened short title, explicit name, generic clue, or numbered fallback. After the user confirms an option, the server verifies a short-lived encrypted token bound to the user, the original question, the archive revision, the permitted option, and an expiration time. A host model’s own judgment cannot promote a candidate into evidence.

My Life Memory does not run a backend model and does not use embeddings, a vector database, or a paid model API. A connected AI client may provide limited vocabulary hints to improve candidate ranking, but those hints can never become memory evidence.

Private photos use a separate second-step tool. MCP first returns supported evidence and relevant note IDs, then revalidates user identity, note ownership, and private Storage paths before returning only a small, bounded set of images.

Challenges we ran into

The biggest challenge was that I did not have a deep technical background. Last year, I was not even comfortable using Photoshop and had not received systematic design training. I had completed only the first hundred-plus lessons of freeCodeCamp.

During development, I needed to understand the frontend, backend, databases, user authentication, image storage, and MCP at the same time. Many problems could not be solved by fixing one isolated piece of code. They required understanding how different functions connected and what kind of cognitive burden a user might experience.

MCP retrieval was especially difficult because human memories are rarely stored using strict keywords. A user may ask, “Where is my home?” while a note says, “we moved into this apartment,” rather than explicitly naming it as home. They may ask about “that cat,” while the saved note contains only a nickname. The system therefore had to connect different expressions without turning weak associations into facts.

I needed to balance helping the user rediscover a memory with refusing to guess private facts on the user’s behalf. In the final design, ambiguous candidates remain explicitly unverified until the user confirms one. The AI is not allowed to make that decision for them.

Accomplishments that we’re proud of

Honestly, this is the first time I have designed a complete frontend from scratch, and the first time I have developed one of my projects into a complete product with a frontend, backend, and real data functionality.

What I am most proud of is that I genuinely accomplished something I could not do before. The interface, logic, and interactions have also received positive feedback from both myself and some users. After I shared the project on other platforms, several people working in technology, travel blogging, and content creation saved it, and some contacted me directly to ask for access. It was the first time I felt that a deeply personal need could also provide real value to other people.

I am also proud of the application’s visual language. It preserves the clarity and order required by a practical tool without losing the privacy and emotional quality contained in personal memories.

Technically, I am glad that I did not turn MCP into a chat interface that can freely browse private data. It remains read-only, separates candidates from evidence, and asks the user when something is uncertain instead of rewriting the user’s memories on their behalf.

What we learned

I prefer learning through a real project rather than waiting until I have mastered every theory before beginning.

Throughout this process, ChatGPT continuously explained unfamiliar concepts to me, and I gradually developed a strong interest in coding.

I learned more than how to complete individual features. I also learned how to break down problems, examine AI-generated solutions, identify conflicts between features, and continually clarify what kind of product I actually wanted to build.

I also came to understand that using AI for development does not remove the need for judgment. Instead, I must continuously decide what the product should do, which solutions match user needs, which generated results need to be changed, and how visual and technical decisions should remain consistent.

After discovering MCP, I quickly realized that it matched this project very well. It made me rethink the relationship between personal software and AI. AI does not have to exist only as a chat window. Under clear permissions, it can enter a real personal tool and work with data that the user has chosen to save. I also learned that, in a private memory product, “not found” can sometimes be more correct than a convincing answer without evidence. Respect for the user is not measured only by how many questions a system can answer. It is also reflected in whether the system knows when it should stop guessing.

What’s next for My Life Memory

Next, I will continue improving the features and fixing possible bugs. I also hope to invite more real users to test the project, observe how they use maps to preserve travel, daily routes, and personal memories, and improve the experience based on their feedback.

For MCP, I will continue studying how real users describe vague places, objects, nicknames, and experiences. I want to improve candidate ranking and confirmation while preserving the principles of read-only access, evidence-first retrieval, and no guessing when evidence is missing.

My goal is for My Life Memory to become a quiet and private tool. As I continue to give it my attention and care, I hope that the speed, lightness, and reusability expressed through its interface and interactions can also offer other users some warmth and a reason to reflect: In such a fast-moving age, how can we embrace modern tools and modern ways of living while still preserving our private lives?

Built With

Share this project:

Updates