A session connects exactly two peers. A third machine cannot join: its handshake fails, or it gets a connection-refused error. There is no "room full" message.
Support for more than two peers is planned for a later release and is in the research stage.
Direct connections need IPv6 on both ends. Without it, traffic takes the bridge. See Network and ports.
The free relay tier allows about 3 connection attempts per 5 minutes.
In incognito mode, interrupted downloads do not resume after a disconnect. Resume is tied to the session identity, and incognito discards it. The download restarts from zero.
Filesystem behavior
Hard links are not supported. Creating one returns EPERM.
Symbolic links are not supported. Creating one returns EPERM.
POSIX compliance of the mount measures about 75.8% on the fstest suite. Most everyday operations pass; edge cases around links and permissions do not.
.DS_Store files write locally but do not sync to the peer.
Behavior for names that differ only in letter case is undefined across platforms. Do not keep File.txt and file.txt in the same shared folder.
Concurrent writing
There is no file locking between peers. A lock taken on one machine does not exist on the other.
Because of this, two machines must not run the same database on the shared folder at the same time. Hand the database over: stop it on one machine, remove its lock file, start it on the other.
SQLite works in turn-taking use. WAL mode fails on Linux FUSE with a disk I/O error; rollback-journal mode works on all platforms.
Databases that write through mmap (for example LMDB) are not supported for shared use on the mount.
macOS: by default, a peer's in-place edit that does not change the file size is not shown live. It appears at the next size change. The live_collab setting flips this tradeoff, at the cost of mmap-write safety (git's index). Details in the configuration reference. Linux and Windows handle both cases without a setting.
Windows: the mount point must not already exist, and binaries are unsigned. See Platform support.
Open items
No offline cache: files stream from the peer. When the peer is offline, bytes you never read are not available. Cached data of interrupted downloads resumes when the peer returns.
No end-of-transfer checksum verification yet. It is a planned item.
No independent security audit yet. See the security model for what is and is not claimed.