SCREAM
From a college web project to an experimental mobile, offline-first, peer-to-peer social platform.
The Origin
SCREAM began in 2024 as a college minor project co-created with Nejin Bejoy. The original requirement was to develop a web application using PHP and HTML. We built a conventional server-based social media platform where users could share and interact with information.
However, from the beginning, the underlying question was much broader: What if a social platform could continue to function even when conventional Internet connectivity was unavailable? At the time, we lacked the technical freedom to implement this within the bounds of a PHP web-development assignment.
The Architectural Problem
A conventional social-media platform depends on a communication path moving from User → Internet → Central Server → Internet → User. This architecture is effective, but it creates a total dependency on infrastructure. If internet connectivity becomes unavailable, unreliable, or inaccessible (due to disasters, infrastructure failures, or physical isolation), users lose access to the platform even when nearby devices are physically capable of communicating.
The Evolution to Peer-to-Peer
In May 2026, I personally began transforming the original PHP/HTML web implementation into a mobile application (APK). The intention was to explore a completely different communication architecture based around mobile devices, local communication, offline operation, and peer-to-peer networking.
The system shifts the paradigm to: User → Mobile Device → Nearby Device → Other Users. This isn't about replacing the internet; it's about exploring what could exist alongside it. When connectivity is available, conventional networking applies. When it's not, local peer-to-peer communication takes over.
Engineering Challenges
Moving to a distributed mobile architecture introduces complex technical challenges. Devices must discover each other locally without a central server. Information must be propagated reliably through the mesh, synchronized correctly when offline devices reconnect, and stored locally. Crucially, all this networking complexity must remain invisible to the user behind a familiar, fluid social-media interface.
Real-World Context
Later in 2026, as student protests occurred in New Delhi, we observed the communication conditions surrounding those events. It's important to clarify: the protests did not inspire SCREAM, nor did they cause the APK conversion. That transition was already underway. Instead, such global events—along with natural disasters and infrastructure failures—provide real-world context for why communication resilience is a technical problem worth solving.