Project Portfolio Analysis¶

Deep-dive research on 0x1RIS backend engineering projects - extracted from source code, architecture docs, configs, and workflow specs

1. SMail - SecureMailSystem¶

Tech Stack Summary¶

Dependencies (from pyproject.toml): fastapi, sqlalchemy, pycryptodome, cryptography, bcrypt, python-jose, passlib, pydantic-settings, email-validator, httpx, psutil, python-multipart, uvicorn

Architecture Highlights¶

Zero Trust Architecture with 5-layer security middleware stack:

# From architecture: middleware chain
RequestSizeLimitMiddleware(25MB) -> AccountProtectionMiddleware -> 
InputValidationMiddleware -> SecurityHeadersMiddleware -> SecureErrorMiddleware

Modular backend structure - clean service/repository separation:

backend/
├── app/
│   ├── api/v1/          # Route handlers (auth, emails, users, keys)
│   ├── core/            # Config, JWT, security middleware
│   ├── services/        # Business logic (auth, email, crypto, e2ee)
│   └── main.py          # FastAPI entry point
├── db/                  # SQLAlchemy models, CRUD, connection
├── crypto/              # RSA engine, AES engine, X25519, bcrypt hasher
└── tests/

Hybrid E2EE encryption pipeline - every email goes through this: 1. Generate random AES-256 session key + 12-byte nonce 2. AES-256-GCM encrypt subject + body with session key 3. RSA-4096-OAEP wrap session key with recipient's public key 4. RSA sign with sender's private key 5. Server stores only ciphertext - zero knowledge

Perfect Forward Secrecy (PFS): Per-message X25519 ephemeral keys combined with RSA-4096 key pairs. Each message gets unique session keys - compromise one doesn't leak others

Security Features¶

Crypto primitives used across the system:

Performance metrics (from chapter 4 results): | Operation | Avg Time | Success Rate | |-----------|----------|-------------| | RSA-4096 Key Generation | 245ms | 100% | | AES-256-GCM Encryption | 1.2ms | 100% | | RSA-4096 Key Wrapping | 4.8ms | 100% | | Full Email Send | 380ms | 100% | | Login Auth | 180ms | 100% | | Token Verification | 8ms | 100% |

Key Challenges Solved¶

• Server breach resilience: Zero-knowledge architecture - server stores only encrypted blobs, never sees plaintext
• Gmail bridge: IMAP sync that re-encrypts incoming emails with user's RSA keys before storage
• Quantum readiness: Hybrid encryption (X25519 + RSA-4096) provides migration path to post-quantum
• Session management: Short-lived tokens + refresh rotation + device fingerprinting + IP/session validation
• Spam in E2EE: Spam scoring on encrypted metadata headers without breaking zero-knowledge

Database Schema Design¶

11 tables with full audit trail: - users: RSA/X25519 key storage, KDF params, 2FA (TOTP), Gmail credentials encrypted - emails: Encrypted subject/body/session-key, nonce, PFS flag, crypto version tracking, spam score - public_keys: Key rotation support with expiry/revocation tracking - audit_logs: Tamper-evident logging with previous_log_hash / log_data_hash chain - sessions: Device fingerprinting, IP tracking, revocation support - email_folders: Custom folder system with drag-and-drop (folder_items bridge table) - drafts: Encrypted draft storage with session keys - attachments: Per-file encrypted content with separate nonces - notifications: In-app notification system with JSON metadata

Code Quality Indicators¶

• Build system: Poetry/pyproject.toml, Docker Compose, Flutter pubspec
• Management: manage.py with health, quickstart, db init/backup commands
• Testing: Manual E2EE verification checklist (STARTUP.md)
• Documentation: 8-chapter thesis-style docs covering architecture, methodology, implementation, results
• Thesis-level rigor: Success rate tracking, timing benchmarks, attack vector mapping, comparison with PGP

Why It Matters¶

This isn't a toy email app - it's a production-grade secure communication system that implements real cryptographic primitives (not wrappers), with measurable performance characteristics and documented threat model coverage. The zero-knowledge architecture, hybrid PFS, and tamper-evident audit logging demonstrate deep understanding of both cryptography engineering and secure system design. The 8-chapter thesis documentation shows academic-level rigor applied to a practical engineering problem. Dual platform (Flutter + FastAPI) with cross-compilation targets shows full-stack capability.

2. Online POS - Car Parts Shop¶

Tech Stack Summary¶

Dependencies: @neondatabase/serverless, bcryptjs, html5-qrcode, jsonwebtoken, xlsx

Architecture Highlights¶

API routes - 13 endpoint modules under /api/:

api/
├── auth.js        # JWT + PIN + bcrypt login
├── categories.js  # CRUD for car part categories
├── customers.js   # Customer management
├── dashboard.js   # Aggregated metrics
├── db.js          # Neon query helper (parameterized)
├── debug.js       # Dev debugging
├── products.js    # Full CRUD + stock tracking
├── purchases.js   # Purchase orders + items (cascade)
├── reports.js     # XLSX export
├── sales.js       # POS sales + discount support
├── settings.js    # Shop config (name, phone, tax)
├── setup.js       # Initial DB migration
└── suppliers.js   # Supplier management

Dual-auth system - cashiers get PIN-based login (4-6 digits), admins get username + password with bcrypt verification. JWT tokens expire after 12 hours.

Database schema - 10 tables for car parts shop ERP: - categories (10 default - Arabic names for engine, electric, tires, batteries, oil, filters, brakes, lighting, chassis) - products with barcode, part number, min_stock alerts - sales/sale_items with discount support, invoice numbers - purchases/purchase_items with cascade delete - customers, suppliers, users (admin/cashier roles), settings - Indexed on foreign keys, created_at timestamps

Key Challenges Solved¶

• Car parts inventory: Barcode + part number + Arabic category names
• Dual auth modes: PIN for cashier speed, password for admin security
• Neon serverless: Cold-start optimized queries via @neondatabase/serverless
• QR code scanning: html5-qrcode for barcode-based product lookup
• XLSX export: Reports module generates Excel for accounting

Code Quality Indicators¶

• Build: Vite 8 (bleeding edge), single-file SPA bundle
• Deployment: Vercel with API route rewrites
• Error handling: try/catch with 500 responses, input validation
• Security: JWT middleware on all routes (requireAuth), parameterized queries
• Auth separation: Cashier vs admin roles with different auth flows

Why It Matters¶

SPA ERP built without React/Vue - raw vanilla JS that deploys to serverless on Vercel with Neon PostgreSQL. The dual auth pattern (PIN for cashiers, password for admins) shows practical UX thinking for retail environments where speed matters. QR code scanning for inventory is a real feature, not demo fluff. The schema is clean with proper cascade deletes and indexing.

3. FerroWA¶

Tech Stack Summary¶

Full Rust dependency list: tauri 2, serde/serde_json, anyhow/thiserror, chacha20poly1305 0.10, argon2 0.5, hmac 0.12, sha2 0.10, rand 0.8, zeroize 1, notify-rust 4, tracing/tracing-subscriber, dirs 5, tikv-jemallocator 0.5, tungstenite 0.24 (native-tls), url 2, native-tls 0.2, base64 0.22, webkit2gtk 2.0, gtk 0.18

Architecture Highlights¶

Module structure - clean domain separation:

src-tauri/src/
├── app.rs            # Bootstrap, AppState, IPC registration, cookie setup
├── main.rs           # Entry point, jemalloc global, dead_code allow
├── core/             # Config loader, FerrowaConfig, errors, observability
├── features/         # Domain modules:
│   ├── auth/         #   PIN setup, unlock/lock, rate limiting, password hashing
│   ├── privacy/      #   Screen blur (privacy mode on lock)
│   ├── notifications/#   Native Linux notifications (notify-rust)
│   ├── settings/     #   Runtime config management
│   ├── ux/           #   View state management
│   └── websocket/    #   IPC WS bridge commands
├── platform/         # Platform-specific:
│   ├── tray/         #   System tray icon + menu
│   ├── webkit/       #   Navigation guard, cookie manager
│   └── ws_bridge/    #   TCP+TLS WebSocket bridge
├── security/         # Crypto primitives:
│   ├── config_encryption/  # ChaCha20-Poly1305 AEAD
│   ├── key_derivation/     # Argon2id PIN→key
│   └── errors/             # SecurityError enum
└── shared/           # Cross-cutting:
    ├── rate_limiter/ # Token bucket rate limiter
    ├── nonce/        # Nonce generation
    ├── sanitize/     # Input sanitization
    └── commands/     # Shared IPC commands

CSP bypass architecture - the core engineering challenge solved in 4 iterations:

1. ws_proxy.rs (v1 - CSP blocked): localhost proxy, but browser's CSP intersect with WA's policy blocked all non-WA WS URLs
2. ws_bridge v1 (v2 - IPC tunnel): fake WebSocket class tunnels through Tauri IPC to Rust TCP+TLS - no browser-level WS to non-WA URLs, CSP never fires
3. ws_bridge v2 (v3 - cookie problem): WA login sets HttpOnly cookies invisible to JS document.cookie; WA rejected WS connections missing these cookies
4. ws_bridge v3 (v4 - WebKitGTK cookie manager): Traverses GTK widget tree to reach WebKitGTK's cookie manager, reads HttpOnly cookies, forwards them in WS upgrade via Cookie header

Key architectural insight from app-shell-ui.js:

// WA CSP: connect-src wss://web.whatsapp.com
// Our CSP: connect-src *
// Browser intersection: only wss://web.whatsapp.com
// Solution: Fake WebSocket -> Tauri IPC -> Rust TCP+TLS
// No browser-level WS created to non-WA URL

Security Features¶

Config encryption format: [12-byte nonce][ciphertext + 16-byte tag][32-byte HMAC] - HMAC covers nonce + ciphertext (authenticate-before-decrypt) - Random nonce generated per encryption via OsRng - Key derived from user PIN via Argon2id

From the security module docstring:

ChaCha20-Poly1305 AEAD for config at-rest encryption Argon2id key derivation from user PIN HMAC-SHA256 integrity verification for encrypted blobs Trust Level: HIGH - cryptographic boundaries that protect secrets at rest

Key Challenges Solved¶

• CSP bypass for WhatsApp Web: WhatsApp's page CSP blocks all non-WA WebSocket connections. The IPC tunnel approach means no browser-level WS connection is ever created to a non-WA URL, so CSP never fires. The fake FerrowaWebSocket class replaces window.WebSocket only for WA WS URLs
• HttpOnly cookie forwarding: WA sets auth cookies as HttpOnly - invisible to JavaScript. Solution traverses GTK widget hierarchy from Tauri window to find the WebKitGTK WebView, extracts its CookieManager, and forwards cookies in Rust-level WS upgrade requests. This required unsafe pointer smuggling across thread boundaries (usize cast because CookieManager is a GLib GObject that doesn't implement Send/Sync)
• Window close→hide: App minimizes to tray instead of quitting (expected chat-app behavior), implemented via on_window_event with api.prevent_close()
• Memory safety: zeroize ensures PINs and encryption keys are scrubbed from memory on drop. jemalloc reduces fragmentation for the long-running desktop app

Code Quality Indicators¶

• Rust standards: #![allow(dead_code)] with documented rationale, #![cfg_attr(not(debug_assertions), windows_subsystem = "windows")]
• Observability: Structured tracing with tracing + tracing-subscriber (env-filter)
• Error handling: thiserror + anyhow with security-specific SecurityError enum
• Testing: Unit tests for crypto config_encryption roundtrip, wrong key failure, tampered data detection; Argon2 key derivation determinism tests
• Release hardening: LTO thin, codegen-units=1, panic=abort, strip=symbols, opt-level=3
• Defense in depth: CSP in tauri.conf.json + navigation guard in Rust + cookie isolation + rate limiter per feature

Why It Matters¶

This is the most technically sophisticated project in the portfolio. The CSP bypass via IPC-tunneled WebSocket is a novel approach to a hard problem (WhatsApp Web's CSP blocks all third-party WS connections). The evolution through 4 iterations of the WS bridge shows genuine engineering iteration. The WebKitGTK widget tree traversal to extract HttpOnly cookies involves unsafe Rust pointer handling across GObject boundaries - real systems programming. The cryptographic module (ChaCha20-Poly1305 + Argon2id + HMAC + zeroize) is production-grade with documented attack surface analysis. The rate limiter per feature, structured observability, and jemalloc integration show maturity in desktop application engineering.

4. Great Society - Website¶

Tech Stack Summary¶

Key frontend deps: @mui/material/icons 7, @radix-ui/* (18 packages), @supabase/ssr + @supabase/supabase-js, tailwindcss 4, motion 12, embla-carousel-react, react-router 7, lucide-react, recharts, cmdk, sonner, zod 4, react-hook-form, date-fns

Key backend deps: express 5, mysql2, jsonwebtoken, bcryptjs, multer, nodemailer, xlsx, openai, cors, dotenv, tsx, pm2

Architecture Highlights¶

Frontend structure - organized by feature:

src/app/
├── App.tsx              # Root with routing
├── routes.ts            # Route definitions
├── components/          # Reusable UI (PropertyDetailModal, NotificationBell, etc.)
├── pages/               # Page components (SuperAdminDashboard, etc.)
├── context/             # React context providers
├── lib/                 # Utilities (api.ts, imageUtils.ts)
└── data/                # Static data / constants

Backend structure - Express 5 with dynamic route loading:

backend/
├── server.ts            # Express entry, CORS, SPA fallback, cron
├── db.ts                # MySQL connection pool
├── jwt.ts               # JWT token helpers
├── routes/
│   ├── auth.ts          # Registration, login, OTP verification
│   ├── properties.ts    # Property CRUD, search, featured, pagination
│   ├── admin.ts         # Admin CRUD, set-featured toggle
│   ├── contact.ts       # Contact form + auto-notification creation
│   ├── notifications.ts # Notification CRUD, push to bell
│   ├── upload.ts        # Image upload with multer (JPEG compression 0.75)
│   ├── payments.ts      # Payment requests, processing
│   ├── property-chat.ts # Per-property chat between buyer/seller
│   ├── ai-chat.ts       # OpenAI-powered property assistant
│   ├── support.ts       # Support ticket system
│   ├── settings.ts      # Global settings
│   └── events.ts        # Event/calendar management
├── middleware/           # Auth middleware
├── server.ts            # Main entry point (dual: Vercel serverless + PM2)
└── migrate.ts           # Database migration runner

Database schema - 14 tables for real estate platform: | Table | Purpose | |-------|---------| | users | Multi-role (user/admin/superadmin) with sub_roles | | properties | 30+ columns - bilingual (ar/en), status workflow (pending→approved→sold), coordinates, amenities | | property_images | Primary flag, ordering, FK cascade | | property_chat_messages | Per-property messaging with admin visibility | | saved_properties | User favorites (unique constraint on user+property) | | contact_messages | Public contact form submissions | | notifications | Directed notifications with JSON metadata, deep-link support | | payment_requests | Screenshot upload, status workflow (pending/approved/rejected) | | otp_codes | Email-based OTP with attempt tracking, lockout, expiry | | support_tickets / support_messages | Customer support system | | admin_emails | Admin whitelist for authentication |

Key Features (from implementation summary)¶

• Featured properties: Toggle switch in admin panel, PATCH /admin/properties/:id/set-featured, immediately visible on homepage
• Contact form notifications: Auto-create notification with contact_message type, deep-link to /admin?tab=contact&msgId={id}
• Image upload: JPEG compression at quality 0.75 via client-side imageUtils.ts, stored in /uploads/
• Super admin dashboard: Edit all property fields (bilingual title/description, price, area, phone, contact_phone), instant DB persistence
• AI chat: OpenAI integration for answering property inquiries
• Property chat: Per-listing messaging between buyer, seller, admin
• Payment requests: Screenshot upload, processing workflow

Code Quality Indicators¶

• Dual deployment: Same codebase runs on PM2 (production VPS) AND Vercel serverless
• Production process manager: PM2 for daemonized Node processes with auto-restart
• Cron maintenance: Vercel cron removes expired OTP codes daily
• Build: pnpm with vite vite 6 pin override; TypeScript 6 (bleeding edge)
• Arabic bilingual: Full Arabic/English property support (title_ar, description_ar)
• Static file serving: Uploads with immutable cache headers (1 year)
• SPA fallback: Express serves index.html for all non-API routes

Why It Matters¶

Full real estate platform with production deployment - bilingual (Arabic/English), image management, OTP auth, notification system, property chat, AI integration, and super admin dashboard. The dual deployment (PM2 VPS + Vercel serverless) shows understanding of production deployment patterns. The 14-table schema with proper foreign keys, cascades, and unique constraints demonstrates solid database design. Feature set is comprehensive enough to be a real product, not a demo.

Cross-Project Patterns¶

Security Engineering (Consistent Theme)¶

Every project has a security-first approach: - SMail: Zero Trust, E2EE, PFS, tamper-evident audit logs - FerroWA: Encrypted config-at-rest, Argon2id key derivation, HMAC integrity, rate limiting - Online POS: JWT auth, bcrypt, role-based access - Great Web 12: OTP auth, JWT, role hierarchy (user/admin/superadmin)

Deployment Diversity¶

Database Design Range¶

• SQLite for embedded/single-server (SMail dev)
• PostgreSQL for relational integrity (SMail prod)
• Neon serverless for Vercel-deployed APIs (Online POS)
• MySQL for traditional LAMP-style hosting (Great Web 12)

Language Versatility¶

• Python 3.13: SMail backend (FastAPI)
• Rust (2021 ed): FerroWA desktop (Tauri 2)
• JavaScript (ESM): Online POS SPA, Great Web 12 (React+Express)
• TypeScript 6: Great Web 12 frontend
• Dart: SMail mobile client (Flutter)