W3C Solid Community Group: Weekly

Present

  • Hadrian Zbarcea
  • Alain Bourgeois
  • elf Pavlik
  • Rahul Gupta
  • Jeff Zucker
  • Michael Toomim
  • Jesse Wright
  • Theo thhck
  • John Kirkwood
  • Erich Bremer
  • Pierre-Antoine Champin
  • Ted Thibodeau
  • Sarven Capadisli (joined at 14:50 UTC)

Announcements

Meeting Guidelines

  • W3C Solid Community Group Calendar.
  • W3C Solid Community Group Meeting Guidelines.
  • No audio or video recording, or automated transcripts without consent. Meetings are transcribed and made public. If consent is withheld by anyone, recording/retention must not occur.
  • Join queue to talk.
  • Topics can be proposed at the bottom of the agenda to be discussed as time allows. Make it known if a topic is urgent or cannot be postponed.

Participation and Code of Conduct

Scribes

  • Theo
  • elf Pavlik (backup)

Introductions

  • Michael Toomim: I work on Braid and collaborated with Theo on braid demo.

Topics

Braid demo

  • Th: I have been hacking with braid and was able to make a POC on the community solid server.
  • Th: I discovered braid last year during Solid Symposium. Thanks to Michael and Greg for help.
  • Th: (sharing screen)
  • Th: I didn't deal with auth; this is public write resource. If I edit the resource, it will be updated directly, will show you in my local filesystem.
  • Th: If I open it in a private/incognito window and open the same resource, you can see that it updates in real time, so we have reactive synchronisation. If another agent modifies it directly in the pod, it will not update in the client. I will demonstrate editing the file directly in the filesystem.
  • Th: What matters with braid, I just have to add the middleware to CSS from 'braid-http'. This adds few functions to the request and the response. I also have to handle the GET and PUT requests to handle braid subscriptions.
  • Th: There is a github repo with this demo
  • HZ: Can you share how this could be used. Also in LWS there are few use cases about using CRDTs with storage.
  • Th: I look for better developer experience when writing Solid app and reactive applications. It is about being able to update value and see live updates.
  • eP: ActivityPods team is working with Jackson Morgan (LDO) on reactive stores for React, Svelte and possibly Vue. It will be LDO based and aims on good reactive DX with those popular frameworks.
  • Th: My insipirations is framework jazz.tools which aims to ease development of web applications. It handles authentication, data storage etc. I think we could have something similar for Solid. One missing piece was data synchronisation and reactivity. I don't mind what we are using but we need to have good DX for synchronization.
  • JZ: I'm curious about shapes and is it in sync with chat draft for client-cilent?
  • Th: For now I haven't dig into that. It would be interesting to see how it works with the chat draft. Chat is an application where you want to have real time synchronization but I'm not there yet.
  • JZ: Is that stored in RDF? Braid just handles the sync, it doesn't care about the format.
  • MT: You can open profile card ans show RDF there.
  • Th: Now I'm pointing to my profile card, braid gives me
  • eP: Your demo doesn't really append messages it replaces the content of the resource
  • Th: The chat title is confusing, currently it replaces the message, that 'chat' label is just accidental from initial experiment.
  • MT: Right now there is no interpretation of content. Next step would be to add it and work with structured data like RDF. You will be able to parse RDF and send
  • eP: Have you tried other mechanisms like Solid Notifications with Streaming HTTP and Websocket. Also Rahul had PREP in NSS.
  • Th: Braid is already including everything I was looking for.
  • eP: I don't promote one solution over the other. Just looking for what we can learn from all those approaches available.
  • RG: Prep is in NSS, I could demo that if needed. This is very similar to Braid, PREP allows for content negotiation to happen. I find all the HTTP based approaches very similar.
  • Th: I have not experince with NSS, I'm more inclined to work with CSS.
  • RG: I hope we can do a lot more at next IETF, and prepare more material.
  • AB: What is objective of Braid? Is it about HTTP being to slow?
  • MT: HTTP is state transfer protocol and braid extends it to synchronization, where one can subscribe to resources. It starts with basic subscription feature which you can see here. If you want you can extend it with full CRDT with concurent writes and offline first mode. There is also versioning, patches and mergin. It is a collection of 4 extensions to HTTP. You can use it with any content type.
  • RG: You may want to explein the 3 other extensions for everyone to understand it better.
  • MT: Sure, it wasn't demoed here. What you saw was subscriptions. You can also do versioning and DAG like in git. There are also patches which can express changes. If you put those two together than you can have collaborative editing. You can define a merge type as well, using headers and HTTP mechanisms. We have few ways of looking at RDF. We are happy to try it furter and collaborate with people more experienced with RDF.
  • HZ: With CRDT you end up changing resource by appending, which is a stream of changes.
  • AB: Does it improve performance of HTTP? There is a question about capacity of servers to deliver more performance. One was going from HTTP/1.1 to HTTP/2 but there are more issues.
  • MT: It is better performance than pulling the resource, even further if you use patches and just send deltas. It holds multiple HTTP streams open. You can do GET and also subscribe to updates, this will keep the responses open and send updates. That becomes more performant with HTTP/2 which multiplexes responses over the same connection, similar HTTP/3 with QUIC. This works well with evented servers slike node, less with PHP and Python which have different architecture.
  • RG: HTTP in contrast to Websocket, it supports intermediation. In that way it is a better sollution than Websockets. It may change with Web Transport.
  • MT: Good point, you can also have caching with CDN network. When you have dynamic state and use websockets the caches are just skipped. With HTTP my client can act as a cache to another client. One can synchronize offline edits. CRDT features allow cache to become a peer.

IIW 40

  • HZ: IIW 40 took place last week. I'd like to share a few impressions that affect Solid.
  • … Dmitri Zagidulin had a very interesting take on wallet attached storage in which it covered everything from WebDAV, ipfs to Solid and LWS.
  • if you have any question reach out of ask me later.

FedID WG/CG meeting update

  • eP: quick update from last week full day hybrid meeting
  • on friday meeting hosted by google. Good news: lot of support for IdP registration feature. Should move slowly to fedcm core. CR should be release in 3 month more or less.
  • suggest to add IdP registration at a "at risk " feature that they can remove later
  • will reach to fediverse, indieweb etc.. the more we are the more chances
  • mozilla is working in implementing in firefox, ( also with another 'lightweight fedcm' version ) and now firefox dev will join the authors which seems like a positive point.

Implementation Experience

URL: https://www.w3.org/policies/process/#implementation-experience

  • HZ: until LWS implementations pick up, it's up to the Solid CG to encourage interoperability. The Solid Project is governed by ODI, we need to figure out how to continue to publish interoperability tests and test results.
  • CG didn't pay attention to that since a while
  • Tim ask if we are maintaining test suite
  • eP: the next step would be to take CG input and start evaluating then in contrast to the requirements. Have a coverage between proposal and requirement. WOuld be a good reference to have.
  • HZ: we will have to update public resources on solidproject.org
  • HZ: I there something we could do ?
  • HZ: its the CG responsible to publish the result of the tests, can the CG have a space on solidproject.org ( tht the CG will manage ) to publish those result ?
  • JW: Against which server do you test ?
  • Alain Bourgeois: against any solid server
  • eP: there use to be a task force for the test suite that seems do not be active anymore . we could see if anyone could be interested in participating into that. https://app.gitter.im/#/room/#solid_test-suite:gitter.im
  • Pierre-Antoinre: I think testing specific deployment could make sense, as config can play a big role in interoperability. Both makes sense.
  • TailTed ( chat ):The point of interop testing would be between codebases, not deployments..
  • TallTed // Ted Thibodeau (he/him) (OpenLinkSw.com) says:W3C testing is absolutely codebase interop. Deployment interop failures would/should generally be considered a cnfiguration error.
  • JW: what outcome are looking for ?
  • eP: I agree with Ted, in more in the context of the WG. If in context of CG there is value in tracking how alternatives works ( with CSS extenssion )
  • JW: in terms of tracking, JZ has the catalog. I suggest solid server instances links to there config, so we can track which feature are used. Also would be great to track which application are interoperable with which servers.
  • JZ: +1 , should be able to see which tests rely to which server, and which server rely to which tests.
  • SC: Solid QA . It is the responsability of this group as a whole to do the QA, and it wasn't just about the panel. The panel helped to produce the document that can be useful to the group and the WG down the line. That is the QA document to on how we approach test coverage and publish implementation reports, express specifications, among other things. LWS WG charter references the Solid QA.
  • Ted: Solid CG has specified very little. If we have a list of requirements, we can have interop tests for each requirement. LWS is storage that is linked on the web. We have so many requirement for that. It is not a Solid WG; it will not deliver everything that Solid requires at first. [some stuff are huge for solid but not for LWS, so won't be able to satify all the requirement]
  • eP: +1 . might be some nuance in the community group that the wg. In the incubation space, a lot of alternatives that are better tested individually.

Practitioners & ODI Announcements

Backup/Restore Issue history

https://github.com/solid/specification/issues?q=is%3Aissue state%3Aopen "copyright" in%3Atitle

https://github.com/solid/specification/issues/454#issuecomment-2666339495

  • RG: Some previous participants have been deleting their comments in a high-handed manner (I am not against somene making an edit or even deleting a comment because they changed their minds). But when it is done after many years, this behaviour is disruptive. Valuable loss of context for those who joined the CG later. Can we please restore those comments, unless there is some exceptional legal reason to let them remain deleted.

QUERY to fetch Auxiliary resources

https://github.com/solid/specification/issues/724

SHQ Notifications

https://github.com/solid/notifications/pull/201

Curated list of known CSS extensions

https://github.com/CommunitySolidServer/CommunitySolidServer/discussions/2024#discussioncomment-12837567

  • eP: Joachim responded

Data domains: contacts and calendars

https://github.com/solid/contacts
https://github.com/solid/webid-profile

  • eP: suggestion to prioritize work, including aligning contact information in address book and discoverabel from person/organization WebID
Select a repo