Technische Artikel
Tiefgreifende Analysen der Peer-to-Peer-Architektur, des Transportsystems und der Kryptographie von PlainApp – direkt aus dem Quellcode.
DLNA Cast: Aufbau eines UPnP-Senders und -Empfängers von Grund auf
Wie PlainApp DLNA/UPnP-AV-Casting auf beiden Seiten implementiert: Scannen und Steuern von Fernsehern per SOAP als Sender sowie Verwandeln des Telefons selbst in einen UPnP-MediaRenderer als Empfänger – mit SSDP-Discovery, DIDL-Lite-Metadaten, Range-Request-basiertem Media-Serving, GENA-Event-Callbacks und einem Sender-IP-Allow/Deny-Vertrauensmodell, alles in reinem Kotlin Multiplatform.
Screen Mirror: Low-Latency-Casting-Architektur
Dieser Artikel behandelt den End-to-End-Entwurf von PlainApps Screen-Mirror-System: Wie Android mit MediaCodec H.264/Opus hardwarekodiert und über WebSocket per benutzerdefiniertem Binärprotokoll überträgt, wie die Webseite per WebCodecs dekodiert und per WebGL2 ohne CPU-Kopie rendert, und wie Verlusterkennung, Orientierungswechsel und Remote-Touch-Steuerung umgesetzt werden.
PlainApp Sicherheit – Tiefenanalyse
Wie PlainApp Ihre Daten im lokalen WLAN schützt — belegt durch den Open-Source-Code.
Wi-Fi Aware-Transport-Design — Neighbor Discovery & Data Paths
Dieser Artikel erklärt, wie PlainApp Wi-Fi Aware (NAN — Neighbor Awareness Networking) als mittlere Ebene seiner Peer-Transport-Fallback-Kette verwendet, zwischen LAN (gleiches Subnetz, HTTPS) und BLE (GATT-RPC als letzter Ausweg). Wi-Fi Aware ermöglicht es zwei PlainApp-Geräten, zu kommunizieren, wenn sie sich in verschiedenen SSIDs, Guest- vs. IoT-VLANs oder ganz ohne Wi-Fi-Infrastruktur befinden — ohne jemals eine IP-Adresse von einem DHCP-Server zu benötigen.
BLE-Transport-Design — Nachrichten & Datei-Downloads
Dieser Artikel erklärt, wie PlainApp Chat-Nachrichten über Bluetooth Low Energy pusht und Dateien herunterlädt, wenn weder LAN noch Wi-Fi Aware verfügbar sind. BLE ist der garantierte Fallback: langsam, aber er funktioniert ohne jegliche IP-Konnektivität. Der Artikel behandelt das Wire-Format, das zweischichtige Chunking-Design, wie gleichzeitiger Verkehr priorisiert wird (und wie nicht), und warum jede Verbindung nach jeder Anfrage abgebaut wird.
Peer- & Channel-Chat-Architektur
Dieser Artikel erklärt, wie PlainApps Offline-First-Chat End-to-End funktioniert: wie eine Nachricht von einem Tap in der UI über den Peer-Transport bis zum anderen Gerät reist, wie Gruppen-Channel-Nachrichten an viele Mitglieder fan-outen, und wie das System resilient bleibt, wenn Netzwerke verschwinden. Pairing (der Vertrauens- und Schlüsselaustausch, der zwei Geräte bootstrapt) ist im separaten Artikel zum Pairing-Ablauf behandelt.
Pairing-Ablauf
Dieser Artikel erklärt, wie zwei PlainApp-Geräte erstmals Vertrauen zueinander aufbauen — wie sie sich gegenseitig entdecken, Schlüssel austauschen und zum gemeinsamen ChaCha20-Transportschlüssel gelangen, mit dem danach jede Chat-Nachricht, jeder Dateitransfer und jeder Presence-Ping verschlüsselt wird. Die Chat- und Channel-Architektur, die diesen Schlüssel verwendet, ist im separaten Artikel zur Chat-Architektur behandelt.