“This post proposes a bit of a copernican revolution, rethinking some fundamental assumptions that a lot of people take for granted: The service-centric architecture that drives websites and most apps.”
"The idea is to invert three key relationships that define today’s computing:
-
Services comes to the data (instead of data going to services)
-
Guardrails on data use are attached to data, both to attest to its integrity and to allow any service to use the data as long as they are verifiably compliant with them (instead of each services individually permissioned)
-
Authority originates at the edges and flows through the system (instead of services deciding who is an authorized client, centralized identity, etc.)"
“We propose that computing is organized around the data, and that data is sent only to code running in a sandbox under the user’s governance.”
“Collaboration is defined around shared data, not services. Users create a collaborative space and invite code into it.”
Still reading, but this looks interesting.
4 Likes
In the Documentathon we treat most documents as data trees that are written and modified collectively. I would say that this data centric approach is already in almost all collaborative writing workflows.
It is not a one to one map to the proposal, as far as I can tell, for example there are still some points of centralized authority, like the (Fossil) source code repository where synchronization happens. The sandbox is a local first stack of technologies (Fossil, Markdown/Markdeep, Pharo/GT) instead of some web word processor (but HedgeDoc plays an important role in our workflows) and so on. But maybe there are strong resonances with our (and other’s) documentation workflows and a data centric way of interaction.
1 Like
This looks like roughly the same inversion as the one behind the idea of computational media, which has been around for quite a while but never became reality. Fundamentally, I see it as a shift of focus from tools (programs, services) to data and from technology to the application domain. The obstacle then is the deeply ingrained supremacy of code over data that pervades computer science (details: Science in the digital era).
I suspect users would find that “inversion” perfectly natural if asked about it, a @Offray’s description confirms.
1 Like
@khinsen I love your idea and am clearly guilty of it myself. Some excuses/rationalizations that come to mind:
-
An app tends to have a bounded size but may emit a KB or GB of data from session to session. Videos, notebooks, etc. So the code is a compressed form of the data, particularly if you preserve context like the order of operations.
-
The nice thing about a file system is that both code and data are first-class named entities. When apps focus on code you get a pleasing orthogonality between code and data. Any app can operate on any file. I think managing files is mostly the task of each person outside of any app. With the aid of tools/code, of course 
but it’s fundamentally up to each person to decide whether they care about each datum and how much. (Blanket assumptions about the value of data lead to misguided policies like the browser not being able to write to files, which has caused Tiddlywiki so much trouble.)
I still wish I could do what you want. Gonna think on it.
1 Like
@Offray I think your approach may be resonating with the post by just the right amount. The first bullet was the most persuasive part here. The post is a lot less persuasive once it gets into how people allow services to exfiltrate and remix data. Mostly the answer seemed like a hand-wavy “encryption” to my eyes. But if y’all understood the details better please explain them to me.
File systems are fine with me, as a low-level infrastructure. It’s the stuff we build on top of it that introduces discrimination.
Same BTW for systems with a different low-level storage infrastructure. Example: Smalltalk and its images. Everything is an object, and all objects are equal. But classes are more equal than others: they have a change-tracking system that lets code survive a serious corruption of the image.
It’s funny to see people encode data as code in Smalltalk to profit from code privileges. Example: the help system in Squeak and Pharo stores all the text as methods that return a string literal. I have even seen this approach once in C code, written by a colleague: he encodes his data as code generating structures with literal values, and uses the C compiler for validating his data schema.
2 Likes