I can't remember exactly when I started using Google Photos, but it’s been my go-to for a long time, probably since it was released. It is one of the most useful pieces of software I've ever used. However, in 2021, I became a father, which completely changed how I used it and made me question if I could keep relying on it. I started taking far more pictures and videos than I ever had before. A couple of months later, the sheer volume of media forced me to start paying for extra Google Photos storage.
Around that time, I questioned why I was paying to store pictures I took myself. I started digging around for another solution to avoid those storage fees. I realized that across all my devices in the office (Android phones, tablets, a laptop, and a desktop), I already had plenty of storage. Each device had a minimum of 500GB, which was more than enough to hold all my media. I also had a DigitalOcean droplet used for random coding projects, but going that route meant paying for another server and dealing with a complex setup, so I skipped it.
Next, I looked into alternatives like rsync, Immich, Syncthing, and similar tools. Immich is great software with a solid UI, but the rest were still too complicated for my needs. I wanted the exact same "install and forget" experience that Google Photos provides. Setting those up took too much time, and I didn't love the UI/UX on most of them. If I had enough coffee and time, I could probably have made them work, but where is the fun in that? I decided to build my own solution so I could do whatever I wanted.
Here is what I wanted to accomplish without spending money or waiting too long:
- Sync all files across all my devices.
- Analyze all the files to extract useful information.
- Provide a simple UI that even a five-year-old could use.
- Ensure photo searches are fast.
- Keep the user experience non-technical.
Google Photos sometimes takes too long to load old memories, but its best feature is how easy it is to find a picture based on a location or person. I wanted that exact same functionality.
So, I grabbed my coffee, put on my geeky hat, and started researching how to build this. This was before ChatGPT, so I had to do it the old-fashioned way by reading articles and extracting the bits and bytes.
After a couple of brainstorming sessions, I nailed down my tech stack. Naturally, I chose Rust because it seemed cool. I also came across Tauri right around the time their team started the project. For syncing, I discovered the WebRTC protocol. It seemed perfect for allowing devices to communicate without a centralized server.
I eventually realized that wasn't entirely true; you still need a centralized way (a signaling server) for devices to find each other. I tried using QR codes to solve this, but it was too complicated. Not every device has a camera, meaning users would eventually have to enter IP addresses manually, which violated my "non-technical" rule.
Around that time, I figured out how to extract metadata from pictures and used jwalk to recursively walk directories. My proof of concept was working.
Then I hit a roadblock: Tauri didn't support mobile yet. I waited for months. One random day, I saw an article about running a Tauri application on mobile. I grabbed my laptop, jumped in, and actually got an app running on my phone. Official mobile support wasn't fully there yet, so I had to wait again until the Tauri team officially released it, which they eventually did.
When that day came, I started working on the project on and off in my free time. Things moved slowly. WebRTC was complicated, and extracting information from the pictures was a headache. But then the software industry shifted, and AI tools arrived. After initially feeling like I was cheating myself by using AI, I got over it once I saw how fast I was solving problems and creating things.
(Note: I only used Gemini to fix this article, not to generate it 🚀)
I decided the QR-code signaling method was definitely too complex. Instead, I discovered mDNS, which allowed me to find other devices on my local network without overcomplicating things. It was difficult to implement, but I got it working.
That left one problem: what if I'm not at home? I realized I still needed a signaling server. I decided to vibe-code a separate project in Go, making it easy to host on my own server using a simple Docker Compose setup. I originally wrote it in Rust, but I wanted to give myself the opportunity to use Go after a couple of years. I currently use OpenCode with the Big Pickle model, and it gets the job done.
Next came the complicated part: picking the right models to analyze all my media. I ended up building a pipeline to run several distinct local models against every file. As of right now, Siegu handles Smart Search (finding objects and scenes), Face Grouping, and a Text Finder for things like receipts. The best part? It all runs locally. The Face Grouping model is only 2MB, and the Smart Search model is 350MB, meaning it stays entirely on-device.
My only current issue is my hardware. I use a ThinkPad E14, which defaults to the CPU instead of the GPU. I know about OpenVINO, but I don't fully understand it yet. I'm going to try to fix this before the 1.0 release. It takes around 40+ hours to analyze about 4,000 pictures and videos that I extracted from a Google Takeout export. And I didn't even extract everything yet, so when I'm done, I will probably need to buy new hardware.
If you're still reading, I know I'm just yapping now. But I got it to work, and the day I no longer have to pay to look at my own pictures is coming soon.
The project is called Siegu, which means "blind" in Papiamentu, the language of Curaçao (that tiny island in the World Cup). Some people will point out that it won't work behind certain firewalls or without a TURN server, but if that's your situation, then you just can't use it. That sounds like a "you" problem.
The project is open source and available on GitHub: https://github.com/denzyldick/siegu.
My next article will be for the 1.0 release. Right now, it's just me, Big Pickle, and sometimes Codex building this, so it takes time.
I also expect a lot of issues with this. I only have a Linux box and an Android device, but I want to support everything eventually. So when you fork it, please open GitHub issues for anything that isn't working—because it probably won't run without a few problems! If you are interested, you know what to do: just fork it! :D
Top comments (0)