“Scan for nearby devices” sounds like a router console: press a button and the page lists every phone and computer in the house. A normal website does not receive that authority. It cannot silently sweep private IP addresses and probe ports across the LAN. Browser discovery has to work inside those privacy boundaries by making devices that are actively using the same service briefly visible to one another.
That limitation is useful. Discovery should reduce code entry, not build the most complete possible network map or reveal coworkers and strangers on a shared network.
Three meanings of discovery
Same-public-exit discovery uses short-lived server presence. Devices currently using uCopy through the same public network exit become candidates. It fits a home or small office, but one exit does not prove one trusted LAN. A corporate proxy, campus network, or carrier NAT may group many unrelated people.
WebRTC candidate discovery begins after two endpoints have met through signaling. The browser gathers network routes and tries direct connectivity; it answers “how can we reach each other?” rather than “who is nearby?” Native LAN discovery often relies on mDNS, operating-system nearby sharing, or an installed application. An ordinary web page has less access.
The end-to-end discovery loop
- Presence: the device opts in and registers an opaque ID, display name, and short-lived status.
- Visibility: eligible devices receive a minimal candidate summary—enough to recognize, not enough to expose IPs or a detailed fingerprint.
- Request: A selects B and sends one expiring connection request. Appearing in a list is not a connection.
- Consent: B sees A’s name and trust status, then accepts or rejects first contact.
- Authentication: after WebRTC connects, both endpoints verify device keys over the channel.
- Use: the workspace opens and the discovery request ends instead of producing repeated prompts.
- Expiry: missed presence heartbeats remove an offline device promptly.
- Stop: turning off discovery, stopping reconnect, or blocking a device survives a refresh.
Many broken scans return a correct first list and fail later. An offline device remains visible, a rejected request immediately returns, or a trusted device asks for first approval again after refresh. Testing must follow the candidate through exit and a later return.
Why another device does not appear
Confirm that discovery is enabled on both pages and both remain online. A phone on cellular and a laptop on Wi-Fi usually do not share an exit. VPNs, corporate proxies, and privacy relays change the exit address. Guest Wi-Fi or a second router may separate devices that are physically close.
Presence also has a timing window. Registration takes a short time to propagate, while an offline entry remains until its TTL expires. A refresh action should cancel an older scan, show when results were updated, and offer a temporary code after a timeout instead of encouraging endless polling.
Visible but unable to connect
Discovery proves only that signaling introduced two candidates. The next stages are receiver consent, ICE exchange, direct or TURN connectivity, and channel identity verification. A timeout should name the stage instead of removing the row and leaving both people to guess.
After B rejects, A should stop that attempt and enter a cooldown. If B missed a notification, one deliberate retry is reasonable; repeated background requests are not. If both people click Connect at once, merge the attempts into one handshake and use a deterministic role rule for the offer.
Reveal as little as possible
A candidate card normally needs a user-chosen device name, coarse device type, previous-trust status, and recent presence. It does not need private or public IPs, a full User-Agent, network-interface details, or a long-term activity trail. Default names should avoid automatically exposing a real name or corporate asset tag.
Analytics can count whether discovery returned a result, latency bucket, request outcome, and failure stage. They do not need the candidate list, raw device identifiers, or addresses. Short-lived hashed identifiers used for abuse control belong in restricted security logs rather than general product analytics.
Test the whole loop
Cover an empty list; a device appearing; disappearing after discovery is disabled; request and accept; request and reject; timeout; simultaneous requests; one refresh after connection; both sides refreshing; a block; a VPN changing the public exit; guest-network isolation; TURN fallback; and stale presence expiry.
For every scenario, assert both interfaces, notification counts, signaling requests, and the final number of peer connections. An API test that receives one candidate cannot catch duplicate notifications, ghost devices, or two competing connections—those failures happen after the API succeeded.
Discover a device in uCopy
Open the connection page on both devices and enable discovery. Verify the candidate name before sending a request. First contact requires approval; trusted recovery authenticates the device and tries to reconnect quietly. If the list remains empty or the networks differ, use a temporary code rather than repeatedly refreshing.
The best discovery view is not permanently busy. It finds the right device when needed, steps into the background after connection, and becomes quiet immediately when a person rejects or stops it.