3 ms·

(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 p

by 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.

by gklitt 6y ago

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.