18 ms·

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

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.
    - stupidcar 6y ago
      Your objections seem to be predicated on the assumption that the attempt to separate storage providers from application providers wouldn't be properly enforced. Yes, obviously if Alphabet can just set up Google Cloud Storage and Google Cloud Apps and continue with business as usual, then this won't work. But what I'm suggesting would be a functioning regulatory regime: An independent authority who classifies cloud providers as utilities, writes regulations specifying standards of interoperability, hears complaints from people and businesses and acts to enforce them. Antitrust regulation that stops collusion between service and application providers, and prevents companies or individuals owning a controlling stake in both. And the major difference I see in contrast to railways is digital infrastructure is not limited in they same way physical infrastructure is. So long as there's only one set of tracks, you can never have a functioning market running trains on them, and it's impossible to build a second set. But while the capital costs of setting up a new data centre are large, they are still within the realm of possibility for many large companies.
      - stickfigure 6y ago
        Any such regulatory regime would serve primarily to entrench incumbents by creating vast compliance requirements on newcomers. How's your <pick random> healthcare startup doing? You imagine a benevolent dictator making optimum choices. I think the F35 design/procurement process is a better metaphor.
    - wongarsu 6y ago
      With storage we already have "S3-compatible" as a widely implemented and supported standard. Just allow the user to set an arbitrary API endpoint for your regular S3 library and you support a breath of providers
throwaway316943 6y ago
We need NPT for software https://en.m.wikipedia.org/wiki/National_pipe_thread https://en.m.wikipedia.org/wiki/National_pipe_thread
- sly010 6y ago
  I don't know if this is a good example :) Anecdote: I recently wanted to extend the hoses for my tabletop dishwasher (the one that hooks up to your tap, not to the wall). It's 2 hoses with 2 connectors each, should be easy. But all 4 are different. After 3 trips to 3 different hardware stores, I found exactly 1 fitting that fits 1 (of the 4) connectors. I ended up slicing the existing hose and extending it in the middle, because that was easier than finding the right fittings. I thought about ordering them online, but that would assume I successfully identified them, which I didn't. Granted, I don't know anything about plumbing, but neither do the average person know anything about technology. That said, I agree, standards are necessary, I just wanted to rant about NPT.
- finiteseries 6y ago
  I genuinely cannot tell you how relieved I am this isn’t a link to the Treaty on the Non-Proliferation of Nuclear Weapons, the thought of FAANG cos “disarming” but snuffing out competitors with government approval is terrifying. https://datatransferproject.dev/ https://datatransferproject.dev/ from yesterday’s iCloud photos thread seems to be a step in this NPT direction though.
istjohn 6y ago
Even better: They have to use the storage provider of your choosing.
nickez 6y ago
We just have to do what the phone manufacturers did for the mobile phone connectivity. GSM was a huge hit thanks to interoperability.
- nimrody 6y ago
  It was but then deteriorated into a big patent war with every company trying to shove its proprietary patents into the next cellular standard. So while everyone can implement the standard, very few can do this profitably (In practice, Qualcomm, Mediatek and to some extent Samsung)
Vinnl 6y ago
There's been some of that already, not in the sense of governments forcing the separation, but in the sense of governments making the keeping of data a liability, e.g. with the EU's GDPR. There's certainly still a whole class of applications when owning the data is a competitive advantage, but there are also lots of organisation whose core competency is not selling data, even though they do have to work with user data. When storing data yourself is a risk, it becomes a lot more attractive to just let the user store that data somewhere themselves and have them give your application access to it. I'm sure this one of the reasons we're seeing a lot more interest from Europe than elsewhere in Solid [1]. Then of course, there are also lots of organisations struggling to maintain correct and up-to-date data. If multiple organisations access the same data as controlled by the user, the user is more likely to have kept that data up-to-date. (Disclaimer: views are my own.) [1] https://solidproject.org/ https://solidproject.org/
- 9dev 6y ago
  From a European perspective, it depends. I wouldn't ever even consider something like Auth0 to store our user records for example, due to the potential legal fallout of storing all our PII on American servers. You have to be really careful just what kind of storage provider you pick, where their servers are located and which specific regulation your business falls under. That being said, I'm a huge fan of splitting concerns - such as connecting anything and everything via OAuth delegations with narrowly scoped permissions!
deepstack 6y ago
>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. Same can be said about gmail. In the old days, one can access gmail via imap/pop3. I believe that was removed. All email ought to provide an alternative way of getting the email other than company's web interface.
- jimktrains2 6y ago
  I'm still using imap and smtp, unless k9 mail for Android is abstracting something else away?
- dmd 6y ago
  Why do you believe that? https://support.google.com/mail/answer/7126229?hl=en https://support.google.com/mail/answer/7126229?hl=en
  - throwaway135919 6y ago
    Probably because as described in the linked article IMAP & SMTP is disabled by default - though if you're willing to ignore the scary warnings they're still possible to use.
- Lex-2008 6y ago
  > In the old days, one can access gmail via imap/pop3 I believe it's still possible. Also IIRC it required some adjustments from mail clients to the "imap as gmail sees it" protocol, like "one message being visible in several folders", since "folders" in imap sense were mapped to "labels" in gmail
- deleted 6y ago
  [deleted]
- timw4mail 6y ago
  Gmail still allows imap access, although it requires an app-specific password. (Or it has to be allowed on the enterprise side with G-Suite)
visarga 6y ago
Separation of application and storage is a great idea! How about web search and social news feeds? Can there be a similar frontend / back-end separation for Google, FB and Twitter? I am thinking - different search front ends with different UIs, rankings and filters. We could have an EFF-Google and a Conservative-Google. Users could pick their preferred flavor, as I don't think it's fair for Google to decide for us all.
alanpearce 6y ago
remoteStorage[1] is already a thing. I don't think anyone's made a full Word-style document editor for it yet, though. [1]: https://remotestorage.io https://remotestorage.io
kjrose 6y ago
Well it can happen if a significant enough open source project establishes a protocol early enough and doesn't get co-opted. That or a consortium of companies agree on some sort of standard. (See the work on pc buses in the early pc days) But you are right. When companies run under trying to get as many users locked in as possible during a paid for investors period. This model is precisely the opposite outcome expected as the whole point is to build a moat around the sales model.
- api 6y ago
  For something to get traction, it has to have excellent UI and UX. So far open source hasn't been very successful at providing that since there is no economic model to finance the immense amount of work required for good UX.
  - edoceo 6y ago
    GitLab? Xfce?
  - nvrspyx 6y ago
    That view seems a little shoehorned because the parent comment specified "protocol", implying that it would be the connection between client and storage, thus not user-facing. Regardless, * Blender * Godot * Krita * GitLab * Olive * Firefox * Thunderbird * NextCloud * Amarok * Vital * and more The problem isn't an "economic model". The problem is that most open-source projects simply don't attract UI designers, UX researchers, and users because contribution flows are more technical or geared toward developers. UX research isn't "expensive" when referring to open-source projects because it predominantly requires people: designers, researchers, and users. The whole foundation of open-source is volunteerism.
    - Lammy 6y ago
      This view is the one that feels shoehorned. "Normies" (not pejorative) have no idea what a protocol is. They just want something that works and is convenient as possible. That's how we ended up at the $free+$surveillance App Store / modern Web model.
CyberRabbi 6y ago
I generally support the spirit of requiring cloud apps to provide equivalently powerful API access to their service. The (solvable) problem is how do you regulate this without stifling development of new cloud apps? Another more practical problem is how do you even get something like this on the agenda of a lawmaker? This isn’t a readily apparent problem to most people but it likely would result in less monopolistic outcomes for cloud providers and potentially better and/or more efficient products.
julienreszka 6y ago
We need not only separation of storage and UI but also labeling providers between the ui and the data so you can find your data easily.
polote 6y ago
> The competitive advantages of owning both the application and the data are so high Honestly this is wrong. Google drive has API for everything, Notion is working on an API, Confluence has API for everything, Trello ... Any serious text editor (and all the ones wrongly cited in the article) software has API for everything. Want to export your Confluence data to Notion ? you can. In the documentation tools space owning the data is not something looked for, because company pay for the service so the data belong to them BYOC can exists today, the only reason it doesn't. Is that the documents format is super complex and require complex editors. But the format themselves are not secret, the application is (and not even always, for example the Confluence editor is open source).
- draw_down 6y ago
  Look at what happened with Twitter and its third party clients. GP is correct. (I'm not saying it's good and I like it, I'm saying it makes sense)
- MichaelApproved 6y ago
  Those APIs are not meant for building a full blown dedicated clients, they’re for application integrations.
  - polote 6y ago
    Check that https://developers.google.com/docs/api/reference/rest/v1/documents https://developers.google.com/docs/api/reference/rest/v1/doc... You have the full specification of Google docs documents and API to edit any kind of blocks inside
    - MichaelApproved 6y ago
      First, that’s not the full spec for Google docs. It’s missing many aspects of the environment. Second, is that meant for building a full blown client or is it meant for 3rd party integrations, like plugins?
      - 6y ago
TheRealDunkirk 6y ago
> without government intervention Well that's the real trick, isn't it? </Han Solo> Our government is "captured" by campaign financing. Now we have 2 problems: ineffective governmental oversight, AND Citizens United. We have to solve the latter before we can ever solve the former.
rozab 6y ago
I think it's not completely inconceivable that this could be regulated some day with music streaming. There are zero technical hurdles (unlike with complex apps like Google docs), and because there is such potential for decoupling the client the consumer benefits would likely be much greater. I've been meaning to switch from Apple Music to Spotify for a while now (I'm on Android). I just had a look around the Spotify app today and the interface is terrible, it won't let me play and view my library like I want to. It would be so much easier if I could just use both from a single open source client, and then I wouldn't have to switch off to soundcloud and bandcamp for certain artists. Wouldn't it be in the interests of players like Google and Apple to create this service/protocol, even before the regulatory net starts closing in?
- moistbar 6y ago
  You should check out Spot[0]. It's a Spotify client written in Rust using GTK. It's quite barebones at the moment and only works with premium accounts, but the interface is much cleaner than the official Spotify client. [0] https://github.com/xou816/spot https://github.com/xou816/spot
  - Bishop_ 6y ago
    If a terminal is more your style you can even use Spotify-tui[0]. Requires some setup and having an additional client installed for the actual audio playback but it's still interesting using Spotify from a terminal. [0] https://github.com/Rigellute/spotify-tui https://github.com/Rigellute/spotify-tui
dec0dedab0de 6y ago
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. I think that is a bit much, I would much rather make reverse engineering/screen scraping/whatever for interoperability be 100% legal with zero grey area. Including a bit that says TOS/Eula/NDA/NonCompete/any contract can not give away this right. Edit: basically let asshole companies use technical means to try to stop us, but give them no legal recourse if we manage to get the cheese out of their trap.
- mindslight 6y ago
  We can split the difference by mandating that whatever storage services are provided via "webapps" must also be provided via a plain API. Users shouldn't have their data locked behind proprietary javascript. This would create zero additional burden, as every webapp needs such an API for the front end to talk to anyway.
  - IX-103 6y ago
    Maintaining a stable API surface is a burden. That said, I would agree with such a mandate, as the costs are probably worth it.
    - mindslight 6y ago
      It wouldn't have to be any more stable than what's already required to coordinate with the proprietary front end. A company would actually have an incentive to stabilize the API, to encourage cooperative use rather than migration. (And if a company starts churning their API in bad faith, that's exactly the kind of thing courts are meant to figure out)
    - lupire 6y ago
      Stable isn't required. Just let the users use the same API the client software (JS,mobile) uses, with password or key authentication. Free market will build clients. For security against social engineering, add some rigamarole around opting into API access.
simonebrunozzi 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. This.
3np 6y ago
OTOH, give it time. Open alternatives exist for every private walled garden. I believe the decentralization/federalization and FLOSS movements have a real chance, even if they move at 0.05 velocity. Private platforms are subject to closure, but the light of an open source project will shine as long as there's someone spending time on it. In due time we'll have networks of small providers catering for BYOC hosting. Cryptocurrencies can play a part in efficient and fair compensation. But then again, maybe by the time we catch up to current date, everything happens in walled VR moats. Maybe I'll be the oddball in the metaphorical cabin in the woods, but given the progress we're making so far I'll refuse to enter a closed VR/AR ecosystem.
- TimTheTinker 6y ago
  Maybe the best solution would be legislated government donations to open source projects, with a mandatory legislative bill each year on who they go to.
  - Shared404 6y ago
    > with a mandatory legislative bill each year on who they go to. Another option would be something similar to farm subsidies, although I don't know if that would be enough.
gklitt 6y ago
(post author here) While I agree that commercial incentives are critical to consider, two caveats I'd add: 1) I think the nature and depth of the incentives problem varies a lot by industry. Social media is a really complex case, for example. But I'm most interested in collaborative productivity tools, where I think many companies are okay being incentivized to build the best product rather than build data moats. 2) Cutthroat commercial incentives aren't the only thing that got us here. There are also tech barriers. If I was starting a Google Docs competitor today, even if I wanted to make it open, I think it would be hard to pull off. What kind of API would I expose to enable realtime editing with good offline mode and conflict resolution? How would I deal with clients that have slightly different rich text representations than my own? In an alternate universe where we already had a user-owned "web filesystem" with good answers to these questions, I could just hook up my client to that existing system and not even worry about persistence at all. It needs to be _easier_ for devs to build the right thing for users, not harder. And it needs to be a _better_ experience for end users, not a sacrifice. The convenient thing will win.
- toomim 6y ago
  Hey Geoffrey! We are building this in https://braid.org https://braid.org: a standard protocol and API for synchronizing state with realtime editing, conflict resolution, and a good offline mode. By building this into the web, we're creating the equivalent of a "web filesystem" as you put it, where every file (aka "resource") has full versioning, realtime updates, offline abilities, and merge resolution. I know you're aware of Braid, but I'm not sure you see how much our work is actually aligned. In fact my deepest personal motivation in creating Braid is to enable the "BYOC" vision — but I've been calling it a "separation of UI from state", where each user can choose their own interface to interact with the world. In today's web, the data owner controls the interface. But this means that they control how way too many people interact with the world, because we increasingly have to interact with the world through computers. The Braid abstraction makes it easier for developers to program with distributed state, and in the process also makes user-interfaces and back-ends interoperable, so that we can easily switch out different UIs for the same state.
deleted 6y ago
[deleted]
ryanmarsh 6y ago
don't see widespread BYOC ever happening without government intervention This is why people don't like nerds, it's like you actually want to fuck up this industry. The number of users that care about this is a rounding error. What you're talking about is increasing the complexity and flakiness of every product through modularization. Have you ever actually shipped a product for the general public?
tomxor 6y ago
I think the focus here is on the wrong thing, the "app", which makes ideas like legal intervention and other distractions feel relevant. I think client interchangeability and ultimately user freedom is fundamentally about data driven design, look at all the examples: text is text is text... git is a file based graph of merkle trees. They are both highly abstract, portable, unopinionated data structures that don't describe APIs, UI or implementation - don't like git CLI? you can literally write a completely different one with different porcelain and use the exact same git repos as everyone else, people have done this. Text is the same, it's just more obvious because so many examples exist. If you start with data and make it successful clients will emerge around it without the choice of making it interchangable. The problem with things like google docs isn't the app, it's the opaque data format. And then there are formats posing as being open and portable like DOCX which is essentially a proprietary microsoft format forced open due to reverse engineering - all of it's details will no doubt be closely coupled to the history of MS Word features and implementation.
- kortex 6y ago
  Exactly. But in this case that opaque data format is exactly the thing that enables live editing. Gdocs runs on Operational Transforms. There is basically no way to do OT without a ton of back end support which means tightly coupled APIs. Martin Kleppmann has a great talk on CRDTs for distributed text editing. It is a hard problem. You also need a dedicated binary format (basically a table) but at least in this case it is a lot easier to use an open format with federated clients.

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.
  - stupidcar 6y ago
    Your objections seem to be predicated on the assumption that the attempt to separate storage providers from application providers wouldn't be properly enforced. Yes, obviously if Alphabet can just set up Google Cloud Storage and Google Cloud Apps and continue with business as usual, then this won't work. But what I'm suggesting would be a functioning regulatory regime: An independent authority who classifies cloud providers as utilities, writes regulations specifying standards of interoperability, hears complaints from people and businesses and acts to enforce them. Antitrust regulation that stops collusion between service and application providers, and prevents companies or individuals owning a controlling stake in both. And the major difference I see in contrast to railways is digital infrastructure is not limited in they same way physical infrastructure is. So long as there's only one set of tracks, you can never have a functioning market running trains on them, and it's impossible to build a second set. But while the capital costs of setting up a new data centre are large, they are still within the realm of possibility for many large companies.
    - stickfigure 6y ago
      Any such regulatory regime would serve primarily to entrench incumbents by creating vast compliance requirements on newcomers. How's your <pick random> healthcare startup doing? You imagine a benevolent dictator making optimum choices. I think the F35 design/procurement process is a better metaphor.
  - wongarsu 6y ago
    With storage we already have "S3-compatible" as a widely implemented and supported standard. Just allow the user to set an arbitrary API endpoint for your regular S3 library and you support a breath of providers

throwaway316943 6y ago

We need NPT for software https://en.m.wikipedia.org/wiki/National_pipe_thread https://en.m.wikipedia.org/wiki/National_pipe_thread

sly010 6y ago
I don't know if this is a good example :) Anecdote: I recently wanted to extend the hoses for my tabletop dishwasher (the one that hooks up to your tap, not to the wall). It's 2 hoses with 2 connectors each, should be easy. But all 4 are different. After 3 trips to 3 different hardware stores, I found exactly 1 fitting that fits 1 (of the 4) connectors. I ended up slicing the existing hose and extending it in the middle, because that was easier than finding the right fittings. I thought about ordering them online, but that would assume I successfully identified them, which I didn't. Granted, I don't know anything about plumbing, but neither do the average person know anything about technology. That said, I agree, standards are necessary, I just wanted to rant about NPT.
finiteseries 6y ago
I genuinely cannot tell you how relieved I am this isn’t a link to the Treaty on the Non-Proliferation of Nuclear Weapons, the thought of FAANG cos “disarming” but snuffing out competitors with government approval is terrifying. https://datatransferproject.dev/ https://datatransferproject.dev/ from yesterday’s iCloud photos thread seems to be a step in this NPT direction though.

istjohn 6y ago

Even better: They have to use the storage provider of your choosing.

nickez 6y ago

We just have to do what the phone manufacturers did for the mobile phone connectivity. GSM was a huge hit thanks to interoperability.

nimrody 6y ago
It was but then deteriorated into a big patent war with every company trying to shove its proprietary patents into the next cellular standard. So while everyone can implement the standard, very few can do this profitably (In practice, Qualcomm, Mediatek and to some extent Samsung)

Vinnl 6y ago

There's been some of that already, not in the sense of governments forcing the separation, but in the sense of governments making the keeping of data a liability, e.g. with the EU's GDPR. There's certainly still a whole class of applications when owning the data is a competitive advantage, but there are also lots of organisation whose core competency is not selling data, even though they do have to work with user data. When storing data yourself is a risk, it becomes a lot more attractive to just let the user store that data somewhere themselves and have them give your application access to it. I'm sure this one of the reasons we're seeing a lot more interest from Europe than elsewhere in Solid [1]. Then of course, there are also lots of organisations struggling to maintain correct and up-to-date data. If multiple organisations access the same data as controlled by the user, the user is more likely to have kept that data up-to-date. (Disclaimer: views are my own.) [1] https://solidproject.org/ https://solidproject.org/

9dev 6y ago
From a European perspective, it depends. I wouldn't ever even consider something like Auth0 to store our user records for example, due to the potential legal fallout of storing all our PII on American servers. You have to be really careful just what kind of storage provider you pick, where their servers are located and which specific regulation your business falls under. That being said, I'm a huge fan of splitting concerns - such as connecting anything and everything via OAuth delegations with narrowly scoped permissions!

deepstack 6y ago

>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. Same can be said about gmail. In the old days, one can access gmail via imap/pop3. I believe that was removed. All email ought to provide an alternative way of getting the email other than company's web interface.

jimktrains2 6y ago
I'm still using imap and smtp, unless k9 mail for Android is abstracting something else away?
dmd 6y ago
Why do you believe that? https://support.google.com/mail/answer/7126229?hl=en https://support.google.com/mail/answer/7126229?hl=en
- throwaway135919 6y ago
  Probably because as described in the linked article IMAP & SMTP is disabled by default - though if you're willing to ignore the scary warnings they're still possible to use.
Lex-2008 6y ago
> In the old days, one can access gmail via imap/pop3 I believe it's still possible. Also IIRC it required some adjustments from mail clients to the "imap as gmail sees it" protocol, like "one message being visible in several folders", since "folders" in imap sense were mapped to "labels" in gmail
deleted 6y ago
[deleted]
timw4mail 6y ago
Gmail still allows imap access, although it requires an app-specific password. (Or it has to be allowed on the enterprise side with G-Suite)

visarga 6y ago

Separation of application and storage is a great idea! How about web search and social news feeds? Can there be a similar frontend / back-end separation for Google, FB and Twitter? I am thinking - different search front ends with different UIs, rankings and filters. We could have an EFF-Google and a Conservative-Google. Users could pick their preferred flavor, as I don't think it's fair for Google to decide for us all.

alanpearce 6y ago

remoteStorage[1] is already a thing. I don't think anyone's made a full Word-style document editor for it yet, though. [1]: https://remotestorage.io https://remotestorage.io

kjrose 6y ago

Well it can happen if a significant enough open source project establishes a protocol early enough and doesn't get co-opted. That or a consortium of companies agree on some sort of standard. (See the work on pc buses in the early pc days) But you are right. When companies run under trying to get as many users locked in as possible during a paid for investors period. This model is precisely the opposite outcome expected as the whole point is to build a moat around the sales model.

api 6y ago
For something to get traction, it has to have excellent UI and UX. So far open source hasn't been very successful at providing that since there is no economic model to finance the immense amount of work required for good UX.
- edoceo 6y ago
  GitLab? Xfce?
- nvrspyx 6y ago
  That view seems a little shoehorned because the parent comment specified "protocol", implying that it would be the connection between client and storage, thus not user-facing. Regardless, * Blender * Godot * Krita * GitLab * Olive * Firefox * Thunderbird * NextCloud * Amarok * Vital * and more The problem isn't an "economic model". The problem is that most open-source projects simply don't attract UI designers, UX researchers, and users because contribution flows are more technical or geared toward developers. UX research isn't "expensive" when referring to open-source projects because it predominantly requires people: designers, researchers, and users. The whole foundation of open-source is volunteerism.
  - Lammy 6y ago
    This view is the one that feels shoehorned. "Normies" (not pejorative) have no idea what a protocol is. They just want something that works and is convenient as possible. That's how we ended up at the $free+$surveillance App Store / modern Web model.

CyberRabbi 6y ago

I generally support the spirit of requiring cloud apps to provide equivalently powerful API access to their service. The (solvable) problem is how do you regulate this without stifling development of new cloud apps? Another more practical problem is how do you even get something like this on the agenda of a lawmaker? This isn’t a readily apparent problem to most people but it likely would result in less monopolistic outcomes for cloud providers and potentially better and/or more efficient products.

julienreszka 6y ago

We need not only separation of storage and UI but also labeling providers between the ui and the data so you can find your data easily.

polote 6y ago

> The competitive advantages of owning both the application and the data are so high Honestly this is wrong. Google drive has API for everything, Notion is working on an API, Confluence has API for everything, Trello ... Any serious text editor (and all the ones wrongly cited in the article) software has API for everything. Want to export your Confluence data to Notion ? you can. In the documentation tools space owning the data is not something looked for, because company pay for the service so the data belong to them BYOC can exists today, the only reason it doesn't. Is that the documents format is super complex and require complex editors. But the format themselves are not secret, the application is (and not even always, for example the Confluence editor is open source).

draw_down 6y ago
Look at what happened with Twitter and its third party clients. GP is correct. (I'm not saying it's good and I like it, I'm saying it makes sense)
MichaelApproved 6y ago
Those APIs are not meant for building a full blown dedicated clients, they’re for application integrations.
- polote 6y ago
  Check that https://developers.google.com/docs/api/reference/rest/v1/documents https://developers.google.com/docs/api/reference/rest/v1/doc... You have the full specification of Google docs documents and API to edit any kind of blocks inside
  - MichaelApproved 6y ago
    First, that’s not the full spec for Google docs. It’s missing many aspects of the environment. Second, is that meant for building a full blown client or is it meant for 3rd party integrations, like plugins?
    - 6y ago

TheRealDunkirk 6y ago

> without government intervention Well that's the real trick, isn't it? </Han Solo> Our government is "captured" by campaign financing. Now we have 2 problems: ineffective governmental oversight, AND Citizens United. We have to solve the latter before we can ever solve the former.

rozab 6y ago

I think it's not completely inconceivable that this could be regulated some day with music streaming. There are zero technical hurdles (unlike with complex apps like Google docs), and because there is such potential for decoupling the client the consumer benefits would likely be much greater. I've been meaning to switch from Apple Music to Spotify for a while now (I'm on Android). I just had a look around the Spotify app today and the interface is terrible, it won't let me play and view my library like I want to. It would be so much easier if I could just use both from a single open source client, and then I wouldn't have to switch off to soundcloud and bandcamp for certain artists. Wouldn't it be in the interests of players like Google and Apple to create this service/protocol, even before the regulatory net starts closing in?

moistbar 6y ago
You should check out Spot[0]. It's a Spotify client written in Rust using GTK. It's quite barebones at the moment and only works with premium accounts, but the interface is much cleaner than the official Spotify client. [0] https://github.com/xou816/spot https://github.com/xou816/spot
- Bishop_ 6y ago
  If a terminal is more your style you can even use Spotify-tui[0]. Requires some setup and having an additional client installed for the actual audio playback but it's still interesting using Spotify from a terminal. [0] https://github.com/Rigellute/spotify-tui https://github.com/Rigellute/spotify-tui

dec0dedab0de 6y ago

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. I think that is a bit much, I would much rather make reverse engineering/screen scraping/whatever for interoperability be 100% legal with zero grey area. Including a bit that says TOS/Eula/NDA/NonCompete/any contract can not give away this right. Edit: basically let asshole companies use technical means to try to stop us, but give them no legal recourse if we manage to get the cheese out of their trap.

mindslight 6y ago
We can split the difference by mandating that whatever storage services are provided via "webapps" must also be provided via a plain API. Users shouldn't have their data locked behind proprietary javascript. This would create zero additional burden, as every webapp needs such an API for the front end to talk to anyway.
- IX-103 6y ago
  Maintaining a stable API surface is a burden. That said, I would agree with such a mandate, as the costs are probably worth it.
  - mindslight 6y ago
    It wouldn't have to be any more stable than what's already required to coordinate with the proprietary front end. A company would actually have an incentive to stabilize the API, to encourage cooperative use rather than migration. (And if a company starts churning their API in bad faith, that's exactly the kind of thing courts are meant to figure out)
  - lupire 6y ago
    Stable isn't required. Just let the users use the same API the client software (JS,mobile) uses, with password or key authentication. Free market will build clients. For security against social engineering, add some rigamarole around opting into API access.

simonebrunozzi 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. This.

3np 6y ago

OTOH, give it time. Open alternatives exist for every private walled garden. I believe the decentralization/federalization and FLOSS movements have a real chance, even if they move at 0.05 velocity. Private platforms are subject to closure, but the light of an open source project will shine as long as there's someone spending time on it. In due time we'll have networks of small providers catering for BYOC hosting. Cryptocurrencies can play a part in efficient and fair compensation. But then again, maybe by the time we catch up to current date, everything happens in walled VR moats. Maybe I'll be the oddball in the metaphorical cabin in the woods, but given the progress we're making so far I'll refuse to enter a closed VR/AR ecosystem.

TimTheTinker 6y ago
Maybe the best solution would be legislated government donations to open source projects, with a mandatory legislative bill each year on who they go to.
- Shared404 6y ago
  > with a mandatory legislative bill each year on who they go to. Another option would be something similar to farm subsidies, although I don't know if that would be enough.

gklitt 6y ago

(post author here) While I agree that commercial incentives are critical to consider, two caveats I'd add: 1) I think the nature and depth of the incentives problem varies a lot by industry. Social media is a really complex case, for example. But I'm most interested in collaborative productivity tools, where I think many companies are okay being incentivized to build the best product rather than build data moats. 2) Cutthroat commercial incentives aren't the only thing that got us here. There are also tech barriers. If I was starting a Google Docs competitor today, even if I wanted to make it open, I think it would be hard to pull off. What kind of API would I expose to enable realtime editing with good offline mode and conflict resolution? How would I deal with clients that have slightly different rich text representations than my own? In an alternate universe where we already had a user-owned "web filesystem" with good answers to these questions, I could just hook up my client to that existing system and not even worry about persistence at all. It needs to be _easier_ for devs to build the right thing for users, not harder. And it needs to be a _better_ experience for end users, not a sacrifice. The convenient thing will win.

toomim 6y ago
Hey Geoffrey! We are building this in https://braid.org https://braid.org: a standard protocol and API for synchronizing state with realtime editing, conflict resolution, and a good offline mode. By building this into the web, we're creating the equivalent of a "web filesystem" as you put it, where every file (aka "resource") has full versioning, realtime updates, offline abilities, and merge resolution. I know you're aware of Braid, but I'm not sure you see how much our work is actually aligned. In fact my deepest personal motivation in creating Braid is to enable the "BYOC" vision — but I've been calling it a "separation of UI from state", where each user can choose their own interface to interact with the world. In today's web, the data owner controls the interface. But this means that they control how way too many people interact with the world, because we increasingly have to interact with the world through computers. The Braid abstraction makes it easier for developers to program with distributed state, and in the process also makes user-interfaces and back-ends interoperable, so that we can easily switch out different UIs for the same state.

deleted 6y ago

[deleted]

ryanmarsh 6y ago

don't see widespread BYOC ever happening without government intervention This is why people don't like nerds, it's like you actually want to fuck up this industry. The number of users that care about this is a rounding error. What you're talking about is increasing the complexity and flakiness of every product through modularization. Have you ever actually shipped a product for the general public?

tomxor 6y ago

I think the focus here is on the wrong thing, the "app", which makes ideas like legal intervention and other distractions feel relevant. I think client interchangeability and ultimately user freedom is fundamentally about data driven design, look at all the examples: text is text is text... git is a file based graph of merkle trees. They are both highly abstract, portable, unopinionated data structures that don't describe APIs, UI or implementation - don't like git CLI? you can literally write a completely different one with different porcelain and use the exact same git repos as everyone else, people have done this. Text is the same, it's just more obvious because so many examples exist. If you start with data and make it successful clients will emerge around it without the choice of making it interchangable. The problem with things like google docs isn't the app, it's the opaque data format. And then there are formats posing as being open and portable like DOCX which is essentially a proprietary microsoft format forced open due to reverse engineering - all of it's details will no doubt be closely coupled to the history of MS Word features and implementation.

kortex 6y ago
Exactly. But in this case that opaque data format is exactly the thing that enables live editing. Gdocs runs on Operational Transforms. There is basically no way to do OT without a ton of back end support which means tightly coupled APIs. Martin Kleppmann has a great talk on CRDTs for distributed text editing. It is a hard problem. You also need a dedicated binary format (basically a table) but at least in this case it is a lot easier to use an open format with federated clients.