SVI/netbird
1
0
Fork 0
mirror of https://github.com/netbirdio/netbird.git synced 2026-06-12 02:11:43 -04:00
Code Issues 3.0k Packages Projects Releases 10 Wiki Activity

Sharing files with netbird #2104

New Issue
Open
opened 2025-11-20 07:03:56 -05:00 by saavagebueno · 4 comments
saavagebueno commented 2025-11-20 07:03:56 -05:00
Owner
Copy Link

Originally created by @aliamerj on GitHub (Jul 23, 2025).

Implement a Taildrop-like file transfer feature for NetBird, we need to create a secure, peer-to-peer file-sharing system that integrates naturally into NetBird’s infrastructure allowing users to send files between their personal devices on a Netbird network.

Overall Implementation Core Logic:

Build the file transfer functionality to work over NetBird’s peer-to-peer connections.

  • Platform-Specific Code:
    • macOS/iOS/Android: Integrate with the share menu (e.g., “Share via NetBird”).
    • Windows: Add to the share context menu or NetBird client interface.
    • Linux: Develop a command (e.g., netbird send <file> <device/ peer-id>)

TASK 1: File Transfer Activation, Permissions, and Default Save Path

In this first step, I’ll implement the core logic for peer-to-peer file transfer inside the NetBird agent — following a model similar to SSH’s controlled file copy behavior.

🧩 What I’ll Do

  • Introduce a new management-side config flag (e.g., enableFileTransfer: true)

    • that governs whether the agent is allowed to participate in file transfer at all.
    • This is synced to the agent and acts as a hard gatekeeper
      If disabled, the feature is entirely inactive regardless of CLI flags or user actions

  • Agent Startup Check:

    • On startup, the NetBird agent checks the management config for the EnableFileTransfer flag.
    • If disabled, the feature remains entirely off — no listeners, no UI, no CLI options exposed.

  • Local Listener with Optional Runtime Signal
    Once management has enabled it, the agent can start a local listener for file transfer requests:

    • Either automatically on startup (based on CLI/config flag like --file-transfer)
    • Or dynamically triggered at runtime via a dedicated internal signal message (e.g., start_file_transfer_listener)

  • Protobuf-Based Control Messages (used in peer-to-peer communication) to support new message types for file transfer:

    • file_offer → initiate
    • file_accept / file_deny
    • file_meta → metadata (size, name)
    • file_chunk → actual data
    • transfer_complete / transfer_error

  • User Authorization Flow — When someone tries to send a file:

    • Receiver gets a request with file metadata (size, name, sender)
    • Receiver must approve via CLI/desktop UI
    • Optionally allow auto-accept from trusted peers via config

  • Default Save Path via Agent Settings

    • Add support for a default download directory (e.g. ~/NetBirdTransfers)
    • Allow override via CLI flag or agent config

  • Handle file streaming over the established tunnel:

    • Once approved, file chunks will be streamed directly over the existing encrypted tunnel using a TCP/Unix socket connection negotiated internally.
      • No extra open ports
      • Data stays within the mesh tunnel
      • Uses same NAT traversal as other NetBird traffic

  • CLI prototype for Linux to send and receive files using the command:

netbird send <file-path> <peer-id>
  • Works only if both peers are management-enabled and listening
  • Prints real-time status in teminal

TASK 2: Cross-Platform File Sharing UX Integration

Now that we have the internal file transfer logic working (from Task 1), this task focuses on making it usable and accessible across major platforms by integrating with native OS interfaces.

🧩 What I’ll Do

  • Linux ( already done in Task 1)

    • Extend the CLI UX (from Task 1) with optional interactive prompts.
    • Optionally create a minimal GTK or terminal UI to make selection easier.

  • macOS / iOS / Android

    • Create component (i.e. "Share via NetBird").
    • When a file is shared, it triggers a background call to netbird send using the CLI or internal bindings.

  • Windows

    • Add a menu item ("Send with NetBird")
    • Under the hood, it calls the same file-sending command.

🔁 How It Works Technically

  • All platforms will reuse the message handlers and transfer logic from Task 1 — no new protocol or backend work is needed.
  • UI or shell integrations simply act as wrappers around the core agent, either invoking a CLI command or talking directly to the local NetBird service (via Unix socket or similar, if exposed).

TASK 3: Nice to have

  • Add optional settings like transfer history, and permissions.
  • Notify users when a new file is received.
Originally created by @aliamerj on GitHub (Jul 23, 2025). Implement a Taildrop-like file transfer feature for NetBird, we need to create a secure, peer-to-peer file-sharing system that integrates naturally into NetBird’s infrastructure allowing users to send files between their personal devices on a Netbird network. ## Overall Implementation Core Logic: ### Build the file transfer functionality to work over NetBird’s peer-to-peer connections. - **Platform-Specific Code**: - **macOS/iOS/Android**: Integrate with the share menu (e.g., “Share via NetBird”). - **Windows**: Add to the share context menu or NetBird client interface. - **Linux**: Develop a command (e.g., `netbird send <file> <device/ peer-id>`) ## TASK 1: File Transfer Activation, Permissions, and Default Save Path In this first step, I’ll implement the core logic for peer-to-peer file transfer inside the NetBird agent — following a model similar to SSH’s controlled file copy behavior. ### 🧩 What I’ll Do - **Introduce a new management-side config flag (e.g., `enableFileTransfer: true`)** - that governs whether the agent is allowed to participate in file transfer at all. - This is synced to the agent and acts as a hard gatekeeper If disabled, the feature is entirely inactive regardless of CLI flags or user actions - Agent Startup Check: - On startup, the NetBird agent checks the management config for the `EnableFileTransfer flag`. - If disabled, the feature remains entirely off — no listeners, no UI, no CLI options exposed. - **Local Listener with Optional Runtime Signal** Once management has enabled it, the agent can start a local listener for file transfer requests: - Either automatically on startup (based on CLI/config flag like` --file-transfer`) - Or dynamically triggered at runtime via a dedicated internal signal message (e.g., `start_file_transfer_listener`) - **Protobuf-Based Control Messages** (used in peer-to-peer communication) to support new message types for file transfer: - `file_offer` → initiate - `file_accept` / `file_deny` - `file_meta` → metadata (size, name) - `file_chunk` → actual data - `transfer_complete` / `transfer_error` - **User Authorization Flow** — When someone tries to send a file: - Receiver gets a request with file metadata (size, name, sender) - Receiver must approve via CLI/desktop UI - Optionally allow auto-accept from trusted peers via config - **Default Save Path via Agent Settings** - Add support for a default download directory (e.g. `~/NetBirdTransfers`) - Allow override via CLI flag or agent config - **Handle file streaming over the established tunnel**: - Once approved, file chunks will be streamed directly over the existing encrypted tunnel using a TCP/Unix socket connection negotiated internally. - No extra open ports - Data stays within the mesh tunnel - Uses same NAT traversal as other NetBird traffic - **CLI prototype for Linux to send and receive files using the command**: ```bash netbird send <file-path> <peer-id> ``` - Works only if both peers are management-enabled and listening - Prints real-time status in teminal ## TASK 2: Cross-Platform File Sharing UX Integration Now that we have the internal file transfer logic working (from Task 1), this task focuses on making it usable and accessible across major platforms by integrating with native OS interfaces. ### 🧩 What I’ll Do - Linux ( already done in Task 1) - Extend the CLI UX (from Task 1) with optional interactive prompts. - Optionally create a minimal GTK or terminal UI to make selection easier. - macOS / iOS / Android - Create component (i.e. "Share via NetBird"). - When a file is shared, it triggers a background call to netbird send <file> <target-device> using the CLI or internal bindings. - Windows - Add a menu item ("Send with NetBird") - Under the hood, it calls the same file-sending command. #### 🔁 How It Works Technically - All platforms will reuse the message handlers and transfer logic from Task 1 — no new protocol or backend work is needed. - UI or shell integrations simply act as wrappers around the core agent, either invoking a CLI command or talking directly to the local NetBird service (via Unix socket or similar, if exposed). ## TASK 3: Nice to have - Add optional settings like transfer history, and permissions. - Notify users when a new file is received.
saavagebueno commented 2025-11-20 07:03:57 -05:00
Author
Owner
Copy Link

@aliamerj commented on GitHub (Jul 23, 2025):

The goal in mind is to allow users to send files between their own devices over the existing encrypted tunnel, no extra ports or infra, but i am thinking now what if the user try to send big files is this will this bloat the agent?
Is it better to have extra port for this feature ? Any risks or architectural concerns I'm overlooking?

@aliamerj commented on GitHub (Jul 23, 2025): The goal in mind is to allow users to send files between their own devices over the existing encrypted tunnel, no extra ports or infra, but i am thinking now what if the user try to send big files is this will this bloat the agent? Is it better to have extra port for this feature ? Any risks or architectural concerns I'm overlooking?
saavagebueno commented 2025-11-20 07:03:57 -05:00
Author
Owner
Copy Link

@1nerdyguy commented on GitHub (Jul 23, 2025):

Is this a feature really needed/asked for?

Netbird already supports secure file transfers. It's called using whatever file transfer protocols you're already using, and doing it via the Netbird tunnel.

I worry this is a bit of scope creep into a region that shouldn't need to be done?

@1nerdyguy commented on GitHub (Jul 23, 2025): Is this a feature really needed/asked for? Netbird already supports secure file transfers. It's called using whatever file transfer protocols you're already using, and doing it via the Netbird tunnel. I worry this is a bit of scope creep into a region that shouldn't need to be done?
saavagebueno commented 2025-11-20 07:03:57 -05:00
Author
Owner
Copy Link

@nazarewk commented on GitHub (Jul 23, 2025):

I think this is more on the side of user experience/convenience and spreading adoption of good practices.

"How do I send a secret/sensitive file securely to coworkers?" seems to be the most prevailing and least addressed issues in my career.

Keeping that in mind, I would omit any scope creep of the feature beyond the bare minimum:

  • don't bother with local file history
    • just log it as an Audit Event with filename, size and hash of the file
  • always create the least privileged file on the given platform:
    • scoped to the user account accepting the transfer
    • put into whatever download/temporary directory is writeable
  • make it run by default & have an opt-out
    • otherwise people might not bother setting it up and therefore might not serve it's purpose
    • make opt-out both enforced company-wide and a separate machine-scoped

I'm not sure it should be convenient to share large or many different files through it at all, could probably do a double-acceptance of files larger than X MB with additional warning and omit handling multi-file transfers completely.
It should be thought of as a primary mode of sharing sensitive files, not just any files (photo albums, movies etc.)

@nazarewk commented on GitHub (Jul 23, 2025): I think this is more on the side of user experience/convenience and spreading adoption of good practices. "How do I send a secret/sensitive file securely to coworkers?" seems to be the most prevailing and least addressed issues in my career. Keeping that in mind, I would omit any scope creep of the feature beyond the bare minimum: - don't bother with local file history - just log it as an Audit Event with filename, size and hash of the file - always create the least privileged file on the given platform: - scoped to the `user` account accepting the transfer - put into whatever download/temporary directory is writeable - make it run by default & have an opt-out - otherwise people might not bother setting it up and therefore might not serve it's purpose - make opt-out both enforced company-wide and a separate machine-scoped I'm not sure it should be convenient to share large or many different files through it at all, could probably do a double-acceptance of files larger than X MB with additional warning and omit handling multi-file transfers completely. It should be thought of as a primary mode of sharing sensitive files, not just any files (photo albums, movies etc.)
saavagebueno commented 2025-11-20 07:03:58 -05:00
Author
Owner
Copy Link

@1nerdyguy commented on GitHub (Jul 23, 2025):

I agree on the proposed setup there, and the reasoning why.

I guess I worry about becoming the 'everything for everyone' kind of problem we see in other products, and instead just focus on the core of Netbird

@1nerdyguy commented on GitHub (Jul 23, 2025): I agree on the proposed setup there, and the reasoning why. I guess I worry about becoming the 'everything for everyone' kind of problem we see in other products, and instead just focus on the core of Netbird
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
2021 Q4
2022 Q1
2022 Q1
accessibility
acl
agent
agent
Android
Android
api
authentik
automation
azure
battery-usage
bug
cache
client
client-ui
cloud
cloud-only
cloudflare
community
compatibility
config-idp
config-issue
connection
contribution
coturn
cross-vpn
dashboard
data-usage
distribution
dns
docker
documentation
duplicate
enhancement
enhancement
event-stream
feature-request
freebsd
getting-started
go
good first issue
gui
help wanted
home-assistant
idp
inconsistency
integration
integrations
ios
ipv6
jwt
k8s
keycloak
linux
login
macos
management-service
missing-docs
mobile
moved-internal
needs-review
netbird-ui
networking
new-platform
nginx
notification
okta
openwrt
packaging
peer-management
peer-management
peer-management
performance
postgres
posture-checks
psk
pull-request
Mirrored from GitHub Pull Request
 question
refactor
relay
release
rfc
routes
security
security-related
self-hosting
server
signal
sleep-issue
ssh
ssl
status
store
synology
system-compatibility-issue
test-suite
third-party-integration
triage
triage-needed
troubleshooting
UX
waiting-feedback
windows
wontfix
zitadel
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
saavagebueno
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: SVI/netbird#2104
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?