It works to repeatedly append to a file on one machine and `tail -f` it on another. Even an encrypted file. It just works.
As for collisions, a "conflict" is handled as you would expect on file syncing services, although all conflict resolution has to be done by the clients! (Even in the unencrypted public folders, the resolution of the conflict has to be signed. And in the encrypted case, obviously the server has no idea.) This is one of the many things that had made KBFS a large and interesting project.
If you really wanted to use KBFS as a transport layer, you could avoid the conflict entirely by each device claiming a file to write to, and each one in a folder can monitor the others' files.
> As for collisions, a "conflict" is handled as you would expect on file syncing services
I'm not sure what to expect though. Does it rename subsequent files by appending _##? Or does it overwrite? Or does it allow 2 files with identical filenames, like Google Drive (at least on the web) does?
Oh I see, sorry for not fully answering. Keybase does not merge files or anything source-control like that. In fact, if that's what you want, you can actually init a bare repo inside of Keybase and clone into and out of it. We do this all the time as we're dogfooding. It's cool that every push is signed automatically, and every pull or clone is verified.
The conflict resolution Keybase does do is simple and much like what Dropbox does. The clients will determine a winner, and the loser will be written as something like `Keybase Logo.conflicted (sjs382's imac5k copy 2016-02-04).psd` Note in this case 'imac5k' is a guaranteed unique device name for sjs382, due to the way our merkle tree of key announcements works.
By the way, the conflict resolution of a single file is one case in a fairly large list of possible conflicts. What happens if you remove a directory on one machine, but add a file to it on another? And so on. The conflict resolution flow is designed to protect you from data loss above all else.
As for collisions, a "conflict" is handled as you would expect on file syncing services, although all conflict resolution has to be done by the clients! (Even in the unencrypted public folders, the resolution of the conflict has to be signed. And in the encrypted case, obviously the server has no idea.) This is one of the many things that had made KBFS a large and interesting project.
If you really wanted to use KBFS as a transport layer, you could avoid the conflict entirely by each device claiming a file to write to, and each one in a folder can monitor the others' files.