Inspiration
Let's cut the bullshit: location data is a company's most radioactive asset. One database breach, and an organization is drowning in lawsuits, compliance fines, and PR nightmares. We looked at the current industry landscape and realized everyone is forcing a false dichotomy: you either get highly accurate spatial data (and accept the massive liability), or you anonymize it so heavily that it becomes completely useless for public safety or targeted queries.
We built EPLQ because organizations need the analytical power of spatial tracking without holding the toxic liability of raw user coordinates. We wanted a system where data utility and mathematical privacy coexist.
What it does
EPLQ (Efficient Privacy-Preserving Location-Based Query) is a zero-knowledge geospatial intelligence grid. It allows users to perform spatial range queries to find Points of Interest (POIs) with absolute privacy.
When a user initiates a query, the cloud provider never sees their raw coordinates. We encrypt the spatial data at the client level. You query the grid, you get your encrypted results, decrypt them locally, and the host stays completely blind to your actual location—dropping the re-identification risk to zero.
How we built it
We refused to rely on bloated templates. We engineered the frontend architecture using Next.js and React, building a highly responsive, client-side decryption engine. To ensure the UI looked and felt like a secure military-grade node without sacrificing performance, we heavily utilized Tailwind CSS for rapid, dark-mode-first styling.
For our infrastructure, we wired the application directly into Firebase. But here is the critical part: Firebase acts strictly as a blind storage provider. By utilizing the crypto-js library, we implemented AES-256 encryption on the client before the data ever hits Firebase's Firestore database.
Challenges we ran into
Hooking up Firebase while mathematically ensuring it could not read the data it was storing was a massive architectural headache. We had to rethink how queries work—you can't ask a database to filter by distance if the database can't read the coordinates.
We had to build a system that securely pulls the encrypted POI payloads from Firebase, decrypts them entirely on the client side using the user's Private Key, and then runs the complex Haversine distance formulas locally in the React state. If our local state management lagged or the decryption integrity check failed, the map grid would just render garbage.
Accomplishments that we're proud of
We successfully decoupled spatial utility from privacy risk. We are incredibly proud of the UI/UX—built with Next.js and Tailwind, it doesn't just look like a secure node; it behaves like one without freezing the browser during heavy decryption loops. We completely abandoned standard passwords in favor of cryptographic "Private Keys," engineering a seamless authentication flow that verifies complex constraints in real-time.
What we learned
We learned that building secure software is easy, but building secure software that people actually want to use is brutal. If the UI is clunky, users will bypass the security. We learned the raw power of React's state management when handling decrypted data arrays on the fly. Most importantly, we learned that true privacy isn't just a compliance checkbox—it requires fundamentally restructuring how client-server data flows operate.
What's next for EPLQ
This isn't just a hackathon prototype. The immediate next step is expanding our Firebase integration to handle real-time, decentralized nodes and implementing stricter Laplace differential privacy noise algorithms to blur coordinates even further.
Down the line, we plan to integrate Federated Learning. This will allow AI models to train on this spatial data across different Next.js edge nodes without ever centralizing the raw records. We are taking EPLQ from a proof-of-concept directly to a production-ready enterprise protocol.
Log in or sign up for Devpost to join the conversation.