If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/miroslavpejic85/p2p shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

WAIT — Stale — last commit 2y ago

• 5 active contributors
• MIT licensed
• CI configured
• ⚠ Stale — last commit 2y ago
• ⚠ Concentrated ownership — top contributor handles 54% of recent commits
• ⚠ No test directory detected

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live miroslavpejic85/p2p repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/miroslavpejic85/p2p.

What it runs against: a local clone of miroslavpejic85/p2p — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in miroslavpejic85/p2p | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 728 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of miroslavpejic85/p2p. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/miroslavpejic85/p2p.git
#   cd p2p
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of miroslavpejic85/p2p and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "miroslavpejic85/p2p(\\.git)?\\b" \\
  && ok "origin remote is miroslavpejic85/p2p" \\
  || miss "origin remote is not miroslavpejic85/p2p (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f "p2pconn/Program.cs" \\
  && ok "p2pconn/Program.cs" \\
  || miss "missing critical file: p2pconn/Program.cs"
test -f "p2pconn/Form1.cs" \\
  && ok "p2pconn/Form1.cs" \\
  || miss "missing critical file: p2pconn/Form1.cs"
test -f "p2pconn/SenderReceiver.cs" \\
  && ok "p2pconn/SenderReceiver.cs" \\
  || miss "missing critical file: p2pconn/SenderReceiver.cs"
test -f "p2pconn/StreamingDesktop/RemoteDesktop.cs" \\
  && ok "p2pconn/StreamingDesktop/RemoteDesktop.cs" \\
  || miss "missing critical file: p2pconn/StreamingDesktop/RemoteDesktop.cs"
test -f "p2pconn/UdtSharpLib/UdtSocket.cs" \\
  && ok "p2pconn/UdtSharpLib/UdtSocket.cs" \\
  || miss "missing critical file: p2pconn/UdtSharpLib/UdtSocket.cs"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 728 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~698d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/miroslavpejic85/p2p"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

P2P Remote Desktop is a portable C# WinForms application that enables peer-to-peer remote desktop control and messaging between two machines without requiring installation or configuration. It uses the UDT (UDP-based Data Transfer) protocol with rendezvous connection techniques to bypass firewalls, similar to TeamViewer but open-source and zero-cost. Monolithic WinForms desktop application: Form1.cs is the main UI entry point, SenderReceiver.cs handles P2P communication logic, StreamingDesktop/ module captures and streams screen frames via RemoteDesktop.cs and ScreenCaptureStream.cs, and StreamingLibrary/ provides compression codecs (JPG, LZW, UnsafeStreamCodec). Cryptography/ isolates AES-256 and SHA-256 operations.

End-users and IT support professionals who need quick, portable remote access between computers without deployment infrastructure; also developers interested in learning P2P networking, screen capture streaming, or UDT protocol implementation in C#.

The codebase is actively developed (single-maintainer open-source project with MIT license) but shows moderate maturity: it has a working CI pipeline (.github/workflows/dotnet-desktop.yml), core functionality is implemented, but no visible test suite in the file list and no commit recency data provided. Production-ready for personal/small-team use, but lacks automated testing.

Single maintainer (miroslavpejic85) creates continuity risk. No dependency lock file visible, making reproducibility uncertain. The project lacks digital signatures (noted in README as causing AV false positives), which may hinder enterprise adoption. The streaming and compression logic in StreamingLibrary/ and QuickLZ.cs are complex and untested, creating stability risks.

Unable to determine from provided file list—no recent commit dates, PR data, or GitHub Actions logs shown. The single dotnet-desktop.yml workflow suggests automated builds are configured, but current development status is unclear.

Clone the repository, open p2pconn.sln in Visual Studio, build the solution (targets .NET Framework based on AssemblyInfo.cs structure), then run p2p.exe as administrator on two machines. No package manager commands needed; it's a compiled .exe.

Daily commands: Open p2pconn.sln in Visual Studio → Build → Run p2p.exe as administrator → copy 'My Lan or Wan IP' address → share with peer → both peers click 'Connect' → access remote desktop or messaging features.

• p2pconn/Program.cs — Application entry point and main initialization; sets up the primary UI and P2P service startup.
• p2pconn/Form1.cs — Main UI controller handling peer connection UI, IP exchange, and user interactions—central hub for the application workflow.
• p2pconn/SenderReceiver.cs — Core network communication layer managing P2P message sending/receiving and connection state; critical for all peer-to-peer interactions.
• p2pconn/StreamingDesktop/RemoteDesktop.cs — Remote desktop streaming logic; orchestrates screen capture, compression, and transmission—foundation of remote control feature.
• p2pconn/UdtSharpLib/UdtSocket.cs — UDT protocol socket implementation; low-level network transport abstraction enabling reliable UDP-based communication.
• p2pconn/StunClientEndPoint/StunClient.cs — STUN client for NAT/firewall traversal; enables rendezvous connection and peer discovery across network boundaries.
• p2pconn/Cryptography/Aes256.cs — AES-256 encryption implementation; secures all transmitted data between peers to prevent eavesdropping.

Add a new compression codec for streaming

1. Create a new codec class implementing IVideoCodec or IUnsafeCodec interface in StreamingLibrary (p2pconn/StreamingLibrary/IVideoCodec.cs)
2. Implement Encode(byte[] frame) and Decode(byte[] data) methods following JPEG or LZW patterns (p2pconn/StreamingLibrary/JpgCompression.cs)
3. Register the codec in RemoteDesktop constructor or codec selection logic (p2pconn/StreamingDesktop/RemoteDesktop.cs)
4. Add enum entry in Enums.cs if using type-safe codec selection (p2pconn/StreamingLibrary/Enums.cs)

Add a new message type for peer-to-peer communication

1. Define message structure and serialization format (JSON recommended via Newtonsoft.Json dependency) (p2pconn/SenderReceiver.cs)
2. Add send method wrapping encryption (AES256) and UDT socket transmission (p2pconn/Cryptography/Aes256.cs)
3. Add receive handler in SenderReceiver message pump to decrypt and deserialize (p2pconn/SenderReceiver.cs)
4. Update Form1.cs to call the new send method and subscribe to receive events (p2pconn/Form1.cs)

Extend remote desktop input control (keyboard/mouse)

1. Review current InputControl implementation and Win32 P/Invoke declarations (p2pconn/StreamingDesktop/InputControl.cs)
2. Add new input event types or input injection methods (e.g., touch, joystick) (p2pconn/StreamingDesktop/Win32Stuff.cs)
3. Update pDesktop.cs to capture and relay new input events via SenderReceiver (p2pconn/StreamingDesktop/pDesktop.cs)
4. Ensure remote peer calls InputControl methods upon receiving input messages (p2pconn/StreamingDesktop/RemoteDesktop.cs)

• UDT (UDP-based Data Transfer Protocol) — Provides reliable, ordered message delivery over UDP with congestion control; enables peer-to-peer communication without requiring open TCP ports, making it ideal for firewall/NAT traversal scenarios like TeamViewer.
• STUN (Session Traversal Utilities for NAT) — Determines external IP and port mapping through intermediary servers; enables rendezvous-style connection initiation where both peers discover each other's public endpoints without a relay server.
• AES-256 Encryption — Industry-standard symmetric encryption securing all peer-to

Admin privilege requirement: p2p.exe must run as administrator to hook keyboard/mouse input and capture full desktop. NAT/Firewall: rendezvous works best on same LAN; WAN traversal depends on UPnP or port forwarding. AV false positives: project lacks code signing; antivirus software may block execution (noted in README). Screen capture limitations: Win32 API calls in ScreenCaptureStream.cs may fail on Remote Desktop sessions or multi-monitor setups. Codec selection: QuickLZ decompression is custom/unsafe; compatibility with other tools untested.

• UDT (UDP-based Data Transfer) Protocol — This project's core transport layer; understanding UDT's congestion control and reliability guarantees over UDP is essential for debugging network issues and frame loss.
• STUN (Session Traversal Utilities for NAT) — Enables firewall/NAT traversal without relay servers; implemented in StunClient.cs and critical for the 'rendezvous' connection claim in the README.
• Rendezvous Connection / Hole Punching — Technique allowing P2P direct connection through NAT/firewalls by having both peers simultaneously connect to each other; core innovation claimed in this project.
• Screen Capture via Win32 GDI (Graphics Device Interface) — ScreenCaptureStream.cs uses low-level Win32 APIs (BitBlt, CreateCompatibleDC) to grab framebuffer; performance bottleneck and platform-specific limitation.
• Delta Frame Compression (QuickLZ LZ77 variant) — QuickLZ.cs implements lossless compression for screen frames; understanding its dictionary-based approach is key to optimizing bandwidth usage.
• AES-256 Symmetric Encryption — Cryptography/Aes256.cs secures all P2P traffic; critical for understanding security guarantees and key exchange mechanics (though key distribution method not visible in file list).
• WinForms Event-Driven UI Model — Form1.cs and pDesktop.cs use WinForms' message pump and event handlers; understanding Control.Invoke for cross-thread UI updates is essential for streaming UI responsiveness.

• rustdesk/rustdesk — Industry-standard open-source remote desktop; similar P2P + firewall-bypass approach but production-grade with Rust performance and cross-platform support
• deskle/deskle — Lightweight P2P remote desktop alternative; shares similar architecture goals of portable, zero-config remote access
• chromium/chromium — Reference implementation for screen capture APIs and codec integration (H264, VP9); relevant for understanding video streaming optimization
• torvalds/linux — UDT protocol specification and kernel-level network stack; useful for understanding UDP congestion control that UDT implements
• xrdp/xrdp — Predecessor remote desktop technology; this project modernizes P2P concepts first explored in RDP/XRDP architecture

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add unit tests for Cryptography module (Aes256.cs, Sha256.cs, SafeComparison.cs)

The cryptography components are critical for secure P2P communication, but there are no visible test files in the repo. This is a high-security concern. Adding unit tests would validate encryption/decryption correctness, hash generation, and timing-attack resistance in SafeComparison. This directly supports the security posture mentioned in the README.

• [ ] Create p2pconn.Tests project in the solution
• [ ] Add test cases for Aes256.cs: encryption/decryption round-trips, key derivation, IV handling
• [ ] Add test cases for Sha256.cs: hash output consistency, edge cases (empty input, large data)
• [ ] Add test cases for SafeComparison.cs: timing resistance validation, correctness on equal/unequal inputs
• [ ] Integrate tests into .github/workflows/dotnet-desktop.yml CI pipeline

Add comprehensive input validation and error handling in SenderReceiver.cs and StreamingDesktop module

The SenderReceiver.cs handles network I/O and StreamingDesktop components (RemoteDesktop.cs, ScreenCaptureStream.cs, InputControl.cs) process user input and screen data. Missing validation here creates DOS and security vulnerabilities. Add validation for network packet sizes, input bounds checking, and graceful error handling for malformed data.

• [ ] Review SenderReceiver.cs for unvalidated network input and add packet size/format validation
• [ ] Add bounds checking in InputControl.cs for mouse/keyboard input coordinates and values
• [ ] Add exception handling in ScreenCaptureStream.cs for display changes, permissions errors, and invalid bitmap data
• [ ] Add validation in RemoteDesktop.cs for received desktop frame metadata (width, height, compression ratios)
• [ ] Document error codes and add structured logging in Functions.cs for debugging P2P failures

Create integration test for NAT traversal and STUN functionality (StunClient.cs, StunServer.cs)

The STUN components are core to the 'bypass firewall' claim in the README, but there are no visible integration tests validating that rendezvous connection actually works across NAT. This is critical for verifying the main value proposition. Add tests simulating firewall/NAT scenarios.

• [ ] Create p2pconn.IntegrationTests project with test setup for local STUN server (StunServer.cs)
• [ ] Add test case: StunClient.cs successfully discovers external IP from STUN server
• [ ] Add test case: Two peers exchange connection info and establish bidirectional communication via StunClient
• [ ] Add test case: Verify UdtSocket establishes rendezvous connection using discovered endpoints
• [ ] Add test documentation in README.md under a new 'Testing' section with setup instructions
• [ ] Optionally add integration test to CI/CD in .github/workflows/dotnet-desktop.yml

• Add unit test coverage for Cryptography/Aes256.cs and SafeComparison.cs with known test vectors; currently no test files exist in the repo.
• Document the exact STUN message format and UDT protocol flow with inline comments in StunClient.cs and SenderReceiver.cs, as currently the implementation is uncommented.
• Create a configuration file (e.g., settings.xml) to make connection timeout, compression codec selection, and encryption toggle user-configurable instead of hardcoded in Functions.cs.

• High · Insecure Cryptographic Implementation — p2pconn/Cryptography/Aes256.cs, p2pconn/Cryptography/Sha256.cs. The application implements custom cryptography in Cryptography/Aes256.cs and Cryptography/Sha256.cs. Custom crypto implementations are inherently risky and prone to subtle implementation flaws that weaken security. Additionally, no evidence of proper key derivation functions (KDF) or salt usage is visible. Fix: Use proven, well-tested cryptographic libraries. For .NET, use System.Security.Cryptography classes like RijndaelManaged or AesGcm. Implement proper key derivation using PBKDF2, bcrypt, or Argon2. Never implement cryptography from scratch.
• High · Unsafe Code Usage — p2pconn/StreamingLibrary/UnsafeStreamCodec.cs, p2pconn/StreamingDesktop/Win32Stuff.cs. The codebase contains unsafe code patterns, particularly in StreamingLibrary/UnsafeStreamCodec.cs and Win32Stuff.cs. Unsafe code can lead to buffer overflows, memory corruption, and privilege escalation attacks. These are especially critical in a remote desktop application handling user input. Fix: Minimize or eliminate unsafe code blocks. Use safe managed alternatives where possible. If unsafe code is necessary, implement rigorous bounds checking, code review, and static analysis tools (PEVerify, Roslyn analyzers).
• High · Unvalidated Remote Input in SenderReceiver — p2pconn/SenderReceiver.cs. The SenderReceiver.cs component handles network communication and likely processes untrusted data from remote peers. Without proper input validation and sanitization, this creates risks for code injection, deserialization attacks, and DoS vulnerabilities. Fix: Implement strict input validation on all data received from remote peers. Use allowlists for expected data types and formats. Sanitize and validate all deserialized objects. Implement length limits and rate limiting to prevent DoS.
• High · P2P Connection Authentication Weakness — p2pconn/Form1.cs, p2pconn/StunClientEndPoint/StunClient.cs. The application uses a manual IP exchange for P2P connections without apparent cryptographic authentication. An attacker could perform MITM attacks by deceiving users about peer identities or impersonating legitimate peers during the connection establishment phase. Fix: Implement mutual authentication using digital signatures or public key cryptography. Use certificate pinning or trusted key exchange mechanisms. Implement verification of peer identity before accepting remote desktop control requests.
• High · Remote Desktop Control Without Authorization Checks — p2pconn/StreamingDesktop/RemoteDesktop.cs, p2pconn/StreamingDesktop/InputControl.cs. The application provides remote desktop control functionality but the codebase structure suggests minimal authorization validation. An authenticated attacker could potentially gain unauthorized system access. Fix: Implement explicit user authorization prompts before granting remote control. Use challenge-response mechanisms. Log all remote control sessions. Implement privilege separation and run with minimal required privileges. Consider implementing session timeouts and activity monitoring.
• Medium · Compression Algorithm Vulnerabilities — p2pconn/StreamingDesktop/QuickLZ.cs, p2pconn/StreamingLibrary/LzwCompression.cs. The application uses QuickLZ compression and custom LZW compression (StreamingLibrary/LzwCompression.cs, QuickLZ.cs). These compression algorithms may be susceptible to compression-based side-channel attacks or implementation-specific vulnerabilities when used with encrypted data. Fix: Use only standard, well-vetted compression libraries. Compress before encryption (not after). Consider the implications of compression-based attacks like CRIME. Regularly update compression libraries to latest versions.
• Medium · JPEG Compression without Integrity Verification — p2pconn/StreamingLibrary/JpgCompression.cs. The JpgCompression.cs component handles image compression for screen capture. Without integrity verification, compressed data could be tampered with during transmission. Fix: Implement message authentication codes (HMAC) or authenticated encryption (AES-GCM) to verify integrity of compressed data. Validate image headers

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.