48 ms·

Bring Your Own Client

• madeofpalk 6y ago
  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.
  • tobr 6y ago
    Has anyone tried to build real-time collaboration on git? What if every participant would run a system that saved on every keystroke, committed and synced with the remote? It would break due to conflicts as soon as two concurrent edits were too close to each other, but you could probably just accept either commit when they’re so granular and happening in real time. The conflict is going to be obvious and fairly easy to resolve since you will see it happen in the document itself. EDIT: For some reason, speculating about the potential to repurpose a technology is attracting replies that point out how it wouldn’t work seamlessly with how they are currently using it. I’m not even mentioning editing code, and I’m certainly not proposing that you try this in a random Git repo where other contributors aren’t expecting it.
    • vbsteven 6y ago
      This problem is what CRDT's are good for. I'm not sure if Git is the right tool to build this on top off.
      • tobr 6y ago
        My comment speculates about what it might be like to repurpose Git for this, so I hope it’s clear that I’m also not sure if it’s the right tool. CRDTs have the problem the article brings up, that they’re usually very specific to the data they’re modeling and need support from a very purpose-built editor. Git is supported by a lot of tooling and uses plain text which works everywhere.
        • ilaksh 6y ago
          True but how would you create a useful client without having access to a data format that is specific to the application?
    • okl 6y ago
      Keep in mind that a big part of working with a VCS is refining your code until it is done or ready to be merged. Syncing on every keystroke would drown others in noise and I'm usually not interested to see my colleagues' unpolished work-in-progress code.
    • pjc50 6y ago
      ... why would you want that? How would you ever run the program when it's broken on every keystroke?
    • luplex 6y ago
      I think that's close to what overleaf.com is doing for LaTeX.
      • tobr 6y ago
        That’s interesting. Their website mentions Git integration [1] but I don’t get the impression that their real-time editing is built on Git. Do you have a reference for that? 1: https://www.overleaf.com/learn/how-to/Using_Git_and_GitHub https://www.overleaf.com/learn/how-to/Using_Git_and_GitHub
    • pharke 6y ago
      Every time you modify a file in git you're actually creating a new file. Committing every keystroke would create a massive number of files that only differed by a single character. If you wanted to have a history of changes that can be shared and potentially merged then you would want deltas instead. A better underlying technology would be something like CouchDB https://docs.couchdb.org/en/stable/index.html https://docs.couchdb.org/en/stable/index.html
  • EuAndreh 6y ago
    That is false. See the built-in git-send-email [0] and git-am [1] commands. You may not like it, don't use it, etc. But Git does have collaboration tools. [0]: https://git-scm.com/docs/git-send-email https://git-scm.com/docs/git-send-email [1]: https://git-scm.com/docs/git-am https://git-scm.com/docs/git-am
    • madeofpalk 6y ago
      I meant in the sense how it was compared to google docs
  • jimbokun 6y ago
    It may be the case that the Git model is good enough for the way a lot of people want to collaborate, if combined with a nice UI. Maybe "save" tries to commit, and pulls up a diff interface if there is a conflict? UI indications of other people's commits pending, and maybe merge those with current state of the document if there is no conflict? There are a lot of edge cases to consider. But I feel like there might be a way to design UX for a Git workflow that makes it comfortable and intuitive to Muggles.
• blfr 6y ago
  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. There's more on this from 'moxie https://www.youtube.com/watch?v=Nj3YFprqAr8 https://www.youtube.com/watch?v=Nj3YFprqAr8 https://signal.org/blog/the-ecosystem-is-moving/ https://signal.org/blog/the-ecosystem-is-moving/
  • lifeisstillgood 6y ago
    tl;dr >>> So while it’s nice that I’m able to host my own email, that’s also the reason why my email isn’t end-to-end encrypted, and probably never will be. By contrast, WhatsApp was able to introduce end-to-end encryption to over a billion users with a single software update.
  • drjgk45839 6y ago
    >...Reddit replaced Usenet... According to Wikipedia, Reddit was created the same year Usenet service was discontinued by AOL. Reddit "replaced" Usenet in the same sense that cell phones "replaced" telegrams.
    • wizzwizz4 6y ago
      AOL's only contribution to Usenet was to fill it with people who didn't understand Usenet, all at once, almost completely eradicating the existing community. They discontinued the service when Usenet was no longer a selling point, because they had destroyed it.
    • Aeolun 6y ago
      Reddit also has tons of unofficial clients that interact with it. It’s not quite the same since you still don’t own the data, bit it comes close.
  • rapnie 6y ago
    > This idea suffers from the same problem federation does. Yes, this is a problem you also see with the Fediverse (based on W3C ActivityPub). You get innovators and laggers, and the latter when they are popular can hold the former back (you see this with Mastodon, which as early adopter created their own client API's, but are now lagging to implement the Client-to-Server part of the AP specification). At the same time standardization of federated protocols can also be an advantage in that it allows many different projects and applications [0] to be developed and mature independently. Innovation can come from unexpected corners here (heads up to openEngiadina with ERIS [1], DREAM [2] and Spritely [3] project). [0] https://git.feneas.org/feneas/fediverse/-/wikis/watchlist-for-activitypub-apps https://git.feneas.org/feneas/fediverse/-/wikis/watchlist-fo... [1] https://gitlab.com/openengiadina/eris/-/blob/main/doc/eris.adoc https://gitlab.com/openengiadina/eris/-/blob/main/doc/eris.a... [2] https://dream.public.cat/ https://dream.public.cat/ [3] https://spritelyproject.org https://spritelyproject.org
• bombcar 6y ago
  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. 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.
  • vbsteven 6y ago
    And this works both ways. Like the Postgres standard API you mention: Not only does it allow you to bring your own client, you can swap the underlying implementation and still use all the clients that speak the protocol. Like the author I would really like to see some open protocols (and adoption) for todo's and calendars. I mention adoption because for calendars there are some standards but popular software like Google Calendar and Exchange do not implement them properly or fully.
    • bombcar 6y ago
      Calendaring is a huge embarrassment and a mess, and it is super annoying if you have to deal with anyone “outside” your group. Emailed ical files seems to be the norm but only work over email. :(
      • SahAssar 6y ago
        Calendaring is surprisingly complex. Especially when it comes to stuff like rules for repeating events and timezones. I had to do work on this at a previous job and it was pretty hard even with all the libraries and tools out there.
        • bombcar 6y ago
          It's insanely complex - one of those problems that is easy to state and nearly impossible to solve (which means there's opportunity here).
          • 6y ago
• benjamir 6y ago
  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. 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.
• stupidcar 6y ago
  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. 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 can't just store the data opaquely on their own cloud servers. They legally have to integrate with a separate storage provider. And that storage provider has an obligation to make my data accessible and manageable by me. 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.
  • pjc50 6y ago
    Interesting proposal, but I see it greatly reducing development and also further entrenching the cloud providers as Lords Of Everything.
    • vages 6y ago
      I don't think that's true. In the areas in which "bring your own client" is the standard ("text editors / IDE, RSS readers, email clients, web browsers" to cite the article), there is a seemingly greater diversity in hosting than when it comes to the backends of the services mentioned. Yes, many of these _may_ use AWS in the end, but there is a great many of them that don't.
    • stupidcar 6y ago
      Can I ask why? As I see it, cloud providers are currently entrenched as Lords of Everything because they can both provide the infrastructure and the products that run on top of it. Making them act more like utility providers would reduce their power, I think.
      • pjc50 6y ago
        Think it through: > enforced separation in law between commercial application providers and storage providers. So, if someone writes an app like Google Docs, they can't just store the data opaquely on their own cloud servers. They legally have to integrate with a separate storage provider. Now, is the law going to mandate the exact API as well? The likely implementation of this is that, just as every app developer copies every other app developer, when choosing which User Storage Backend to integrate with, they will pick the most popular one, or a near competitor. AWS, Azure, or Google Cloud. (Apple-focused developers may choose Apple Cloud; I'd expect Facebook to spin up one if this became law too). Just as you don't get general-purpose OAuth integration so much as "log in with Facebook / Google" buttons. Those are your two choices. Yes, the original intent would be targeted at Google and Microsoft, which currently own both big web apps and big cloud platforms to run them on. I'm not convinced that splitting them vertically would stick; the convergence effects are very strong. So you end up with (choice of two office suites) x (choice of two backend providers), big deal. Is it sufficient that Google Cloud Storage would have a separate stock ticker from Google Cloud Apps? It reminds me of rail privatization and the nonsense of having thin shell companies run the trains while leasing all the rolling stock from a couple of companies and running on tracks owned by exactly one company. It didn't really expand choice and it provided plenty of opportunity for blame deflection.
• ghoshbishakh 6y ago
  I trust someone from the HN community will get started working on some of these :)
• asim 6y ago
  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 https://github.com/micro/services https://github.com/micro/services. Curious to hear what others think will happen.
  • carapace 6y ago
    FWIW, my $0.02: I think this problem has been noticed and solved over and over again. If you squint a little stuff like CORBA are in the same stew pot, eh? There's relatively recent work on collaborative editing and CRDTs, but as it says in the Wikipedia entry: > The first instance of a collaborative real-time editor was demonstrated by Douglas Engelbart in 1968, in The Mother of All Demos. Widely available implementations of the concept took decades to appear. https://en.wikipedia.org/wiki/Collaborative_real-time_editor#History_of_key_products https://en.wikipedia.org/wiki/Collaborative_real-time_editor... There are a lot of these protocol/API tools like gRPC, Thrift, Swagger/OpenAPI, or even good old ASN.1, eh? To me the question is how to drive convergence? How to alleviate https://xkcd.com/927/ https://xkcd.com/927/ ? (The "Standards" comic.) Who shall forge the "one true ring to bind them"? - - - - Also, I think Data Model catalogs (like "Data Model Patterns: A Metadata Map" by David C. Hay) should be part of the answer. Instead of rolling your own data models you should be able to just pull models from a standard catalog. - - - - In sum, if we're lucky, we'll start to get convergence in the protocol and model space. Anything that isn't working towards convergence is just adding another log to the burning pile of standards, eh?
• o_m 6y ago
  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.
  • tonyarkles 6y ago
    And Apollo, a wonderful alternative client for iOS.
• eric4smith 6y ago
  The main reason for using google docs is not it’s superlative editor... /sarcasm It’s the collaboration features. And no I don’t mean the multiple people typing the doc at the same time. It’s the ability to quickly share a document with a set of people that you want. 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. 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. Until we have some sharing infrastructure easy enough for a any client to sit on top of, it’s all a dream.
  • alexf95 6y ago
    I think your point is spot on and probably one of the bigger reasons why we won't see any change happening in the Google Docs department.
  • munificent 6y ago
    > It’s the ability to quickly share a document with a set of people that you want. In particular, it lets you do that while maintaining a single source of truth. It's equally easy to just email people a document. But then if you change the doc, they still have the old version. Maybe they forwarded it on to some other people you don't know about it after making some changes. The next thing you know, there are twenty versions of this file floating around all slightly different and everyone thinks they are on the same page.
  • asdff 6y ago
    What about emailing your brother the recipe? That's ultimately the sharing infrastructure Google docs sits on top of.
• deleted 6y ago
  [deleted]
• teekert 6y ago
  Nice thoughts, now please think of some nice pro "bring your own OS" arguments I can make towards my IT department ;) 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.
• GameOfKnowing 6y ago
  This article is basically describing the UNIX philosophy from a user-facing perspective, right?
• jasode 6y ago
  >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? 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. The issue is that a plain text file used for programming code is linear from top to bottom and so the low 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 opening the file for display is still just parsing CR/LF.) The complexity is higher for pdf/zip/xls because a common theme is each have a internal hashmap/dictionary/directory that has byte pointers backwards and forwards to other parts of the file. And they have internal hierarchies of data structures. 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. When I collaborate with others in MS Word/Excel, a best practice is to make sure everybody is using the same version of MS Office. 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. >Some successful existing examples of client ecosystems built around open standards: [...] email clients I'm not totally sold on this example. Yes, the open standard is SMTP for network communication... 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.
  • swiley 6y ago
    Maybe collaborate using markdown with stylesheets instead of word then. As for the mbox problem: on a normal machine that must be shared between multiple tools (at the very least: biff,lmptpd, and the MUA) if thunderbird can't interoperate that's a serious bug.
    • 6y ago
• lewisjoe 6y ago
  I work on a popular Google Docs alternative product in the market. 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. 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. This is one huge roadblock that I don't see any practical solution for.
  • diggan 6y ago
    Decentralized Identifiers are aimed to solve this, basically having interoperable identifiers you can use across different applications but still referring to the same user. Initial concept for DIDs were made for blockchains and other decentralized projects (I think, someone please correct me if I'm wrong) but useful for federation or for centralized projects that want to offer flexible data migration too. - Specification: https://www.w3.org/TR/did-core/ https://www.w3.org/TR/did-core/ - https://en.wikipedia.org/wiki/Decentralized_identifiers https://en.wikipedia.org/wiki/Decentralized_identifiers - One organization working on DIDs: https://identity.foundation/ https://identity.foundation/ - Project leveraging DIDs: https://sovrin.org/ https://sovrin.org/
  • thomastjeffery 6y ago
    Rich text is expressed with markup. The rest can be done with protocol. Just like clients would have to implement markup parsing and rich text rendering, they would need to implement protocol endpoints like notifications,etc.
• luplex 6y ago
  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. 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. We need to figure out that process of standardization and opening up.
  • tantalor 6y ago
    > situation like parents patents?
    • luplex 6y ago
      yes. patents :)
• throwaway316943 6y ago
  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.
  • carapace 6y ago
    Yup yup. I'm on the trail of just this using a purely functional Forth-like language called Joy. Your hunch is correct, you're intuiting the "Categorical" (as in Category Theory) nature of "point-free" format: http://conal.net/papers/compiling-to-categories/ http://conal.net/papers/compiling-to-categories/ > It is well-known that the simply typed lambda-calculus is modeled by any cartesian closed category (CCC). This correspondence suggests giving typed functional programs a variety of interpretations, each corresponding to a different category. ... This paper describes such an implementation and demonstrates its use for a variety of interpretations including hardware circuits, automatic differentiation, incremental computation, and interval analysis. ... The general technique appears to provide a compelling alternative to deeply embedded domain-specific languages.
    • ssivark 6y ago
      That Conal Elliot paper is being my current level, and I don’t see the relation to the comment about composability in Forth. Is there a simplified explanation somewhere? (Preferable less mathematical and more verbal, but I’ll take what I can get) Thanks.
      • carapace 6y ago
        I don't know if it's written up anywhere like that, sorry. The very brief section on mathematical purity of Joy in the Wikipedia article describes it but in (IMO) an unhelpful way: https://en.wikipedia.org/wiki/Joy_(programming_language)#Mathematical_purity https://en.wikipedia.org/wiki/Joy_(programming_language)#Mat... > In Joy, the meaning function is a homomorphism from the syntactic monoid onto the semantic monoid. That is, the syntactic relation of concatenation of symbols maps directly onto the semantic relation of composition of functions. It is a homomorphism rather than an isomorphism, because it is onto but not one-to-one; that is, no symbol has more than one meaning, but some sequences of symbols have the same meaning (e.g. "dup +" and "2 *"). > Joy is a concatenative programming language: "The concatenation of two programs denotes the composition of the functions denoted by the two programs".[2] [2] "Mathematical foundations of Joy" by Manfred von Thun https://web.archive.org/web/20111007025556/http://www.latrobe.edu.au/phimvt/joy/j02maf.html https://web.archive.org/web/20111007025556/http://www.latrob...
• alexf95 6y ago
  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.
• EGreg 6y ago
  It seems like local-first software is a good foundation for promoting Bring Your Own Client more broadly. 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: https://news.ycombinator.com/item?id=26356391 https://news.ycombinator.com/item?id=26356391
• harha 6y ago
  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. 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.
• anthk 6y ago
  On Google Docs, there were some CLI tools that today are deprecated. EDIT: not yet: https://coderwall.com/p/elfkaq/editing-google-docs-with-vim https://coderwall.com/p/elfkaq/editing-google-docs-with-vim The best setup would be: Wordgrinder/nvi+py3-markdown for Google Docs. Sc-IM+GNUplot opening Google Sheets. MagicPoint generating HTML files usable for Google Slides. Rclone for Drive.
• ilaksh 6y ago
  So maybe something like CRDT or OT on top of libp2p? Does something like that exist already?
  • jamil7 6y ago
    Not exactly that I know of but the automerge project is one of the more active open source CRDT spaces. https://github.com/automerge/hypermerge https://github.com/automerge/hypermerge for example
• pixelkritzel 6y ago
  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. https://prosemirror.net/examples/collab/#edit-Example https://prosemirror.net/examples/collab/#edit-Example
• rakoo 6y ago
  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. 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 (https://datatracker.ietf.org/doc/html/draft-toomim-httpbis-braid-http#section-4 https://datatracker.ietf.org/doc/html/draft-toomim-httpbis-b...) attempting to standardize state synchronization on top of which one can bring any client
  • falcolas 6y ago
    > I don't see Google Drive ever providing an API for bringing your own client In a way, they already have, since you can mount your Google drive on your local file system, and interact with the files from there. The problem lays with the proprietary Google Doc format.
    • xd1936 6y ago
      https://developers.google.com/docs/api https://developers.google.com/docs/api Most things you would want to do to a Google Doc are available via oAuth API, right?
      • falcolas 6y ago
        Not... really? I can't open it with a local application. At least, not until someone (not me, no time) creates a local application which interacts with Google Docs via this API.' In the mean time, I'll continue to use .docx, since Google docs can export and import form this format.
  • gklitt 6y ago
    Yes! I think Braid is a good effort in this area, will add to the prior art section.
• crails124 6y ago
  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? 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. 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.
• bitwize 6y ago
  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.
• imwillofficial 6y ago
  This article was pleasant to read. Well reasoned, well delivered, and timely.
• abbiya 6y ago
  I want to add Music services to the list
• ChrisMarshallNY 6y ago
  Really, a good API is all that is necessary. Also, maybe an SDK, but I am not particularly enthused by some of the SDKs I encounter, these days. 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.
  • asim 6y ago
    Can you elaborate. What kind of API? Just a HTTP/JSON api?
    • ChrisMarshallNY 6y ago
      I prefer a REST-like API, like Google uses for their services (basically, sending is done with "raw" GET/POST/PUT arguments, instead of blocks of JSON/XML), and Raw/JSON/XML responses. But realistically, some levels of functionality are so intense, you need a “beefier” API, like GraphQL. If that is the case, it might not be a bad idea to review the API. In my opinion, overcomplicated APIs are likely to be the result of the service, trying to exert too much control over the interaction/presentation. Many times, an API is a "back window" or partial view to a more ambitious effort. For example, if the project is a Web-based framework, it will have a lot of rendering and View/Controller functionality that may be of no interest to something like a specialized text editor for content maintenance, so there would be no reason to expose that functionality. It may be a good idea to provide a suite of APIs, as opposed to a single one.
  • kgwxd 6y ago
    For data-only applications. But if an application wants or needs to promise pixel-perfect results, at the very least, there would need to be a single standard rendering engine.
    • ChrisMarshallNY 6y ago
      I would suggest otherwise. One of the reasons that people choose differing clients, is because they have preferences in how they like the data/process represented. If it is necessary for a team to be "all on the same page," then the management needs to require that everyone use the same rendering client.
• zomglings 6y ago
  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. 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. 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.
  • Cthulhu_ 6y ago
    I think it makes sense to at least have the mindset from a developer's point of view. It helps prevent lock-in between the client and whatever APIs or storage your product uses. I've tried to build apps with a strict client / server separation for a decade now, it made sense at the time because of mobile apps, and it makes sense now due to application half-life (front-ends don't last as long as their back-ends). In my current project we may offer API access to our customers in addition to a user interface.
    • zomglings 6y ago
      Agreed - with the understanding that maintaining distinct clients is a LOT of work.
  • thomastjeffery 6y ago
    Most people just aren't familiar enough with the underlying idea. You can't express or even recognize a desire for your own client if you don't know what a client is. Because businesses focus on meeting users' desires instead of needs, they are content with the status quo of rigid UI/UX design. This is why we see BYOC so prevalent in developer tools like text editors and terminal emulators, but not in office tools like Google Docs or art/design tools like Photoshop and Maya. I've heard a million times or more the phrase, "industry standard" used to defend rigid proprietary tooling, even by users who would benefit from want sincerely enjoy more freedom in their tooling.
• folex 6y ago
  Background gradient makes me dizzy after reading a single paragraph
  • gklitt 6y ago
    (author here) sorry to hear that! Out of curiosity, what screen size are you reading on? Anyone else have similar problems? Sounds like I should add a button to disable the gradient.
    • bombcar 6y ago
      It might be that it goes left to right instead of top down.
    • berekuk 6y ago
      I'm having issues with this gradient too. (Though I'm running a fever after being vaccinated yesterday, so my perception might be different than usual today). It feels like that optical illusion with disappearing background [1] where your brain attempts to re-tune itself, and it's kind of uncomfortable. My screen width is 1280px. [1] https://knowyourmeme.com/photos/834411-optical-illusion https://knowyourmeme.com/photos/834411-optical-illusion
    • neurotrace 6y ago
      It's a cool idea but I wrote a userstyle to override it. Reading on a plain color is easier for me
      • gklitt 6y ago
        Thanks for the feedback everyone! Never realized it was causing problems. Will change or at least add an option.
    • folex 6y ago
      Hi! Sorry for the late reply. Here's a screenshot of my screen from the time of writing the comment https://i.imgur.com/ngD1Xkj.png https://i.imgur.com/ngD1Xkj.png I'm on a macbook pro 15.4-inch (2880 x 1800). I see you've changed background, thank you for that! <3 Now it is far far better. Though I still find myself having to try harder to read the text on such color. I'm not sure of the reasons, though. Maybe it's me, maybe it's f.lux. (though f.lux is on Movie Mode, meaning the dim and color correction are lighter than default) P.S. I do not know of and never experienced any color perception problems.
• vladmk 6y ago
  To work day?
• phren0logy 6y ago
  I'm in medicine, and I desperately want this model for electronic health records. The current state of lock-in has been effectively maintained by the entrenched players, and it's really bad.
  • wittyreference 6y ago
    Since HLX has become increasingly required, I've seen that the lock-in doesn't mean diddly squat. Now we're not "locked in", but for my new vendor to drop-in means I have to pay an extra "API Fee" for them to whip up the API interface to pull everything from the old EMR and into the new EMR. So either we get to the point where we are legislating perfect compatibility (and I can't imagine how good EMRs will get once the federal government has to outline every individual data field, and update them through, what, the rulemaking process?); or we'll always be paying up for this transition, and lock-in is beside the point.
    • phren0logy 6y ago
      Maybe we need a coalition of second-tier EMRs to band together and commit to supporting an API and a group to keep it open and updated? I agree that the current approach isn't really working, and doing more of the same is probably not going to help.
      • wittyreference 6y ago
        The problem, from my perspective, is that we're fighting the battle on two fronts: I need to get all my data from my old EMR into my new EMR, and I need my new EMR to slot in where my old EMR was with respect to feeding data to my data warehouse. Part of the difficulty there is the API, and part of it is that a bunch of shit is done as a black box in-EMR (e.g., my EMR will feed my warehouse some financial data, but my vendor is opaque as to how it's calculated). It's gotten to the point where I don't want a legal requirement to be HLX compatible: I want a legal requirement separating back-end data from front-end UI, so that we can shop for each of those independently. Once all the front-end shops (which are more valuable than back-end - as a healthcare org, I care about documentation and billing and error prevention) can't lock you in via data, I imagine there will be a fucking quick race to be the universally compatible back-end. And the back-end is ultimately the stuff that affects patients (portability of records) and loosen the bindings on provider organizations (because... portability of records). Which of course is why even things like HLX didn't really start working until major orgs like CMS and NYS Medicaid came along and said "you will find a way to be compatible with HLX voluntarily, or you will do it via regulation. One way or another it's going to happen within the next 12 months." (I was at a major conference where that was laid out pretty much that explicitly. It was wonderful.)
• indymike 6y ago
  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.
• greenie_beans 6y ago
  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.
• ndespres 6y ago
  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.
  • judge2020 6y ago
    Maybe you should suggest to your company to set up a bridge[0] to mirror it to something like irc. 0: https://github.com/42wim/matterbridge https://github.com/42wim/matterbridge
• awinter-py 6y ago
  msft's docx is only a documented open format bc the european union sued them in like 07 for antitrust fight for open file formats for common things
• jimbokun 6y ago
  > Today we generally think about BYOC at the “app” level. But can we go finer-grained than that, picking individual interface elements? Reminds me of this: https://en.wikipedia.org/wiki/OpenDoc https://en.wikipedia.org/wiki/OpenDoc
  • thomastjeffery 6y ago
    The only thing I've used that has gotten close to this is emacs. Even then, you have to fight the default ui/ux.
• intrasight 6y ago
  I'm a developer. Pretty much everything is a text file. Text files get edited with Emacs :)
• rullelito 6y ago
  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.
  • platz 6y ago
    He's at MIT in the Software Design Group, so his objective is to do blue-sky thinking for things that will never make sense economically.
• Fnoord 6y ago
  Open network and interface protocols. This was Sun's argument before they opened up Solaris and Java.
• derefr 6y ago
  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.) 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? 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?
  • deleted 6y ago
    [deleted]
  • TeMPOraL 6y ago
    > 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? They would. The verticals wouldn't. A service like Trello is at least two components - a storage layer for lightly connected lists of rich data, and UI for displaying/managing them. In a world where interoperability would be the norm, these two components would be two different markets. The user would be free to choose or buy the UI separately from the storage layer. Most would probably choose a vendor that provides both services, just out of convenience. The main difference would be that all these companies would operate on lower margins, and wouldn't support such insane valuations like our-world tech companies have these days.
• pbreit 6y ago
  Unirest is the BYOC that I was hoping would get traction: https://github.com/kong?q=unirest https://github.com/kong?q=unirest 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.
  • mmcdermott 6y ago
    I understand both sides of it. The thing is that most code bases that aren't using an official SDK will tend to wrap the raw HTTP calls in something that performs the relevant operations anyway. A good SDK cuts out a few classes/functions that would have been written anyway. Of course, that assumes that the SDK exists and is good.
  • granos 6y ago
    If the SDK in question is just a thin wrapper on REST then sure, it isn't providing very much value. But most of the SDKs I've used implement higher level logical operations -- things that require understanding the intent of the API/data model and how things are supposed to fit together. By being able to write my code against that higher level abstraction I'm able to save time and offload some of the responsibility for knowing how the pieces all fit together to the people who know that best. Ultimately my goal is not to make REST requests, it's to provide value to my customers, and the APIs I call are means to that end.
  • scottlamb 6y ago
    I think the problem described in this article is more fundamental: these services don't have documented, stable APIs for clients to build on. Not HTTP APIs. Not libraries either. In some cases they go out of their way to prevent third parties from using whatever internal API their own apps use. [edit to add: to combat abuse/spam, or because they have ads, or as deliberate lock-in.] But to answer your question: when an API exists, why have an SDK? One reason is to provide strong typing (and everything that goes with it, like IDE auto completion). A very thin layer over the HTTP requests is enough to provide this. Eg, in one of my projects [1] I wrapped a HTTP API with Go calls like this: Method(ctx context.Context, req *MethodRequest) (*MethodResponse, error) where each method call corresponds to exactly one HTTP request. It handles deadlines, cancellation, HTTP error checking, and using Go's built-in json marshalling/unmarshalling on structs. That's about all I want in an SDK. The unirest project you linked doesn't seem to offer strong typing so I wouldn't use it (even if it weren't dead). [1] https://github.com/scottlamb/luxor https://github.com/scottlamb/luxor
• uyt 6y ago
  I think no one wants to go through the work of creating a full featured client. What most people want is just adhoc customizability. 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. 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.
• deleted 6y ago
  [deleted]
• hntestacc 6y ago
  test comment blahlqjbwejlkblrq blahnmeqwflbeqlwblew blahkasjflkanweklqwbfkelbqlfbklqweblfkbq
• hntestacc 6y ago
  blah
• polote 6y ago
  > even if Google wanted to expose an API for editing Google Docs in third-party editors, it would probably be very challenging It does, https://developers.google.com/docs/api/reference/rest/v1/documents https://developers.google.com/docs/api/reference/rest/v1/doc... The reality is that building an editor for text is easy. Building a rich text editor is faaaaaaar from being a simple thing
• noir_lord 6y ago
  Small note: Trello has an excellent API - it is my goto example of a pleasant API to work with as an end user. 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.
  • brundolf 6y ago
    Part of the problem is that APIs are intrinsically harder to interop with than a local file format, for fundamental reasons like latency and shared state that others might modify from underneath you. You couldn't just read once at the beginning and then keep things in synchronous memory thereafter, persisting as needed but never reading again. Of course that doesn't mean the accessibility situation couldn't be improved with (for example) more standardized APIs, better documentation/discoverability, etc. iOS Shortcuts make it easy to work with third-party services; what would the equivalent in a real programming context look like? There's probably some interesting brainstorming to be done here.
• mandliya 6y ago
  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.
• amelius 6y ago
  I want BYOC for consuming social media.
• hirundo 6y ago
  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. What reads to some as worker exploitation is actually empowerment in practice.
• marmada 6y ago
  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.
  • karlicoss 6y ago
    Clients don't have to have exact same power. For example it would totally make sense to grep over a google doc represented as a plaintext file. Or at least traverse over the complex structure to extract some data, even if it's read only.
• dnissley 6y ago
  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. 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. 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. 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.
  • tshaddox 6y ago
    Tweetbot on iOS supports hiding images in tweets (but not hiding avatars). It costs a bit of money, but I have bought every version so far.
  • nsgi 6y ago
    Couldn't you accomplish that with a browser extension?
    • texasbigdata 6y ago
      I think OP maybe made a meta point about a (company/team/project) having carte blanche ability to, or perhaps restated to not give you the ability to restrict someone from, modify your initiative towards your existing end users (who may prefer your setup) in a way which threatens your survival. Extending the analogy to absurdium, should (CompanyX/Twitter) be allowed to have ToS against a (browser extension/etc) which would reduce it's revenue to $0, and theoretically force it to shut down and lay off all the (engineers/employees)? If no, what rights does Twitter have to decide alterations to it's product if any, and where do they begin? If yes, who makes that decision: a government, a regulatory body etc? What if the ToS said "don't circumvent our API rate limiting" and someone made a browser extension doing just that. Is it okay to have it in the Google chrome store? If it got in, should it stay up? Note, against my points, the Supreme Court decision on scraping in the LinkedIn case.
• nippoo 6y ago
  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...
• Andrew_nenakhov 6y ago
  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. Humanity really needs that.
• megous 6y ago
  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. 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. On this API you can easily create a fully featured 3rd party online shopping clients. Some shopping experiences these days are atrocious. 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.) Each new eshop you have to learn how to navigate it, and collecting information about the ToC and payment/delivery methods is a hassle. 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. 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.
  • Too 6y ago
    I think you forgot the API endpoints that will tell you how few items are left in stock and how many other users that are looking at this item right now. Not all stores would be sophisticated enough to implement such endpoint though but luckily it is easy to approximate in your client using stock=Random.nextInt(1,2) and users=Random.nextInt(50, 2000).
    • megous 6y ago
      heh, if those are gone, good riddance. :)
• grose 6y ago
  I went with the BYOC route for my current side project: https://inter.tube https://inter.tube It’s a music locker service with a custom web client. Instead of writing my own native app I implemented the Subsonic protocol: http://www.subsonic.org/pages/api.jsp http://www.subsonic.org/pages/api.jsp 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. 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.
  • loceng 6y ago
    Looks neat. Mind shooting me an email matt@engn.com?
    • grose 6y ago
      Thanks! Just sent one.
• markandrewj 6y ago
  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.
• vhanda 6y ago
  disclaimer: Markdown Notes App Author 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] [0] https://obsidian.md https://obsidian.md [1] https://zettlr.com/ https://zettlr.com/ [3] https://dendron.so/ https://dendron.so/ [4] https://foambubble.github.io/foam/ https://foambubble.github.io/foam/ [5] https://logseq.com/ https://logseq.com/ [6] https://gitjournal.io https://gitjournal.io 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)
• dgudkov 6y ago
  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.
• RcouF1uZ4gsC 6y ago
  >Today we generally think about BYOC at the “app” level. But can we go finer-grained than that, picking individual interface elements? 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.
• allenu 6y ago
  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. 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. 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.
• z0r 6y ago
  I'd love to be able to pay a music streaming service a monthly fee to play their catalog without having to use any of their first party software.
• hanspagel 6y ago
  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. 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. I really hope we all can leave the cloud behind soon. [1] https://hocuspocus.dev https://hocuspocus.dev
• godot 6y ago
  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. 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? 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.
  • HDMI_Cable 6y ago
    Notion basically is the client. Everything can be exported as .csv or markdown, so the only thing that notion provides are the nice database features and the UI.
• TimJRobinson 6y ago
  BYOC is why I'm so excited about decentralized social media. 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?
• w0de0 6y ago
  Isn’t this just a reinvention of the idea of Open Standards? 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. 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.
• SnowProblem 6y ago
  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.
• pvorb 6y ago
  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.
• deleted 6y ago
  [deleted]
• bo3OU 6y ago
  This reminds me of the solid project from Tim Berners-lee https://solid.mit.edu/ https://solid.mit.edu/ which i find very interesting
• voceboy521 6y ago
  this is stupid and you're stupid.