1.0.9920.1 MB
MIT
strict
core24
Share files with nearby Android, Windows, macOS, and Linux devices
NearShare speaks Google's Quick Share / Nearby Share wire protocol
directly, so it interoperates with:
- Android Quick Share
- Windows Quick Share
- macOS NearDrop
- itself, Linux <-> Linux
No cables, no cloud account, and no companion app on the phone -- just a
shared WiFi network (or NearShare's own experimental Direct-mode
hotspot) and a 4-digit PIN you confirm on both screens.
Discovery uses mDNS (python-zeroconf, which binds its own multicast
sockets rather than talking to Avahi) plus an optional Bluetooth LE
"wake up" beacon so an Android phone's share sheet notices this machine
proactively. Every transfer is end-to-end encrypted (UKEY2 key
exchange, then AES-256-CBC + HMAC-SHA256 per frame) and requires a
manual PIN confirmation on both devices -- there is no persistent
cross-device trust (no Google-account "paired key" support).
AFTER INSTALLING -- two commands
--------------------------------
Bluetooth discovery and Direct mode need interfaces that snapd does
not connect automatically. Run both, then start the app:
sudo snap connect nearshare:bluez
sudo snap connect nearshare:network-manager
Without bluez the app still works, but your phone may only see this
machine while the phone's own Quick Share screen is open. Without
network-manager, Direct mode (the built-in hotspot for when there is
no shared WiFi) is unavailable. Everything else -- discovery,
sending, receiving -- works with no extra setup.
Optional: a Super+Shift+S shortcut to toggle visibility can be bound
from the app's own setup panel, or with
Right-click "Send with NearShare" in Files
------------------------------------------
Not available in the snap. Strict confinement forbids writing to
~/.local/share/nautilus, so no snap can install a Files extension.
If you want right-click sharing, install the Debian package instead:
sudo add-apt-repository ppa:dhiva-labs/apps
sudo apt install nearshare
The .deb ships a system-wide Files extension and needs no per-user
setup. Both builds are the same application otherwise.
directly, so it interoperates with:
- Android Quick Share
- Windows Quick Share
- macOS NearDrop
- itself, Linux <-> Linux
No cables, no cloud account, and no companion app on the phone -- just a
shared WiFi network (or NearShare's own experimental Direct-mode
hotspot) and a 4-digit PIN you confirm on both screens.
Discovery uses mDNS (python-zeroconf, which binds its own multicast
sockets rather than talking to Avahi) plus an optional Bluetooth LE
"wake up" beacon so an Android phone's share sheet notices this machine
proactively. Every transfer is end-to-end encrypted (UKEY2 key
exchange, then AES-256-CBC + HMAC-SHA256 per frame) and requires a
manual PIN confirmation on both devices -- there is no persistent
cross-device trust (no Google-account "paired key" support).
AFTER INSTALLING -- two commands
--------------------------------
Bluetooth discovery and Direct mode need interfaces that snapd does
not connect automatically. Run both, then start the app:
sudo snap connect nearshare:bluez
sudo snap connect nearshare:network-manager
Without bluez the app still works, but your phone may only see this
machine while the phone's own Quick Share screen is open. Without
network-manager, Direct mode (the built-in hotspot for when there is
no shared WiFi) is unavailable. Everything else -- discovery,
sending, receiving -- works with no extra setup.
Optional: a Super+Shift+S shortcut to toggle visibility can be bound
from the app's own setup panel, or with
nearshare install.Right-click "Send with NearShare" in Files
------------------------------------------
Not available in the snap. Strict confinement forbids writing to
~/.local/share/nautilus, so no snap can install a Files extension.
If you want right-click sharing, install the Debian package instead:
sudo add-apt-repository ppa:dhiva-labs/apps
sudo apt install nearshare
The .deb ships a system-wide Files extension and needs no per-user
setup. Both builds are the same application otherwise.
Update History
1.0.8 (8) → 1.0.9 (9)6 Aug 2026, 11:15 UTC
1.0.7 (7) → 1.0.8 (8)6 Aug 2026, 11:00 UTC
1.0.5 (5) → 1.0.7 (7)6 Aug 2026, 10:30 UTC
1.0.3 (4) → 1.0.5 (5)6 Aug 2026, 08:30 UTC
1.0.2 (3) → 1.0.3 (4)6 Aug 2026, 00:45 UTC
1.0.2 (3)5 Aug 2026, 23:30 UTC
5 Aug 2026, 22:58 UTC
6 Aug 2026, 11:14 UTC
5 Aug 2026, 23:30 UTC