I asked @NoelDeMartin, @Vincent, @Timea, and @timbot1789 about Solid interop and they shared their thoughts.
Thanks, everyone, for gathering this critical feedback!
Dependency management in general is a bit of a mess, specially in JavaScript -.-. I think the problem arises from the fragmentation in the JS ecosystem, there are just too many tools and environments: Node, Deno, Bun, Webpack, Vite, Rollup, ESBuild, etc… All of that coupled with the fact that JavaScript is supposed to be backwards compatible, and add TypeScript into the mix, and you’ve got a big mess
. But it seems like most JS devs feel the same way, so I’m definitely not alone :/.
As a dev community, we can and should help one another overcome those problems. Since this is not specific to Solid, I would prefer not to discuss any specific nuances of any particular programming language on this thread.
So, while I have no problem with creating the data model myself, I didn’t make time to share my vocabularies or shapes because I felt the ecosystem wasn’t ready for it anyway.
Since we want apps to interoperate, no developer should be creaing the data model themselves. As Solid CG, we are making close to no progress on client-to-client specs. Since Linked Web Storage WG will be taking over the core spec work, I hope Solid CG can prioritize answering the developer’s needs for standard data models.
a lack of standardized discovery process by which an app can find a pod or determine what data is inside. Type Indexes attempt to solve this, but as a type index is not enforced by the server, it requires each app to enforce the type index. This makes the type index untrustworthy, as an app needs to be able to trust that all other apps using the type index are updating it properly. I am also aware of the existence of SAI, but it’s unclear to me how to use it, or if it is supported in all servers.
One challenge is that the main story for interoperability is not clear, and there’s no “official way” to do it. So each developer has to decide what they want to do. There are basically two possibilities now: Type Indexes and Solid Application Interoperability (SAI). Type Indexes is the only one you can use in practice, so it’s the way my apps work, but it’s still a draft and has some limitations, so I understand why some people don’t use it yet. SAI is also still a draft and requires server-side implementation, so even though I’m very excited about it, I don’t think I’ll use it until it’s part of the official spec and supported in most pods.
I have submitted a new proposal to NLnet to wrap up my work on https://sai.js.org. As part of it, I want to rewrite the included Authorization Agent service as a CSS extension (which still can be deployed separately). This would allow any CSS deployment to support SAI out of the box.
To me, interoperability means different apps can access the same data in new, novel ways that fit their use case. A to-do app allows you to create calendar events for each to-do item without opening your calendar. Emails can be opened with either a traditional “inbox” interface or an IM chat interface. You can message your doctor, and then in the chat, share your medical records with them.
I see it as an essential aspect of client-to-client effort. Some types of data are very specific for a given domain: prescriptions, blueprints, milestones, etc.
At the same time, various types of data are so common that they appear in most domains: contacts, calendar events, messages, etc.
It will most likely take a lot of effort to structure that work in a way that different domains can be modeled by the experts in those domains while, at the same time, there is an overarching effort for those common types of data.
This contextual aspect should also be captured in use cases when it comes to authorization and access policies. For example, a hospitality exchange app might get access to messages related to a hospitality request but not messages between users and their doctors related to their therapy. In SAI, there are Inherited Data Grants that rely on the relation in the data instead of expecting users to create artificial directory structures. There is a lot of feedback on the design of containers in Solid. Most likely, the LWS WG will be stewarding the any future re(work) but Solid CG should still help with gathering feedback and documenting various use cases.
There is a lot more to follow up on in this report. I proposed it as a topic for the Solid CG weekly plenary tomorrow. I hope we will seize the opportunity and incorporate this feedback in the ongoing spec and implementation work.
If anyone is in a position to help, I’ve been trying to document the Umai data model using shape trees and have gotten stuck on the right way to describe the presence of four different shapes in one document:
1 Like