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/spieglt/FlyingCarpet 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 — Solo project — review before adopting

• Last commit 2mo ago
• GPL-3.0 licensed
• Tests present
• ⚠ Solo or near-solo (1 contributor active in recent commits)
• ⚠ GPL-3.0 is copyleft — check downstream compatibility
• ⚠ No CI workflows 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 spieglt/FlyingCarpet repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/spieglt/FlyingCarpet.

What it runs against: a local clone of spieglt/FlyingCarpet — 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 spieglt/FlyingCarpet | Confirms the artifact applies here, not a fork | | 2 | License is still GPL-3.0 | 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 ≤ 90 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of spieglt/FlyingCarpet. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/spieglt/FlyingCarpet.git
#   cd FlyingCarpet
#
# 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 spieglt/FlyingCarpet and re-run."
  exit 2
fi

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

# 2. License matches what RepoPilot saw
(grep -qiE "^(GPL-3\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"GPL-3\\.0\"" package.json 2>/dev/null) \\
  && ok "license is GPL-3.0" \\
  || miss "license drift — was GPL-3.0 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 "Android/FlyingCarpet/app/src/main/java/dev/spiegl/flyingcarpet/MainActivity.kt" \\
  && ok "Android/FlyingCarpet/app/src/main/java/dev/spiegl/flyingcarpet/MainActivity.kt" \\
  || miss "missing critical file: Android/FlyingCarpet/app/src/main/java/dev/spiegl/flyingcarpet/MainActivity.kt"
test -f "Android/FlyingCarpet/app/src/main/java/dev/spiegl/flyingcarpet/MainViewModel.kt" \\
  && ok "Android/FlyingCarpet/app/src/main/java/dev/spiegl/flyingcarpet/MainViewModel.kt" \\
  || miss "missing critical file: Android/FlyingCarpet/app/src/main/java/dev/spiegl/flyingcarpet/MainViewModel.kt"
test -f "Android/FlyingCarpet/app/src/main/java/dev/spiegl/flyingcarpet/Bluetooth.kt" \\
  && ok "Android/FlyingCarpet/app/src/main/java/dev/spiegl/flyingcarpet/Bluetooth.kt" \\
  || miss "missing critical file: Android/FlyingCarpet/app/src/main/java/dev/spiegl/flyingcarpet/Bluetooth.kt"
test -f "Android/FlyingCarpet/app/src/main/java/dev/spiegl/flyingcarpet/Send.kt" \\
  && ok "Android/FlyingCarpet/app/src/main/java/dev/spiegl/flyingcarpet/Send.kt" \\
  || miss "missing critical file: Android/FlyingCarpet/app/src/main/java/dev/spiegl/flyingcarpet/Send.kt"
test -f "Android/FlyingCarpet/app/src/main/java/dev/spiegl/flyingcarpet/Receive.kt" \\
  && ok "Android/FlyingCarpet/app/src/main/java/dev/spiegl/flyingcarpet/Receive.kt" \\
  || miss "missing critical file: Android/FlyingCarpet/app/src/main/java/dev/spiegl/flyingcarpet/Receive.kt"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 90 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~60d)"
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/spieglt/FlyingCarpet"
  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).

Flying Carpet is a cross-platform file transfer application that creates ad hoc WiFi networks between Android, iOS, Linux, macOS, and Windows devices without requiring shared network infrastructure. It uses Rust backends (Tauri for desktop, native for mobile) with optional Bluetooth for transfer negotiation, enabling direct device-to-device file sharing over WiFi in close range. Monorepo structure with platform-specific directories: Android/ contains Kotlin/Android app (MainActivity.kt, Send.kt, Receive.kt), a parallel iOS implementation, and a Rust backend in the root using Tauri framework (src-tauri in typical Tauri layout) that powers Linux/macOS/Windows clients. State and UI logic are compartmentalized per platform (MainViewModel.kt for Android state management).

Users who need to transfer files between different devices and operating systems without internet access, flash drives, or network setup—particularly people moving files larger than 2GB across different filesystems, and contributors building cross-platform file transfer tools.

The project is actively maintained and production-ready; it's at version 9.0.8 with recent APK releases, published on Google Play and the App Store, and well-structured with proper build configurations (compileSdk 34, targetSdk 35). The codebase shows active development with Bluetooth integration in v9 and proper CI/release infrastructure, though the single maintainer (spieglt) and modest test coverage suggest it's a smaller, focused project rather than enterprise-scale.

The single-maintainer architecture (spieglt appears to be the sole developer) creates maintenance risk; the moderate dependency count (~12 direct Android deps, Tauri's full stack) is manageable but introduces transitive risk. iOS restrictions mentioned in the README (Apple devices only transfer to Android/Linux/Windows) suggest platform-specific limitations that could break workflows. No visible test suite in Android code (ExampleInstrumentedTest.kt is a template) and lack of CI pipeline visibility increase regression risk for multi-platform changes.

Version 9 (current) added Bluetooth for transfer negotiation as mentioned in README; the last released version is 9.0.8 with versionCode 21 in build.gradle. Development appears focused on stability and cross-platform parity given the multi-OS coordination required.

Clone the repo: git clone https://github.com/spieglt/FlyingCarpet.git && cd FlyingCarpet. Install Rust: curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh. Install Tauri CLI: cargo install tauri-cli. For Linux, install system deps (libsoup2.4, libwebkit2gtk, etc. per README). Run desktop dev: cargo tauri dev. For Android, open Android/FlyingCarpet in Android Studio and build with ./gradlew build.

Daily commands: Desktop dev: cargo tauri dev (requires Rust + Tauri CLI + platform-specific libs). Desktop release build: cargo tauri build. Android dev: Open Android/FlyingCarpet in Android Studio, sync Gradle, run on emulator/device. Android release: ./gradlew assembleRelease in Android/FlyingCarpet directory. iOS: Requires Xcode and Apple developer account (build process not in provided files).

• Android/FlyingCarpet/app/src/main/java/dev/spiegl/flyingcarpet/MainActivity.kt — Main Android entry point and UI controller; understand this to grasp the Android app's lifecycle and core interaction model.
• Android/FlyingCarpet/app/src/main/java/dev/spiegl/flyingcarpet/MainViewModel.kt — State management for Android UI; essential for understanding how data flows between send/receive operations and the UI.
• Android/FlyingCarpet/app/src/main/java/dev/spiegl/flyingcarpet/Bluetooth.kt — Bluetooth negotiation and discovery protocol; critical for version 9's new feature of Bluetooth-based transfer setup.
• Android/FlyingCarpet/app/src/main/java/dev/spiegl/flyingcarpet/Send.kt — File sending logic and WiFi transmission; core data transfer implementation for outgoing transfers.
• Android/FlyingCarpet/app/src/main/java/dev/spiegl/flyingcarpet/Receive.kt — File receiving logic and WiFi listener; core data transfer implementation for incoming transfers.
• Flying Carpet/src-tauri/Cargo.toml — Rust backend dependencies for desktop (Linux, macOS, Windows); defines all core networking and system libraries used across platforms.
• Android/FlyingCarpet/app/build.gradle — Android build configuration and version management; essential for building and understanding minSdk/targetSdk constraints.

Add a new Bluetooth feature or message type

1. Define new Bluetooth message structure in protocol constants section (Android/FlyingCarpet/app/src/main/java/dev/spiegl/flyingcarpet/Bluetooth.kt)
2. Add parsing/handling logic in the BLE callback or message handler (Android/FlyingCarpet/app/src/main/java/dev/spiegl/flyingcarpet/Bluetooth.kt)
3. Expose new state or callback through MainViewModel if UI needs to react (Android/FlyingCarpet/app/src/main/java/dev/spiegl/flyingcarpet/MainViewModel.kt)
4. Update MainActivity to bind new ViewModel state to UI elements (Android/FlyingCarpet/app/src/main/java/dev/spiegl/flyingcarpet/MainActivity.kt)

Add a new UI dialog or alert

1. Define new composable or Dialog in Alert.kt following existing patterns (Android/FlyingCarpet/app/src/main/java/dev/spiegl/flyingcarpet/Alert.kt)
2. Add trigger state to MainViewModel with appropriate LiveData or StateFlow (Android/FlyingCarpet/app/src/main/java/dev/spiegl/flyingcarpet/MainViewModel.kt)
3. Call the new alert from MainActivity.kt or other component (Android/FlyingCarpet/app/src/main/java/dev/spiegl/flyingcarpet/MainActivity.kt)

Modify file transfer protocol or add new transfer mode

1. Update Send.kt with new protocol message format or transmission logic (Android/FlyingCarpet/app/src/main/java/dev/spiegl/flyingcarpet/Send.kt)
2. Update Receive.kt to handle and parse the new format on receive side (Android/FlyingCarpet/app/src/main/java/dev/spiegl/flyingcarpet/Receive.kt)
3. Expose progress or status through MainViewModel for UI feedback (Android/FlyingCarpet/app/src/main/java/dev/spiegl/flyingcarpet/MainViewModel.kt)
4. Mirror changes in desktop backend Rust code (Cargo.toml dependencies or src changes) (Flying Carpet/src-tauri/Cargo.toml)

Add new Android permissions or system features

1. Declare new permission in AndroidManifest.xml (Android/FlyingCarpet/app/src/main/AndroidManifest.xml)
2. Request runtime permission in MainActivity or appropriate Activity/Fragment (Android/FlyingCarpet/app/src/main/java/dev/spiegl/flyingcarpet/MainActivity.kt)
3. Add permission checking utility method in Utilities.kt if not already present (Android/FlyingCarpet/app/src/main/java/dev/spiegl/flyingcarpet/Utilities.kt)

• Kotlin + Android Framework — Cross-API-level support (minSdk 29 to targetSdk 35); native Bluetooth and WiFi APIs; Jetpack MVVM architecture for robust state management.
• Bluetooth Low Energy (BLE) — Version 9 feature enabling ad hoc device discovery without requiring pre-existing network infrastructure; lower power than classic Bluetooth.
• Ad Hoc WiFi / WiFi Direct — Core to product vision: P2P file transfer without requiring router or cellular network; both devices must support this WiFi mode.
• Rust + Tauri — Desktop (Linux, macOS, Windows) implementation; Rust provides safe cross-platform networking and system APIs; Tauri bundles lightweight Chromium UI.
• Swift for iOS — Required for iOS App Store distribution; native APIs for Bluetooth and WiFi peer connection on Apple platforms.

• No centralized server or authentication

  • Why: Aligns with product vision: direct P2P, no infrastructure required, privacy-first
  • Consequence: Limited to local network range (Bluetooth ~10m, WiFi ~100m); no roaming between networks; each transfer is isolated/stateless.

• Optional Bluetooth for negotiation only

  • Why: Reduces complexity; Bluetooth handles discovery & handshake; actual files transfer over faster WiFi
  • Consequence: Users must manually input IP if Bluetooth unavailable; adds two-step setup burden but simplifies protocol.

Android minSdk is 29 (Android 10+)—older devices cannot run the app. Bluetooth negotiation in v9 requires both devices to support Bluetooth and have it enabled; no fallback to pure WiFi negotiation is visible in provided code. Apple restriction mentioned in README: iOS can only transfer to Android/Linux/Windows, not to other iOS devices—this is a hard OS limitation, not a bug. WiFi hotspot permissions: Android requires users to manually enable WiFi Direct or create an ad hoc network; the app doesn't do this automatically. ProGuard disabled in release build (minifyEnabled false)—unusual for production; may indicate obfuscation issues or incomplete dependency inlining. QR code library (ZXing) requires camera permissions and device camera hardware; no fallback for devices without cameras.

• Ad Hoc WiFi Networks (WiFi Direct) — Flying Carpet's core networking capability—two devices directly connect over WiFi without an access point. Understanding WiFi Direct's peer discovery, group formation, and IP assignment is essential to modifying network behavior.
• Bluetooth Low Energy (BLE) Pairing for Negotiation — Version 9 added Bluetooth as a side-channel for transfer negotiation (Bluetooth.kt); BLE allows devices to exchange metadata and initiate WiFi transfer without manual user input, reducing friction.
• QR Code Transfer Protocol — Android and desktop clients use ZXing (com.google.zxing) to encode device addresses/credentials in QR codes for easy scanning; understanding the QR payload format is needed to modify or debug peer discovery.
• File I/O Abstraction Across Filesystems — Flying Carpet transfers files across Android (MediaStore/SAF), Linux (ext4), macOS (APFS), Windows (NTFS), and iOS (sandboxed app storage)—each with different permission models and file APIs. This abstraction is critical for correctness.
• Tauri IPC (Inter-Process Communication) — Desktop version uses Tauri's invoke/listen system to communicate between Rust backend and JavaScript frontend (src-tauri). Understanding command serialization and error propagation is essential for adding new desktop features.
• Kotlin ViewModel & Jetpack Architecture — MainViewModel.kt uses MVVM to manage UI state across configuration changes (screen rotation, backgrounding). Understanding ViewModel scope and LiveData/StateFlow is required to add or modify Android state management.
• Cross-Platform Build Orchestration (Tauri + Cargo) — The project builds Rust, JavaScript, Kotlin, and Swift from a single Cargo.toml root using Tauri's build system. Understanding Cargo workspace dependencies and Tauri's build hooks is needed to refactor or optimize build times.

• localsend/localsend — Direct competitor solving the same cross-platform local file transfer problem with a focus on simplicity and no ads
• snapdrop/snapdrop — Browser-based alternative for local file transfer over WebRTC; no app installation required but less reliable over spotty WiFi
• tauri-apps/tauri — Parent framework used for Flying Carpet's desktop (Linux/macOS/Windows) implementation; understanding Tauri's event system and IPC is essential for desktop changes
• google/material-design-lite — Design system underlying Flying Carpet's Android UI (Material Design 3 via androidx.appcompat); useful reference for consistent UI components
• Kotlin/coroutines — Async runtime used in Android code (kotlinx-coroutines-android:1.6.4); understanding coroutine scopes and Job cancellation is critical for responsive UI

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 instrumented tests for Bluetooth negotiation flow in Android

Version 9 added Bluetooth for transfer negotiation (mentioned in README), but Android/FlyingCarpet/app/src/androidTest only contains an example test stub (ExampleInstrumentedTest.kt). The Bluetooth.kt module lacks integration tests covering device discovery, pairing, and handshake failures. This is critical for cross-device reliability.

• [ ] Expand Android/FlyingCarpet/app/src/androidTest/java/dev/spiegl/flyingcarpet/ with BluetoothTest.kt
• [ ] Add test cases for Bluetooth.kt methods: device discovery, connection establishment, error handling
• [ ] Test integration between Bluetooth.kt and Send.kt/Receive.kt negotiation flow
• [ ] Verify tests run with androidTestImplementation dependencies already in build.gradle

Add Android unit tests for file transfer state management in MainViewModel.kt

MainViewModel.kt manages the app's transfer state and likely coordinates Send.kt and Receive.kt, but no unit tests exist in Android/FlyingCarpet/app/src/test/. The testImplementation JUnit 4.13.2 dependency is available but unused. Unit tests here would catch regressions in state transitions and error handling.

• [ ] Create Android/FlyingCarpet/app/src/test/java/dev/spiegl/flyingcarpet/MainViewModelTest.kt
• [ ] Test state transitions: idle → sending/receiving → complete/error
• [ ] Test integration points with Send.kt, Receive.kt, and Bluetooth.kt
• [ ] Mock coroutines using kotlinx-coroutines-android:1.6.4 test utilities

Add GitHub Actions CI workflow for Android APK build and lint checks

The .github/FUNDING.yml exists but there's no CI workflow to validate Android builds on every PR. With compileSdk 34, Kotlin 1.9.20, and build.gradle already configured, a workflow would catch dependency conflicts, compilation errors, and lint issues before merge. Critical for a cross-platform file transfer tool.

• [ ] Create .github/workflows/android-build.yml
• [ ] Add steps: checkout, setup-java (JDK 17+), run ./gradlew build, run ./gradlew lint
• [ ] Configure to run on push to main and on pull requests
• [ ] Archive APK artifacts (android_FlyingCarpet_*.apk) for releases mentioned in README

• Add unit tests for Send.kt and Receive.kt file transfer logic—ExampleInstrumentedTest.kt is empty, leaving the core transfer logic untested across Android versions
• Implement CI/CD pipeline (.github/workflows/*.yml missing)—automate Android build, Kotlin lint, and APK generation on push to catch regressions early
• Add detailed error messages in Alert.kt for specific failure cases (Bluetooth pairing failed, WiFi unavailable, file permissions denied)—currently errors appear generic based on file names

The FlyingCarpet Android application has a generally reasonable security posture with appropriate dependency selections and some defensive configurations. However, there are notable concerns: (1) minification is disabled in release builds, reducing code protection against reverse engineering; (2) Kotlin reflect dependency may be outdated; (3) network and file security implementations need verification in the actual code (not fully visible); (4) Bluetooth transfer security implementation requires review. The application handles sensitive file transfer operations, so additional hardening around input validation, secure file handling, and encryption is recommended. No hardcoded secrets or SQL injection risks are evident from the provided file structure.

• Medium · Minification Disabled in Release Build — Android/FlyingCarpet/app/build.gradle (buildTypes.release). The build.gradle configuration shows 'minifyEnabled false' for release builds. This disables code obfuscation and shrinking, making the APK larger and easier to reverse engineer. The ProGuard rules file is defined but not actively used. Fix: Set 'minifyEnabled true' in release builds to enable code obfuscation and dead code removal. Review and customize proguard-rules.pro to prevent obfuscation of necessary public APIs while protecting sensitive code.
• Medium · Outdated Kotlin Reflect Dependency — Android/FlyingCarpet/app/build.gradle (dependencies). The dependency 'org.jetbrains.kotlin:kotlin-reflect:1.9.20' is pinned to a specific older version. Kotlin 1.9.20 is behind current stable releases and may contain known vulnerabilities. The build uses Kotlin but the reflect library version may not be synchronized with the actual Kotlin compiler version. Fix: Update kotlin-reflect to match the latest stable Kotlin version used in the project. Remove hard version pins or use version ranges to allow patch updates automatically.
• Low · Missing Network Security Configuration — Android/FlyingCarpet/app/src/main/AndroidManifest.xml. The AndroidManifest.xml file structure is present but not visible in the provided context. For a file transfer application using ad-hoc WiFi and Bluetooth, there should be explicit network security policies defined to prevent MITM attacks on unencrypted connections. Fix: Implement a network_security_config.xml file that enforces certificate pinning, disables cleartext traffic for sensitive operations, and configures proper domain-specific security policies.
• Low · Dependency Metadata Disclosure Prevention — Android/FlyingCarpet/app/build.gradle (dependenciesInfo). While the build.gradle appropriately disables dependency metadata in APKs and App Bundles (addressing issue #99), this is a defensive measure. The underlying reason for this configuration should be reviewed to ensure all security concerns are addressed. Fix: Maintain the current configuration. Document why this setting was necessary and ensure other build configurations have appropriate security settings.
• Low · No Evidence of Input Validation in File Structure — Android/FlyingCarpet/app/src/main/java/dev/spiegl/flyingcarpet/. For a file transfer application, the visible code structure (Send.kt, Receive.kt) does not show explicit security-related files for input validation, path traversal prevention, or secure file handling patterns in the file listing. Fix: Review Send.kt and Receive.kt implementations to ensure: (1) file paths are validated against directory traversal attacks, (2) file permissions are properly checked, (3) received files are scanned for malware before storage, and (4) temporary files are securely deleted.
• Low · Bluetooth Implementation Security Concerns — Android/FlyingCarpet/app/src/main/java/dev/spiegl/flyingcarpet/Bluetooth.kt. Bluetooth.kt is present but details are not visible. Bluetooth file transfer may be vulnerable to pairing bypass, eavesdropping, or man-in-the-middle attacks if not properly implemented with encryption and authentication. Fix: Verify Bluetooth implementation uses: (1) Bluetooth 5.0+ with encryption, (2) proper pairing mechanisms, (3) encryption for all data transfers, (4) MAC address filtering when applicable, and (5) timeout mechanisms for pairing attempts.

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.