CloudChat | Server Side v1.0.0

Secure Messaging Backend & Scope Locked / 15 Working Days

CloudChat je interni secure messaging system fokusiran na backend arhitekturu, kontrolisan tok podataka i sigurnosni model u kojem server nema pristup plaintext sadrzaju, vec prima, skladisti i obraduje sifrovane podatke. Sistem je zamisljen za kontrolisanu internu upotrebu, sa Laravel backend-om, MySQL bazom, razvojnim debug slojem i minimalnim web pregledom stanja servera.

Status: Backend Project Active Delivery Window: 15 Working Days Theme: Defense / Commission Review Ready Stack: Laravel + MySQL + Web Project Page

Project Scope

In Scope

  • Laravel backend setup and structure
  • MySQL integration and migrations
  • messages and tmp_messages
  • API and web entry scenarios
  • curl validation and browser validation
  • project page for centralized review
  • server health and background jobs overview
  • fine tuning of project presentation layer

Controlled Boundaries

  • No fake claims about completed mobile app
  • No hidden debug layer
  • No polling as target communication model
  • No dependency on Google push services in target design
  • No plaintext storage in final production direction

Planned Extension

  • Android Studio client phase
  • client-side encryption/decryption demonstration
  • open-connection delivery direction
  • status events and expanded server-side review
  • group and media extensions

Project Overview

CloudChat nije zamisljen kao masovna chat aplikacija, vec kao sigurnosno-orijentisan komunikacioni sistem za ogranicenu grupu korisnika. Fokus rada nije na vizuelnim efektima, vec na brzini, funkcionalnosti, sigurnosti i jasnoj backend arhitekturi. :contentReference[oaicite:2]{index=2}

Kljucna poruka rada je da server u sistemu nema pristup izvornom sadrzaju poruke. Enkripcija se vrsi na uredaju posiljaoca, dekripcija na uredaju primaoca, dok server prima, skladisti i isporucuje sifrovane podatke, uz pracenje statusa i dogadaja bez uvida u plaintext sadrzaj.

Ova stranica sluzi kao centralizovano mjesto za pregled scope-a, dnevne egzekucije, implementiranih backend komponenti, debug sloja, health/job mehanizma i naredne integracione faze.

Architecture

Presentation Layer

Web project page za pregled sistema, dnevnog napretka, server health stanja i demonstracionih scenarija. Kasnije i Android klijent kao dodatni ulazni sloj.

Application Layer

Laravel backend organizovan kroz routes, controllers, models i servisni sloj, sa dogadajno-orijentisanim pristupom obradi poruka i statusa.

Data Layer

MySQL baza za korisnike, poruke, statuse, pomocne razvojne debug zapise, kao i pratece server-side evidencije i job tokove.

Web / Curl / Future Mobile Client ↓ Routes / Controllers / Services / Models ↓ Messages / Debug Layer / Health Jobs / Status Data ↓ MySQL Database

Security Model

Core Security Rules

  • Server i baza ne smiju imati uvid u plaintext poruke u konacnom rezimu.
  • Ista poruka ne smije generisati isti ciphertext pri svakom slanju.
  • Za svaku poruku koristi se IV/nonce vrijednost.
  • Metapodaci i traffic analysis moraju biti uzeti u obzir.

Transport Perspective

  • Posiljalac salje sifrovani sadrzaj ka serveru.
  • Server cuva ciphertext, IV i statuse.
  • Server-side view prikazuje samo ono sto je stiglo backend-u.
  • Primalac kasnije dekriptuje sadrzaj na klijentskoj strani.
Security note: Sigurnost sistema zasniva se na pravilnoj primjeni provjerenih rjesenja, a ne na izmisljanju sopstvene kriptografije. Dokument projekta izricito trazi da server-side pogled ostane bez plaintext sadrzaja u konacnom rezimu rada.

Debug Layer tmp_messages

Razvojni debug sloj je obavezno implementiran i nije sakriven. Tokom razvoja koristi se pomocna tabela tmp_messages kao transparentan zapisni sloj za validaciju tokova obrade poruka. Ovo je direktno u skladu sa zahtjevom da se razvojni proces prikaze posteno i jasno.

Development Mode

  • MSG_DEBUG_MODE=true
  • upis u messages
  • dodatni razvojni upis u tmp_messages
  • transparentna validacija ulaza i obrade

Production Direction

  • MSG_DEBUG_MODE=false
  • glavni tok ostaje aktivan
  • debug zapis se gasi
  • bez plaintext debug tragova

Server Health & Background Jobs

U zavrsnom scope-u dodat je i server health sloj kroz pozadinske jobove. Cilj ovog dijela nije da projekt postane te ak , vec da postoji jasan pregled osnovnog stanja serverske strane i minimalni operativni sloj, Sto je u duhu dokumenta koji predvida monitoring i rutine odrzavanja servera.

Health Jobs

  • scheduled server health checks
  • database reachability verification
  • queue/job status awareness
  • basic application readiness signal

Monitoring Intent

  • minimal server-side operational review
  • readiness for defense demonstration
  • future extension for message statistics
  • fine tuning of project status view

Implementation Direction

  • Laravel jobs / scheduler layer
  • health status cards on project page
  • clear separation from core message flow
  • supporting server-side discipline

15-Day Execution Plan

Realisticna procjena za naprednog studenta uz vodeni rad, sa jasno definisanim scope-om, backend-first pristupom i odvojenim fazama implementacije, prezentacije, health sloja i fine tuning-a.

Day 1 : Environment Setup Foundation

  • Laravel project initialization on server
  • project structure review
  • .env configuration
  • MySQL connection validation

Day 2 : Base Framework Validation Initial Readiness

  • initial migrations
  • framework database readiness
  • environment confirmation through phpMyAdmin
  • core project folder validation

Day 3 : Core Message Table Database Model

  • design of messages table
  • sender, receiver, ciphertext, IV and status fields
  • database structure review
  • server-side storage model confirmation

Day 4 : Debug Table Transparent Development Layer

  • creation of tmp_messages
  • clear development-only debug write strategy
  • validation of visible debug records
  • alignment with transparent project reporting

Day 5 : Debug Mode Switch Controlled Environment

  • MSG_DEBUG_MODE configuration
  • development vs production separation
  • non-hidden debug flow policy
  • preparation for controlled disable path

Day 6 : Model & Controller Layer Application Logic

  • Message model configuration
  • MessageController implementation
  • fillable fields and request validation
  • message insert path prepared

Day 7 : Backend Write Flow Processing

  • write to messages
  • conditional write to tmp_messages
  • server-side processing proof
  • same logic for multiple entry points

Day 8 : Request Entry Design Web and API Direction

  • web route role clarified
  • API route role clarified
  • backend-first routing logic aligned with MVC
  • clean request entry strategy defined

Day 9 : Curl Scenario Direct Validation

  • HTTP POST test via curl
  • direct backend validation without browser layer
  • database insertion confirmation
  • debug write confirmation

Day 10 : Web Scenario Browser Validation

  • browser-based request validation
  • same backend flow as curl
  • PC/mobile browser equivalence for HTTP perspective
  • demonstration-ready visual entry point

Day 11 : Central Project Page Single Review Point

  • scope visible immediately
  • overview and architecture sections
  • daily execution blocks
  • defense and commission-friendly layout

Day 12 : Server Health Layer Operational View

  • background jobs for health checks
  • basic monitoring concept
  • status visibility for server-side readiness
  • job role separation from core message flow

Day 13 : Fine Tuning Presentation & Review

  • layout simplification
  • dark theme refinement
  • content tightening for commission review
  • hardening of project presentation layer

Day 14 : Communication Model Definition No Polling / No Google Push

  • event-based direction clarified
  • open-connection concept defined
  • explanation of why polling is excluded
  • explanation of why external push services are excluded

Day 15 : Mobile Readiness & Defense Positioning Next Phase

  • Android Studio phase prepared conceptually
  • Telefon A ? Server ? Telefon B flow described realistically
  • implemented vs planned scope clearly separated
  • defense-ready final project overview

Current Status Snapshot

Backend

Laravel structure, routes, controllers and message processing direction defined.

Database

messages and tmp_messages form the visible core of the current prototype.

Health

Server health/job layer added into final locked scope as a monitoring extension.

Execution Principle

Uvod daje puni pregled projekta, dok se po danima prikazuje egzekucija: Sta je implementirano, sta je validirano, sta je dodatno uvedeno u finalni scope i sta predstavlja narednu fazu sistema.

Request Scenarios

Browser / Web Scenario

Browser (PC or phone) ↓ Web entry point ↓ Laravel controller flow ↓ messages + tmp_messages ↓ database state visible on server side

Browser is only the client entry. Backend processing remains identical.

Curl Scenario

Terminal / curl request ↓ Direct HTTP backend call ↓ Laravel controller flow ↓ messages + tmp_messages ↓ database state visible on server side

Curl serves as direct backend proof without browser presentation layer.

Next Phase

Android Direction

  • Android Studio client implementation
  • controlled onboarding and login flow
  • message sending from device
  • client-side encryption/decryption demonstration

Delivery Direction

  • open-connection communication model
  • event-driven client notification direction
  • no polling as target architecture
  • no Google push dependency in target delivery model

CloudChat u konacnici nije obicna chat aplikacija, vec sigurnosno-orijentisan komunikacioni sistem ciji su glavni stubovi backend arhitektura, kontrolisan tok podataka i pravilno implementiran sigurnosni model.

CloudChat Project Page @ centralized dark-theme review of scope, execution, backend architecture, debug layer, server health and next-phase readiness.