What KeibiDrop does not do, through 0.4.3. Stated plainly.
Connection limits
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 76% of 1957 pjdfstest cases on Linux and about 61% of 2058 on macOS. Most everyday operations pass. The failures cluster around links and permission edge cases.
.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.
Read-only shares, from 0.4.1
A read-only share is one directional. The peer reads and the origin refuses every write, delete, rename and attribute change arriving from it. Set up a second share for a return path.
mount_read_only on the reading side returns EROFS for writes. It is a local courtesy, and share_read_only on the origin is the enforced guarantee.
preserve_metadata applies the origin's permission bits, modification time and access time to the received file. Birth time crosses the wire and shows through the mount, though the copy on disk keeps its own. Change time is kernel-maintained everywhere and no tool can set it.
Serving reads from a read-only share leaves the origin's access times alone, using O_NOATIME on Linux and a handle sentinel on Windows. Reads of the received copy afterwards follow the local filesystem's own access-time policy.
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.
See the security model for what is and is not claimed about the cryptography.