9 ms·

The Future Needs Files

168 points by polm23 5y ago

rektide 5y ago
There's almost no cross-system paradigms that have survived the cloudification of software. Each app builds it's own intra-verse of ideas, it's own tools. The only thing left that has any meaning is the URL. Which I for one like, but it feels deeply insufficient. This article is great. Great topic, great coverage, good range, solid points. Thanks.
- theamk 5y ago
  Not sure how is this related to "cloudification"? I mean, my Nokia N9110 communicator back in 2000 (which had no associated cloud service) had the same setup for note app -- single file in proprietary format, with all notes stored there. And no mass export tools either! And before that, in the middle school, we used "At Ease" system [0] which was alternative system interface which exposed no files -- there was one "tab" with objects, but no folders or renames. [0] http://toastytech.com/guis/atease.html http://toastytech.com/guis/atease.html
  - paleogizmo 5y ago
    It’s also probably worth mentioning that the iPhone borrowed some UI conventions from Palm OS. I recall correctly, not only did Palm OS not expose files to the user, but it lacked a file system entirely. Instead it had a database associated with each application to store user data. As the linked article pointed out, this worked very well for the use case of taking quick notes or checking a grocery list but quickly becomes limiting for workflows with multiple programs.
    - zepto 5y ago
      > the iPhone borrowed some UI conventions from Palm OS This isn’t the case. iOS is closer to “At ease”, which pre-dated palm os by a decade.
      - AshamedCaptain 5y ago
        You are joking, right? http://toastytech.com/guis/atease.html http://toastytech.com/guis/atease.html
        zepto 5y ago
        Why would you think I was joking. At ease was a simplified interface from the regular finder. It’s primary change was to flatten the file hierarchy into a limited set of panels. It pre-dated both palm os and iOS, and informed the design of both of them.
        AshamedCaptain 5y ago
        Because there are files, folders, windows, and the entire suite. This resembles MS Bob (as the linked webpage says) more than it does resemble PalmOS / iOS. Initial versions of PalmOS / iOS had no files whatsoever, at least visible to the user. If you had say a document editing app on iOS/PalmOS, and you uninstall it, your documents are absolutely gone from the device unless you backed them up somewhere else. The app "owns" the documents. On iOS, this is because apps can only access their private storage space with a few exceptions; on PalmOS this is because there is no filesystem whatsoever so all your apps can do is store stuff on your application's private database, also with a few exceptions (e.g., PalmDOC standard for ebooks). There are no folders, just "categories" or tags at most, there's no way to "browse files" because there aren't, just "apps" and a app launcher which you reach through a home button, and there's no way to share information between apps except through the clipboard. This "at ease" is clearly showing a shared filesystem where apps can load/save random documents to, and in fact it even shows you can create folders and subfolders... http://toastytech.com/guis/ateasesubfolder.png http://toastytech.com/guis/ateasesubfolder.png
- pjmlp 5y ago
  Besides the sibling replies, IBM mainframes are known for not having a file system, they use a database and catalogs for storage. The Newton also used a database for storage.
zepto 5y ago
This is a weak analysis. There are large numbers of ‘shoebox’ style applications which pre-date iOS, and they exist on every platform. It’s a mistake to attribute their existence to iOS. The point of a shoebox app is decouple the user model of organization of data from the file system model even as files are used for storage. This is done because the filesystem user model is inadequate or inappropriate, or because the storage model is expected to change. iOS allows apps to expose their data as files within the Files app without requiring them to expose the underlying files themselves. A good example of this is Quip, which is a collaborative document editor. All of Quip’s data is stored in their online database, but it is also exposed through the files app as a set of PDFs. Notes could expose a filesystem style view if Apple prioritized it. Of course then we’d have the issue of file format versioning etc. to deal with. If I were them I wouldn’t be rushing to make that trade-off.
- rektide 5y ago
  > This is done because the filesystem user model is inadequate or inappropriate, or because the storage model is expected to change. This is a weak analysis. I agree reasonably with your overall point, that this isn't entirely iOS's fault. But I see no evidence or cause to believe any of the alternate anti-file approaches have anything better to offer, present better. You yourself argue that better interfaces are presentable atop the filesystem interface, so it's obviously not a limiting factor in data-representation & data-modelling. Rather, to me, I see cloudification requiring adaption. Files didn't apply, weren't connected, where-as the digital entities we we began trying to work with were connected, cross-system. That doesn't outmode the filesystem, but it does require adaption & reconsideration. It requires connecting. It requires going further. I'd point out that we have no replacement for the filesystem. There's no words, no descriptor we can use to describe the alternate, the pervasive, cloudy objects that we interact with everywhere. There's nothing generic, or user-manageable that's replaced the idea of the file. Files were a convenient reification of the digital to sacrifice, to make computing harder, and because we didn't know how to make the notion of a file more online.
  - zepto 5y ago
    > But I see no evidence or cause to believe any of the alternate anti-file approaches have anything better to offer, present better. I think it’s fairly clear that the iOS photos app is easier to navigate than a folder with tens of thousands of files. Even the notes app presents the notes in a more useful way than a folder would. Other obvious examples are things like notion or roam research, or any number of systems where the file metaphor just isn’t natural. Many people today use a web browser to view pages of text and multimedia connected via hyperlinks. This technology hides the underlying implementation which may be files, or may be databases or other kinds of store. It is more successful than the earlier file based protocols such as FTP and Gopher. > I'd point out that we have no replacement for the filesystem. It’s not clear what this is supposed to mean. We have many other kinds of data store, e.g. relational databases, graph database, time series databases etc.
theamk 5y ago
Some counterpoints: (1) Just "files" are not going to save you -- they must also be in the standard format. It may be pretty simple for text-only notes with no support for formatting, but anything more advanced gets complex fast, especially if you expect files to be editable. ("Editable" is the worst, actually.. Imagine a pen-based note-taking app which stores data as PDF in user-accessible location... users would expect to be able to drop any random PDF and have it show up and be editable. This will make the code immensely more complex compared to simple proprietary format) (2) The file interface is pretty limited (no easy way to detect new files, can only query by name), so you need indexes and secondary metadata. You might need a non-trivial amount of metadata in app-specific format for advanced functionality, like "get past version" or "find similar objects". If you are allowing user to mess with your files, this gets much harder -- you now need to be able to re-scan the whole folder, and try to infer renames. This is certainly possible -- many old-school MP3 managers did this -- but it is a significant additional effort. (3) A lot of times, it is easier to provide alternate mechanisms rather than trying to shoehorn the data model into filesystem (this applies less to mobile, and more to other non-file-based apps), for example: - The (cloud based) note-taking service I use offer "export" option -- your notes are stored in whatever cloud database, but there is a 2-click way to download entire thing as .zip full of text + opml files. - There are also APIs -- the same service offers API to download/upload notes. I run a small script from crontab which downloads all the nodes periodically to my computer. - Local only: "git" does not expose past revision as files -- you use various git commands to see that data.
- kps 5y ago
  > If you are allowing user to mess with your files […] That's the problem. They shouldn't be your files, they should be the user's files.
  - theamk 5y ago
    As a software author, they are "my files" as long as I am responsible for them. Think like a school teacher saying "my class" -- it does not mean the kids belong to teacher, but it does mean that as long as teacher is responsible for them, the kids should be following teacher's instructions. The same goes with the files -- sure, they belong to user, but as long as you want to process it in the program, you need to follow program's rules. How complex and onerous those rules are depends entirely on the program. For example: - Text editor like emacs can handle pretty much any file you throw at it -- but OpenOffice will fail with "file damaged" error if you just change 1 byte in the file header - Many programs require filenames to have certain suffix - Some programs require files to live in designated "projects" dir - A lot of programs have some sort of internal database and will fail if user edits it in a non-trivial way. - Some programs require you to do special manual actions anytime you rename the file using third-party file managers (for example, git needs "git add"/"git rm") Let's not pretend that allowing arbitrary file renames is some sort of ideological standpoint which separates "user files" from "non-user's files". Every program requires something from user to work, and "do not allow arbitrary filenames" is just one point on this spectrum. OpenSSL does not impinge on user freedom just because it requires a very rigid naming structure in /etc/ssl/cert.
travisgriggs 5y ago
It’s interesting to me that the focus of this analysis is handhelds. But what about all the web apps out there that use SQL databases to rowify my data? Can/should one argue that web apps should be backed by highly indexable/searchable file systems so that when I want to depart a platform I can just ask the backend for my files?
- vorpalhex 5y ago
  SQL is at least a meaningful format, so as long as the holder of your data is required to give you a copy you are still good.
- pphysch 5y ago
  Yes. Active Record ORMs (Rails, Django, etc.) are a plague that teaches devs to pretend data engineering isn't important. IMO, the only valid use for them is storing configuration that somehow can't be kept in memory after reading config files. Actual "data" (content) should be kept in stable, readable formats.
superbaconman 5y ago
This is a big complaint I have about iOS. One day I get a notification telling me that my cloud drive is almost out of space so I go to clean it out using the finder, and I find like 4 empty folders. An hour later I realize I have a bunch of photos synced, but I they're only viewable/removable through the photos app (somehow this includes images that I downloaded). It feels like such a poorly designed system.
- zepto 5y ago
  Yes, the finder predates cloud syncing and is not designed for managing storage space. iOS has a built in tool for managing storage space, which is much better.
  - superbaconman 5y ago
    What tool is that? It sounds useful.
    - fouc 5y ago
      I think they're referring to Settings > General > Storage or something like that
  - yboris 5y ago
    It might be much better, but it's atrocious! I open up storage and it shows 10+ GB under "other" with zero transparency and no method for cleaning anything out.
    - zepto 5y ago
      Presumably that is system stuff that can’t be deleted without causing problems. I don’t see what is wrong with reporting that to you.
      - asdff 5y ago
        In my experience usually its cache from installed apps. It would be nice to clear it or see which applications it belongs to easily.
ape4 5y ago
It seems each new release of Android makes it harder for apps to access boring old files. Seems to be on purpose.
reidjs 5y ago
If you’re on an iPhone I recommend iA writer which allows you to save .md or .txt files and sync to your other devices with iCloud or Dropbox https://apps.apple.com/us/app/ia-writer/id775737172 https://apps.apple.com/us/app/ia-writer/id775737172
sbazerque 5y ago
I agree with the author on the merits of the file abstraction, but I think the concept should be updated for networked devices. We need file formats that support both offline usage and seamless sync over the network. For example, here I use a merkle DAG-based file format to represent CRDT-like types: https://www.hyperhyperspace.org https://www.hyperhyperspace.org The resulting abstraction can be universally looked up using a hash (or short sequence of words), can be modified offline and synchronized flawlessly. It's still WIP (for example, you still can't export it to an actual file, hehe).
- samsquire 5y ago
  I am interested in the distributed computing/P2P space and study it. Developers dont want to rewrite their data models to reflect a strange API or weird model. I dont want to pollute my domain objects with MutableReferences or extend HashedObject. So while I think the ideas in Hyperhyperspace are good, the programming model needs revisiting if you want people to actually use it. You need to use plain old objects and spider them for references. ORMs dont require you to use MutableReferences, they let you use your actual data model as is. If we can get the backend storage to be P2P then any application outside the backend storage can be written traditionally. I am personally interested in distributed SQL databases and have written a simple distributed SQL database that could in theory be used as a P2P application backend with distributed joins I think a combination of event sourcing and CRDTs could be used to provide arbitrary synchronisation and merging between peers that handles bad actors through web of trust. I have started a discussion of P2P storage backends on Infinity family which is a community of inventors (I can provide invites). I have mentioned Hyperhyperspace there. https://0oo.li/intent/74001/distributed-data-storage#1630701020 https://0oo.li/intent/74001/distributed-data-storage#1630701...
  - sbazerque 5y ago
    Thank you for your feedback! There are other projects that take an approach similar to what you're describing (Automerge and its derivatives, mainly). I guess there is a distinction between distributed databases and permission-less p2p applications. Having a data center where you can trust the compute nodes running your distributed database is very different than having random untrusted peers over the net. But maybe data validation can be done in a less intrusive way, something like what Automerge does for JSON merging (maybe in a typed setting?). That said, hyper-hyper-space is still work in progress, once we have a proper library of container types programming will be a bit more intuitive. Or so I hope, at least.
gumby 5y ago
The terrible culture of app-centric (rather than document-centric) computing goes back to the 1980s. iOS (and as a result android) merely accelerated the trend.
- jart 5y ago
  Or the terrible culture of accepting the framing that phones are not only computers but the only computers that matter, since it erases the existence of those of us who use computers.
streamofdigits 5y ago
Seems to me the focus on "Files" is more of an excuse to discuss the broader data architecture of mobile devices, in particular how they store and make accessible private data to ML type applications. Not sure they are (or ever will be) the core issue preventing this future. Linux desktops are file based, in principle one could envisage intelligent open souce PIM applications that integrate all the personal data securely and privately, but nothing of the sort exists...
jofer 5y ago
I never would have believed that "filesystems are useful and good for organizing information" was a controversial statement until last year when I worked for a company where the CEO insisted that "files and folders are ruining people's minds" and started a very serious push to avoid anyone using a local filesystem in any way. In principle, sure, centralize data management. It's important. I get it. Messy shared filesystems aren't a great way of archiving data. But at the same time, they're a good solution for quickly producing and using data. The context was around specialized desktop application for technical users (desktop GIS). Yes, you can stream data, and yes, database connections are very much a thing, but that doesn't get around the simple fact that the UIs on everything are set up for local file access. Furthermore, the other applications used alongside this also expect (and in many cases, only accept) local files. 90% of the expensive software you're paying for (or the open solutions too) can't talk to that nice fancy internal-only API you set up to "replace filesystems". In practice, folks are going to wind up with local files anyway, which means you wind up with multiple different copies of the data, which was the whole thing you were trying to avoid. Also, users are _mostly_ creating new data and not just consuming existing data. The whole point is to have a gui toolbox for processing data and creating new datasets. At a deep level, that's best solved by local files for this use case. (i.e. the formats you need to use for interoperability are meant to be updated efficiently as local files. You can stream them, but not easily update them.) Yes, it's possible to have centralized data stores, but they often wind up being a SMB/NFS/etc share because you need to open the data in multiple applications and local files _are_ the interoperability standards. Embrace shared filesystems where they make sense. They're not the enemy. Next is hierarchy. Folders are a _great_ system for organizing temporary ad-hoc work. They're also a pretty good system for organizing longer-lived structures. Pushing things into a limited database schema or tagging structure actually makes things harder to find than a "working folder" approach, as it's difficult to group unrelated data together. Sure, you can tag things for grouping, but that generally loses hierarchy. You can reproduce hierarchy with nested tags, but then you're back to representing things as folders. That representation is _useful_ in many cases and isn't a bad thing. In short, filesystems are good for interoperability on the desktop and desktop workflows are still very necessary for many things. Hierarchical organization is useful, and insisting on dropping it comes with a cost. "Shoebox" / no-file solutions are good for some cases, but not for all. Be _very_ careful about trying to force solutions where they don't fit.
grandpa_on_lawn 5y ago
To paraphrase an old saying: how do "files" help me go viral on TikTok?
skybrian 5y ago
On the other hand, file format compatibility is hard to get right and results in ugly hacks and subtle breakage when multiple apps want to extend a standard. Steve Wittens has a good blog post about this: http://acko.net/blog/on-variance-and-extensibility/ http://acko.net/blog/on-variance-and-extensibility/

168 points by polm23 5y ago

There's almost no cross-system paradigms that have survived the cloudification of software. Each app builds it's own intra-verse of ideas, it's own tools. The only thing left that has any meaning is the URL. Which I for one like, but it feels deeply insufficient. This article is great. Great topic, great coverage, good range, solid points. Thanks.

theamk 5y ago
Not sure how is this related to "cloudification"? I mean, my Nokia N9110 communicator back in 2000 (which had no associated cloud service) had the same setup for note app -- single file in proprietary format, with all notes stored there. And no mass export tools either! And before that, in the middle school, we used "At Ease" system [0] which was alternative system interface which exposed no files -- there was one "tab" with objects, but no folders or renames. [0] http://toastytech.com/guis/atease.html http://toastytech.com/guis/atease.html
- paleogizmo 5y ago
  It’s also probably worth mentioning that the iPhone borrowed some UI conventions from Palm OS. I recall correctly, not only did Palm OS not expose files to the user, but it lacked a file system entirely. Instead it had a database associated with each application to store user data. As the linked article pointed out, this worked very well for the use case of taking quick notes or checking a grocery list but quickly becomes limiting for workflows with multiple programs.
  - zepto 5y ago
    > the iPhone borrowed some UI conventions from Palm OS This isn’t the case. iOS is closer to “At ease”, which pre-dated palm os by a decade.
    - AshamedCaptain 5y ago
      You are joking, right? http://toastytech.com/guis/atease.html http://toastytech.com/guis/atease.html
      - zepto 5y ago
        Why would you think I was joking. At ease was a simplified interface from the regular finder. It’s primary change was to flatten the file hierarchy into a limited set of panels. It pre-dated both palm os and iOS, and informed the design of both of them.
        AshamedCaptain 5y ago
        Because there are files, folders, windows, and the entire suite. This resembles MS Bob (as the linked webpage says) more than it does resemble PalmOS / iOS. Initial versions of PalmOS / iOS had no files whatsoever, at least visible to the user. If you had say a document editing app on iOS/PalmOS, and you uninstall it, your documents are absolutely gone from the device unless you backed them up somewhere else. The app "owns" the documents. On iOS, this is because apps can only access their private storage space with a few exceptions; on PalmOS this is because there is no filesystem whatsoever so all your apps can do is store stuff on your application's private database, also with a few exceptions (e.g., PalmDOC standard for ebooks). There are no folders, just "categories" or tags at most, there's no way to "browse files" because there aren't, just "apps" and a app launcher which you reach through a home button, and there's no way to share information between apps except through the clipboard. This "at ease" is clearly showing a shared filesystem where apps can load/save random documents to, and in fact it even shows you can create folders and subfolders... http://toastytech.com/guis/ateasesubfolder.png http://toastytech.com/guis/ateasesubfolder.png
pjmlp 5y ago
Besides the sibling replies, IBM mainframes are known for not having a file system, they use a database and catalogs for storage. The Newton also used a database for storage.

zepto 5y ago

This is a weak analysis. There are large numbers of ‘shoebox’ style applications which pre-date iOS, and they exist on every platform. It’s a mistake to attribute their existence to iOS. The point of a shoebox app is decouple the user model of organization of data from the file system model even as files are used for storage. This is done because the filesystem user model is inadequate or inappropriate, or because the storage model is expected to change. iOS allows apps to expose their data as files within the Files app without requiring them to expose the underlying files themselves. A good example of this is Quip, which is a collaborative document editor. All of Quip’s data is stored in their online database, but it is also exposed through the files app as a set of PDFs. Notes could expose a filesystem style view if Apple prioritized it. Of course then we’d have the issue of file format versioning etc. to deal with. If I were them I wouldn’t be rushing to make that trade-off.

rektide 5y ago
> This is done because the filesystem user model is inadequate or inappropriate, or because the storage model is expected to change. This is a weak analysis. I agree reasonably with your overall point, that this isn't entirely iOS's fault. But I see no evidence or cause to believe any of the alternate anti-file approaches have anything better to offer, present better. You yourself argue that better interfaces are presentable atop the filesystem interface, so it's obviously not a limiting factor in data-representation & data-modelling. Rather, to me, I see cloudification requiring adaption. Files didn't apply, weren't connected, where-as the digital entities we we began trying to work with were connected, cross-system. That doesn't outmode the filesystem, but it does require adaption & reconsideration. It requires connecting. It requires going further. I'd point out that we have no replacement for the filesystem. There's no words, no descriptor we can use to describe the alternate, the pervasive, cloudy objects that we interact with everywhere. There's nothing generic, or user-manageable that's replaced the idea of the file. Files were a convenient reification of the digital to sacrifice, to make computing harder, and because we didn't know how to make the notion of a file more online.
- zepto 5y ago
  > But I see no evidence or cause to believe any of the alternate anti-file approaches have anything better to offer, present better. I think it’s fairly clear that the iOS photos app is easier to navigate than a folder with tens of thousands of files. Even the notes app presents the notes in a more useful way than a folder would. Other obvious examples are things like notion or roam research, or any number of systems where the file metaphor just isn’t natural. Many people today use a web browser to view pages of text and multimedia connected via hyperlinks. This technology hides the underlying implementation which may be files, or may be databases or other kinds of store. It is more successful than the earlier file based protocols such as FTP and Gopher. > I'd point out that we have no replacement for the filesystem. It’s not clear what this is supposed to mean. We have many other kinds of data store, e.g. relational databases, graph database, time series databases etc.

theamk 5y ago

Some counterpoints: (1) Just "files" are not going to save you -- they must also be in the standard format. It may be pretty simple for text-only notes with no support for formatting, but anything more advanced gets complex fast, especially if you expect files to be editable. ("Editable" is the worst, actually.. Imagine a pen-based note-taking app which stores data as PDF in user-accessible location... users would expect to be able to drop any random PDF and have it show up and be editable. This will make the code immensely more complex compared to simple proprietary format) (2) The file interface is pretty limited (no easy way to detect new files, can only query by name), so you need indexes and secondary metadata. You might need a non-trivial amount of metadata in app-specific format for advanced functionality, like "get past version" or "find similar objects". If you are allowing user to mess with your files, this gets much harder -- you now need to be able to re-scan the whole folder, and try to infer renames. This is certainly possible -- many old-school MP3 managers did this -- but it is a significant additional effort. (3) A lot of times, it is easier to provide alternate mechanisms rather than trying to shoehorn the data model into filesystem (this applies less to mobile, and more to other non-file-based apps), for example: - The (cloud based) note-taking service I use offer "export" option -- your notes are stored in whatever cloud database, but there is a 2-click way to download entire thing as .zip full of text + opml files. - There are also APIs -- the same service offers API to download/upload notes. I run a small script from crontab which downloads all the nodes periodically to my computer. - Local only: "git" does not expose past revision as files -- you use various git commands to see that data.

kps 5y ago
> If you are allowing user to mess with your files […] That's the problem. They shouldn't be your files, they should be the user's files.
- theamk 5y ago
  As a software author, they are "my files" as long as I am responsible for them. Think like a school teacher saying "my class" -- it does not mean the kids belong to teacher, but it does mean that as long as teacher is responsible for them, the kids should be following teacher's instructions. The same goes with the files -- sure, they belong to user, but as long as you want to process it in the program, you need to follow program's rules. How complex and onerous those rules are depends entirely on the program. For example: - Text editor like emacs can handle pretty much any file you throw at it -- but OpenOffice will fail with "file damaged" error if you just change 1 byte in the file header - Many programs require filenames to have certain suffix - Some programs require files to live in designated "projects" dir - A lot of programs have some sort of internal database and will fail if user edits it in a non-trivial way. - Some programs require you to do special manual actions anytime you rename the file using third-party file managers (for example, git needs "git add"/"git rm") Let's not pretend that allowing arbitrary file renames is some sort of ideological standpoint which separates "user files" from "non-user's files". Every program requires something from user to work, and "do not allow arbitrary filenames" is just one point on this spectrum. OpenSSL does not impinge on user freedom just because it requires a very rigid naming structure in /etc/ssl/cert.

travisgriggs 5y ago

It’s interesting to me that the focus of this analysis is handhelds. But what about all the web apps out there that use SQL databases to rowify my data? Can/should one argue that web apps should be backed by highly indexable/searchable file systems so that when I want to depart a platform I can just ask the backend for my files?

vorpalhex 5y ago
SQL is at least a meaningful format, so as long as the holder of your data is required to give you a copy you are still good.
pphysch 5y ago
Yes. Active Record ORMs (Rails, Django, etc.) are a plague that teaches devs to pretend data engineering isn't important. IMO, the only valid use for them is storing configuration that somehow can't be kept in memory after reading config files. Actual "data" (content) should be kept in stable, readable formats.

superbaconman 5y ago

This is a big complaint I have about iOS. One day I get a notification telling me that my cloud drive is almost out of space so I go to clean it out using the finder, and I find like 4 empty folders. An hour later I realize I have a bunch of photos synced, but I they're only viewable/removable through the photos app (somehow this includes images that I downloaded). It feels like such a poorly designed system.

zepto 5y ago
Yes, the finder predates cloud syncing and is not designed for managing storage space. iOS has a built in tool for managing storage space, which is much better.
- superbaconman 5y ago
  What tool is that? It sounds useful.
  - fouc 5y ago
    I think they're referring to Settings > General > Storage or something like that
- yboris 5y ago
  It might be much better, but it's atrocious! I open up storage and it shows 10+ GB under "other" with zero transparency and no method for cleaning anything out.
  - zepto 5y ago
    Presumably that is system stuff that can’t be deleted without causing problems. I don’t see what is wrong with reporting that to you.
    - asdff 5y ago
      In my experience usually its cache from installed apps. It would be nice to clear it or see which applications it belongs to easily.

ape4 5y ago

It seems each new release of Android makes it harder for apps to access boring old files. Seems to be on purpose.

reidjs 5y ago

If you’re on an iPhone I recommend iA writer which allows you to save .md or .txt files and sync to your other devices with iCloud or Dropbox https://apps.apple.com/us/app/ia-writer/id775737172 https://apps.apple.com/us/app/ia-writer/id775737172

sbazerque 5y ago

I agree with the author on the merits of the file abstraction, but I think the concept should be updated for networked devices. We need file formats that support both offline usage and seamless sync over the network. For example, here I use a merkle DAG-based file format to represent CRDT-like types: https://www.hyperhyperspace.org https://www.hyperhyperspace.org The resulting abstraction can be universally looked up using a hash (or short sequence of words), can be modified offline and synchronized flawlessly. It's still WIP (for example, you still can't export it to an actual file, hehe).

samsquire 5y ago
I am interested in the distributed computing/P2P space and study it. Developers dont want to rewrite their data models to reflect a strange API or weird model. I dont want to pollute my domain objects with MutableReferences or extend HashedObject. So while I think the ideas in Hyperhyperspace are good, the programming model needs revisiting if you want people to actually use it. You need to use plain old objects and spider them for references. ORMs dont require you to use MutableReferences, they let you use your actual data model as is. If we can get the backend storage to be P2P then any application outside the backend storage can be written traditionally. I am personally interested in distributed SQL databases and have written a simple distributed SQL database that could in theory be used as a P2P application backend with distributed joins I think a combination of event sourcing and CRDTs could be used to provide arbitrary synchronisation and merging between peers that handles bad actors through web of trust. I have started a discussion of P2P storage backends on Infinity family which is a community of inventors (I can provide invites). I have mentioned Hyperhyperspace there. https://0oo.li/intent/74001/distributed-data-storage#1630701020 https://0oo.li/intent/74001/distributed-data-storage#1630701...
- sbazerque 5y ago
  Thank you for your feedback! There are other projects that take an approach similar to what you're describing (Automerge and its derivatives, mainly). I guess there is a distinction between distributed databases and permission-less p2p applications. Having a data center where you can trust the compute nodes running your distributed database is very different than having random untrusted peers over the net. But maybe data validation can be done in a less intrusive way, something like what Automerge does for JSON merging (maybe in a typed setting?). That said, hyper-hyper-space is still work in progress, once we have a proper library of container types programming will be a bit more intuitive. Or so I hope, at least.

gumby 5y ago

The terrible culture of app-centric (rather than document-centric) computing goes back to the 1980s. iOS (and as a result android) merely accelerated the trend.

jart 5y ago
Or the terrible culture of accepting the framing that phones are not only computers but the only computers that matter, since it erases the existence of those of us who use computers.

streamofdigits 5y ago

Seems to me the focus on "Files" is more of an excuse to discuss the broader data architecture of mobile devices, in particular how they store and make accessible private data to ML type applications. Not sure they are (or ever will be) the core issue preventing this future. Linux desktops are file based, in principle one could envisage intelligent open souce PIM applications that integrate all the personal data securely and privately, but nothing of the sort exists...

jofer 5y ago

I never would have believed that "filesystems are useful and good for organizing information" was a controversial statement until last year when I worked for a company where the CEO insisted that "files and folders are ruining people's minds" and started a very serious push to avoid anyone using a local filesystem in any way. In principle, sure, centralize data management. It's important. I get it. Messy shared filesystems aren't a great way of archiving data. But at the same time, they're a good solution for quickly producing and using data. The context was around specialized desktop application for technical users (desktop GIS). Yes, you can stream data, and yes, database connections are very much a thing, but that doesn't get around the simple fact that the UIs on everything are set up for local file access. Furthermore, the other applications used alongside this also expect (and in many cases, only accept) local files. 90% of the expensive software you're paying for (or the open solutions too) can't talk to that nice fancy internal-only API you set up to "replace filesystems". In practice, folks are going to wind up with local files anyway, which means you wind up with multiple different copies of the data, which was the whole thing you were trying to avoid. Also, users are _mostly_ creating new data and not just consuming existing data. The whole point is to have a gui toolbox for processing data and creating new datasets. At a deep level, that's best solved by local files for this use case. (i.e. the formats you need to use for interoperability are meant to be updated efficiently as local files. You can stream them, but not easily update them.) Yes, it's possible to have centralized data stores, but they often wind up being a SMB/NFS/etc share because you need to open the data in multiple applications and local files _are_ the interoperability standards. Embrace shared filesystems where they make sense. They're not the enemy. Next is hierarchy. Folders are a _great_ system for organizing temporary ad-hoc work. They're also a pretty good system for organizing longer-lived structures. Pushing things into a limited database schema or tagging structure actually makes things harder to find than a "working folder" approach, as it's difficult to group unrelated data together. Sure, you can tag things for grouping, but that generally loses hierarchy. You can reproduce hierarchy with nested tags, but then you're back to representing things as folders. That representation is _useful_ in many cases and isn't a bad thing. In short, filesystems are good for interoperability on the desktop and desktop workflows are still very necessary for many things. Hierarchical organization is useful, and insisting on dropping it comes with a cost. "Shoebox" / no-file solutions are good for some cases, but not for all. Be _very_ careful about trying to force solutions where they don't fit.

grandpa_on_lawn 5y ago

To paraphrase an old saying: how do "files" help me go viral on TikTok?

skybrian 5y ago

On the other hand, file format compatibility is hard to get right and results in ugly hacks and subtle breakage when multiple apps want to extend a standard. Steve Wittens has a good blog post about this: http://acko.net/blog/on-variance-and-extensibility/ http://acko.net/blog/on-variance-and-extensibility/