Boundaries, stated plainly, so you can decide fast.
A session connects exactly two computers. A third machine that tries to join fails its handshake or gets connection refused; there is no room-full message, because there is no room for three. This is the current design: the two-peer case has provable no-silent-loss guarantees, and those guarantees do not extend to three writers with the same mechanism. Multi-peer support is research for a later release.
Two people per session still composes: A shares with B, and B can hold a separate session identity for C in a second instance. See Run two instances.
Dropbox-style tools replicate everything to every device, all the time. KeibiDrop streams: files appear immediately, and bytes move when read. That is the feature, and it has a flip side: when the peer is offline, content you never read is not on your disk. There is no background replication and no offline cache today (an offline cache mode is on the roadmap). If you need a local copy, pull it or copy it out of the mount while connected.
It is also not a backup tool. Nothing is versioned server-side, because there is no server holding your files.
Office file servers hand out locks so two people cannot write the same record at once. KeibiDrop has no cross-peer locks: a lock taken on one machine does not exist on the other. Simultaneous edits of one file are safe, the loser becomes a conflict file, but simultaneous use of one always-open database is not supported. Databases follow the hand-off pattern: one machine at a time.
Mobile is transfer-only: the same encryption, send and receive, no mounted folder. The Android app is available from the KeibiSoft F-Droid repository. The iOS app is in testing; a link appears here when it ships.
The positive statement of what KeibiDrop is: How KeibiDrop works. The engineering list of specific limits: Limits and known issues.