4 ms·

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

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. [0] https://perkeep.org/ https://perkeep.org/

danabramov 10mo ago
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 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.
- Diti 10mo ago
  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 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.
mike_hearn 10mo ago
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.
- skeledrew 10mo ago
  > 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 https://en.wikipedia.org/wiki/OpenDoc [1] https://en.wikipedia.org/wiki/Object_Linking_and_Embedding https://en.wikipedia.org/wiki/Object_Linking_and_Embedding

danabramov 10mo ago

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

Diti 10mo ago
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 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.

mike_hearn 10mo ago

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.

skeledrew 10mo ago
> 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 https://en.wikipedia.org/wiki/OpenDoc [1] https://en.wikipedia.org/wiki/Object_Linking_and_Embedding https://en.wikipedia.org/wiki/Object_Linking_and_Embedding