The competitive advantages of owning both the application and the data are so high that don't see widespread BYOC ever happening without government intervention.<p>I'd like to see an enforced separation in law between commercial application providers and storage providers. So, if someone writes an app like Google Docs, they <i>can't</i> just store the data opaquely on their own cloud servers. They legally <i>have</i> to integrate with a separate storage provider. And that storage provider has an obligation to make my data accessible and manageable by me.<p>This wouldn't be a panacea, but it at least makes it theoretically possible to write a replacement client for Google Docs that could be a drop-in replacement.
This idea suffers from the same problem federation does. It's harder to move a whole ecosystem. Makes it harder to innovate. Leads to centralized platforms outperforming these BYOC/federated/open options. Basically how Reddit replaced Usenet with upvotes and basic spam filtering.<p>There's more on this from 'moxie<p><a href="https://www.youtube.com/watch?v=Nj3YFprqAr8" rel="nofollow">https://www.youtube.com/watch?v=Nj3YFprqAr8</a><p><a href="https://signal.org/blog/the-ecosystem-is-moving/" rel="nofollow">https://signal.org/blog/the-ecosystem-is-moving/</a>
This strikes at something that people often WANT when they say "text files are better than the registry/binary formats" - they want to easily bring their own tooling to bear.<p>Standard APIs let you do this - even if you have a "binary format" like MySQL or PostgreSQL (on disk) - nobody really complains about that because they have a defined API you can interact with.
> even if Google wanted to expose an API for editing Google Docs in third-party editors, it would probably be very challenging<p>It does, <a href="https://developers.google.com/docs/api/reference/rest/v1/documents" rel="nofollow">https://developers.google.com/docs/api/reference/rest/v1/doc...</a><p>The reality is that building an editor for text is easy. Building a rich text editor is faaaaaaar from being a simple thing
The problem (currently) is that most people simply don't care about being forced to use a particular client - as long as that client looks nice.<p>I say this with a lot of love for the idea. My company sells a collaborative knowledge base that supports Bringing Your Own Client. Out of the hundreds of users I have spoken to, only ONE has ever asked me if they could use their favorite markdown editor to access their knowledge base.<p>On the positive side of things, having the capability to bring your own client makes it really easy for us to support many different use cases. We just have to write those clients ourselves.
Immutability and mutability of content, and expectations or conventions surrounding it, seems to play a large role in feasibility here. The successful examples listed are generally cases where content is immutable to the general audience (someone produces content and then publishes it to others) or the way content is mutable is "understood" by the participants. That is, text editors mutate content, but no one expects there to be multiple editors of a text file, and the convention of a file is understood and encapsulates the "state" of the data.<p>In the wishful cases listed, collaboration is the norm, so to make it BYOC, you'd have to expose core "mutation" API or else use a general convention that is understood across the board.<p>In my dream world, we'd be use CRDTs for data and the "schema" of the data for a given "service" (say something like Google Docs) is open. The data storage layer would be a commodity and you can swap in different providers as you see fit. Of course, there is no benefit to the creators of such services to do this, and I don't think CRDTs are quite there yet with defining mutation efficiently with respect to multiple collaborators. However, from a data portability standpoint, it feels like the ideal to me.
The main reason for using google docs is not it’s superlative editor... /sarcasm<p>It’s the collaboration features. And no I don’t mean the multiple people typing the doc at the same time.<p>It’s the ability to quickly share a document with a set of people that you want.<p>Sure I use Vim every day, but without that git push and a trip to GitHub to invite collaborators I’m a man on a desert island waiting for that next weekly ferry.<p>Code editors and that ecosystem is good for code, but too slow for people who just want to share some recipes with their brother and not think about it too much.<p>Until we have some sharing infrastructure easy enough for a any client to sit on top of, it’s all a dream.
I've got lots of small tweaks I'd love to incorporate into a Twitter client. Unfortunately, I think many of them would violate the developer TOS.<p>For example: hiding avatars completely or generating replacement avatars using the username to remove any chance of internal bias associated with an account's avatar. Another one: hiding images by default and forcing you to click to expand/open to see them (no previews). A lot of these ideas are intending to modify Twitter's default salience landscape.<p>However disappointing it might be though that I can't do this, I get it. These kinds of modifications could totally change the ways in which a user experiences Twitter, and how Twitter would be able to monetize those users. Simply forcing Twitter (via legislation) to allow BYOC doesn't seem like a good idea because of this. It doesn't seem right to force them to run a service with a reduced potential for monetization -- e.g. many clients could just not show any ads, which would totally remove Twitter's ability to monetize at all.<p>An idea might be to charge users money in order to allow BYOC, so Twitter could focus on building out the core offering, which is just basically the public messaging substrate of the internet. But I'm not at all sure how well that would work out in practice.
<i>>What would it look like to have a thriving ecosystem of third-party clients for Google Docs style word processing, which can all interoperate with each other, even supporting realtime collaboration?</i><p>Well, based on decades of history of other complex file formats such as pdf, zip, and MS Office formats of doc, docx, xls, xlsx, etc... it would be a buggy mess. It didn't matter whether the format was reverse-engineered or an officially open specification.<p>The issue is that a plain text file used for programming code is <i>linear</i> from top to bottom and so the <i>low</i> complexity for universal editors is just parsing CR/LF to interpret lines. (Yes, there can be extra complexity of syntax highlighting but the base level complexity of <i>opening the file for display</i> is still just parsing CR/LF.)<p>The complexity is higher for pdf/zip/xls because a common theme is each have a <i>internal hashmap/dictionary/directory</i> that has byte pointers backwards and forwards to other parts of the file. And they have internal <i>hierarchies of data structures</i>. And changing from binary representation to XML such as Microsoft's OOXML doesn't change the base complexity which is why LibreOffice has constant bug reports from users unable to open their particular docx/xlsx file.<p>When I collaborate with others in MS Word/Excel, a best practice is to make sure <i>everybody is using the same version of MS Office</i>. If somebody is using MS Office 2007 while others are on Office 2013, a roundtrip save & open between different versions will eventually corrupt the file or lose data. Even staying with just one vendor like MS can get unreliable. The wild west has lots of utilities/libraries that write incorrect zip files and broken pdf files.<p><i>>Some successful existing examples of client ecosystems built around open standards:
[...] email clients </i><p>I'm not totally sold on this example. Yes, the open standard is SMTP for <i>network communication</i>... but there's another aspect that isn't standard: the on-disk file format for email archives. Microsoft Outlook uses binary PST files but Mozilla Thunderbird uses text-based MBOX files. But Mozilla's MBOX is slightly different from other tools that use MBOX.
I'm in medicine, and I desperately want this model for electronic health records.<p>The current state of lock-in has been effectively maintained by the entrenched players, and it's really bad.
Re: Notion, Trello, etc. — wouldn’t enabling interoperability on top of a presumably-free “open core”, completely commoditize these services? (As, for anything they offered on top of their open core, you could instead substitute a third-party service that does the same thing by operating against the service’s API.)<p>Which is to say — in a world where interoperability is a social norm or legal requirement, how would these services exist? (I would suspect they wouldn’t.) And, without them, would there be any money in advancing the state of the art in these verticals?<p>It’d be a lot like if there were a legal requirement for every drug to have a generic available from the start. Would there still be an incentive for drug research?
That's why I hate forums without a proper E-mail gateway -- for me plain text E-Mail is the most essential API between humans.
My mail client is the main reason and I really hate everyone changing something that disables using either my preferred editor.<p>Everytime some modern hype takes that from me I cannot stop thinking of goose fattening: forcefully stuffing it down the throat and not for good.
I feel Reddit is another thing that has "Bring your own client". I'm using the old design and Reddit Enhancement Suite to tweak it to whatever I want. Reddit also gives you everything as JSON if you just add ".json" behind any URL.
It's a situation like parents: There should be an incentive for a company to build a closed, innovative system. But once that system converges on features, and they reaped their rewards, it should be replaced by an open standard.<p>Instant messaging was fine, WhatsApp and Slack brought a lot of innovation and drove adoption, and I would argue it has gotten to a stable place where we should all use Matrix.<p>We need to figure out that process of standardization and opening up.
I work on a popular Google Docs alternative product in the market.<p>I gave some thoughts around this idea of experimenting a standard for collaborative rich text, that any client can implement. The problem though is that people want easy collaboration, more than the freedom to bring their own clients.<p>To simply put how can we deal with assigning people (for @mentions, comments, document ownership and content locking for a group of people) in such file formats? SaaS universe has a concept of a userbase with unique ids. So when a person is assigned/mentioned the product knows who is relevant and what to do. This implies we need a universal userbase standard (which is already hugely complicated) and is adopted by the SaaS that your target users belong to.<p>This is one huge roadblock that I don't see any practical solution for.
This applies well to the remote work environment. My employer makes no requirement about which editor or terminal or operating system or anything else we use to access their resources. The deliverables are (mostly code) files, and they just don't care what we use to manipulate those. They don't provide any hardware either.<p>What reads to some as worker exploitation is actually empowerment in practice.
I’m reading Thinking Forth at the moment and there’s a part in the description of Forth about how it decouples words from their parameters and return types by only allowing stack manipulation. This means that all words share a common interface and so they’re infinitely composable. The reason I started reading this book is due to learning how WebAssembly works which turns out to be quite similar to Forth. It got me thinking if there might be a way to make all code modules interoperable. Being able to compose an application or client out of many independent parts would be a dream come true.
BYOC for shopping online would be nice. Exchange formats for product aggregators sort of solve one part of the equation. But ordering is still an unsolved issue.<p>It shouldn't be that hard to do. You may need maybe 5 endpoints. Get all product data for the whole stock, get individual product images, get order requirements (can include terms and conditions, desired information for the order, payment options, human contact info, etc.), post an order, get order status.<p>On this API you can easily create a fully featured 3rd party online shopping clients. Some shopping experiences these days are atrocious.<p>Some hugely popular platforms have product lists hidden like 4 screens bellow the fold, separated by tons of crap, that just gets in the way. Category selection is placed such, so that categories slide away, when you get to the product list after selecting one of the categories, and if you want to switch category, you just have to scroll all the way up again. No options for selecting alternative views, like in a file manager (large icons with a ton of detail, list view, etc.)<p>Each new eshop you have to learn how to navigate it, and collecting information about the ToC and payment/delivery methods is a hassle.<p>Could be so much better if there was some simple web protocol for this, and it could be exposed in addition to existing website, too.<p>In the simplest implementation, everything but the POST could just be some static json files uploaded to the http server. And POST /order could just be sending an e-mail to someone.
I think a major omission from the authors' wishlist of BYOC-capable applications is chat. Maybe in their case they are lucky enough to have a choice in the matter, but I think overall the walled gardens and closed APIs for the major chat programs is a shame. Every day that I have to use Microsoft Teams in an attempt to communicate with coworkers is an exercise in patience. Basic chat functionality should be open and interoperable.
disclaimer: Markdown Notes App Author<p>At least for simpler text documents, where formatting isn't a big concern, markdown seems to be wining as the standard. Sure, each of these have added a few features on top of the markdown standard, but even those features are slowly getting quite standardized. [0][1][2][3][4][5][6]<p>[0] <a href="https://obsidian.md" rel="nofollow">https://obsidian.md</a><p>[1] <a href="https://zettlr.com/" rel="nofollow">https://zettlr.com/</a><p>[3] <a href="https://dendron.so/" rel="nofollow">https://dendron.so/</a><p>[4] <a href="https://foambubble.github.io/foam/" rel="nofollow">https://foambubble.github.io/foam/</a><p>[5] <a href="https://logseq.com/" rel="nofollow">https://logseq.com/</a><p>[6] <a href="https://gitjournal.io" rel="nofollow">https://gitjournal.io</a><p>I wish using Git as the VCS would also become more standardized, but we're still lacking good clients which hide the complexity [6] (my project, fails at hiding all of the complexity, but hopefully it'll get there)
I would like something like this but for banking logs. I got an alert from the bank about suspicious activity yesterday. The customer support rep couldn’t give me much information about it. I had to stop myself from asking if I could see the logs to determine myself whether it was a bug in their code or a real risk... I wondered if it was a bug because they had a similar buggy incident in the past.
Really, a good API is all that is necessary.<p>Also, maybe an SDK, but I am not particularly enthused by some of the SDKs I encounter, these days.<p>If a service can be exposed by a good, basic API that doesn't require (but also affords) an SDK, then this allows development of connectors. Many client packages, these days, are written to allow connectors to be developed.
There is a company called EditShare whose primary stock in trade is (or was, times do change) digital video server appliances. AVID sold such a thing, but it requires AVID software to work... and it turns out that film editors are about as persnickety about their choice of NLE software as programmers are about their text editor choice. So Alice may favor AVID, Bob likes Final Cut, and Claire uses Adobe Premiere. All three are competent editors and the director wants them all on the project. By using standard file sharing protocols like AppleTalk and SMB, the EditShare server lets them work on the same footage.
I don't see Google Drive ever providing an API for bringing your own client; it will probably have to be from the other side.<p>We already have OT and CRDTs for concurrently defining changes from each user and a way to merge them. There is also the Braid spec (<a href="https://datatracker.ietf.org/doc/html/draft-toomim-httpbis-braid-http#section-4" rel="nofollow">https://datatracker.ietf.org/doc/html/draft-toomim-httpbis-b...</a>) attempting to standardize state synchronization on top of which one can bring any client
Great read! Just wanted to chime in and say I’m working on a collaborative editing backend [1] based on Y.js, which already makes some of the things you write about possible.<p>For example interop between different editors, like CodeMirror and Monaco. And thanks to Y.js, the server helps with syncing, but isn’t the single source of truth anymore. It’s more like Git, where every copy has all changes.<p>I really hope we all can leave the cloud behind soon.<p>[1] <a href="https://hocuspocus.dev" rel="nofollow">https://hocuspocus.dev</a>
I went with the BYOC route for my current side project: <a href="https://inter.tube" rel="nofollow">https://inter.tube</a><p>It’s a music locker service with a custom web client. Instead of writing my own native app I implemented the Subsonic protocol: <a href="http://www.subsonic.org/pages/api.jsp" rel="nofollow">http://www.subsonic.org/pages/api.jsp</a><p>It’s awesome to have a polished native app for “free” (eg. play:Sub on iOS is really nice) but it’s such an underspecified and loose spec that implementing it was a huge pain in the ass. For example, clients will choke on results missing values that are specified to be optional in the spec. The spec imposes integer offsets for pagination but my database wants string continuation tokens. It’s specified as XML but there’s an option to make it JSON with zero information on how to deal with discrepancies. Some clients use GET, some POST, some mangle the URL or capitalize random paths. I just had to reverse engineer pre-existing servers to figure out what clients can handle and there’s still a few clients that are mysteriously broken. I’m going to have to test as many as possible and create a list of recommended ones.<p>I’m happy I went with BYOC but I highly recommend to plan for it from the start so you can deal with the protocol’s weaknesses sooner than later.
Isn’t this just a reinvention of the idea of Open Standards?<p>The fundamental problem is not that no one has formalized the idea, but that the baseline incentives for commercial software do not include optimization for interoperability.<p>For that we need standards bodies or other regulation - RFCs and the like. And, hacker news, we need line engineers to recognize when their produce is suboptimal by these standards, and why.
This isn't to detract from what the author has said, but Google Docs does have a public API now. I wanted to mention this because the public API is fairly new, and people may not know about it. I am not sure if the API is rich enough to achieve what the author is describing though. It's also not built on any kind of standard, like email, or other examples that are described.
Interesting premise, but some of the examples given as BYOC wishlist is a little weird to me. Google doc (the main example) makes sense, sure.<p>With others like Notion -- I recently started using Notion at a personal level and I feel like much of the draw about Notion is basically the UI (client). I don't use it to publish public pages or anything, only private notes. Most of its usefulness to me comes down to it having a really nice client and it syncs between desktop/mobile/etc. I don't know what Notion would be without the built in client. Simply a set of markdown files?<p>Other examples like Trello / Asana seem to already have solutions. They offer APIs, and while I haven't worked with them to know them extensively, my understanding is you can do basic CRUD operations on tickets. You could possibly build your own clients there.
Unirest is the BYOC that I was hoping would get traction:
<a href="https://github.com/kong?q=unirest" rel="nofollow">https://github.com/kong?q=unirest</a><p>I don't understand why each API needs it's own SDK. Or even why developers use SDKs instead of just calling the RESTful endpoints directly.
Nice thoughts, now please think of some nice pro "bring your own OS" arguments I can make towards my IT department ;)<p>Regarding BYOC, I guess Git is where it is at right now, not? Allthough I switch clients for my personal note-taking every now and the which works well with NextCloud syncing of MD files.
For the "todo list" item: check out Todo.txt and any number of the clients that use the same, human-readable/editable text-based format. I really enjoy being able to choose the client I want on my Mac, iPad and Android phone while keeping the same todo list file...
Small note: Trello has an <i>excellent</i> API - it is my goto example of a pleasant API to work with as an end user.<p>That means you can "bring your own client", I have a "todo today" list that I pull via the API and display via conky right on my desktop.
>Today we generally think about BYOC at the “app” level. But can we go finer-grained than that, picking individual interface elements?<p>Maybe will will end up re-inventing OLE from the 1990's for the web. In OLE 2, there was a standard OLE Compound Document file storage API/format. Different apps could all work with different parts of a document. You could even change which app you wanted to handle a certain type of feature. It was complicated, but when it worked, it was pretty neat. This was done during the time when most people had maybe 4-8MB of RAM. With much more powerful CPUs and vast amounts of RAM, we could probably come up with something even better.
There is an app called Twetch which is basically Twitter on the blockchain with money. Recently, I wanted to share someone's feed to a friend, but Twetch requires you to login, and that friend didn't have an account. I then remembered a third-party app called bitsurf.network that essentially served this role, and sent him that instead. Similarly, before Twetch had its search feature, a random developer had built one, because the data was available. So long as you are OK with limited privacy, these are pretty magical experiences compared to the status quo. I wonder if the incentives will allow it to last.
We had standardisation at the protocol level for the internet which let us build services on top, but now we're looking for the same at the app level. HTTP was meant for web pages, we never created anything for Apps and Services. What that new standard is going to look like, I have no idea, gRPC does well to define the APIs and so we use it across dozens of services here <a href="https://github.com/micro/services" rel="nofollow">https://github.com/micro/services</a>. Curious to hear what others think will happen.
I admire the thought here however as author himself pointed out this is an innovation killer in some way. I think then we need to separate what can be shipped with universal BYOC and what can’t. Any new innovation is build up on existing features. Extending it to heterogeneous clients will be neither cost effective nor innovation friendly. I work for MS office and shipping the same feature on online client vs win32 apps takes 1-2 quarter and sometime whole rewrite.
I think no one wants to go through the work of creating a full featured client. What most people want is just adhoc customizability.<p>For this reason, the web is great if you know how to code. Most sites are pretty easy to reverse-engineer so you can add whatever feature you want via extensions.<p>For example I do a lot of simple stuff with greasemonkey scripts like making stuff sortable or filterable, creating a bulk download and rename button, or just customizing appearances/css.
Another one is storing data, Apple for instance can easily lock in users with iCloud because it is so much more complicated keeping all devices and apps in sync without, with iCloud you have one login for passwords, browser, files, etc.<p>In theory a shared folder with clients that handle multiple devices/operating systems in their dot-files well would be able to replace that, but with most phones in a closed ecosystem, I don't see that happening.
On Google Docs, there were some CLI tools that today are deprecated.<p>EDIT: not yet:<p><a href="https://coderwall.com/p/elfkaq/editing-google-docs-with-vim" rel="nofollow">https://coderwall.com/p/elfkaq/editing-google-docs-with-vim</a><p>The best setup would be:<p>Wordgrinder/nvi+py3-markdown for Google Docs.<p>Sc-IM+GNUplot opening Google Sheets.<p>MagicPoint generating HTML files usable for Google Slides.<p>Rclone for Drive.
Prosemirror might be a good starting point for a headless collaborative rich text environment. It manages rich texts state and is collaborative out of the box.<p><a href="https://prosemirror.net/examples/collab/#edit-Example" rel="nofollow">https://prosemirror.net/examples/collab/#edit-Example</a>
Not having to ship your own client to every platform is the biggest selling point of web apps (or cloud apps). The border between app and client shifted to more low-level, but also more capable interfaces: HTTP, HTML, CSS, JS rather than single-purpose file formats like DOCX or PSD.
Most of these closed systems exist because of gaps in the open alternatives, and those gaps may be be difficult to close. For example, an open client for Google docs, which works fundamentally differently than say, a closed-source word processor that was written in the 90s.
> Today we generally think about BYOC at the “app” level. But can we go finer-grained than that, picking individual interface elements?<p>Reminds me of this:<p><a href="https://en.wikipedia.org/wiki/OpenDoc" rel="nofollow">https://en.wikipedia.org/wiki/OpenDoc</a>
Another great example of BYOC is SQL. Even despite popular relational databases have slightly different SQL dialects, it's still possible to use different clients to query/view/design/update a relational database.
The problem with BYOC client for Google docs / Figma is that the underlying data isn't simple plaintext, it's too complex, and the protocol requires things like operational transforms, so BYOC wouldn't make sense.
BYOC is why I'm so excited about decentralized social media.<p>I hate how we have to put up with whatever UI / algorithms each site gives us. Why can't we have access to the underlying data and choose how we wish to consume it?
What about options of importing and exporting files? For example Google Docs lets download your file in another format making it easy to open in another client e.g. MS Word. Wouldn't that be somewhat of a BYOC approach.
This reminds me of the solid project from Tim Berners-lee <a href="https://solid.mit.edu/" rel="nofollow">https://solid.mit.edu/</a> which i find very interesting
It does not suprise me that it's a kid proposing this. They probably live and breathe open source and still dream of a free and open world, where companies prioritize the user far above over profit.
All I want from office software is a clone of Google Docs that would be open source, self hosted, allow concurrent file editing and would use OpenDocument file standard for storing files.<p>Humanity really needs that.
msft's docx is only a documented open format bc the european union sued them in like 07 for antitrust<p>fight for open file formats for common things
<i>It seems like local-first software is a good foundation for promoting Bring Your Own Client more broadly.</i><p>It also goes hand in hand with end-to-end encryption. This sounds a lot like the Case I made for building Client-First web apps, I just posted it on HN:<p><a href="https://news.ycombinator.com/item?id=26356391" rel="nofollow">https://news.ycombinator.com/item?id=26356391</a>
I agree that you should choose your own clients. I think the examples provided beg a different question as to why it's not like this today?<p>PDF and DocX files are open specifications that provide for extension. Nothing is stopping anyone from building clients around these formats with the features listed in the article. PDF is definitely more common as most programming languages have comprehensive libraries to work with it.<p>The path forward would to be build the features you want and publish the extension specifications for others to use. Perhaps the interesting question however isn't technical possibility but if a market exists for it? Email clients were very widespread over a decade ago but have consolidated to 3-4 over the years. Hey.com has been the first big new email clients that I am aware of. I'm curious if it can prove there is big business in improving on existing, standardized specifications.
Git does not have colaboration tools. It's very much a "work in a silo for a period of time and then evtually figure out how to mash these things together" approach.