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.
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.
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.
Maintaining a stable API surface is a burden.
That said, I would agree with such a mandate, as the costs are probably worth it.
I'd like to see cold storage providers split from app providers.
Strict enforcement policy on cold storage data warehouses. And sensible policy for the app providers, like not caching PII.
Implement and enforce at the fed level using this division in a manner that is something akin to Glass-Steagall.
Owning data should not be something providers can ever exploit.
[edit]: I also think this could be used as a means to break apart Big Tech
(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.
Hey Geoffrey! We are building this in 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.
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.
One of the better examples still seeing widespread mainstream use is email, and this even applies to multiple stages throughout the email ecosystem: sending mail, receiving mail, managing mailboxes. Imagine if email wasn't cross provider compatible
The surviving open protocols are like libraries: they were created before the space got commercialized. They got grandfathered in. If libraries didn't exist for centuries already, there is no way they could have been created under current intellectual property laws and IP economy. Similarly, new open protocols don't generally gain widespread adoption - and in the rare case they do, that's only because some companies are using them to gain adoption; once those companies gain the market share they want, they switch to proprietary protocols and the open one dies. See e.g. Google and XMPP or RSS.
Email is only useful because it is cross platform compatible. Otherwise, weād all be back to writing to some friends in AOL, others in MSN, maybe some back in Compuserve. Some people like to send messages only in Facebook and others via Twitter DMs. None of these are/were interoperable which is why they arenāt ubiquitously used.
Email is only useful because each server can send and receive with other servers.
But we all know this, so what the point here?
I would say that my point is that if interoperability becomes more useful than the walled garden approach, then we will see something like this posts call for BYO client. Email is an example. We have interoperable email because it is was more useful than service specific inboxes.
Until interoperability is necessary for Word, we wonāt see an opening for other Word āclientsā.
Aside: you could argue that Google built Gmail to make a dent in the ubiquity that was Exchange for corporate messaging. It exploited the openness/interoperability of email in order to do this. If you accept that argument, then maybe they should take a page from that playbook and work to make Google Docs as open as possible. Allow for more interaction with external clients. Let a more open ecosystem develop. That might have the potential to diminish the position of Office for document creation.
Or maybe email is just so old, the owners got established before it could be commercialized... it might happen again, but Iām not hopeful. For example, I donāt expect Twitter to care about federating their system with other messaging applications. There is too much to be gained (selling ads) by keeping people on their site.
Absolutely, however a major problem occurs, and email is a great example of this. When there is a fundamental need to change the protocol for reasons of privacy, security, authentication, etc. It becomes almost impossible to do when it is as wide spread as email, or it takes a very very long time to spread enough.
When one person controls the whole system, it's easy to pivot rapidly. I guess that's another argument against having widely used protocols (even though I disagree with it.)
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.
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.
I posited a similar point to a former colleague (mine was more about eventual market dominance due to excellent UI+UX), and he came back with Craigslist as a perfect example of a product that gained a massive user base well into an era where its UI felt very outdated. A few years after this exchange, I feel more like I was right about my point: FB Marketplace has almost completely taken over as far as a classified product marketplace, but the point still stands that Craigslist was able to do a ton with very lackluster UI+UX
UX is a trojan horse, now everything has to be mobile friendly for absolutely no bloody reason. You know what also works on mobile? Zooming, yes you heard me.
Just the other day I had someone, an old person, complain about how a "revamp" of an internet banking site. They rewrote their functional, working UI, with a site that was designed by "UX designers", and you know how he phrased his opinion of the new site? "They made the site for stupid people".
GitLab? Xfce?
> 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.
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
Can you imagine a world where you could only use a specific phone model with a specific operator? or where you could only send text messages to people that is on the same network? If we can regulate phones we should be able to regulate social networks.
When the iPhone originally came out in the US it was locked together with a 2 year contract with AT&T.
(Deleted my identical but less detailed comment)
Then again, this was never the case in the EU, where bundling handsets with a GSM subscription was banned.
But yes, we donāt have to imagine - and the change certainly didnāt come out of the goodness of the carrierās hearts!
And it took how long for people to figure out how to unlock it?
> Reddit replaced Usenet
Many things replaced Usenet. Usenet is more of a protocol (that uses NNTP) than a social media platform. If you're any way a systems thinker, you would know that protocols are more resilient than services.
NNTP is basically dead, maybe abused* for piracy in some corner of the Internet, while Reddit ate half of the web that Facebook didn't eat.
* To be clear, I'm rather ok with piracy. NNTP is just really poorly suited for it.
ā If you're any way a systems thinker, you would know that protocols are more resilient than services.ā This is not just a terrible saying, itās also completely wrong. All things are not equal, so a crappy protocol may or may not be more resilient than a service. āSystems thinkingā is not code for āLazy thinking.ā
When making the point that protocols are more resilient than services, consider including an example of a protocol that has at least .0001 as many users as Reddit does.
It's also not the _same_ users, which may not matter but probably does.
> Leads to centralized platforms outperforming these BYOC/federated/open options. Basically how Reddit replaced Usenet with upvotes and basic spam filtering.
That is a nice insight.
> 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-fo...
[1] https://gitlab.com/openengiadina/eris/-/blob/main/doc/eris.a...
The C2S part of ActivityPub isn't for everyone, and it's okay. It basically moves too much logic to the client. It prevents any semblance of a good UX because you have everything ā posts you would display in the feed, interactions with your content, etc ā in the same inbox. You have to connect to many different domains to render something to the user, and you also have to have a sophisticated caching system on the client. Also good luck loading those full-size images over an EDGE connection.
There are 2 kinds of ActivityPub servers.
- The "dumb" one, that does minimal processing and simply stores JSON objects. Someone POSTs an activity to its inbox, the server does minimal required verification, stores it, and the client then queries it with GET. And does the reverse for the outbox. That's it. That's where c2s would work fine.
- The "smart" one, that treats s2s ActivityPub like an API, comes with a built-in web interface, and stores everything in a way which makes sense for its particular presentation. That's the kind I'm making (Smithereen, it's on the list you linked, btw), and that's what Mastodon is. Implementing c2s in this kind of server is a major pain in the ass, and I won't. You'd have to throw away all your careful optimizations, synthesize ActivityPub objects out of things that never were ActivityPub objects in the first place, do horribly inefficient things to merge notifications and feed and other conceptually unrelated stuff from several different database tables just for the client to split them back apart... Doesn't make much sense. A domain-specific API is the only way to make a client for this kind of server.
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.
Or SQLite, which I would recommend over some homebrewed text file format, see https://www.sqlite.org/appfileformat.html
Opening untrusted SQLite files tends to not be safe: https://research.checkpoint.com/select-code_execution-from-u...
There was a bug in an older version of SQLite that CheckPoint was able to exploit. That bug has been fixed for a long time. It was fixed even before the referenced talk was given. They had to use an older version of SQLite in that talk so that the attack would work. The CheckPoint attack was a clever new idea, to be sure, and so more recent versions of SQLite have added new defenses to this kind of mischief, such that even if new bugs in SQLite are found, there will be defense in depth and attacks similar to the CheckPoint attack will still be unlikely. And yet for some reason, because we had that one bug, long ago, people keep saying that SQLite is "unsafe" years after the bug was fixed. Why is that?
See https://www.sqlite.org/security.html for tips on safely opening SQLite database files that have been tampered with by a hostile agent.
Unless you like your database to take types as a little more than suggestions.
We're talking about SQLite instead of text files, not instead of RMDBS. Plaintext files don't even have the concept of a type, they're just unstructured blob with a well-known mapping to printable characters. SQLite is a step up, because it lets you express structure and hint at the desired interpretation.
Text file formats have the benefit of being easier to kerge sometimes. SQLite files are binary and hard/impossible to merge.
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.
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. :(
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.
Standard APIs still can require a fair amount of code to write. A plain text format with a well defined grammar allows me to pull out any old text editor, and get to a working change with trial and error.
Protocols and binary formats have their place too -- but there's simply nothing as universal as text.
> 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/doc...
The reality is that building an editor for text is easy. Building a rich text editor is faaaaaaar from being a simple thing
The problem (currently) is that most people simply don't care about being forced to use a particular client - as long as that client looks nice.
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.
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.
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.
Agreed - with the understanding that maintaining distinct clients is a LOT of work.
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.
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.
> 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.
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.
What about emailing your brother the recipe? That's ultimately the sharing infrastructure Google docs sits on top of.
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.
FWIW the Twitter web client can be somewhat easily hacked by blasting it with an interval from a web extension or userscript. It's a bit inefficient and you have to awkwardly navigate the DOM since they're using obfuscated class names but it works and it can be stable.
Here's some example code from a web extension I wrote that removes promoted tweets: https://gitlab.com/t0astbread/no-promoted-tweets/-/raw/maste...
Couldn't you accomplish that with a browser extension?
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.
Twitter is actually working on a new BYOC model for their platform. Called Blue Sky: https://twitter.com/bluesky
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.
Get a daily email with the the top stories from Hacker News. No spam, unsubscribe at any time.