What is planned
Where Fileporter stands today, the work that is scheduled next, and the things it is deliberately not going to do.
Where it stands
The application is built and its behaviour is covered by tests — 156 of them across identity, the wire protocol, the transfer engine and application state, including injected write and fsync faults on the durability paths.
What it has not had is the thing that matters most for software that moves your files: a run on two real machines.
Planned work
What is being built
Grouped by theme and ordered by intent. These are horizons, not dates — nothing on this page is a delivery commitment, and the order can change when a customer gives us a reason to change it.
-
In progress
Proving it on real hardware
Everything today is verified against a loopback smoke suite on one machine. That is the right way to make the logic testable, and it is explicitly not the same as two computers on a real network — real mDNS, a firewall, an interface moving between Wi-Fi and Ethernet, and macOS asking for local-network permission are none of them things a loopback test can produce.
- Two-device acceptance on a private LAN: discovery, trust, transfer, resume and fan-out
- The manual private-address route with multicast switched off
- macOS local-network permission prompt and recovery on 12.0 and later
- Visual QA of the interface itself, which the mocked frontend tests do not cover
-
Next
Something you can install
Windows MSI and NSIS packages build, and CI produces unsigned Windows and macOS artifacts. Unsigned is not shippable: signing and notarisation are what stand between the current builds and something a person can double-click without an operating-system warning.
- Windows code signing and installer acceptance
- macOS packaging, signing and notarisation
- Crash, power-loss and long-running interface-churn acceptance
-
Next
An independent look at the security
Fileporter holds a private key, pins peer certificates and writes files it received from another machine. Those are the boundaries worth having somebody else check, and the credential store moved to the platform keychain recently enough that the move is part of what should be reviewed.
- External review of the credential store, pairing, certificate pinning and transfer boundaries
-
Later
After v1
Deferred on purpose rather than forgotten. None of these change the transfer architecture, which is why they can wait.
- A signed auto-update feed
- A file-manager context-menu share extension
- Per-peer default recipient groups, and offline queueing to every trusted device
- QUIC and multiple streams — but only once profiling shows TCP is the limit
Out of scope
Not on the roadmap
Said plainly, because the alternative is a sales conversation that ends in disappointment. If one of these is the thing you need, Fileporter is not the product for it.
-
Transfers over the Internet
No relay, no NAT traversal, no WAN path. Manual addresses are restricted to private ranges, and that restriction is the product rather than a limitation of it.
-
Folder synchronisation
Fileporter sends what you drop, once. Watch folders and two-way sync are a different product with a much harder failure mode.
-
Linux, mobile and the browser
v1 is Windows and macOS desktop. A headless or NAS build is not planned.
-
Browsing another device’s files
A trusted device can send to you. It cannot look around.
-
Accounts, telemetry and cloud history
There is nothing to sign into and nothing is reported anywhere. Removing that would remove the reason to use it.
How this is maintained
Every item above corresponds to work tracked in our own issue tracker, and this page is rewritten from that tracker rather than kept by hand. What is not shown: unfixed defects and security work, which belong in the tracker until they are closed, not on a product page.
Want the detail behind a line on this page, or a view of where something sits? Write to dmoore@dwmmholdings.com and ask.
Next
Get Fileporter
Ask about availability, a build for your platform, or a licence.