Skip to content

Latest commit

 

History

History
270 lines (214 loc) · 28.4 KB

2022-09-14.md

File metadata and controls

270 lines (214 loc) · 28.4 KB

W3C Solid Community Group: W3C TPAC 2022

Present

Note: Some attendees introduced themselves but not listed above.

Announcements

Meeting Recordings and Transcripts

  • 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.

Participation and Code of Conduct

Scribes

  • Jackson Morgan
  • Timea Turdean
  • Sarven Capadisli

Introductions

  • SC: Round of optional intros.
  • SC: Been part of Solid for a bit. Started at MIT. Member of Inrupt / AC rep. Chairs the Solid Community Group
  • ME: Happy to be here. Maintains two Solid servers: Solidweb.org and Solidweb.me
  • KK: Previously at Inrupt. Now works for NORAD with the digital public good alliance. Also editor of the Solid editors group.
  • VB: Works at Inrupt and is a part of the WebID profile group
  • AB: In charge of maintaining NSS and chasing bugs in SolidOS. Also in charge of the Solidcommunity.net server
  • CP: New to Inrupt. Lead engineer for applications.
  • DD: Was working on WebID. Working at the university of ?? and interest in Semantic Web and Linked Data
  • JM: Former Inrupt, currently consulting at O.team. Small-medium size business working on Solid open source work on my free time.
  • JW: AC rep for the defense and informations agency. Just renewed their membership in W3C. Excited about the impacts that Solid is doing to make changes to the web.
  • JC: New to Microsoft. Very focused on interoperability.
  • PBA: Works as a linked data expert for the Danish Agency for Digital Government
  • TT (TallTed): With OpenLink Software (source of Virtuoso). Been involved with Solid, RDF, Linked Data, and related things for 20+ years.
  • Kristina: Co-chair of the verifiable credentials working group in the W3C
  • JZ: Around at the beginning of the web. Did work with web stuff at the UN. Been involved with open source volunteering working on SolidOS, apps, WebID profile, Diversity and inclusion, and various other aspects
  • TT (Timea): Software engineer at Inrupt. Was more involved in the Solid community last year. I work on Solid WebID profile specification, type indexes, and the occasional presentation.
  • TimBL: I invented the web 33 years ago. Seemed to be a good idea at the time, but I want it to be a more powerful platform for individuals. Inrupt is a company formed to follow the Solid ecosystem. I'm also the leader of the Solid movement (solidproject.org). Any fun time I have is spent coding SolidOS.
  • TS: Work for Fujitsu limited. I'm interested in Solid because it's related to VC and DID work.
  • Chase: I'm just a Solid contributor on github. Just here to watch the event.
  • Michal: At TPAC this week and there's a slot in the schedule. I'm just an observer.
  • NdM: Based in Barcelona, and I'm an app developer. I made Media Kraken, and I want to see what we talk about.
  • Jon: I normally join the SolidOS team at this time. I've contributed to a couple of issues over there. I'm also working on an app for Solid.
  • Joost: With government of Canada. I'm at TPAC right now. I'm just here out of interest as an observer.

Topics

TPAC 2022 Group Meetings

URL: https://www.w3.org/2022/09/TPAC/

  • SC: Agenda overview.
  • SC: 10 minute break at the top of the hour?
  • SC: Topic proposals are welcome. See section at the bottom of the agenda. If time allows, and there is interest, we'll cover it.

W3C Code of Ethics and Professional Conduct

3.1 Expected Behaviour:

Treat each other with respect, professionalism, fairness, and sensitivity to our many differences and strengths, including in situations of high pressure and urgency.

3.2 Unacceptable Behavior:

W3C strictly prohibits discrimination, intimidation, harassment, and bullying of any kind and on any basis.

Solid Vision and Goals

  • SC: 15 minutes.
  • TimBL: Timea and I have slides! (https://solidos.solidcommunity.net/public/2022/tpac-2022-solidos.pdf) The web is a platform for people to work together. The data you put online is public at one end of the spectrum, but medical data is private. In between are things like chat. Actual creative stuff is done by groups of people. The web is not set up for groups of people because it didn't have single sign on. So, you would need to sign in with services like Facebook. So, Solid is about single sign on. The things missing from the web standards stack that is now in the Solid project which was worked on at MIT and is now a community group:
    • Single Sign On
    • Universal Concepts of Access Control (We have a common standard for example sharing a photo)
    • Universal API. The typical way people build web apps is by writing JavaScript that talks to a backend and you have a specific backend for each web app. But, that architecture creates Siloed ecosystems that prevents you be being able to share things between platforms. So, Solid separates the storage from the apps. Your chat and your todo list and your wishes and hopes and dreams are in your Pod. If you want to use an app, that's fine. You can use any app as long as it stores its data in your Pod.
  • TimBL: This community group is about designing the standards for the Pod. If you have a Pod you can use lots of different apps to access it. You could be making a slideshow in your Solid Pod while your kids are watching that slide show using a different app. It's all about interop
  • TimBL: The crucial thing is security. When you design a Solid server, you have to get it right. It must be very secure. When you say "nobody has access to this thing," that's gotta work. Solid servers are like dropbox or google drive. It's not a blockchain. A blockchain is public; a Solid pod is private.
  • TimBL: Solid creates ecosystems of applications and data because data links to each-other. Integration between different apps is more straightforward than traditional apps because data is linked.
  • TimBL: We decided that if you get a Solid Pod you should get an operating system. A Pod isn't usable unless it does something when you open it. We have an OS call SolidOS. Timea will talk about SolidOS later.

Solid Technical Reports Review

URL: https://solidproject.org/TR/

  • SC: This is our technical reports index. All the work items that we have in the community group are listed here.
  • SC: As Tim mentioned, there are certain aspects of the ecosystem we're trying to cover in the Solid Community Group. We cover authentication, authorization, notifications (live updates), data interoperability, and various aspects of identification and profiles, test suites (documenting use cases and requirements).
  • SC: The Solid protocol is the bread and butter in that all servers and clients must adhere to it. It describes authentication (based on Solid-OIDC). We have other works that are work in progress, but we're looking into implementation experience and adoption. Once they're at a certain level, they'll be listed in the index here as a work item. Depending on the types of problems they solve, the Solid protocol will link to them at various levels of recommendation (like MUST or SHOULD)
    • Solid-WebID Profile Spec: talks about how individuals can describe themselves, and how they can be accessed. Since identity is a core part of the ecosystem, we're trying to get this right. We have a lot of experience in it; it just comes down to spec'ing it properly and making sure the implementations accept it.
    • HTTP Sig
    • Web Access Control Spec: A basic access control ontology to allow agents to access resources and control or modify resources
    • Access Control Policy: One model that's in the works and already has implementations as well. We're trying to figure out what aspects are compatible with WAC.
    • Solid Application Interoperability: How applications discover resources and how access is given to clients. This works with "shape trees." They give an outline of the structure of resources in a Pod.
    • Solid DID method: we have an early draft, but we may come back to it soon due to interests in DIDs
    • Solid Notification Protocol: Anything from live updates to static resources on the Pod that indicate when an activity was created or removed. For example, you can get an update when a resource changes. You can subscribe to a resource, and the server will notify a client
      • WebSocket Subscriptions: One subscription type
      • Other types are in the pipeline
    • Solid OIDC Primer
    • Other Applications interop primer
    • Test Suite: have a charter for this, so looking forward to a lot of people contributing there, whether as authors of tests or reviewers of tests. Eventually, all specs will have a test-suite and implementation reports.
  • SC: This is all ongoing work, and I encourage everyone to pick an area of interest. There are groups working on these in various repositories.

WebID Profile

URL: https://solid.github.io/webid-profile/

  • SC: The technical report is to specify discovery and data model of Solid profiles.
  • SC: Current state and next steps for the technical report.
  • SC: Call for implementation experience on profiles to date.
  • SC: Call for intent to implement the spec - TBD.
  • JZ: The webID and the Solid profile have to do with identity. It's core to the notion of Solid and the notion of presenting an identity as they relate to different audiences. On the technical side, there's been a de facto standard, but no set standard, so application developers and servers are heading in different directions. So, we need to pull in all the directions and help everyone understand how the system works. There are questions of what happens when you dereference the WebID. How do you handle multiple personas? There are a lot of questions to wrestle with, so anyone with any ideas on this topic, please get in touch and submit and issue or chat with us in the gitter chat room.

Implementation Feedback

SolidOS

URL: https://solidos.solidcommunity.net/

  • SC: Timea Turdean ...
  • TT (Timea): As Tim said, SolidOS is where a lot of the magic gets implemented and beyond. Bear with me if I put a lot of positive adjectives in this presentation. A lot of people misunderstand when we say SolidOS; they expect Windows or Linux. People who get started using Solid all go through a prior step of getting registered. You need to get yourself a WebID, and you can go to a Pod provider. Most of the people in the community have WebIDs that are "solidcommunity.net." (My webID is https://timea.solidcommunity.net/profile/card#me.) In the future, there will be more, because you can take your WebID to different providers.
  • TT: So, if you get a Pod and a WebID, what's next? The first time you get a webID on solidcommunity.net, you'll see a front-end like this one. It looks similar to what you would see on Facebook or LinkedIn. It's a profile page. You can upload a picture, a bio, friends. That's what gets you going. This is what people see on your profile, unless you take the route of creating a landing page, which is not difficult, but is not standard.
  • TT: This is what we call SolidOS. By default, it's the front-end application that is deployed on solidcommunity.net and inrupt.net. But, if you want to host your own Solid server, then you could have a different interface or even no interface. As Virginia pointed out, she has her own server and a webID. It looks completely different, so if you want to host your own Pods, that's doable too. You can have SolidOS or freestyle it.
  • TT: The fact that SolidOS is now deployed as the frontend for solidcommunity.net is just one aspect of SolidOS. We also have "Data Kitchen" which is an Electron application that can be installed on your desktop as a stand-alone. It doesn't have to be on top of a server. Data Kitchen can also work locally. If you have questions about data kitchen, Jeff is the person to ask.
  • TT: All the data that is saved on your Pod is represented as RDF. You don't have to be able to read the raw data because SolidOS takes that data, interprets it, and displays it on your profile.
  • TT: SolidOS is the biggest product in the team, but the team is much more than just this code. Beyond getting together in our free time to develop the SOlidOS code, they also have their own use cases and Solid apps and demos and prototypes. Some are integrated into SolidOS, and some may be coming in the future, because we're working on "plug and play".
  • TT: This code has a long history. This is the code that first implemented the specification. SolidOS tried it out, stumbled, and improved. I think it is the most innovative codebase in the Solid ecosystem.
  • TT: If you want to join our team, you will find a lot of vanilla JavaScript, and TypeScript, and some React, but most of it is kept good-old-fashioned JavaScript. We have different modules and building blocks as NPM packages. We're trying hard to separate different abstraction layers. If you see "RDFLib," that's one of the most important blocks. It does the heavy lifting around RDF data. Then we also have features that are Solid-specific, like authentication in "Solid-Logic" or "Solid-UI" that has things like Solid Forms.
  • TT: We just released the newest SolidOS (v5.7.3). Both solidcommunity.net and inrupt.net have the new version. This includes the discovery code. This was developed by Tim to showcase what we're doing in the WebID specification. It can help us try out ideas that are not proven. And they've left a lot of breadcrumbs for the next version of the WebID specification. So, this is where the code helps
  • TT: We have a gitter channel where we hang out and a time to meet. We have our own organization for SolidOS since spring https://github.com/SolidOS. So, if you want to ask questions, then shoot them over. Don't hesitate to ask.
  • SC: There's a link to the gitter chat. It's solid/solidos https://gitter.im/solid/solidos

10 MINUTE BREAK

  • SC: Best topic ever.

Notifications Protocol

URL: solid/notifications#110

  • SC: TimBL ...
  • TBL: The notification protocol is currently running at less than a second. And that happens with websockets. The current implementation is not secure, and can listen to if something changed. There's now a notification discovery system that allows you to find all the different types of notifications you can sign up to on a specific Pod, and my comment on that allows you to immediately know where to subscribe. If I need to go through a back and forth to load the whole server, that's too slow. I don't want to wait that long. The performance we require is greater. If you look at all the code, you can just use the way the HTTP header is used to include a nonce in the websocket URI.
  • SC: As one of the editors, that feedback is useful. Not only to know where we've gone wrong. There needs to be a test suite and implementation reports. We don't want to be at a point where we release a spec, and people don't like a feature and/or are unwilling to implement.
  • JM: Had a few clients where they needed Notifications API, Webhooks but it goes through the same notifications process. At least from my experience I haven't found complaints around the notifications API. At least from the dev side, it is abstracted, so they don't have to see the negotiation.

WebID implementation feedback

URL: https://virginiabalseiro.com/#me URL: https://dokie.li/ (where the graph is borrowed from)

  • VB: This is my webID. I've listed some things I'm interested in and other information that identifies me. I made a graph where you can see me and all the people that I know in purple, as well as things that I like and things I'm interested in. If I click on, for instance, Sarven, I can see where our WebIDs connect. We have one shared interest which is veganism. You can play around with it, and if you look at the source, it's just simple HTML and RDFa. Always taking suggestions for things to add. You can contact me if you have any suggestions.
  • Virginia's Cat: Purr, Purr, Meow.
  • TimBL: So, that's not a Turtle Profile, it's an RDFa profile and with a bit of code you can show the graph?
  • VB: Yep, I was trying to show that you could do this without knowing Turtle. You can just add things to your HTML.

Panels

  • SC: Are the panels sufficiently diverse in their participants? expertise? contributions?
  • SC: ...
  • SC: We should consider dropping grouping around panels. Focus on work items. Have weekly meeting for the whole CG. Participants can propose topics that need group input. Task Forces can be formed to carry out specific assignments for the group.
  • SC: I want to understand how diverse the participants are. Are there any thoughts? If not, I'll share a few of mine.
  • MM: I'm Web-of-Things co-chair. I want to manage IoT devices and we're looking at the Solid stuff. Web of things is also JSON-LD. We don't have any implementations in Solid, but we could try to get our current thing to satisfy the Solid spec. We're about to go to CR with our discovery spec.
  • SC: I'm familiar with some of the WoT specs. We want to see whether an application can find its way from a Solid perspective to do web of things.
  • MM: I think it's doable, but maybe next year we could try it out.
  • SC: One consideration is we can see if a weekly meeting works. We have topical discussions about the panels, and each panel has a number of work items, so maybe we need a weekly meeting that includes everyone. This would include implmenters, spec writers, and test suite authors. I feel that panels are helpful because it keeps focus, but maybe the coordination is not as strong as it could be.
  • TimBL: The panels would report in and take questions?
  • SC: It could also be a typical working group weekly meeting.
  • SC: To be able to have a working group accept it, there's a higher bar on prior work, so I'm not sure if we'd meet that requirement at the moment. So, the Solid community group can still do what it does, and whenever something in mature enough, we could send it off to a working group.
  • TimBL: The Solid protocol could be a working group. Have TAG reviews, etc.
  • SC: Yes, that's perhaps the most mature at the moment. We have issue for horizontal reviews (including TAG).

High Priorities for the Solid Specification

  • TT: ...
  • SC: Referring to Solid "specification" as in all the work items or just the Solid Protocol?
  • TT: Actually, let's scope it to just the Solid protocol only because the topic is so broad. I was reading the Solid protocol and was asking myself, "What are the big open points?" I'd love to have a refresh update.
  • TimBL: The Solid protocol, the way clients talk to servers, is described by the Solid Protocol Roadmap. There are three roadmaps. For the whole movement, the Solid Ecosystem RoadMap; also, for SolidOS, the SolidOS Roadmap. They're ordered by priority. There are some protocol oriented things on here. We don't have the status of working on things like "contacts," "calendars," "photos," and "music." So, we need another task manager to manage the verticals. A huge amount of the value of Solid comes from those client-client specs, so we need a roadmap for them, too. The Solid protocol shouldn't change too often. The important thing is to build really cool apps on top of it, that work together.
  • SC: Can you mention a few things on updates and Queries re Jackson's topic?

Updates on Queries (Local and Global)

  • JM: ...
  • TimBL: I thought we had Pod-Wide SPARQL query in the roadmap.
  • JM: what are the official efforts on the way. I heard that UGhent — it would be good to have QPF or SPARQL, and Communica is looking at global query, but it looks dispersed in the efforts done. I want to understand, what are the efforts?
  • TimBL: We should have a workshop around that. Last I heard was: quad part fragments is a sweet spot. If we ask servers to provide QPF, you can integrate them with different languages that adapt. A black box could do that. But maybe there is not so much consensus yet. A workshop is one way to go.
  • JM: I would support that. Any way to query across pods would be useful.
  • TimBL: Would you be happy with one pod?
  • JM: Initially yes, but vision is to have a global query. I was wondering waht the progress is.
  • SC: There are issues on this. Could you nudge if there is something stale? Maybe you just need to get people excited about it again.

Container Discovery

URL: #227

How easy is it for people to understand Solid (for newcomers)

  • TT (Timea): ...
  • SC: In the context of the Solid CG.
  • TT: We could divide this in different ways: How do you keep up to date? Where is the overview? How do you address this topic with newcomers? How do you address the learning experience? Are we there yet?
  • NDM: There was something called "This month in Solid." What happened to that?
  • SC: That's on the Solid Team.
  • JM: I can add that as a next discussion for the Solid Team.

Emergency Information

  • JW: Oasis has a set of emergency standards to support tracking of emergency information, e.g. tracking of emergency patients, hospital availability, resource management, and alerting. Solid might be a key enabler for the reference implementation that the Oasis emergency management people want to provide. Of course, emergencies don’t respect organization or governmental boundaries and it comes down to individuals and groups of people who support each other. For people to share their information during an emergency, but have control over the information, this might be an important use case that applies to everyone. If this is of interest, I could would be happy to follow up with someone sometime and chat about that. People could share their unique needs and resources, so people from a first responder aspect could share. I thought it might be a use case that could help sell Solid work.
  • SC: This is very minor to what you are talking about ... some of us have tested out emergency contact in our WebID profiles.
  • JW: Here are some links that might be helpful to learn more: https://docs.oasis-open.org/emergency/ , https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=emergency , https://www.youtube.com/watch?v=7eoV5XwZVO8
  • JW: https://www.oasis-open.org/committees/download.php/54960/EverydayEDXL_ver_1c.pdf is a paper describing an emergency management vision that might be enabled by Solid.
  • JM: I'd love to hear more about your work on emergency. Setting up a separate call would be great.
  • TimBL: I know I certainly put together publicising my Covid status. If everyone has solid pods, they can check that stuff. So, obviously, as you see, crisis happens, it is not going to be same size and shape as another, and things have to be simple to use. Famous apps developed by folks in Kenya for managing disasters in different forms. There are also mappings of quake damage and so on. So, we put :) emergency contact.. but also if I'm lying upside down on the street, I want you to know about my allergies. If people create their own taxonomies.. in the UK ??? some things that need to be put on / indicated on ??? shelves. They don't have URLs or taxonomy for it. Really surprised but I couldn't find it. But maybe I didn't look hard enough.
  • JW: It turns out from my thinking that it becomes an individual relevant thing. What languages you speak, or do you have someone in your household that needs special attention — that kind of attention isn't really maintained or tracked or worried about sharing. It is a perfect kind of application perhaps for the work you are doing. It might be fun to talk about it and develop some examples and see how solid supports that need.
  • TimBL: Languages we certainly do at the moment. If my Pod doesn't have the label to display something like a skill in language you understand, SolidOS can go back to the public ontology and get a label in a language you do. I fill out my profile in English, you read it in Swedish. People will realize that it's useful to put languages in your Pod. They may find that just languages is a motivation to do it. They will get better service when they sign in with Solid.
  • SC: JW, can I ask you to have a look at https://github.com/solid/user-stories and https://github.com/solid/specification and create an issue, if there isn't one to the depth you are interested in, to continue this discussion? Feel free to ping the gitter channel to have a meeting and so on.
  • JW: I might reach out to you individually to get up to speed. I will do my best.
  • KK: There is a topic that we've discussed a little bit: if you're about to die, you're not in a position to change your ACL. You would want to have the person who's helping you access your data. And this brings up a few other problems like "What data should have been in there?" It seems to me, those are the key problems we'd have to address for it to be useful for emergency services.
  • JW: I have a paper that describes a vision of what sharing environment could work for emergency management. A follow up could be how that works with Solid.
  • SC: Also a good topic for the webid-profile team. Factor it in or allow the work to be extended with emergency information.
  • TimBL: One use case: On the back of your phone is a QR code of a Solid ID. If there's an emergency, an emergency service would have to prove that they're an emergency service, and then it can grant access to your medical data. Making the QR code of the profile easily available would be good for emergency services.
  • SC: Is there a property for QR code?
  • SC: In the DOM only or in the profile description?
  • TimBL: No. Just the profile code currently generates the QR code. There's no statement in the profile. It's just the SolidOS UI generates it.
  • SC: We may need to define the property if we want that to be accessible without JavaScript.
  • TimBL: Who do we trust to sign VCs? You should just be able to fork an app, put it on the web somewhere and sign it. And then my OS loads the code because it trusts you. There's a lot of interesting stuff.
  • JM: Why we may need VC-based access control.
  • SC: Some say we may need an "authorization framework" (cough / nervous laugh): solid/authorization-panel#121
  • TimBL: :)
  • TT (TallTed): Shades of PGP signing parties, but it fell apart because it was too limited to technically extra-savvy people.

Propose Topic Title Here

URL:

Proposed by: [name][url]