LifeLog - Automatic Life Tracking Used AI

Added some API functionality, fixed bugs, and did stuff that I can't exactly remember. Was away for a while working on Solace, a physical extension of LifeLog for Highway, and went to Undercity!
With this current version I figured out the details of the architecture, so now I'm about to start from a blank slate and rewrite everything from the ground up. This time my goal is to write better code that's less prototypey.

Wish me luck

Today I continued cleaning the code, started writing a README, and even made an install/setup script for the LifeLog Agent (the local daemon). Tonight I'll go to sleep at a good time so I can work extra hard tomorrow!

Made a new banner image, logo, and cleaned up the code!

MWA HA HA! I've finally finished making everything work for postgres, and everything dockerized! It's finally back to the working state it was in 2 weeks ago.

Turns out that we've got a slight issue with our front end and api, but a fix is in the works!

It's dockerized! That's right, everything is now dockerized and running nicely! I'll clean up the code, then maybe, just maybe, I can ship!

Made major progress rearchitecting everything. I’m switching to a central server model that runs off-device, so each device just runs a daemon now. This makes it way more scalable and lets me support multiple devices cleanly.

Also fully dockerized the backend. Everything’s way more organized now, architecturally at least, code wise it's kinda a mess, but I'll clean that up soon. Few more bugs to fix before this new system works.

I've finished porting over to postgres!
That's it really.
Next update will be major, hopefully.

Alright, devlog time again! So, here’s the tea: I totally got distracted by all the shiny-new-thing hype and dove head-first into DuckDB without actually checking if it was the right fit. I spent basically the entire last week wiring up my whole LifeLog backend to use DuckDB—felt super productive… until reality slapped me.

Turns out DuckDB only lets one reader or writer touch the file at a time. Guess what happens when the enrichment pipeline and the API both want in at once? Yeah—💥 race-condition city. How did I not see that coming?

Cue the record scratch: “Wait, why am I fighting the database instead of actually continuing to work on the project?”
So today I went full tunnel-vision mode, spun up a local Postgres instance, and started porting everything over. I’m talking schema tweaks, ORM shenanigans, fresh config files—the works. I basically lived in VS Code for, like, eight hours straight, but the crazy part is… it’s almost done already. Since I’m still in version-zero territory, there were no migration scripts to worry about—just rip-and-replace, run the tests, and boom: the app boots without screaming at me. 🎉

Moral of the story: research first, chase hype later. Anyway, that’s where LifeLog’s at right now. Next devlog will probably be about ironing out the last Postgres edge-cases.

Stay tuned!

Turns out we have a bug that I should've foreseen. We can only have one writer to the database at a time, so when we have our API and daemon, they clash. I'll be working on fixing the code, but maybe I'll just use a different db.

🚀 API Online, Auth Added, and Frontend Works Once Again

Everything works once again! I feel like I spent this entire week working on this and it’s sad because it literally has no obvious changes to the end user — but ehh, it was required.

Rebuilt the entire API layer from scratch with authentication, fixed a small timezone bug that was messing with event days, and fixed the frontend so everything talks to each other again.

No visual changes, but under the hood it’s 10× cleaner and way more reliable.

Might take a short break before I tackle the next chunk — probably the dashboard or maybe clean up the code some more.

🧹 Bugs Fixed and Rigorous Testing Underway

After a long (and painful) battle with DuckDB and its weird SQL-standard-defying quirks, I finally got everything working again!

Rewriting the backend took way longer than expected, but it’s totally worth it — the architecture is way more solid now, and I’m sooo close to a clean public release and finally finishing this massive recoding sprint. I wish I had the energy to type out all the technical details, but I'm a little lazy right now...

Next up:

• Double-check that I didn’t break any processing logic (PLEASE PLEASE PLEASE let luck be on my side)
  
• Rebuild the API layer
  
• Rigorous testing to catch anything that slipped through
  

Hoping to make the GitHub repo public very soon™!

So far I’ve been calling the project LifeLog, but I’m open to better name ideas — got any?

Until next time!

Fixed major bugs, still many squash! Going through debugging pain, first time using duckdb.

I've completed the restructuring of the backend of my app!
This devlog was slightly rushed, but expect higher quality devlogs soon, as school just ended so I can primarily focus on my projects.

Major milestone today — I'm almost done fully redesigning the backend, again.
This time it's not just a simple rewrite though, it's an entire architectural redesign to allow it to work long term and with future features I've got planed.

Highlights:
- Replaced JSON & Parquet files with DuckDB (AMAZING improvement for long term use!)
- Added a daemon to automatically mange and run data ingestion and processing, but the interval of which I run each task may still change.
- New architecture to allow for both real-time data and automatic batch processing for LLM processing data. (setting the stage for upcoming features!)
- Updated the project classification logic to be more reliable and scalable

This took a while as I basically redesigned a major part of my app, but I think it was well worth it.
Thanks so much for reading — see you in the next update! 🚀