"Can I Use" for Solid?
I see interoperability as emerging from an active effort to connect with what already exists. In the browser space, "Can I Use" describes current implementation support for specific browser features. How might this idea play out with Solid apps?
- Comment
- I see interoperability as emerging from an active effort to connect with what already exists. In the browser space, "Can I Use" describes current implementation support for specific browser features. How might this idea play out with Solid apps?
- Label
- "Can I Use" for Solid?
- RedirectTo
- caniuse.html
- TaskUpdate2
- 2024-12-31-caniuse
2024-02-29
112014684859380315
- Date Modified
- 2024-02-29
- SeeAlso
- outbox-min id-0.jsonld
2024-04-15
112277581865129825
- Date Modified
- 2024-04-15
- SeeAlso
- outbox-min id-112064513835089106.jsonld
2024-04-18
112289475584674989
- Date Modified
- 2024-04-18
- SeeAlso
- outbox-min id-112064513835089106.jsonld
2024-05-06
112394066943324839
- Date Modified
- 2024-05-06
- SeeAlso
- outbox-min id-112331283225497771.jsonld
2024-05-17
112458483164211094
- Date Modified
- 2024-05-17
- SeeAlso
- outbox-min id-112331283225497771.jsonld
2024-05-19
112465733392006133
- Date Modified
- 2024-05-19
- SeeAlso
- outbox-min id-112331283225497771.jsonld
2024-09-19
113164549752222316
- Date Modified
- 2024-09-19
- SeeAlso
- outbox-min id-112928503569299861.jsonld
2024-09-21
113175640433841721
- Date Modified
- 2024-09-21
- SeeAlso
- outbox-min id-112928503569299861.jsonld
2024-09-21
113175660497432283
- Date Modified
- 2024-09-21
- SeeAlso
- outbox-min id-112928503569299861.jsonld
2024-09-29
113218682736011495
- Date Modified
- 2024-09-29
- SeeAlso
- outbox-min id-113192498268394952.jsonld
2024-10-11
113291470490690547
- Date Modified
- 2024-10-11
- SeeAlso
- outbox-min id-113192498268394952.jsonld
2024-10-16
113316903487910891
- Date Modified
- 2024-10-16
- SeeAlso
- outbox-min id-113291470490690547.jsonld
2024-12-31
113747390007971264
- Date Modified
- 2024-12-31
- SeeAlso
- outbox-min id-113665701594445312.jsonld
2025-01-03
113764141176644871
- Date Modified
- 2025-01-03
- SeeAlso
- outbox-min id-113665701594445312.jsonld
2025-01-05
113776326231033294
- Date Modified
- 2025-01-05
- SeeAlso
- outbox-min id-113773065552589552.jsonld
2025-03-04
114098701387170324
- Date Modified
- 2025-03-04
- SeeAlso
- outbox-min id-113773065552589552.jsonld
2025-03-05
114109918875564025
- Date Modified
- 2025-03-05
- SeeAlso
- outbox-min id-113773065552589552.jsonld
2025-03-08
114121582134784273
- Date Modified
- 2025-03-08
- SeeAlso
- outbox-min id-113773065552589552.jsonld
2025-03-17
114176447114010249
- Date Modified
- 2025-03-17
- SeeAlso
- outbox-min id-113773065552589552.jsonld
2025-05-04
114448127339317753
- Date Modified
- 2025-05-04
- SeeAlso
- outbox-min id-114176447114010249.jsonld
2025-01-01
1735681304616
- Content
- There's been a few challenges so far, notably what I'm calling the resource-literal problem (see previous post), how to handle Umai's use of CRDT, and how to determine what compatibility with Umai involves. In my experimental context, I'm fairly comfortable with my current solutions to these, usually at the expense of UX, DX or relying on Umai's flexibility. I can now keep track of groceries within one or more locations, edit the quantity and age of a grocery, saving it as an observation, record that a grocery was used, list groceries that are available or need to be bought, and search for groceries. I can also annotate a receipt and mark items as bought in the pantry. The app links recipes with what is in the pantry and I can annotate recipes to note which groceries are required, see whether the ingredients for a recipe are available, and list recipes, including which ingredients need to be bought, separating out staples from special ingredients I have two big issues left before I feel comfortable sharing the app. Firstly, I want to link the pantry and recipes to a shopping list, with both allowing to add ingredients to a shopping list and being able to mark ingredients as bought (at least from the receipt). I haven't yet confirmed the shopping list's properties, though leaning towards the more complex case of making it a single use, mutable list rather than a perennial mutable list or an append only event log. Updating the shopping list and the pantry at the same time is also pushing the limits of my UI binding approach, so there's more fundamental DX questions coming up. Secondly, the pantry app has followed my usual refactoring path in which I start by editing data with generic tools, then write html with hardcoded uris for loading the data, and only gradually refactor into html modules with generic paths. There's currently a bottleneck in that last stage of making things public, because I already have a (semi-) working app, so the incentive to share (half-broken) modules is lower than the incentive of creating the functionality for myself. Additionally, the complexity of making modules generic still has a step up that breaks the dynamic of incremental user effort creating incremental user value (https://lea.verou.me/blog/2024/engage-dont-show/). I've only barely started thinking about testing, but it will become really important to iron out the many bugs both in the modules and the underlying web components. The current frontier is actually to enable the use of components as panes in PodOS and SolidOS, and I have, for example, started experimenting with auto-loading of my custom web components to support this. If my other apps can natively use these new HTML modules with zero custom code in the host app, that'll tackle both the value and effort side of the equation. I also want the shapes used to be well documented to support a next stage of schema standardisation (also see https://jg10.solidcommunity.net/devlog/now.ttl#CanIUse). Finishing the pantry app therefore becomes equivalent to finalising panes for the missing components.
- Date Modified
- 2025-01-01
2025-01-10
1736486270061
- Content
- I use this app daily despite its bugs, though this has mostly been in online mode. I've finally fixed some race conditions that prevented the last note from being reopened correctly when offline. The next barrier is to streamline sync. My current plan is to provide a dialog listing locally modified files. Selecting that file should show differences with the online version, and allow saving. While I could imagine a competing app offering text CRDT syncing, my intention is currently for changes to be purposefully compared and approved, with a diff view. I like the UX used by Umai, which provides a view of local data and the ability to reconnect, which then initiates sync. I'd therefore like to replace my current login button with icons showing connection and sync status. A key difference will be that by design the notes app will only have local copies of some and not all notes. Consistent with the idea of a locally cached web, rather than local-first, the dynamic is that recently visited or manually synced folders/notes are kept locally. I also imagine eventually having a list of cached notes (similar to e.g. OneDrive), though this is lower priority given that simply visiting a folder already caches recent notes. For the time being, I'd like the app to open quickly in offline mode without having to reconnect, and being able to confidently sync individual notes later, rather than needing them to appear automatically on the pod. One simplification is that I plan to replace the open-with functionality with a link to an external app. Especially because of its local caching, I think this kind of notes app should follow the principle of least privilege. Eventually I think that means using SAI, but before I operationalise an authentication agent for my pod, an intermediate step is for open-with functionality to be handled by a single trusted app. As with many of my experiments, I can't imagine anyone using this notes app before the underlying web components have well tested, bug free implementations - and probably some attention to design. But as the open-with & can-I-use experiments progress, I might try to first document this app's requirements to 1) allow others to compare their compatibility, 2) experiment with whether a client-client/application domain protocol might be worthwhile in this space.
- Date Modified
- 2025-01-10
2025-01-10
1736489359141
- Content
- I'm fairly happy with how this website has been working. It started off as a simple wiki version of the content from my Mastodon account, i.e. organised by topic, and I've found this useful as a snapshot of where my previous thinking has gotten to. Adding listings of Mastodon posts by tagging them using the page uris has helped reflect on the content on Mastodon and provide some discipline in what is covered in the wiki pages. I'd be interested in further exploring the vision in https://forum.solidproject.org/t/ideas-for-a-possible-faq-solid-app/4627 . This would probably firstly involve being able to attribute text in wiki pages to specific Mastodon posts (probably with the oa vocab), but could go quite a bit further in building on posts by others, and making it easier for others to consume the content added here. Given my work on individual experiments is fairly haphazard, I'm enjoying the ability for the updates to structure where things are at by project rather than topic and therefore shape what I might do next. I've actually been hesitant about the concept of open productivity, but I've now found I'm comfortable documenting work pseudonymously where it's clearly experimental - while the content is public, with the social benefits that offers, the accountability it brings is actually to myself rather than to others. Given how open-ended my experiments have been, it'll be interesting to see if the now page can help drive projects to a level of completion - or whether some other mechanism will be needed to help keep the number of "active" projects manageable and making meaningful progress.
- Date Modified
- 2025-01-10
2024-12-31
2024-12-31-caniuse
- Content
- I started this task prompted by https://jg10.solidcommunity.net/devlog/now.ttl#OpenWith in which I concluded that I would want to validate data against both its expected shape and the shapes that apps are expecting. Things are still at the messy stage, but I've already discovered a few requirements. I want two primary classes - an app, and an app feature. I want to be able to describe relationships between features and reason based on these. It turns out I don't just want to know shape-based data compatibility, but also e.g., JS, because I'm also interested in apps that are in fact 'panes' within SolidOS or PodOS, as well as other app functionality such as authentication. Apps and features can be documented one per document to allow linked data collections of different groupings of apps. The basic use case involves selecting a high level function, e.g., task management, loading (usually linked) descriptions of apps providing this function, and then comparing which lower level features (e.g. use of wf:Task) each app supports. As an app designer, this gives me an overview of potential in/compatibilities with other apps. As an (expert) user, this gives me an overview of how data structures, especially shapes, I might want to prioritise in my own pod.
- Date Modified
- 2024-12-31
2024-12-31
2024-12-31-open-with
- Content
- Building on the previous update and comments on earlier experiments, it makes sense that compatibility with an app depends on how the data is structured. Two apps might not be able to use data even if their types are the same, but might still be able to use the same data even if there are some differences in what data they use. Open-with functionality can therefore benefit from being able to test compatibility/validate the data structure. At the same time, stored data is structured with a particular application in mind. We end up with a triangular structure between data, shape and app. A data registration describes what shapes the stored data respects, and what apps a user wants to use, and therefore be compatible with. An app registration defines the shape the app expects. The data itself implicitly or explicitly complies with requirements of the shape and app. One could imagine a shape pointing to the apps that support it. This makes the question of identifying compatible shapes central, which will be explored in a new task: https://jg10.solidcommunity.net/devlog/now.ttl#CanIUse I haven't implemented this structure fully yet, as the previous versions work fine for the few existing apps, and the next big change would be to work out how to manage compatibility with SAI and type registrations.
- Date Modified
- 2024-12-31
Creating a Pantry app
One of the theoretical advantages of Solid is to reuse data for other purposes. Here, I want to use recipes compatible with Umai, but connected with a record of what ingredients are in the house.
- Comment
- One of the theoretical advantages of Solid is to reuse data for other purposes. Here, I want to use recipes compatible with Umai, but connected with a record of what ingredients are in the house.
- Label
- Creating a Pantry app
- TaskUpdate
- 112458483164211094
- 112465733392006133
- 114098701387170324
- 114109918875564025
- 114121582134784273
- 114176447114010249
- 114448127339317753
- 1735681304616
Experiments in personal knowledge management
This website is itself an experiment both in being hosted on a Pod and in its design as a personal knowledge management tool. Part of what drew me to Solid (initially through Dokieli) is the vision of the read-write web, of being able to manage content and knowledge on the web, at web scale and with others.
- Comment
- This website is itself an experiment both in being hosted on a Pod and in its design as a personal knowledge management tool. Part of what drew me to Solid (initially through Dokieli) is the vision of the read-write web, of being able to manage content and knowledge on the web, at web scale and with others.
- Label
- Experiments in personal knowledge management
- TaskUpdate
- 112014684859380315
- 112394066943324839
- 113747390007971264
- 1736489359141
Exploring Solid open-with functionality
For me, seamlessly opening a resource in other apps is key to data portability. Each app provides a different view on a different combination of data. I'm experimenting with how that could work with Solid. Also see https://jg10.solidcommunity.net/devlog/open%20with.md
- Comment
- For me, seamlessly opening a resource in other apps is key to data portability. Each app provides a different view on a different combination of data. I'm experimenting with how that could work with Solid. Also see https://jg10.solidcommunity.net/devlog/open%20with.md
- Label
- Exploring Solid open-with functionality
- TaskUpdate
- 112277581865129825
- 112289475584674989
- 113291470490690547
- 113316903487910891
- 113764141176644871
- 113776326231033294
- 2024-12-31-open-with
Notes
A note editor for a folder of plain text files, inspired by the now defunct Denkzettel app. Built on Solid as a PWA with experimental UI bindings, and offline capabilities. Also see https://jg10.solidcommunity.net/notes/notes2.html
- Comment
- A note editor for a folder of plain text files, inspired by the now defunct Denkzettel app. Built on Solid as a PWA with experimental UI bindings, and offline capabilities. Also see https://jg10.solidcommunity.net/notes/notes2.html
- Label
- Notes
- TaskUpdate
- 113164549752222316
- 113175640433841721
- 113175660497432283
- 113218682736011495
- 1736486270061