Upload Mesh

Install it once, then choose what your mesh is for

1. Install the Android package. Open the downloaded file, read Android's install screen, choose Install, and then open UploadMesh.
2. Install the Linux package. Extract the archive, open a terminal in its folder, and run ./Install-UploadMesh.sh. The installer starts the node and opens pairing.
3. Link the two devices. On the phone, open Send and choose the computer shown under Found on this Wi-Fi. Once you approve the pairing, the devices remember each other.
4. Begin with one real job. Send a file between the devices. You decide what belongs in your mesh and which features each device may use.

What has actually been proven

The simple start is above. The rest of this page shows the evidence and the unfinished work, because a claim with no execution behind it is not a result.

• Live verified Run against real hardware or between two real machines, the result read back on the receiving side, and the record of that run in the repository, cited by line.
• Built The code is in the repository and a named test proves the behaviour with a paired negative. The other side was a fixture, a loopback, a second process on the same machine, or an emulator driven against a real desktop.
• Not yet Not built, not run, not in the repository, or blocked on a decision or on hardware. Listed so it cannot be mistaken for finished.

One product across the devices you choose

UploadMesh does not decide what your devices are for. It gives them one private way to recognize each other, and you choose the connections and capabilities that matter to you.

• One product, with the right package for each device. Android and Linux use different packages because their operating systems require it, but they join the same mesh. It is not a suite, a browser tab, or a different product for every job.
• Devices pair with each other, and that is the whole account. Two devices you hold pair directly, each pins the other's certificate, and each holds a credential for the other that is never stored in clear. There is no account to make, no code to redeem, no server that can reset anything. Having no account raises the bar rather than lowering it: the device pair is the whole trust root, so the link between them is the strongest available and the person at each end is asked before anything risky.
• A private network between your own devices only. A coordination server lets your devices find each other across the internet and hands out keys. It never holds your files, your clipboard or anything you send, and it never holds the keys the devices use with each other.
• Your files, your clipboard, a picture of a screen, a wake signal, and a question travel that link, device to device, with a pinned certificate at each end and a hybrid post-quantum key exchange on the direct link.
• Everything is optional. Every feature has a switch, the switch is on the device it concerns, and the ones that can expose or change a device ship off.
• Every file explains itself. The TAGII Code Documentation Standard: each source file carries what it is, why it exists, what it connects to, where it runs and which day's record it came from, and the tools that check and write that header ship inside the same binary.
• Open source, on a self hosted forge. Never GitHub, never a Microsoft service. Licensed AGPL-3.0-or-later. Read the source, run it, modify it, share it. If you run a modified copy as a network service that other people use, the licence requires you to offer those people that modified source in turn. A company cannot take this code, close it, and run it as a proprietary service; that is the effect the licence is chosen for, not a side effect of it.

What is proven between two real machines

4 claims. Each was run between two real machines over the private network between them, on the build of 2026-08-29, with the result read back on the receiving machine and the record kept, by line, in the repository. The current build has not been re-run between two machines, and the next section says so.

• A file reached a second real machine, hash checked on that machine Live verified

  Two real machines over the private network between them, on the build of 2026-08-29. A small file landed and its hash matched on the receiving side. A larger one stalled part way, and a second send resumed from the exact byte it had reached and finished with the hash matching. The stall and the recovery are both in the record, which is the receiving machine's own journal, written by the person at that machine.

  UM.75 (part) · daily record 2026-08-29 · TestResumableAtomicTransfer, TestPullResumesAndVerifies · on the build of that day; the current build has not been re-run between two machines

• A file pulled from a second real machine, in one piece Live verified

  The other direction: this machine asked the other for a file it had never seen and received all of it, hash exact, nothing partial on disk. Verified on the receiving disk, which is the only side that counts.

  UM.75 (part) · daily record 2026-08-29 · TestPullResumesAndVerifies · on the build of that day

• A clipboard item went to a second real machine and came back unchanged Live verified

  Pushed from one machine, pulled back from the other, byte for byte the same, both ways. The build of 2026-08-29. The two-process relay guard covers the same path on one machine.

  UM.14, UM.75 (part) · daily record 2026-08-29 · TestClipboardRelayTwoNodes · on the build of that day

• An update kept the device's identity, seen from the other side Live verified

  The program on one real machine was swapped for a new build while its peer watched. The peer, from its own box, saw the same pinned identity before and after, so the pin did not trip and nothing had to be paired again. A swap that quietly regenerated identity would have been refused as an impostor.

  UM.15 · daily record 2026-08-29 · TestInstallSwapsByRenameAndKeepsIdentity, TestRollbackRestoresPrevious

Built and tested, on one machine or an emulator

32 claims. Each is in the repository with a named test that proves it with a paired negative, and several were driven on an emulator against a real desktop and read back there. The other side was a fixture, a loopback, a second process on this machine, or that emulator. Read them as engineering, not as a product promise.

• Clipboard relay in both directions, nothing dropped silently Built

  Copy on one node and the text arrives at the other with a notice. No echo back. Text that looks like a secret is withheld and the withholding is logged. Every outbound item is a file with a state, and a refusal by the far side is visible rather than retried forever.

  UM.14 · TestClipboardRelayTwoNodes, TestQueueStateMachine, TestQueueBackoffBounded, TestQueueNewerClipboardSupersedesTheOlderOne, TestQueueOnePassSkipsTheRestOfADownPeer, TestQueuePinMismatchHoldsUntilPairedAgain, TestClipWatcherSecretFilter

• The node does not listen where it was not asked to Built

  It binds the loopback address and the private network address. A dial to the machine's ordinary network address is refused, and a positive control proves the refusal is the rule and not a firewall. Every wildcard spelling is refused outright.

  UM.10 · TestBindRefusesLAN, TestBindSetNeverWildcard

• A peer whose certificate changed is refused Built

  Pinning is enforced on the transfer path. With a wrong pin the transfer is refused and the file never lands. Disabling the check makes the wrong pin succeed, which is how we know the test tests it.

  UM.10 · TestTailnetListen

• One identity, however many things start at once Built

  Every first start on a machine is a concurrent first start: the background node and any one-shot command share the same folder. The creation of the device certificate takes a lock, writes the key before the certificate, and losers wait for a complete pair, so no device ever serves an identity nobody pinned.

  daily record 2026-08-29, defect 3 · TestCertCreateRace · go/internal/meshcore/tls.go

• A bad update is refused whole Built

  Wrong signature, wrong size, wrong hash, no build for your platform, published too recently, a replayed sequence, or a manifest carrying a field the verifier cannot check: each refused, with the program on disk unchanged and nothing recorded.

  UM.41, UM.55 · TestUpdateRefusals, TestParseEnvelopeStrict, TestVerifyPositiveAndNegatives · a test key; the release key is not yet wired into a signed build

• Waking a device you own Built

  First ask the device: if it answers, it is awake. If not, send the wake signal, directly when the target is on the same network and otherwise through another of your devices that is. A wake is only ever claimed on an answer, never on a packet sent.

  UM.23 · TestWakeLayersAndMACAtPairing, TestWakeRelayEndpointAndRelayedWake

• A screen session refuses a device outside your set Built

  Pairing is the approval, so there is no per session dialog, but a device that is not one of yours is refused and the pairing code is never printed. Starting and stopping both write an audit row that names the devices and never the content. Credentials in a file other accounts can read are refused before any request goes out.

  UM.20, UM.24 · TestStreamHostAndStopEndToEnd, TestStreamOfferEndpointGuards, TestCredentialsFileModeGuard

• Your screen, as a picture, only to a device you paired Built

  Frames are served single and as a continuous stream to a paired device, and refused with no content to a device with no token or the wrong one. With the view paused, the next request is refused and marked paused; resuming serves a frame again. Nothing is written to disk.

  R7 · TestViewFramePairedAndUnpaired, TestViewPauseStopsFrames, TestViewStreamDeliversParts, TestNightTailAndUnpaired

• Files: a hash you can check, and nothing outside what you shared Built

  The response carries the hash of the file so you can check what you received. Path escapes are refused, and a symbolic link that points out of the share is refused as well. A device that has not paired gets nothing.

  R7 · TestFilesListAndGet, TestFilesEscapeRefused, TestFilesUnpairedRefused

• Every file explains itself, and the binary checks it Built

  Every source file carries a header that says what it is, why it exists, what it connects to, where it runs and which day's record it came from. The check, the stamper and the enricher are commands in the same binary, dry runs until told to write, and they show a diff before a change is accepted. The three defects the earlier tools once shipped are now tests that fail if they return.

  L.1, L.2, UM.62 · chapter 31 · TestStampWritesTheNineFieldsAndTouchesNothingItMustNot, TestEnrichAddsProvenanceFromGitAndImports, TestDiffShowsInsertionReplacementAndNothingForIdentical

• Deploy by header Built

  The files git says changed go to the device and share path their own header names. A file whose header claims another file's home is refused, so a backup can never overwrite the live copy. A file with no deployment block is never touched.

  L.4 · chapter 32 · TestDeployGoesWhereTheHeaderSaysAndNowhereElse, TestDeploymentReadsTheBlockAndRefusesTheRest

• A folder you edit, kept on a server as you save Built

  One way: this machine is the source of truth and every save is pushed into the other device's writable share. It runs only while asked. Nothing on the far side is ever deleted.

  L.3 · chapter 30 · TestWatchSendsWhatChangesAndNothingElse, TestWatchLandsEverySaveOnTheOtherDevice

• On a phone, receiving is a switch, and it is off until you turn it on Built

  The Receive tab has one switch. Off, the phone listens to nothing. On, it accepts files from your other devices on that one network, and it turns itself off when the network goes away rather than saying Ready over a dead socket. Proven on an emulator against a real desktop, not yet by a person on a phone.

  UM.104 · TestLanReceivingIsOffUntilItIsAskedForByPort, TestLanReceivingRefusesAWildcard, TestLanListeningTurnsFalseWhenTheSocketDiesUnderneath

• An incoming file is a question, not a download Built

  The phone shows who wants to send what, with Accept and Decline, as a card and as a notification, so it reaches you with the app closed. Nothing is taken until you accept. Decline takes nothing and the sender is told. Say nothing and it is a no. Always accept from this device is a switch you can turn off again.

  UM.44, UM.52 · TestAnOfferWaitsForThePersonAndAcceptPullsIt, TestDeclineTakesNothingAndTheSenderKnows, TestAnUnansweredOfferExpiresIntoADecline

• Progress you can watch, and a list of what arrived Built

  Sending and receiving both show a bar with the file's name. What the phone has received is a page: open it, hand it to another app, or forget it; a file that is gone says so.

  UM.106, UM.107 · TestDesktopPutReportsProgressAndTheBytesArrive, upload_mesh_history_page_test.dart

• No account, no sign-in, no code to redeem, anywhere Built

  There is nothing to register. A guard walks every screen the app can reach and fails if any of them mints a code, redeems one, or shows a sign-in. The guard was shown the old registration screen and recognised it, so its silence elsewhere means something.

  UM.90, UM.92 · upload_mesh_no_registration_test.dart

• The device's identity is locked to the person holding it Built

  The phone's device key lives in the secure hardware and refuses to work without a fresh face or PIN. Leave the app and it seals with no prompt; come back and you are asked. The order, ask then unseal, is the whole property, and a test would fail on a lock that opens first.

  UM.93, UM.96 · mesh_identity_lock_test.dart

• You can always see who is at the other end Built

  Every place you act on a device shows that device's pin, the same characters the other machine prints about itself. If they match, it is that machine and nothing in between.

  UM.97 · upload_mesh_home_test.dart, mesh_settings_screen_test.dart

• A phone in your hand can be the one that says yes Built

  Name one phone as the approval phone and the mesh asks it before anything risky happens to a computer: watching its screen, changing its files, opening a link on it, waking it, admitting a new device. Reading a shared file never asks. The question is bound to the device that asked, expires, cannot be replayed, and no answer is a no. Off until you turn it on.

  UM.56, UM.95 · chapter 33 · TestDecideApprovalBindsToAddressedDeviceNotABodyName, TestDecideApprovalIsSingleUse, TestWakeIsHeldForApprovalAndFailsClosed, TestFileChangesStepUpAndReadsNeverDo

• A ring plays at the volume you chose, and stops when you say Built

  Find a device by making it ring. It plays at whatever volume you already set, never touches the mixer, shows who asked, has a Stop button on the device making the noise, and stops on its own after a short time. A test fails if anything in that path ever calls the mixer again.

  UM.46 · TestRingNeverTouchesTheMixer, TestStopRingNowActuallyStopsIt, TestRingTimeLimitIsShortAndLogged

• Remove a device and it is refused, and told why Built

  A revoked device's next request is refused on the wire, and the refusal says revoked rather than leaving it to guess it hit a bug. The credential a paired device holds is never written to disk in clear.

  F13 · TestRevokedPeerIsRefusedOnTheWire, TestRotatedPeerOldGrantIsExpiredNotUnknown, TestPairedTokenNeverWrittenAsCleartext

• The link between your devices uses a post-quantum hybrid key exchange Built

  The direct, pinned connection between two devices negotiates a hybrid post-quantum key exchange by default, read back from the finished handshake rather than from a setting. The tunnel layer underneath it does not, and that is stated rather than papered over.

  UM.38 · TestPinnedHandshakeNegotiatesHybridPostQuantumByDefault, TestClassicalHandshakeIsDistinguishable

• Every feature has a switch, and only the owner can reach them Built

  The settings live behind a socket that only the owner's own account can open. Every feature is on one page with the switch that turns it off, where it is, and what it ships as. A diagnostics bundle you can send carries no credential.

  UM.70, L.6 · chapters 18 and 33 · TestSettingsAPIOwnerGates, TestSettingsAPIEveryFlutterEndpoint, TestDiagBundleCarriesNoSecrets

• Notifications cross only for the apps you name Built

  Which of the phone's own notifications may reach a desktop is one decision per app, off for every app until you turn one on by name. The permission Android needs for this is granted only from its own settings screen, and the app says so rather than hiding the list.

  UM.57 · mesh_notify_rules_service_test.dart, MeshNotifyRules.kt

• Control of a desktop is off, gated, and expires Built

  Typing and pointing into a desktop from a phone exists behind a gate: off unless turned on, refused while the session is locked, a window that expires on its own, and a list of the peers allowed. The path that injects input cannot be aimed at one window, and that hazard is stated where the switch is.

  UM.19 · TestControlOffIsThePanicKey, TestControlLockGuard, TestControlDeadManTimeout, TestControlPeerAllowlist

• Other clipboard tools on your network are seen, not trusted Built

  The message shapes are taken from KDE Connect so that talking to it stays possible. Today a stock KDE Connect on the same network becomes visible to a node and nothing more: no dial back, no pairing, no trust record, however many broadcasts arrive. Off by default.

  UM.14b · TestKDEDiscoveryOffByDefault, TestKDEDiscoveryNeverTouchesTheTrustStore

• Handing one file to a device with nothing installed Built

  A device with no app cannot run the protocol, so it is not asked to. A one-shot door serves exactly one file, on one exact path, to one connection, then closes. It refuses everything else and never listens on every address. It is code with tests and nothing in the product opens it yet: no command and no screen reaches it.

  UM.53, UM.54 · TestDoorServesExactFileOnExactPath, TestDoorIsOneConnectionOnly, TestDoorRefusesWrongPath · reachable from nothing today

• A code that is never sent anywhere Built

  A join by code is built so that the code itself never travels: each side derives a key from it locally, and a wrong code is refused at the first step. It is not reachable from any screen today, because the product links devices by pairing them directly.

  D13 · TestHandshakeSameCodeOpens, TestUpdate_WrongCode_RefusedAtUpdate, TestJoinByCode_WrongCode_IsRefused · not on any screen

• Two-way folder sync, driven and not re-invented Built

  Where a folder must stay the same on two devices, a maintained sync program is run as a subprocess and driven over its own interface, bound to the loopback only, with its credentials in a private file. The driver changes only what it manages. Two instances exchanging a file has not been run, and this ships off.

  UM.48, D5 · TestFolderCRUDRoundTrip, TestNewRefusesNonLoopback · one instance run

• A generated project passes the audit, an unfinished one fails Built

  The developer kit generates a project whose every file passes the header check. The same project with one unfinished field fails with the field named, and an empty tree is refused rather than passed.

  UM.21 · TestProjectFromKitPassesAudit, TestAuditFailsOnTodo, TestAuditRefusesEmptyTree

• A signed Android package is ready to download Built

  The Android package installs as UploadMesh and is signed by TAGII Incorporated. Its SHA-256 digest is published beside it so the downloaded bytes can be checked. This is an early-access package, not proof of a complete physical-phone session.

  UploadMesh-Android.apk · SHA256SUMS · physical-phone proof remains open

• The Linux package installs the node and opens pairing Built

  The Linux archive includes the program, licences, parts list and one installer. The installer was checked first with its no-change path, then run in an isolated user home where the installed program listened, opened its pairing window and stopped cleanly.

  UploadMesh-Linux-x86_64.tar.gz · Install-UploadMesh.sh · SHA256SUMS

What is not finished yet

This is the honest list. Nothing here is a capability of Upload Mesh today, and none of it should be read as nearly done unless it says so.

• The current build, between two real machines Not yet

  Files both ways and the clipboard were proven between two real machines on the build of 2026-08-29. The build since then has been proven on one machine, or between a real desktop and an emulator. Watching a screen, delivering an alert, and revoking a device across two real machines have not been run at all.

  UM.75 · the four lines above are the 2026-08-29 build

• A person, on a phone Not yet

  The Android early-access package is offered on this page, but every recorded phone-side proof was driven on an emulator against a real desktop and read back there. A complete physical-phone session has not yet been recorded.

  UM.11, UM.12, UM.104 · chapter 5

• Phone to phone Not yet

  A phone can open a sixty second door to be paired with, with a Stop on the phone; that was proven with a desktop as the other device. Two real phones in one room has not been run.

  UM.105

• Installing on a phone that has nothing Not yet

  The door that hands a phone the app from a code was built in a separate lane whose code is not in this tree, so nothing about it is claimed here. When it merges, its tests come with it and this line moves.

  UM.22 · not in this tree

• Anywhere but the home network Not yet

  That one person's two devices reach each other from different networks, that another person's device is refused with the error named, and that revoking a device cuts it off within one poll, has not been run. It needs a second machine away from this network.

  UM.09

• Our own relay, in our own hands Not yet

  When two devices cannot reach each other directly, traffic relays. The self hosted relay is written and its configuration validated, but nothing has been applied, so a third party relay is still in the path today. A relay sees encrypted traffic only, which makes this a question of who is in the path, not of who can read it.

  UM.08 · chapter 19

• Watching an actual video stream Not yet

  The host side pairs and starts a session. The client that turns that into a moving picture is not written, because which client we may use depends on a licence decision. On a real viewer today the request times out and records the timeout.

  UM.20 · chapter 17

• Waking a real machine Not yet

  No wake signal has been sent to a real network. Waking a machine that is fully off also needs a firmware setting on the target, which no software can set from the outside, and a machine on wireless usually cannot be woken from off at all.

  UM.23 · chapter 16

• Independent reproduction and a transparency log Not yet

  The early-access packages have published digests and the Android package is signed. Two independent machines have not yet reproduced the release byte for byte, and the product does not yet check a public transparency log before updating.

  UM.73, UG14 · release-build.sh, sbom.py · SHA256SUMS

• Coming back after a restart Not yet

  That every part returns by itself after a machine reboots has not been demonstrated. Absent, not assumed.

  UM.16

• Apple devices Not yet

  Nothing on iOS or macOS has been built or run. Beyond that there is a wall, described below, that no amount of work removes.

  chapter 6

• Windows Not yet

  A Windows build compiles, and that is all that is proven. The clipboard and background service pieces for Windows do not exist and the binary has never been run on Windows. The missing pieces answer with a typed not implemented, never a silent success.

  UM.15 · TestNotImplementedIsTyped

• Clipboard from a phone, in the background Not yet

  Android does not let an app in the background read the clipboard, and we will not pretend otherwise. Sending a copy from a phone is one deliberate tap, and always will be.

  chapter 12

What it cannot do

Refusals and walls, not to do items. The refusals are ours and will not change. The walls are decisions of the operating systems and the networks in between, and no amount of our work removes them.

Sources for this section: the manual's chapter 20, What this never does, and chapter 21, the threat model, each read from the platform's own documentation rather than from memory.

What we can see, and what we cannot

How to check any of this yourself

The point of a page like this is that you do not have to take it on trust. Here is what exists to check against, and what does not exist yet.

• The tests, by name. Every Built line names its tests. In the repository, go test ./internal/meshcore -run TestRingNeverTouchesTheMixer runs one; flutter test runs the app's. Each test's own header says what its paired negative is.
• The build record. Every item on this page names a workbook item, and every Live verified line names the daily record and the line. The record is written as the work happens, is only ever appended to, and carries the failures with the same weight as the wins.
• The product checks its own headers. tagii-mesh check go/internal/meshcore audits every file in the heart of the product against the standard it ships, and exits nonzero on a finding. The same command works on any folder of yours.
• The attacks page. What an attacker can try, and what happens: each answered attack names the test that proves the refusal, and the cases this design does not defend against are listed as such. attacks.html.
• The register beside this page. CLAIMS.md resolves every test name to its file, and the repository's own documentation check refuses a register that names a test or a file that is not there.
• The source, on a self hosted forge. Public repository, never GitHub and never a Microsoft service, licensed AGPL-3.0-or-later. Not yet The licence is decided; the public repository itself is not open yet.
• The release files and their digests. The Android and Linux downloads on this page are listed in SHA256SUMS. The Android package is signed. Independent byte-for-byte reproduction and a public transparency log are still unfinished. Partly finished
• Reading the source before you run it. The licence is decided, but the public self-hosted source repository is not open yet. That remains a real limitation of this early-access release.

Proof index

The same table is kept beside this page as CLAIMS.md, with the workbook item, the record and every test resolved to its file. Counts on 2026-09-09: 4 live verified, 32 built, 14 not yet, and 1 governance decision (the licence) that is not a proof state at all. 51 rows.