Fixing SSR Cache Issues & CSP for Portal Calls — September 2, 2026

Today was all about fixing some critical issues that had been nagging at my portal's performance. I tackled two main problems: one related to the SSR caching of the gp_theme cookie and another concerning the loading mechanism for daily-js calls. In the world of web development, these fixes may seem small on the surface, but they hold significant implications for user experience and system reliability.

The first fix I implemented was for the SSR caching of the gp_theme cookie. It turns out that allowing this cookie to be honored for anonymous requests led to a rather peculiar bug. A visitor who had their theme set to dark mode inadvertently baked a dark-variant page that was served to everyone else. This misconfiguration was due to the shared nginx page caches, which do not vary based on the gp_theme cookie. I spent about an hour digging into this issue, analyzing how the caching mechanism interacted with user requests. The solution was straightforward: I ensured that the gp_theme cookie would not be SSR for anonymous requests. This fix protects against cache poisoning and ensures that user-specific settings don't inadvertently affect others.

Next up was the issue with the daily-js call machine. The enforced Content Security Policy (CSP) on my portal was causing problems with loading the call-machine bundle. The CSP allowed wasm-unsafe-eval but not unsafe-eval, which meant that the default loader for daily-js was failing because it relied on eval() to fetch and execute the code. This issue was particularly frustrating because it was blocking every Tavus portal call at the join stage. After a focused hour of troubleshooting, I implemented a fix that allowed the daily-js call machine to load without eval, using the dailyConfig.avoidEval setting instead. This change not only resolved the immediate issue but also improved the overall security posture of the application by adhering to the CSP guidelines.

While both fixes were essential, they also highlight the challenges of building a robust system solo. I often find myself in a cycle of fixing bugs that arise from seemingly minor decisions, like how to handle cookies or how to structure my CSP. Each fix, while rewarding, also reminds me of the complexity of developing a one-man-show company. I rely heavily on AI, specifically Claude Code in VS Code, to assist me through these challenges. This collaboration allows me to tackle issues more efficiently than I would be able to alone, saving me countless hours and keeping me focused on my long-term vision.

As I reflect on today's progress, I appreciate the incremental nature of this journey. Fixes like these may not seem glamorous, but they are the backbone of a reliable product. The goal of achieving a billion-dollar valuation with my solo venture feels more tangible with each resolved bug and improved feature. Every fix contributes to a better user experience, reinforcing the value of the agentic web and the spatial AI capabilities I'm building into #SPACE.

Looking ahead, I know there are more challenges waiting for me. The path to a successful solo venture is littered with obstacles, but each fix brings me closer to my vision. I also recognize that the more I can optimize the portal's performance and reliability, the more confident users will be in engaging with the platform. This is especially crucial as I continue to build out features that leverage the power of agentic SEO and AEO, ensuring that my portal remains competitive in the ever-evolving landscape of AI-driven web solutions.

In summary, today’s work was a reminder of the importance of attention to detail and the necessity of robust error handling in the development process. As I move forward, I’ll keep these lessons in mind while pushing toward my goal of creating a world-class platform that harnesses the full potential of spatial AI and the agentic web. Each day, each fix, and each improvement takes me one step closer to realizing my ambitions and building something truly remarkable.