Markdown as a First Class Filetype
However, there are those of us who prefer something with Markdown as a first class document filetype, which could be seamlessly synchronized alongside other files, and edited with other editors. This is what the cloud editors do, after all, provide some level of editing of desktop-class documents, collaboratively, and those same files are generally available in the same binary format (via sync or import/export). Of course by Markdown we mean much more than the anemic initial (but no less necessary) initial Markdown spec. We like Markdown Extra as a more complete specification. With Dropbox Paper there is at least one additional feature from straightforward Markdown, the inclusion of images without having to know where they physically reside. Drag in and the image appears as a part of the document. This is similar to what Github does well with its Github-flavored Markdown. Clearly there is some kind of zip/archive file format behind the scenes, which we simply don't have access to, or perhaps a nasty rats nest of pointers in a database. The thing is, Paper doesn't have a public spec or source available. In other words, Paper documents only live in Paper, the Application (akin to Google Docs). This means Paper is not a first class filetype, and therein lies the rub.
Stable File Format is Key to Offline Sync, Editor Diversity
With its Office-in-the-Cloud, Microsoft actually preserves both the file format and allows a variety of editors (which is what preserving the file format enables). This in a superior way with Word and Excel documents, essentially round-tripping edits into synced files in the desktop or the cloud. Libre Office Online, Collabora CODE, and Collabora Online are similar to the Microsoft approach, with files not changing their basic structure. Of course one would expect Microsoft to take this approach of focus on file format, since it is what helped cement their leadership in editing applications. Own the format, own the tools. Google took a different approach (for scalability reasons, surely), and the ability to edit anywhere requires offline applications and the use of a browser (which means lock-in to the Google Suite editors). Dropbox Paper is less functional than Microsoft, Libre, and Google suites, but appears to be taking a Google approach, sad.
Scalability and the Requirements for State Management
A quick read of the EtherCalc story provide excellent insight into what it takes to maintain state in a connection-less multi-user environment. Essentially a copy of the document needs to be kept updated. That generally requires the same resources as on a workstation, and was likely a strong motivation for Google building from scratch simpler non-compatible file formats for Word and Excel documents, as well as a log of all change-sets (for version tracking). The same is said for the Pydio/LibreOffice Cloud offerings, namely that they take a bit of memory to get them to work, again due to the architectural requirements of real-time server-based state management.
Limitations of Paper as a First Class Editor
Since Dropbox already uses the Microsoft Online editors for Word and Excel documents (which work as advertised), Paper is a bit of an unwanted stepchild in terms of integration. Paper (which is both a file storage and a file editor, with web and mobile app versions) doesn't live within the Dropbox folder system, but rather has its own file system. This is awkward, for navigation, to say the least. Paper folders and files do not sync.
Offline Editing with Mobile, but not Web
With the IOS or Android App, Paper files can be edited offline, akin to Google Suite, but without the ability to do offline editing with the web app. Paper files can be exported in Markdown and Word document formats, but there is no ability to import Paper files, one has to copy/paste. This is trouble if someone has a lot of Markdown files already at hand. It seems clear that this use case is fairly well ignored.
Copy/Paste and AutoCorrect in Dropbox Paper
Mo' Paper, Mo' Problems
Intimated above is that what went wrong is a lack of open source of the file format that Dropbox Paper uses, which gives it severe technical limitations in terms of portability, offline editing, file synchronization, and a clear separation between interface and file format. This approach is one which Google has also embraced, and Google's moderate success in the face of such technical limitations should not be a signal of the weakness of such limitations. Rather one should look at the years and years of massive resources poured into the cloud editing project, which still cannot do proper offline file synchronization, and which has allowed Microsoft to compete effectively after a very long delay in entering the market with cloud editors.
Conclusion: Ignore Dropbox Paper
For the particular use case mentioned above, requiring file format and content integrity, file synchronization, diversity of editors, and the like, the solution is to simply ignore Dropbox Paper. The product is not for me or others with my same requirements. Fair enough. For our needs: - Dropbox for file synchronization - Stackedit version 5 for web-based editing (with access to the Dropbox file system) - Editorial for IOS is a great plain text editor supporting Markdown and Fountain (screenplay formatting), and also includes workflow scripting with python. There's a book on doing workflow with Editorial. - Atom editor Updated needs (18-Sep-2018): - Google Drive (Gsuite) + Insync for Linux - for files only, no online editors - Text - Chrome Extension, Excellent - Caret - Chrome Extension, Also Excellent - Atom editor - Native Application, Cross-Platform - Libre Office - Clunky but Functional