Changelog

What changed

Farview for the desktop, and the relay. Versions are YYYY.M.N: the Nth release of that month.

Download · the Android app's changes are on its Google Play page.

The desktop app

2026.10.11

• Areas: group a site’s cameras by room or place (“Ingresso”, “Giardino”…). The camera list shows each area as a section that can be folded, with “Altre” last for cameras in no area; the Aree button names, orders and deletes them (a deleted area’s cameras stay in the site), and the camera form has an Area field. Areas live in the site, so the phone and everyone the site is shared with see the same ones; read-only members see them and cannot change them.

2026.10.10

• Syncing no longer reverts or drops site data written by a newer Farview on another device: a field this version does not know now keeps the server’s copy, instead of the copy of whichever side edited a camera last. This prepares sites for camera areas, which come in a later version.

2026.10.9

• Day and night in the live view: for a camera that lets Farview switch its infrared-cut filter, a “Giorno e notte” card offers Automatico, Giorno and Notte (only what the camera supports), on the home network, through the relay or through the tunnel.
• A stream that the computer’s decoder refuses is restarted once re-encoded, instead of leaving a black picture; if that fails too, the view says so.
• This version carries relay 2026.10.8: the day and night route, and a log line for every notification decision.

2026.10.8

• The sync badge no longer stays on “Syncing…” for up to five minutes after a camera is saved or a sync is started by hand, and the Sync button is no longer disabled in the meantime.
• This version carries relay 2026.10.7: the video of a camera with privacy zones is sized to the camera’s own bitrate.

2026.10.7

• Privacy zones (Pro): in a camera’s settings, up to four areas of its picture that Farview never shows and never keeps. The relay that records the camera paints them black before anything else sees the video: in the live picture, in the recordings and in the pictures this computer keeps, and nothing moving there raises an event or a notification. Removing them is always allowed.
• A camera with privacy zones is watched only through its relay, on the home network or through the tunnel, never straight from the camera; when the relay cannot mask it the live screen says why and shows nothing. The zones are also drawn over the picture here, so recordings made before them are covered too.
• Pictures of a camera kept on this computer are deleted when its privacy zones change, on whichever device they were changed.
• This version carries relay 2026.10.6, which does the masking (detection pack 4, with x264).

2026.10.6

• A notification already shown through the tunnel is not shown again when you get home, and none appears after you switch notifications off or sign out. A summary (“and N more”) older than two minutes goes to the list quietly, like any other notice, instead of popping up.
• Saving a camera’s settings keeps the ignore zones drawn on another device since you opened them: only what you changed is written. “Apply to the other cameras” switches off the notifications of a class the new detection no longer looks for, as the Android app does.
• A tunnel the rendezvous refused is asked for again once, with a new permission, instead of failing until the old one expires; signing out closes it for good.
• The notifications ask the cloud once per check, not once per camera, and keep working when the cloud does not answer for a moment.
• This version carries relay 2026.10.5: push notifications to phones (2026.10.4), a phone with a key nobody can seal to no longer stops the others, and the notification limits survive a restart.

2026.10.5

• Detection says what it saw: people, animals, vehicles or movement, each with its own colour and icon. Live draws a box with a caption around what it sees, and says which classes are on and what is in the picture now.
• Recordings list the day’s events with how long they lasted, filter them by class from the legend, and chart the day’s activity in quarters of an hour above the timeline.
• Notifications (Pro, relay 2026.10.3): camera by camera, people by default, or animals, vehicles and movement alone. This computer shows them only once you switch them on in the Notifications panel, and only while the app runs; a click opens the recording a few seconds before the event.
• Vehicles can be detected, off unless a camera asks, and up to four areas of a camera’s picture can be ignored: draw them on its last picture in the camera’s settings.
• Live through the tunnel is smoother: the picture arrives every half second rather than in two-second lumps.
• A camera already streaming to as many viewers as it allows (a Tapo allows two, and a relay recording it is one of them) is said in those words, not as “Operation not permitted”.
• This version carries relay 2026.10.3.

2026.10.4

• A new look, the same as the Android app’s. A sidebar replaces the row of buttons at the top; the cameras are a grid of pictures, each showing the camera’s last live picture, kept on this computer only; Live and Recordings open as pages instead of windows over the list. Light or dark follows the system.
• Cameras move away from their network too, through the tunnel: arrows, zoom, home and the saved positions. A short click on an arrow moves the camera. The saved positions show a picture of their view, kept on this computer only. On a site shared with you, you can move its cameras if you can edit it.
• Every password field can be shown before you save it.
• The camera’s password no longer appears in the error shown when a stream does not open.
• Fixed: the app wrote the site back to the server on every sync even when nothing had changed.
• It still carries relay 2026.10.2.

2026.10.3

• Detection set once for a whole site. In a camera’s Detection section, “Apply to the other cameras” gives the site’s other recording cameras the same movement, people and animals, sensitivity and what to keep, when you save. Cameras that do not record are left as they are, and nothing else of the others’ recording settings changes.
• It still carries relay 2026.10.2.

2026.10.2

• It carries relay 2026.10.2. Detection on a camera with a low-bitrate stream is no longer interrupted every few seconds, and the relay no longer downloads its detection pack again each time it starts.

2026.10.1

• Detection, with Pro, on a camera that is recorded. The camera’s settings have a Detection section: keep everything or only what is around events, which of motion, people and animals to look for, and how sensitive. It is on only with Pro and with recording on, and the relay that records the camera does the looking; nothing it finds leaves your network except through the tunnel, to you.
• Boxes on the picture. The live view draws what the relay finds, over the video itself even when the window is not 16:9, and holds them for a moment so they do not flicker. They follow the picture on screen, which runs a few seconds behind the relay, not the data as it arrives, so a box stays on the person it belongs to. In a recording they are drawn the same way.
• The Recordings timeline marks events: motion, animals and people, the strongest on top. Click a mark to play from there.
• The recording file still being written can be played. The newest minutes of a camera were out of reach until the file closed; now the Recordings view plays up to the last complete fragment, asks for more before it runs out, and offers Live when playback reaches the end.
• Cameras that share one address (the channels of a recorder, two paths of one media server) get their own status, recordings and boxes through the tunnel, instead of the first camera’s.
• A ruler under the live picture: drag it back to watch the recordings from that moment, even the last two minutes still being written; Live brings you back. The wheel or a pinch zooms from ten minutes to a day, the arrows step by ten seconds, and a click on an event mark plays from it, with its boxes.
• The live picture could stay black: the start of the stream reached the window before the window was listening, and without it nothing after it plays. The window now asks for it once it is ready.
• Recordings land where you ask. The relay’s files carry the time of day in the video itself, which put seeking, the clock and the boxes off by hours and stopped a closed file after a couple of seconds; they are now read on that timeline.
• It carries relay 2026.10.1.

2026.9.8

• Recording on the relay, with Pro. A camera’s settings have a Recording section: the stream to keep, how many days, the sound, and your consent to give its username and password to the relays that record it — suggested: a camera user that can only watch. The section says which relay records the camera and which one stands by.
• A Recordings view: pick a camera and a day, see what exists on a timeline, and play it from any point — from the relay at home, or through the tunnel away from it.
• The relay’s panel shows its recordings disk: used, free, the free space it keeps, and each camera’s state.
• It carries relay 2026.9.8.

2026.9.7

• A relay is told the cameras of its own sites and no others. Before, a site this computer had never opened — created on the phone, or whose password was changed on another device — made its relay look unassigned, and the app sent it the primary site’s cameras.
• A site can have more than one relay. Each site’s settings list the account’s relays with a checkbox, the primary’s too, so a relay can be moved from one site to another.
• A camera can name the relay it goes through and, only if you choose one, a backup relay for when that one does not answer. The player says “relay di riserva” while it is in use. A plan limit never makes it switch: every relay would refuse the same way.
• Comes with relay 2026.9.5, which stops serving a camera as soon as its list no longer names it.

2026.9.6

• Signing out threw away an unsaved change in any site but the primary — or in a site shared with you to write — without a word. It now syncs them and, if something cannot reach the server, asks first, as it already did for the primary.
• A site’s “change password” now goes through the same queue as every other write. With the automatic sync landing at the wrong moment it could otherwise put the new password on an older copy of the site, and a change made moments earlier would vanish.
• Taking a site’s tunnel machine away left that machine receiving the primary site’s cameras. It now receives nothing: the cameras at home do not end up on a machine that sits somewhere else.
• The bundled relay is 2026.9.4.

2026.9.5

• Sites: an account can have more than one vault — “Home”, “Office” — and each one is a vault of its own, with its own password, its own cameras, its own tunnel machine and its own people. One site’s password never opens another. More than one site is part of Pro; the vault you have today stays the primary site and does not change.
• “Vault and sharing” becomes “Sites and sharing”: your sites, “New site”, and for each one its name, opening it with its password, changing that password, the people who reach it — to watch only, or also to edit — which machine the tunnel comes out of, “Start over” and “Delete site”. The primary site is never deleted: it can only be emptied.
• Cameras are grouped per site once you have more than one, or somebody shares one with you. With a single site the screen looks as it did.
• A site shared with you to read and write can now be edited here too, not only on the phone.
• Every relay is sent the cameras of the sites that name it as their tunnel machine.

2026.9.4

• Signing in is with Google or with a link by email, and nothing else: the passphrase no longer signs anybody in. The vault has a password of its own, which opens only the vault.
• The first time, you create the vault with its password, or open the one your phone made. A vault made by an earlier version opens with the passphrase it was made with, and is converted on the spot: from then on that password opens only the vault.
• Once opened, this computer remembers the session and the vault key in the system keychain, and opens straight onto the cameras at every launch. It stays in step with your phone on its own, every few minutes and whenever the window comes back to the front, and passes the changes on to your relays.
• Vault and sharing: what the vault is, changing its password, and — with Pro — the people you share it with, each able only to watch or also to edit. The vaults shared with you open here too, to watch; their password is not saved on this computer.
• Signing out takes the session, the key and the cameras off this computer; they stay in the vault. If a change has not reached the vault yet, it asks first.
• Google with a PIN on Drive is gone: once the vault password has been typed on a computer, it is not asked for again there.
• Deleting a camera, forgetting the relay and stopping the relay on this computer ask first, and Escape closes the player and the relay panel. The tray menu is in Italian.

2026.9.3

• The tunnel line in the relay panel follows the new fair use of half an hour a day per camera: the minutes each camera gets, the cameras used today out of those the plan allows, the open streams, this month’s traffic and when the day starts again, in local time. 2026.9.2 read “0.1 GiB of 0.0 GiB” there.
• The relay inside is 2026.9.3, which tells the Farview cloud its version.

2026.9.2

• The relay inside is 2026.9.2: farview-relay version prints its version, and a word the relay does not know is now an error naming it, instead of being ignored.

2026.9.1 — first public release

What it does

• Watch cameras with low latency, and pan, tilt and zoom the ones that move: hold the arrows, or jump to a saved position.
• Keep the same camera list as your phone, encrypted on this computer with a passphrase only you know, and synced through your Farview account.
• Open it with the passphrase, or with Google and a PIN once the key is on your Google Drive.
• Create the account by proving your address first, with Google or with a link by email, and then choosing the passphrase.
• Host the relay on this computer, so the cameras can be reached from outside the house without a second install.
• See which way the cameras are reachable from outside, and whether Plus works: the Farview cloud now tries to connect from the internet and says why not.
• Set up a phone by scanning a QR code, and adopt other machines by approving the code they show.
• Reach cameras through the tunnel when the line is behind carrier-grade NAT.
• Keep running in the tray with the window closed, and start with your computer, hidden, when it hosts the relay.
• Be told once per launch when a newer version is out.
• Run just the relay, with no window, with farview --headless.

Since the first builds

• Signing up proves your address before a passphrase can be set: an address alone no longer makes an account.
• Google sign-in works in the downloaded app, not only on the computer it was built on.
• The app talks to relays and services at /api/v1, and still to older relays.
• PTZ movement stops when you let go, close the window or lose the connection.

The relay

2026.10.8

• Day and night: POST /api/v1/cameras/{id}/daynight reads and sets a camera’s infrared-cut filter over ONVIF Imaging (auto, day, night), with the camera’s credentials in the request as for PTZ; nothing is kept. A camera without the control answers 422 no_daynight. Tapo C200 and C320WS do not offer it over ONVIF; other cameras do.
• Every notification decision is logged on one notice: line with decision= and reason=: issued, or skipped for the cooldown, the hourly cap, the camera’s settings or the plan; sent, or not sent because the cloud has no device for it, answered with an error or accepted none. Skips are logged once per camera, class and reason per window. Nothing secret is logged.

2026.10.7

• Privacy zones: the masked video is now sized to the camera. The encoder’s ceiling follows the bitrate the camera actually sends, measured over the last 30 seconds: 1.25 times it, at least 500 kbit/s and never above the ceiling for the picture’s height that applied until now. A Tapo C200 sending about 0.85 Mbit/s was recorded masked at about 29 MB every 2 minutes, against 13 MB without zones. Until there are 10 seconds of measurements the old ceiling applies; a masker that started on it restarts once, at a keyframe, when the measured ceiling is under three quarters of it.

2026.10.6

• Pins detection pack 4 (ffmpeg with x264, GPL; the helper takes up to 8 zones).
• Privacy zones: a camera can have areas of its picture that Farview never shows and never keeps. The relay that records the camera decodes the video, paints the zones solid black, encodes it again (x264, in the detection pack’s ffmpeg, pack 4) and records and serves only that. If it cannot (no pack, the encoder down, not the camera’s owner or standby) the camera is not recorded and its live picture is refused: nothing ever falls back to the camera’s own picture. The relay masks whatever the plan; creating zones is Pro, in the apps.
• The relay serves a privacy camera’s live picture itself, from an RTSP server inside the relay, on the camera’s own address through the tunnel and on its LAN listener (same credentials as the camera, up to 8 viewers). Those connections are never forwarded to the camera any more. The masker starts on demand and stops 30 s after the last viewer.
• The zones the relay holds are kept in privacy.json and applied at start-up, before the first roster: a relay that restarts without the internet keeps masking. A roster from an older app that leaves the zones out does not unmask the camera; only an explicit empty list does.
• The roster has a second list, privacyCameras, which a relay from before this never reads. A camera with recording off can still be masked and served (record.mode: "off").
• Detections inside a privacy zone are dropped (up to 8 zones now go to the helper: the ignore zones, then the privacy ones), so nothing there raises an event or a notification.
• GET /api/v1/recordings (and meta+ /status) gain a top-level privacy and, per camera, its masker’s state; GET /api/v1/cameras marks a privacy camera with "privacy": true. The pack is downloaded for a privacy camera this relay masks, whatever relay.json says about detection.

2026.10.5

• Push: a phone whose key cannot be sealed to no longer stops the notice for the phones after it in the list; it is skipped, and dropped from the list. Stopping the relay no longer waits up to half a minute for a cloud that does not answer.
• Notifications: the 5-minute pause per camera and class and the 30-an-hour limit now survive a restart, so a person still at the door is not announced again. A crash in the middle of writing a notice no longer costs the next one as well.

2026.10.4

• Push notifications (relay side): a notice that would be shown is also sealed on the relay for each phone the cloud names, so that only that phone can read it, and handed to the cloud to deliver. The cloud and Google see that a notice was sent, never what it says. A relay that is not adopted, or a cloud that does not do push yet, does nothing different.
• A camera’s notices go only to the phones of the people of its site (and to the relay owner’s); the relay-wide “and N more” goes to the owner’s phones only.

2026.10.3

• Notifications, without the cloud: the relay decides when something a camera saw is worth a notice — a person by default, and animals, vehicles or movement alone if the camera asks — and keeps the last seven days of them. At most one notice per camera and class every 5 minutes (15 for movement alone), at most 30 an hour, then one line saying how many more. The apps read them on the home network (GET /api/v1/notices, and a live stream) and away from home through the tunnel, camera by camera; never through the relay’s public API. A roster written by an app that does not know about notifications leaves them as they were.
• Vehicles and ignore zones (detection pack 3): a camera can look for vehicles, off unless it asks, and ignore up to four areas of its picture.
• A parked car is not an event every time something else moves: a vehicle is reported only once it has been seen moving.
• The end of a movement event says whether a person, animal or vehicle was there at the same time, so the apps can tell movement alone from movement that something explains.
• This release pins detection pack 3 (see detect/CHANGELOG.md).

2026.10.2

• The detection helper no longer makes the relay download its pack again after every restart. It now runs in its own directory next to the packs (detect/run), where what ONNX Runtime writes cannot make a pack look damaged; before, the relay logged “installed detection pack is damaged” at each start and fetched 18 MB again.
• This release pins detection pack 2 (see detect/CHANGELOG.md): the helper’s video decoder is no longer restarted every few seconds on a camera with a low-bitrate stream, and ONNX Runtime’s telemetry is off.

2026.10.1

• The relay can look for movement, people and animals in the cameras it records, and tell the apps where. It is part of Pro, like recording, and runs for a camera only while this relay is the one writing it. Nothing is added to the relay binary, which stays one static file: a helper process with its own ffmpeg, ONNX Runtime and a small model does the looking, in a pack the relay downloads the first time a camera needs it (about 15 MB; checked against sha256 values compiled into this release, and again before every start). The recorder feeds the helper the video it is already receiving, so a camera costs no second stream unless it is recorded on its main one and has a smaller one. Next to each recording the relay writes the boxes it found (<start>.det.jsonl) and, in each day’s directory, the events they add up to (events.jsonl); both go when the recording goes. This release pins detection pack 1 (see detect/CHANGELOG.md); a new pack reaches machines with the next relay release.
• A camera can be set to keep only what is around events: recordings over 24 hours old that overlap no event, and that detection watched all the way through, are deleted before their retention. Anything not known to be quiet keeps its retention, and when the plan stops allowing detection nothing is shortened any more.
• New read-only endpoints, behind the usual token and through the tunnel as meta+: GET /api/v1/cameras/{id}/events, GET /api/v1/cameras/{id}/segments/<start>/detections and GET /api/v1/cameras/{id}/detections/live (Server-Sent Events, with the boxes as they are found). GET /api/v1/recordings shows the pack, each camera’s retain and detect state with the reason when it does not run, and the segments list marks the recordings that have detections ("det": true). A meta+ session now lasts up to ten minutes, like rec+ (it was two), so that a live stream is worth opening. The meta+ cap grows with the plan: 3 sessions per viewer plus the plan’s streams, so that the live boxes of several cameras do not use up the ones the status and file lists need.
• relay.json gains detect (false is a veto: nothing downloaded, nothing run), detectDevice, detectThreads, detectMaxFps, detectDir, detectPackURL and detectPackFile. The Linux unit is unchanged for the CPU, with every hardening line (the helper was checked under MemoryDenyWriteExecute); a detectDir outside the state directory is added to ReadWritePaths= by relay service install, and on Windows the install makes %ProgramData%\Farview\detect writable by SYSTEM and Administrators only. relay service gpu on|off (Linux, as root) adds or removes the systemd drop-in a GPU will need.
• The control API’s logging wrapper no longer hides the connection from handlers that flush, which a live stream needs.
• The recording file that is still being written can be played. Files are now closed at the first keyframe after two minutes (they were one minute), and until now the newest stretch of every camera, up to those two minutes, could not be reached: a seek a little way back landed in live. The relay now lists the open file ("open": true, with the duration and size of its complete fragments) and serves it cut at its last complete fragment, so a player never receives half of one, never from the cache, and the same address keeps working when the file closes. The playlist includes it as its last entry.
• The recordings playlist lists each file as sub-segments of about 6 seconds, cut at fragment boundaries, with the time of each. A player that seeks into a file now fetches from the piece it lands in, not from the start of the file. A file the relay cannot read the fragments of is still listed whole.
• Cameras that share one host and port (the channels of a recorder, two paths of one media server) can be told apart through the tunnel: meta+ and rec+ requests take ?id=<camera id>, so each camera gets its own status, files and boxes instead of the first one’s.
• Found with cameras that behave like real ones: a camera that reboots or loses its network for a few seconds no longer leaves detection on the main stream for ten minutes once it is back, its smaller stream is reconnected; a camera that answers 401 without a challenge on the second stream is treated as refusing it, like any other refusal; a reconnection of the recorder’s session no longer makes detection think the picture is 0x0, which restarted the decoder and wrote an empty size in the file’s head; a camera that asks for detection on a relay with detect set to false is reported as disabled_on_relay, so the app can say why nothing happens; and a camera whose helper died is reported as starting, not running, while it waits to be restarted.

2026.9.8

• Which cameras to record, and which relay records them, comes from the account. A camera somebody chose to record — agreeing, in the same gesture, that its username and password go to the relay — is recorded by one relay of its site, the owner, with a second one standing by. The two find each other on the home network (UDP port 47086, multicast 239.255.70.86, every message signed with a key of the site, so a relay of another account is ignored): the standby starts after thirty seconds without news of the owner and stops at its next file once the owner is back, so the worst case is a short overlap and never a gap. The passwords reach only those two relays, and are never logged.

• Recording is part of Pro. The relay reads the account’s plan with every camera list and keeps the last yes for seven days while the cloud cannot be reached; told no, it stops at once, and what it recorded stays viewable at home until its retention removes it. The answer is kept in the service’s state directory, since its configuration directory is read-only.

• The relay can record the cameras it is given, to its own disk: an RTSP session per camera written as fragmented MP4, H.264 and H.265 as sent, audio only when asked, one fragment per GOP and a file per minute, under recordingsDir (new, in relay.json only; /var/lib/farview/recordings under the Linux service, beside the configuration otherwise). It keeps the disk’s free space above minFreePercent (15 by default) by deleting the oldest files of any camera, honours each camera’s retention and an optional maxRecordingGB, and pauses rather than fill the disk. A file left open by a crash is repaired at start. Read-only endpoints on the control API list what exists and serve it as HLS with byte ranges, and the tunnel reaches them for a known camera as meta+host:port and rec+host:port. The systemd unit gains StateDirectory=farview and a ReadWritePaths= for the recordings directory. Nothing records until the relay is told which cameras to record.

2026.9.7

• The tunnel can now reach a camera’s ONVIF service as well as its video, so a phone away from home can ask the camera which streams it has. Only the port the camera’s own discovery announced for its device service, on the camera’s own address: never another port of the same machine, never an address a camera’s announcement merely names, and nothing at all for a camera added by hand, which has no such address. The phone asks for it as onvif+host:port, a target of its own: the cloud does not count it as a camera of the day, as tunnel time or as one of the open streams, and the relay ends it after two minutes or thirty seconds of silence. The bare host:port of the ONVIF service is not a tunnel target. A relay from before this version refuses that target and the phone falls back to the stream path it already knew.

2026.9.6

• A phone away from home can ask this machine which cameras it found. The list — and only the list — now answers through the tunnel as well as on the machine’s own address, so the app can import cameras from a relay it cannot reach directly. What answers there is read-only: moving a camera, reading its profiles and changing the machine still need the machine’s own address and its token. Asking needs the tunnel in the account’s plan and does not count as one of the day’s cameras.

2026.9.5

• A camera the account’s list stops naming for this machine stops being served at the next read of the list, not at the next restart: one deleted, one moved to a relay of another site, or every camera when the machine is released from all its sites. Before, a relay moved from one site to another kept serving the first site’s cameras until somebody restarted it. The config file’s own cameras, and cameras discovery found that no list named, are never removed this way. A machine that reads the vault as well as the list keeps the old behaviour.

2026.9.4

• Discovery accepts an answer only when the address it declares is the one it came from. Before, anything on the camera network could have an arbitrary host registered as a camera — and that host got a public relay port of its own and became a legal tunnel target.
• One network error no longer costs a camera its relay: the accept loop retries with a growing pause instead of closing that port until the next restart. Each camera also takes at most 32 connections at once, and a connection idle for two minutes is closed.
• GET /api/v1/tls also answers a proof for the token the account published, not only for the one in the config file: an app that adopted this machine through pairing can now pin its certificate. Nothing changes for a client using the config file’s token.
• The README said the bearer token protects the relay ports too. It does not, and now it says so: only the camera’s own RTSP credentials stand in front of them, which is why they belong behind a firewall, a VPN or a tunnel, and why TLS matters.

2026.9.3

• The relay tells the Farview cloud which version it is, in the User-Agent of every request, as farview-relay/<version>. Before, most requests carried none.

2026.9.2

• farview-relay version prints the version. A word the relay does not know is now an error naming it, instead of being ignored while the relay started.

2026.9.1 — first public release

What it does

• Discovers ONVIF cameras on the local network using WS-Discovery and keeps the list updated.
• Relays each camera by opening an external TCP listener and transparently proxying bytes to the camera’s internal RTSP endpoint.
• Exposes a token-protected control API and status page, on port 8088 under /api/v1, for listing cameras, adding them by hand and moving PTZ cameras.
• Optionally wraps listeners in TLS, with support for providing your own certificate or letting the relay generate one of its own.
• Asks the router to forward its ports — UPnP first, then PCP, then NAT-PMP — to make the relay reachable from outside the home network.
• Checks reachability with STUN (is the line behind carrier-grade NAT?) and asks the Farview cloud to connect from outside, so it can say whether Plus will work — and why not.
• Joins your account with relay pair, approved from a phone, without the account passphrase ever being on the machine.
• Offers relay login to sign in directly on the machine with Google or email, then adopts itself and signs out.
• Installs as a system service with relay service install so it starts automatically on Linux, macOS, and Windows.
• Can reach cameras through the Farview tunnel when the line is behind carrier-grade NAT.
• Comes as Linux packages (.deb, .rpm, Arch) for machines with no desktop, and as a single binary for Windows and macOS.

Since the first builds

• The API moved under /api/v1; the old paths still answer, so older apps keep working.
• PTZ movement times out, so a camera stops moving if the connection drops.
• The relay makes its own TLS certificate when asked to and keeps it across restarts, so a phone that trusted it once goes on trusting it.
• The camera list can come from your account as a sealed roster, opened with a key that never leaves the machine, instead of a passphrase stored on it.