Packet: a Linux client for Google's Quick Share protocol

A partial implementation of a protocol nobody documented

Packet is described as a partial implementation of Google's Quick Share protocol that lets you send and receive files wirelessly from Android devices using Quick Share, or from another device running Packet itself.

The word partial is the most important word in that description, and it is honest in a way that is easy to appreciate from the acknowledgements. The reverse engineering of the closed-source Quick Share implementation in Android's GMS is credited to NearDrop, and rquickshare is credited for their internal Rust implementation of the protocol. The Cargo.toml shows that Packet depends directly on that work, pulling in rqs_lib from a git repository at a pinned revision with the experimental feature enabled.

So the architecture is layered. The protocol implementation is somebody else's work, used as a library, and Packet is the desktop application on top of it: the GTK interface, the discovery, the file transfer orchestration and the desktop integration. That layering is also the risk profile, since the protocol side can change underneath whenever the upstream library is updated, and the pinned revision in Cargo.toml is what keeps a build reproducible in the meantime.

The result is a Linux application that does not ask your phone to install anything. That is the appeal. Quick Share is already on the phone, and Packet makes it usable from the desktop side without a companion app on the Android device.

The application is Rust with GTK4 and libadwaita, distributed on Flathub as io.github.nozwock.Packet, with nightly Flatpak builds available separately, and third-party packages on the AUR and in nixpkgs.

The Wi-Fi LAN medium, and what it means for your network

There is one requirement that determines whether Packet works for you at all, and it is stated in a single line.

Since only the Wi-Fi LAN medium is implemented, Packet requires Bluetooth to be enabled and the devices to be connected to a Wi-Fi network with mDNS.

Three conditions, and the third is the one that surprises people. mDNS is multicast DNS, the mechanism that lets devices announce themselves on a local network without a server. Quick Share discovers peers that way, and mDNS multicast is notoriously unreliable across some consumer router configurations and Wi-Fi networks that enable client isolation. If a router puts wireless clients on separate network segments, or a corporate network filters multicast, discovery silently fails.

Bluetooth being enabled is needed for the discovery phase even though the transfer itself goes over Wi-Fi. That sounds odd until you consider that the Bluetooth radio is what the two devices use to exchange the address of the Wi-Fi interface they will actually talk over. So a desktop with Bluetooth disabled, or a phone with it disabled, will not find the other end even though both are on the same Wi-Fi.

The practical consequence is that Packet is a tool for a home or small office network where mDNS works, and it will frustrate you on a network where it does not. The FAQ in the README does not address mDNS specifically, which is a fair criticism: the single most common reason a user cannot get it working is the network, not the application.

The D-Bus interface is the extension point

Packet exposes a session D-Bus interface for external integrations such as desktop extensions and scripts, and the current scope of that interface is narrow and precisely stated.

The service is io.github.nozwock.Packet.Api, the object path is /io/github/nozwock/Packet, and the interface is io.github.nozwock.Packet1. The interface currently provides read-only access to the configured device name, and read and write access to device visibility.

That is a small surface, and it is a deliberate one. Device visibility is the interesting half, because it lets another program control which of your devices are reachable, and the configured device name being read-only is what stops an integration from renaming the machine out from under the user.

The interface can be introspected from a running instance of Packet using tools like D-spy, which is the D-Bus inspector. For a developer building a panel, a script or a status indicator that needs to know whether Packet is running and what it is called, that is enough to start, and the ability to introspect rather than guess at the interface means you do not have to read the source.

The dependency list backs up the D-Bus claim. zbus 5.7.1 is the D-Bus library, ashpd is the XDG desktop portal client with the background, notification, gtk4 and async-io features enabled, and whoami is present. The presence of ashpd is worth noting on its own, because the portals are the sanctioned way for a sandboxed application to ask the user for access to something rather than demanding it.

Flatpak, the Nautilus plugin, and the permission friction

The FAQ section is the most useful part of this README for anyone actually trying to use Packet, because it documents three concrete failure modes.

The first is not being able to send to the app from other devices. The cause is that your firewall may be blocking Packet's port, and the fix is to enable Static Port in Preferences and allow it through the firewall.

The second is a Couldn't open files error. It occurs if the file is invalid, for example empty, or on Flatpak if you are sending files through the Nautilus plugin from a location Packet cannot access. The suggested fix is to consider granting All system files access via Flatseal, to allow sending from any location.

The third is a downloads folder that keeps resetting. In Flatpak, folder access is temporary and resets after a session restart because static access cannot be requested. To set a permanent downloads folder you grant access in advance using Flatseal, or you run:

flatpak override --user io.github.nozwock.Packet --filesystem='/path/to/your/folder/here'

That command is the general solution and is worth bookmarking, because the flatpak override mechanism is how you give a Flatpak permanent access to a path rather than the temporary access the portal grants per session.

The Nautilus integration is the part that makes this feel like a system feature rather than an app, and it has its own dependency requirements per distribution:

Ubuntu/Debian:
sudo apt install python3-dbus python3-nautilus
Fedora:
sudo dnf install python3-dbus nautilus-python
Arch:
sudo pacman -S python-dbus nautilus-python
Fedora Silverblue (rpm-ostree):
rpm-ostree install python3-dbus nautilus-python

Note that the package names differ between distributions, which is the sort of thing that a single install command cannot cover, and the Flatpak and rpm-ostree cases need different treatment again.

A hybrid Rust and Meson build

The build system is a mixture, and understanding why explains the repository layout.

The Cargo.toml is the Rust side, with the package named packet, edition 2024, and a release profile that enables link time optimisation. The dependencies are the interesting part. gtk 0.11 is the GTK4 binding with the v4_22 feature, adw 0.9 is libadwaita with v1_9, and gettext-rs 0.7 is the translation layer with the gettext-system feature, which links against the system gettext library rather than bundling one.

Then there is the application logic: tokio with the full set of async features, zbus for D-Bus, ashpd for the desktop portals, and a set of small utilities that each do one thing. human_bytes formats sizes for the transfer display, formatx does string formatting, port_scanner is there for finding the port to use, which connects directly to the Static Port preference in the FAQ, and fs-err and anyhow handle errors. The whoami crate is presumably for the device name that the D-Bus interface exposes.

On Linux only, ksni 0.3 is pulled in, which is the StatusNotifierItem tray icon implementation.

The Meson side is meson.build with meson_options.txt, a.justfile for task running, hooks/ for the git hooks, build-aux/, subprojects/ for the wrap-based dependencies, and a.gitlab-ci.yml. The data/ directory holds the icons, the.desktop file and the Flatpak manifest, since the repository layout carries a data/icons/io.github.nozwock.Packet.svg and a data/resources/screenshots path, and the.doap file is the GNOME metadata document.

The build instructions are not in the README but in CONTRIBUTING.md. The last push was on 2026-10-02 and the release history shows 0.7.3 on the same day, 0.7.2 on 2026-09-30 and 0.7.1 on 2026-09-29, so this is a project shipping small increments very actively.

Where Packet is the wrong tool

The first limit is the one the project states: this is a partial implementation. If you need a Quick Share feature that is not in there, there is no configuration that turns it on, and the upstream rquickshare library is where the missing pieces would have to be implemented. The experimental feature flag in the Cargo.toml suggests the underlying protocol library is itself not finished.

The second limit is the medium. Only the Wi-Fi LAN medium is implemented. If your phone and your desktop are on different networks, Packet cannot help you, and there is no relay path through Google's servers in this implementation. A cloud file sharing service solves that problem and Packet does not attempt to.

The third is the network dependency, and it is the one you will hit first. The mDNS requirement plus the firewall requirement plus the Bluetooth requirement is three ways for discovery to fail, and the failure mode in each case is that the other device simply does not appear. Without a second Android device to test against, diagnosing that is slow.

The fourth is a platform one. This is a Linux application. The repository topics list linux, gtk, android, nearbyshare and quickshare, and there is no macOS or Windows version in the project. If you share files between a Mac and an Android phone, this is not the answer.

There is also the small but real risk that comes with reimplementing a closed protocol. Quick Share is not a documented, stable API. Google can change the protocol, and the practical effect of that would be that Packet stops interoperating with newer Android versions until someone reverse engineers the change again. That is a maintenance liability that a cable does not have, and it is worth weighing against the convenience for anyone planning to rely on it long term.

Editorial conclusion

Packet is a good pick for a Linux desktop user who regularly swaps files with an Android phone and is tired of using a cable or a web upload, because it speaks the protocol the phone already speaks rather than asking the phone to install anything, and the Flatpak with the Nautilus integration makes it feel like a native feature; it is the wrong pick if you need the full Quick Share feature set, since the implementation is explicitly partial and only the Wi-Fi LAN medium is implemented, and before you rely on it you should check the Bluetooth and mDNS requirements on your network, because the two devices have to be on the same Wi-Fi and both have to be discoverable.

Frequently asked questions

Official sources

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