Thanks for working on this, itās great to see a Master thesis on Solid :D. Iāll check out all the content youāve put out, Iām sure itāll be interesting to read.
Only read the presentation as yet, but bumping this back up because not only really important but also because responding to these concerns may offer Solid a ground-up strategy for countering āweb3ā blockchain insanity.
May seem weird for an intiative started by the inventor of the world wide web, but hear me out:
Offering a desktop/mobile app with ability to SFTP (or similar) updates over patchy, laggy, high latency connections would arguably benefit a vast swath of net users not just in ādevelopingā countries but in many ādevelopedā countries outside urban areas.
Promoted properly, such an app could even approach ākillerā status for its reliabity and speed, something that even urban net users complain about with many of the all-online, all-the-time apps commonly in use.
There would also be important efficiency aspects, with presumably a much lower traffic consumption rate in that the app would not be recording and transmitting every. single. keystroke.
For perspective on my comments, I was raised and lived on a tiny, remote island in the Pacific - same time zone as Hawaii but 4,734 kilometres (2,949 miles) south. Advent of email was a huge boon for us at a time when every fax cost us US$3 a page. The net even more so - but of course high latency and service failures were frequent, and, two decades later, still are. As they still seem to be in most parts of Africa, and no doubt, Asia, the Americas and beyond.
A device-first approach may yield real strategic benefits for Solid, and Solid users.
@jasonbrown1965 I think this would depend on how you see Solid: if you see it just as storage, then yes, something like SFTP where you work directly with files makes sense, but if you look at it as structured data storage, then it makes less sense, as thatās generally very app-specific (i.e., where to store datasets, how to update predicates to reference those datasets, etc).
But there is probably a lot of research that could go into making solid more offline-first in an approach, which could benefit the entire community. The Inrupt SDKs already largely manipulate the datasets offline, but there is currently no ādataset cacheā nor any tooling for managing instances of a dataset over time. Likewise, thereās no integration with offline storage or web workers at the moment, such that applications would behave consistently even if operating offline.
In the Inrupt SDKs, we do also make use of If-None-Match, but this could probably go further to include using etags and such to ensure that you donāt overwrite a resource if itās different between when you first fetched it and when you go to update it.