Photon moves whole folders over a local network, folders intact

Photon preserves the directory tree, not just the files

Photon is a cross-platform file and folder transfer application built with Flutter, and the behaviour it puts first is directory fidelity. The project states that it preserves the entire folder structure including subdirectories on the receiver's end. Most transfer tools flatten a picked selection into one download directory, so a project folder arrives as a loose pile of files with the original nesting gone. Photon targets the case where that nesting carries meaning: a folder of source code, an assets directory with a required layout, a photo archive sorted by date.

Selection is not limited to a single item either. You can pick any number of files in one transfer, so the folder case and the bulk case belong to the same workflow rather than to two separate tools. Raw text can go the same way, either stored as a txt file or copied to the clipboard on the receiving device, which covers the short snippet that would be tedious to retype by hand.

One local network is enough, and a hotspot counts

Photon does not need an internet connection. The supported topology is a local area network: two devices attached to the same router, or two devices joined through a mobile hotspot. The project's own wording is that no wifi router is required because a hotspot can be used instead, which makes the phone acting as access point a first class path rather than a fallback for people without a router.

That constraint also defines the scope. No account, no cloud account and no remote relay are described in the project documentation; the exchange is local, between two installations of the app. The price of that simplicity is that both ends must be physically near each other, on the same network segment, with the app running on both. The project's own description frames it plainly: files move between devices that run Photon.

HTTPS and a random path per session, with a brute force caveat

Version 3.0.0 is the release that added HTTPS support with token based validation and a random URL path for each session. Before that, older versions relied on cryptographically secure secret code generation for authentication internally, with the secret acting as the URL path. The project is blunt about the weakness of that earlier scheme: it was still vulnerable to a brute force attack, since a static style path can be guessed over time. The v3.0.0 design changes the path on every session, so a path captured from an earlier session no longer matches.

The guidance that comes with this is to use HTTPS where possible and to keep Photon inside trusted networks. Both halves matter. A per session path raises the cost of guessing but does not turn a local radio into a private channel, and the project documentation does not describe certificate pinning or any client side key exchange beyond the token itself. On an open network the transport protection depends on the session path remaining unguessable while the transfer is running.

The build path is two Flutter commands and one rendering flag

The project's build section is short. It lists two commands, run from the repository root. The first resolves and caches the Dart and Flutter package dependencies declared in pubspec.yaml, and the second compiles the app and launches it on the host machine.

flutter pub get packages
flutter run

The repository root carries the usual Flutter layout, with lib/, android/, ios/, linux/, macos/, web/ and assets/ alongside pubspec.yaml, pubspec.lock, a LICENSE, a Makefile, analysis_options.yaml and privacy_policy.txt.

One specific failure is documented, and it has a specific remedy. If running the program with flutter run shows a blank application window instead of the interface, the fallback is to enable software rendering.

flutter run --enable-software-rendering

That matters mostly on virtual or headless hosts, where the GPU backed renderer has no display to draw to. The repository also ships a Makefile with packaging targets for a Linux bundle, an AppImage, an Inno Setup based Windows installer, a Chocolatey package and MSIX creation, but the documented build instructions do not go through those targets.

Download artifacts are archives, and iOS is still a placeholder

Distribution is split per platform. Android is served through Google Play and an IzzyOnDroid repository listing. Windows points at a zip named photon-windows-release-v3.0.0.zip, macOS at a dmg named photon-macos-x86_64-release-v3.0.0.dmg, and Linux at a zip named photon-linux-release-v3.0.0.zip, with a link to all releases alongside.

The file names tell you what to expect after download. The Windows and Linux artifacts are zips to unpack rather than installers to run, and the macOS one is a dmg for x86_64, which is not a universal binary for newer Apple hardware. The Makefile goes further than the download links do. Its tar target bundles linux/photon.desktop, assets/images/icon.png and linux/com.github.abhi16180.photon.appdata.xml into an xz archive, its appimage target calls appimage-builder, and its innoinstall target downloads the Inno Setup 6.2.1 installer into build before compiling scripts/windows-setup-creator.iss.

The platform list names iOS, but marks it as coming soon. Read that as listed rather than shipped.

Photon is the wrong tool for anything that is not a local hand-off

Because both ends must sit on the same network and both must run the app, Photon cannot deliver a file when the sender is on one office network and the receiver is on another. There is no documented relay, no share link that a browser can open, and no unattended or headless mode, so the mobile target in particular is a foreground application that someone has to watch.

It is not a synchronisation tool either. Nothing in the project documentation describes continuous replication, conflict handling, versioning, or resumption after a dropped connection, so treating Photon as a stand-in for a cloud drive or for version control would be a misreading of what it does. What it does well is a deliberate, supervised exchange.

The raw text feature narrows the practical use further. Sharing text to a txt file or the clipboard is convenient for snippets and short messages, but it still travels as an ordinary file transfer with the same size and directory implications as everything else the app moves.

The licence moved from MIT to GPL-3.0

The project's notes record a licence change: the LICENSE was updated to GPL3 from MIT. A LICENSE file sits at the root of the repository, and the project's licence is GPL-3.0. Anyone who integrated earlier MIT-licensed code into a product has to treat that earlier snapshot as MIT and the current one as GPL-3.0, whose copyleft obligations for distribution differ. That question belongs to your own release process, not to this review, and it is worth checking against the licence text before adoption rather than after a release.

Attribution details travel with the code as well. Avatars come from multiavatar, icons from SVG Repo, the font is the Google Fonts project Questrial, and the app icon was made in Canva. The Windows and Apple icons carry their own Creative Commons or public domain terms, the Linux icon is MIT, and a redistributor should keep those notices intact in any package built from this source.

Editorial conclusion

Photon suits people who need to hand a folder of files to a nearby machine without an internet connection or an account, and it is a poor fit for remote delivery, unattended synchronisation or anyone who cannot take on GPL-3.0 terms. Before adopting it, check the licence move from MIT to GPL-3.0 against your own distribution, confirm your platform has a published artifact since iOS is still marked as coming soon, and run the two documented build commands on a machine with a Flutter toolchain, using the software rendering flag if the window comes up blank.

Frequently asked questions

Official sources

1. abhi16180/photon on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases