At some point Chris Coyne implemented a terminal chat UI on top of KBFS and `tail -f`. I can't remember if he published it anywhere though.

One of the reasons you don't want a real chat app to be implemented like this is that KBFS has to be pretty conservative about conflict resolution. If you and I both edit `foo.txt` at the same time, then we're going to wind up with something like `foo.txt` and `foo.txt_CONFLICTING_COPY_2020_02_14`. (Basically the same as what Dropbox does.) But of course, that's not what we want to happen if you and I send a message to each other at the same time. There, we want the server to just tell us which one came first, and that's fine. There's no real conflict. (For larger gaps, where my phone has observed your message before I send mine, Keybase will indeed sign over that observed history, and the server won't be able to reorder the messages.)

What if we push the abstraction? Folders in the FS represent recipients and files are the messages? Then if you and I send a message we don't have to worry about who edited some file last, rather, we inspect the time stamps of the file IOT render the messages in the correct order. We could even do arbitrary nesting/threading a la reddit if we wanted (treating writable files as folder descriptors as well, like Scrivener).

If I send you a message for the first time, your FS (nodes connected together) gets a request/ invitation to mount a new FS/folder containing files where each is a message. Want to add someone? Invite to mount the collective FS. Instantly the new member can see the chat history and begin writing new files/messages to the FS.

That all seems possible, but this honestly just seems like tons of effort for very little benefits compared to a rest api and a nice little data-store.