25 Sep 2024 - TPAC Breakout Session
Present:
Minutes
Laurens: Welcome to this breakout session. I’m one of the chairs of the Linked Web Storage Working Group, together with Aaron Coburn and Eric Prud’Hommeaux. Let’s start with a round of introductions. After that we will go to the mission of the WG and discuss use-cases for the WG.
Ora Lassila: chair of the RDF-star WG, have been doing RDF for a long time.
Yuta Hagio: NHK, Japanese public broadcast group.
Wonsuk Lee: ETRI. I was an editor in the Automotive WG. I created a project related to Solid. Interested in the future plans for LWS.
Rahul Singh: Microsoft, learning about the WG.
Pierre-Antoine Champin: W3C/INRIA, staff contact of the LWS WG.
Rahul Cupta: contributor of the CG for 4 years, focus on the Notification protocol. I have some use-case suggestions, drawn from my own app.
Aaron Coburn: working with Inrupt, involved in Solid for a while. Co-chair of the WG.
Maxime Lecoq-Gaillard: I work at INRIA with Pierre-Antoine Champin, about indexing in the Solid eco-system. I’m developing Solid apps for farmers.
Niklas Linström: I work for the National Library of Sweden, member of the RDF-star WG. In libraries we work hard to get rid of silos using RDF.
Sarven Capadisli: author/editor of most specs that are in the charter, former chair of the Solid CG. Working on Solid since 2015. I work on implementing these specs in applications. I’ll share a category of use cases.
Ted Thibodeau: OpenLink Software, involved in RDF / Identity / Security in W3C for ~20 years.
Virginia Balseiro: one of the chairs of the Solid CG.
Evan Stade: Google, Chrome.
Laurens: Let's jump to the mission statement. The mission of the WG is to decouple identity, storage, and applications. The aim is to redecentralize the web, by standardizing a protocol to realize that loose coupling. The work of the Solid CG will be an important source, but we are interested in input from other communities.
… Our working group will likely start by writing a note capturing use-cases. Please raise your hand in Zoom.
Sarven: I can start. Laurens, you mentioned that the WG will start with a group note, but there was no WG meeting to agree on publishing such a note – not to be picky. I’m sure it’ll be agreed but just saying.
…Much of what I’m about to say is based on implementation experience with https:/dokie.li/ but it goes beyond LWS, Solid, IndieWeb and so on for decades, and hopefully it’ll be clear:
… Authoring tools are essential for creating and co-creating accessible content on the web. It's important to acknowledge that a diverse group of users, in masses, today consume and produce content using various authoring tools and interactive documents. A wide range of creative works such as articles, reviews, research papers, resumes, journals, slideshows, and even technical specifications and interactive content are produced using these tools. This category spans across industries. I should point out that this meeting's minutes are being taken on GDocs, an authoring tool.
… It's impossible to discuss this without mentioning a core principle of the W3C: accessibility. Ethical Web Principles clearly say that the web platform and the tools we use to create content must be accessible "for all people." I may be preaching to the choir when I say that but the W3C has established guidelines for Web Content Accessibility (WCAG) and Authoring Tools Accessibility (ATAG). Documented use cases go back decades and are still being worked on.
… In the context of Linked Web Storage (LWS), coordination between the two general product classes - applications and storage must ensure adherence to the spirit of the web. More specifically, it is critical to ensure that both human- and machine-readable content are available and accessible.
… So, I'd like to see that LWS takes even further steps to ensure that content made available from storage fully meets W3C standards and community expectations. If LWS doesn't take content authoring into account, and with implementation experience, there may be no reason for the masses to ever bother using the LWS stack.
Rahu Guptal: Computers were invented to do knowledge work. One major problem is that the Web has a high barrier to entry to publishing, in the way Sarven has pointed out. This is what forces people to go to platforms in the first place rather than publish under their own domain and storage. We need to make it very easy for people to collaborate. We need to make the protocol accessible to users, the way this requirement translates to Solid is to enabling users to build their own HATEOAS - paths through hypermedia that their readers can follow.
Laurens: no more raised hand. From another perspective, every technology has its blind spots. One key use-case that I’m lacking in the Solid stack is a standardize mechanism for requesting access of someone else’s data. Currently, there are out-of-band ways to do that, there are mechanisms to grant access, but not the other way around. This is critical IMO to provide a good user experience.
Ben Goering: I would like to be able to use my Solid/LWS storage to store content that I can then share with ActivityPub. Also binary data.
Ted Thibodeau: The problem of requesting access is a broad topic. There is reading, writing, appending, etc… You don’t always know what exists, or the exact kind of access you need. Having to figure it out to start with is not a good user experience. When you encounter some document or other data, you (or your app) should be able to tell the hosting system “I want read/write/execute/other access. Do the right thing to request it from the owner.” We've implemented a degree of this in OpenLink Data Spaces for more than a decade.
Ben Goering: about requesting access: you can grant access to an app, but then after a while it starts abusing that permission. You need to be able to revoke access as easily as to grant it. Auditing is also important.
Laurens: auditing has not been largely studied, and it is important.
Maxime: I can talk about the work we do with farmers. For instance I can have an application to manage my products and another application to display my products on my website. When I change a product in the first application, I want the change to be reflected in the other application.
Laurens: interoperability between applications is an important part of our charter. While the group is named “Linked Web Storage”, the term “Linked Data” is used only 3 times in the charter. What is our position on the use of Linked Data to ensure this interoperability, at the risk of poking at the bear?
Niklas: One of the big problems we have in libraries in moving out of silos is to try to replace the behaviour of downloading subset of data and keeping them, rather than linking to the data where they are. We know that we need caches and notifications of change. Not sure if that’s relevant here, if not this should be put in the charter.
Laurens: notification is mentioned as a potential topic for the WG in our charter. Caching might also be interesting.
Sarven: maybe we are going too deep into the requirements. The user is not going to care about the internal format. They are going to click on things, and things should work, without the user being aware of what’s involved. After the use-cases, we need to define interop precisely - what are the “classes of products” and what products are expected to interact - what constitutes interop. We will see at this point whether this is JSON-LD, HTML, or something else…
… So far in the Solid protocol, we use Linked Data to help applications navigate to resources. Besides that, storage is agnostic to the format of data.
Laurens: I like the idea of interop as a relationship between product classes.
Rahul Gupta: maybe we should also look at interoperability for transport. Currently, everything is based on HTTP. Will this still be true in the future? Requirements should be agnostic to the protocol, and then an HTTP “binding” can be defined.
Dmitri Zagidulin: (one of the engineers on the Solid Project in 2016-2017). One use-case is Wallet+Storage. Verifiable Credentials and Decentralized Identifiers need wallets to work, but wallets need interoperable storage. Encrypted storage to store VCs, but Solid/LWS can help exchanging those VCs. Example: Instead of sending my diploma (a VC) to a company, I can give them a link to the VC stored in my storage, where a presentation app can disclose only what I chose to the viewer.
… Need for portability: as a user of social media (Mastodon, other), we don’t want our data to be stuck in a given domain. Come to the Data portability breakout later today. I need interoperable storage that I can take from social media provider to social media provider. From the perspective of web developer, every database system has an API, an access control mechanism, but they are all incompatible. With the LWS storage, we have an opportunity to fix this, by making interoperable storage not just for triple stores but for other kinds of databases.
Aaron: I’ve been working with wallet-related scenarios. This category of use-cases is going to be key. The question of portability, which Dmitri brought up, is also very important. We need to think about how we identify data, and do it in a way which fits models of data portability and global data identity.
Dmitri: I hope this group will explore content-addressed data (with relation to user-centric storage)
Laurens: in order to do access request, content-addressing is useful, as you don’t necessarily know where the data is.
Ted Tibodeau: back to HTTP being the lingua franca. It is the only protocol with content negotiation, which is a super-power. You can ask for different formats for a given resource, the server may decide to give you that, or something similar, or something different. Regarding interop: there are many standardized formats (for calendar, contacts, email,…), which allow the data to be moved from one app to another. This has not been brought to its full potential yet. [refers back to Ted Nelson].
Laurens: the relationship to CarDAV, CalDAV was raised as a comment on our charter. We need to figure that out.
… WebIDs were also discussed, and their relation with other kinds of identifiers, e.g. DIDs. DIDs are solving a number of problems which the WebID spec can not currently. Also WebID does not have currently the level of maturity to be a normative dependency of a REC.
Sarven: I agree that it’s a good consideration. The group may need to be careful about its scope, in the amount of time that we have. We have input documents, and the possibility to take another route on the other end of the spectrum. Balance with incubation. It is hard to say if a decision we make now will be a good decision in a few years.
Aaron: I wanted to add that this is where Use Cases and Requirements are going to be very important. This is not about whether we like technology A and B, but about how we can accomplish the use-cases.
Ben Goering: there is an emerging trend in decentralized technologies for “local first”. Things should work even when I’m not connected to the internet. For web pages to provide that property, it needs a lot of custom code. Data stored locally, and eventually synced with your pod.
Pierre-Antoine: Ben, look at Aerogel, developed by Noel de Martin.
Laurens: [lists the different topics that were brought up]