Comment by skeledrew
21 days ago
I've been thinking of this for some time, conceptually, but perhaps from a more fundamental angle. I think the idea of "files" is pretty dated and can be thrown out. Treat everything as data blobs (inspired by PerKeep[0]) addressed by their hashes and many of the issues described in the article just aren't even a thing. If it really makes sense, or for compatibility sake, relevant blobs can be exposed through a filesystem abstraction.
Also, users don't really want apps. What users want are capabilities. So not Bluesky, or YouTube for example, but the capability to easily share a life update with interested parties, or the capability to access yoga tutorial videos. The primary issue with apps is that they bundle capabilities, but many times particular combinations of capabilities are desired, which would do well to be wired together.
Something in particular that's been popping up fairly often for me is I'm in a messaging app, and I'd like to lookup certain words in some of the messages, then perhaps share something relevant from it. Currently I have to copy those words over to a browser app for that lookup, then copy content and/or URL and return to the messaging app to share. What I'd really love is the capability to do lookups in the same window that I'm chatting with others. Like it'd be awesome if I could embed browser controls alongside the message bubbles with the lookup material, and optionally make some of those controls directly accessible to the other part(y|ies), which may even potentially lead to some kind of adhoc content collaboration as they make their own updates.
It's time to break down all these barriers that keep us from creating personalized workflows on demand. Both at the intra-device level where apps dominate, and at the inter-device level where API'd services do.
I'm using filesystem more as a metaphor than literally.
I picked this metaphor because "apps" are many-to-many to "file formats". I found "file format" to be a very powerful analogy for lexicons so I kind of built everything else in the explanation around that.
You can read https://atproto.com/specs/repository for more technical details about the repository data structure:
The repository data structure is content-addressed (a Merkle-tree), and every mutation of repository contents (eg, addition, removal, and updates to records) results in a new commit data hash value (CID). Commits are cryptographically signed, with rotatable signing keys, which allows recursive validation of content as a whole or in part. Repositories and their contents are canonically stored in binary DAG-CBOR format, as a graph of data objects referencing each other by content hash (CID Links). Large binary blobs are not stored directly in repositories, though they are referenced by hash (CID).
Re: apps, I'd say AT is actually post-app to some extent because Lexicons aren't 1:1 to apps. You can share Lexicons between apps and I totally can see a future where the boundaries are blurring and it's something closer to what you're describing.
But you don’t need the AT protocol and lexicons to describe semantics. Ontologies have been a thing for decades, and search engines (the “rich results”) and ActivityPub use them.
Why use the lexicons you described, instead of the more supported https://www.w3.org/ns/activitystreams ontology that ActivityPub uses, for example?
If you allow me to, I would be interested in re-writing your article but by using ActivityPub concepts instead. Maybe I will learn about a fatal flaw in one of the protocols during that process.
It's bold to say users don't want apps when the expressed preferences are so strongly for apps that "App Store" is a well known brand.
The word app is short for application, which in this context is just a synonym for capability. People have tried breaking apps apart into more fine grained capabilities before and it never worked (OpenDoc and OLE being two well known examples). Brand names matter, they have value to people. YouTube isn't an abstract collection of decomposable capabilities, it's a brand that summarizes numerous unarticulated pieces of information, like its commenting culture, what kind of content is allowed and what isn't, etc.
> I'd like to lookup certain words in some of the messages, then perhaps share something relevant from it.
This is already a built-in feature on macOS. If I right click in your message "Look up PerKeep" is literally the first command, and if I click it I get a nice info window telling me what it is that I can copy/paste from. There is nothing to solve here.
> the expressed preference
Marketing and culture can do wonders to one's preference.
> synonym for capability Yes and no. An "app" is usually a set of capabilities, not a single capability. Many of the core *nix utilities for example are specifically designed to have a single capability each, and these are then composed for complex requirements. But for the most part today's apps contain multiple, usually overlapping capabilities. For example Microsoft Word offers not only text editing and formatting, but also has a dictionary+thesaurus, spelling+grammar check, mail merge and lots more. Of course, you can abstract this all away as "word processor capability", but there are other word processing apps out there with varying capabilities, and so things become problematic fast especially in terms of interoperability.
> OpenDoc and OLE These "never worked" due to people/policy, not due to tech ability. OpenDoc essentially stagnated at Apple due to conflicts and lack of clarity, and then was outright killed by Steve Jobs[0]. OLE(tm) hasn't failed per se, but it's proprietary to Microsoft[1] and thus doesn't have much adoption outside Windows.
> Brand names matter All they really do is put a label on a bundle - or bundles - of capabilities to create handy associations. YouTube is associated primarily with accessing videos that can be made and uploaded by anyone, secondarily allows commenting on and liking said videos, etc. Again, marketing is a significant factor.
> a built-in feature You seem to be missing the forest for a tree here. That's a single example, of infinite permutations. Also, even given that example you're still missing parts of the flow.
[0] https://en.wikipedia.org/wiki/OpenDoc [1] https://en.wikipedia.org/wiki/Object_Linking_and_Embedding
FWIW the Look Up feature, whilst built in to macOS, can also be implemented using "services" which are a way to plug in to other apps and system features like text rendering and highlighting. I can also select text in your message, right click, services -> "Add to music as spoken track". That's a plugin offered by an app. It's only one extra click.
My perspective on why OpenDoc/OLE failed are different to yours. The model in which apps host targeted plugins which don't affect data formats proved very successful, the model in which an app is nothing but plugins wasn't. And if you want to talk about marketing and culture, well, OpenDoc and OLE both benefited from corporate marketing. Using OLE was part of Microsoft's "Designed for Windows 95" programme, which came with a badge and marketing dollars attached. This concept was heavily pushed at the time. OLE had more success than OpenDoc but only temporarily and only because it was a less pure implementation of the concept, closer to fancy plugins than truly decomposing apps into components.
I think the reason they didn't take off was a mix of technological problems and user demand problems. It wasn't people/policy related. Quite the opposite: both technologies lived on long after the real problems had become apparent.
Programming for both OpenDoc and OLE was extraordinarily complicated. The developer experience was atrocious. Making your app OLE embeddable required mastering not only COM and Win32 programming but dozens of other poorly documented and flaky APIs, like for compound documents. Code generation was rampant, everything was memory unsafe. I never did OpenDoc apps but I heard it was a very similar experience.
Then there was the user experience: if you embedded an object from an app and sent the resulting document to someone else who didn't have the app, or had an old version of the app, then the document would just have a hole in it. Useless. OLE tried to do a kind of weird mind-meld between totally different app GUIs, meaning that depending on where you clicked in a document the hosting app could look totally different. There were dozens of problems like this.
In the end it was all rendered irrelevant by the web. On the web, if you share a document with someone it always appeared for them correctly (or if it doesn't, it's a minor and quickly fixable bug). Reliable sharing mattered more than anything else and so all the non-web platforms started dying out.
3 replies →