Skip to content

Latest commit

 

History

History
253 lines (161 loc) · 28.7 KB

2021-10-27.md

File metadata and controls

253 lines (161 loc) · 28.7 KB
Raw

W3C Solid Community Group: W3C TPAC 2021

Present

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

  • Justin Bingham
  • Sarven Capadisli

Introductions

  • Tim Berners-Lee: the Web Developer.
  • Justin: work on Solid with other editors, focus on interoperability between apps and data.
  • Henry: I am working on a solid server and client libraries in Scala. Participating in authorization-panel.
  • Eric Meyer: doing standards for a while now. I am here as observer. Here with Igalia and self.
  • Jeff Jaffe: from W3C, not a Solid implementer, but hearing nice things about Solid. In general, am interested in the importance of decentralisation. I am mostly curious about its maturity, on how it can moving on from incubation. So I am visiting TPAC meetings randomly. Here for short time. Thanks.
  • Kjetil Kjernsmo: Work for Inrupt on Solid. Been implementing node-solid-server. Currently working on specs. Doing implementation on the test suite/conformance testing. I am juggling quite a number of things.
  • Pierre-Antoine Champin: watching Solid from a distance for a while now. I am interested in catching up and getting more involved. I have been involved in Linked Data/JSON-LD 1.1. Currently a w3c team as a fellow - related to data. I am here with my w3C hat on to get a sense of this group and how to move things forward inside W3C.
  • Alexander Flenniken: Work at Boku(sp?) - Interested in efforts that are future-focused and looking to learn about the latest goings-on with Solid.
  • Dirk Roeleveld: Web developer, part of the Solid CG (member of 2 years) - excited about Solid and where its heading. I believe its heading in the right direction - keen to see what's next.
  • Matthias Evering: Private interested person in Solid. Not a professional programmer but acting as a pod provider, and finds the concept persuasive (interested private enthusiast)
  • Peter Bruhn Anderson: Works for Danish Government Agency as a linked data architect. Looking to promote solid as a solution for different wallets. Inspired by what's been happening in Flanders
  • Sarven Capadisli: Been with Solid for a while, originaly as part of MIT project. I started working on applications and recently have been spending more times working on specs. CG Chair and Editor of several solid specifications.

Topics

TPAC 2021 Group Meetings

URL: https://www.w3.org/wiki/TPAC/2021/GroupMeetings

  • SC: Agenda review.

  • SC: 5 minute break at the top of the hour?

  • Sarven: Following vision and goals, will review technical reports.

  • ... 0.9 milestone and 1.0 afterwards. Will look into protocol tests following that.

  • ... added a topic on panel participation - as there are a number of panels focused on various areas (authn, interoperability, test-suite)

  • ... touch on 1.0 (how do we get there)

W3C Code of Ethics and Professional Conduct

  • SC: 2 minutes.

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.

  • Sarven: Have noticed others in TPAC are reviewing W3C Ethics / Code of Conduct
  • ... Reading from sources above
  • ... Always a good reminder to review these things for the health of the community

Solid Vision and Goals

  • SC: 5-10 minutes.

  • SC: TimBL to give a reminder/overview on Solid vision and goals.

  • TimBL: Explanation of where Solid is depends on who you're explaining to

  • ... People from different backgrounds (some with deep knowledge of protocols and CGs, others are new)

  • ... I will try to give lots of different explanations of Solid to cater to both audiences (this is hard :))

  • ... Solid is like a third take on the web - 1.0 was a web of docs. People talk about 2.0 as user-generated content (for instance, social networks) -- started as blogosphere (better) and transitioned to large companies that dominate. When you want to do something / exchange data, you always have to interact with major dominant parties. No real interoperability between these data silos. Solid is a dramatic retake on this. Imagine a world where it is not like that. Imagine going to these major sites and they ask you first where to store your data? We are decoupling the app from the data. Data is stored in Solid Pods (data stores). The data stores are compatible, and the Solid Protocol is the API layer as the interface / standard between clients and servers (apps and storages). Also, it means that, because the storage is responsible for the sharing and access control, the storage has to have the concept of people in groups, read/write access, etc.

  • ... Imagine your favorite social networks were all broken into pieces and connected interoperably, and all compatible over a protocol. Solid Protocol identifies how clients talk to servers. When clients talk to servers, they speak in graphs. The server doesn't care what app the client is. The other parts of the spec allow clients to agree on how data is stored in a pod. For example, if an app is getting access to your contacts, this is the shape to apply. Specs which this community group has to produce are Solid Protocol (crucial - must be robust with thousands of tests and many implementations). There are Application Level protocols where context needs to be shared with each other. If you want to put together a covid tracker or festival organizer, you should be able to write an app that writes to your and others PODs, and roll it out. ... The Solid Community Group works by having a bunch of panels (groups within the CG) -- Authentication (Authn), Authorization (Authz), Interoperability, Notifications, Test Suite. We need to determine whether we need any more. There's also a day-to-day management group of people that manage the website, manage the community pod provider (solidcommunity.net).

  • ... Solid Protocol should be something that changes relatively slowly. Once you are able to store anything in a pod and share with whoever you want - anyone can use it. It is complete and powerful. One can produce any type of App. We want to get to version 1.0, and then build apps so they connect to each other, which will be also a lot of work, but we're in a place now where we should be able to close out the core protocol (though we will continue to add features). We currently have 6-7 interoperable implementations of the server. Usually in standards work, 2-3 open implementations is considered good.

  • Jeff Jaffe: In a word - Solid is reimagining the web (or at least a piece) around greater decentralization. Different people interpret decentralization differently. In recent years, there have been a few communities in W3C that have been active around decentralizations: Two I know of are the decentralized ID community (whose spec was proposed to recommendation level); and AdTech Companies who think there should be more decentralization of who controls advertising. (I have been active in discussion groups, but am not working on a spec).

  • ... What's holding us back? In Solid there's a view of decentralization. There is a protocol that has been improved for several years. How do we get from where we are today to be a more active effort in W3C?

  • TimBL: First answer - Important for the Solid CG ... Solid is about re-decentralization, like giving everyone their own website (for data). Blockchain is about giving people a place to put stuff on the chain... But solid and blockchain are very different in many ways. When you get a Pod, there's a market for Pods. They are every shape and size. You can decide to transfer your pod provider to one that provides more reliability and bandwidth. You can point your domain to somewhere else... or you can host it yourself. Every Pod is different. People invest in their Pod just like they did when they had a website. The QoS for Solid Pod is the market. In Solid you choose where your data is stored. With Blockchain you all use the same storage, so you don't choose. When data is shared among the group, everyone gets the same level of service - and reliability is directly tied to that system. On Solid, when doing video games, those the data can be stored on very fast/cheap/unreliable hardware. You can pick your blockchain but once you do you're stuck with the same QoS as them, and all the data you put there will last until that community stops maintaining it. With a Pod you can choose. It is tough to put large amounts of data on-chain. Solid designed for it. Now we have said that if someone can get a DID system working and provide a login with public-key based system and people are using it, and you want to plug into Solid - sure - but we won't hold our breath. We might develop other login systems. But if a good DID (or similar) solution comes along, then great, we'll use it.

  • Henry Story: My summary of the differences: Blockchain is a global "one truth" database whereas Solid is a multi-agent system that allows incompatible or contradictory points of views to coexist together. The Difference with Indieweb is that Indiweb concentrates on getting people to write semantics into the HTML whereas Solid is more about building apps that then write the data, ie turning every App into a web browser. So Solid is more software-engineering focused in that way.

  • Justin: two things in practice: 1) Solid and Blockchain isn't either/or. They do different things. We tend to apply them for different needs and purposes. With BlockChain, it'd be tough to store diverse data.. so with Blockchain networks they are separate data vaults. Nevertheless those communities could benefit quite a bit from Solid's standardised storage and interop. It is a real opportunity for different proprietary chains. For identity, in an abstract sense: however you're proving that identity, may have different data stores. Typically in Web 2.0 data is tightly coupled with apps, whereas in Solid, we can have different apps interoperate over the same data. For stores and identity we have similar equivalences: people can have several different storages as long as they can interop, we could realise a 'web 3.0' I believe.

  • TimBL: Answer to second question -- what's holding us back? This is a good discussion for everybody. With Flanders government deciding that everyone should have a Pod, and other countries are thinking of giving their citizens pods -- if it gets adopted country by country, we don't need to wait, because citizens are getting it and it gets provided to them. To what extent should we ramp this whole thing up in W3C? Should it be an interest group managing a bunch of Working Groups, rather than a Community Group managing a bunch of panels? Could we rope in great engineering talent across W3C by organizing differently?

  • Sarven: panels have a huge load.. and they could in fact be their own WGs.. if there is interest.

Solid Technical Reports Review

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

  • SC: 5 minutes.

  • SC: The stages of work items need to be updated with expected completion.

  • SC: PRE-PROPOSAL: PR to https://github.com/solid/specification and/or add to each panel's agenda.

  • Sarven: In Solid we try to follow W3C process as much as possible. ... In TR we list all of the specs that are work items being looked into across panels

  • ... some are editor's drafts that are still being committed

  • ... note the table needs some updates on dates/status. Part of the topic here is to understand how we can go ahead with updating some of this information and see whether we could ask each panel / spec editors to PR this document (TR/index) with expected dates of completion. Can have an agenda item in each panel where they can discuss with an agenda item on each. Dates are important as to when they are in a more mature state, but also they can incubate longer.

  • Justin: active in authorization and interop panels, for interop the proposal to PR the TR doc seems reasonable. It might be the same for the authorization panel as well. access controls and shapetrees. process seems reasonable.

  • Henry Story: Tim emphasized the importance of a stable platform that works together. I think that's important - the web has involved slowly by HTML adding new tags to the format and slowly evolving. I would like to know if at some point we can speak about integrating ACP and WAC so that we don't end up with two different access control systems. I don't believe that they are conceptually that different and so I would like to understand what the strategy is there.

  • Jeff: Trying to decode the vocabulary - but support there is an interesting status called Ecosystem Proposal. Is the perspective on the CG to get to Ecosystem proposal and that becomes a pseudo-standard for the ecosystem or does that status align with CG Final Spec as a launching point to propose something for formal standardization.

  • TimBL: Ecosystem proposal / spec is just the overall architecture of the ecosystem into which the protocol fits and other domain-specific specs fit.

  • Jeff: I see various specs have the ecosystem proposal as the next stage - what does that mean?

  • Sarven: Let us ignore the "Solid Ecosystem" work item

  • Jeff: Referring to "Next Stage" being Ecosystem Proposal. Where in the hierarchy does that fit?

  • Sarven: Good question. What was intended was that we have one repo (solid/specification), and everything that makes it there is deemed to be mature and would be published under the TR/. Panels are incubating these specs, and when they feel they reach a certain maturity, they create a PR to specification repo -- that status is what is referred to in the next stage ecosystem of "Ecosystem Proposal". Anything that makes it into the solid/specification repo is mature enough.

  • TimBL: It might be worth going to the ACP people and asking about common (JS?) API (whether in WAC or ACP). Going back to ACP people and asking whether they could declare if "this" in ACP means the same in WAC -- that could be productive.

Panel Participation

  • SC: 10 minutes

  • SC: Are the panels sufficiently diverse in their participants? expertise? contributions?

  • SC: Information flow between panels and other teams.

  • SC: Concerns with Solid process (or lack of it) and other matters.

  • SC: Request that Solid Diversity, Equity, and Inclusion Team (DEIT) to review Use Cases.

  • SC: Actionable suggestions welcome.

  • Sarven: Most CGs have one meeting for the whole group. The Solid CG has different panels with different topics and participants / backgrounds. Participation varies over time, and pace of work has varied. Each panel has their own meetings once per week, and are looking at broader questions as well as immediate items. All while trying to balance what can be accomplished within reasonable amount of time. Trying to improve whether panels are independent units are meaningful on their own. Is participation diverse enough? Ongoing concern about diversity of editors / authors, expertise and contributions. Dropping ideas here on feedback that is desired, which can then flow to panels.

  • ... Is there concern with current Solid process or lack of it?

  • ... Other issue while working on notifications use cases -- where it may be useful to have the Solid DEIT -- similar to positive work at W3C. Hoping that we could raise use cases and have them reviewed by the DEIT. Like horizontal reviews in W3C.

  • Dirk: Idea of panels is good. Like the idea of diversity team reviewing use cases. People need to find out how they can get involved. How do we let people know how to join the panels? I see there are a lot of meetings going on. How are people notified about meetings? Since talking about a notifications specification, can you get a notification in your pod that you should join in?

  • Sarven: Announcing agendas ahead of time in the Gitter chat. Experimenting with PR'ing the agenda in advance.

  • Dirk: I'm part of Gitter chat, but there's so much going on, i can't follow it. If its announced there, I find it very overwhelming (like an e-mail from W3C group).

  • Sarven: We have dedicated chats from each panel

  • TimBL: We should be using Solid for all of it. SolidOS team uses this for meeting management (in a solid pod for itself). Can use shared groups to provide people read-write access. Rather than Gitter chat, use Solid chat. Should be a group to-do list for each group, so that anytime you're in a chat, you can add a to-do, and then see / discover it on your own personal dashboard. A lot of these needs are covered by some of the basic Solid use cases.

  • Justin: We had an implementer feedback session. There are a number of items being worked on in depth in the panels, but the implementers didn't realise that. They are actively building, pretty invested. The fact that they're completely aware of and described their needs -- we really need to resolve. Being active in panels, we could use more participation, with capital Diversity... researchers, different locales... Couple of issues raised: lack of visibility into development in specs; I think they circle around the same thing. Dog-fooding the tech is one key part. Using some tech that everybody has established, e.g., email lists, might be another. We do a lot of notifications in Gitter. A common theme about Gitter: there is a lot, so it gets tuned out. We need to plug those gaps to improve participations.

  • TimBL: there was a bot in #swig IRC. Whenever anyone mentioned a URL, it would put that URL somewhere else that people could annotate it. It was a daily summary of what was discussed. People would drop a URL in order to make it a topic of conversation. We could look at simple tools or use things like Solid Chat. For example, label some things as a thread. Headings/TOC. That might be approachable. New people can see the FAQ. FAQ becomes a rich compendium. Reference work for institutional knowledge.

  • Henry: we have 100s of repositories, which is getting confusing. Perhaps a map of repositories, which are important would help. In a way TR is doing that.

  • TimBL: flag repos. Classify repos by putting them into GitHub categories.

  • Henry: we use Gitter and GitHub a lot. Issues are single threaded in GitHub. It gets very confusing to follow discussions which often tend to get very long and as conversations are interleaved. GitHub Discussions provide one level of threading more (note much, but it is better than none). Perhaps we should use GH Discussions more? In issues conversations it is hard to see what parts of the discussions are settled. Note that we also have repositories with their own issue mechanims, and often some overlap. It takes time to find out where the action is taking place. I found that many of the issues in authorization-panel were ignored. Then I found out about the WAC repo. Anyway conversations get fragmented.

  • Kjetil: We haven't used the mailing list, because we felt that it might fragment conversations even more. We might reasonably want to use it for announcements for those that want to have low volume channel for basically keeping up with things.

  • Dirk: with Gitter, there is Q&A. But announcements should be separated.

  • Sarven: there is @/all ... not great.

  • Henry: 5 months ago or so, there was an incident that some people (unknown) were deleting messages in Gitter. Was that resolved?

  • Sarven: perhaps for agendas we can?

  • Justin: +1

  • Pierre-Antoine: +1

  • TimBL: @all works. But I tend to give no priority. For big channels that might be annoying.

Protocol 0.9 Milestone Review

URL: https://github.com/solid/specification/milestone/5

  • SC: 30 minutes (max)

  • SC: Remaining issues to be taken as subtopics.

  • Kjetil: We have a process, but haven't followed it very strictly. Working towards it. The intention is to have monthly milestone. There are different phases. We have a monthly work schedule to process these issues -- to advance them to another phase or to resolve them. We're now trying to apply them to finish 0.9 spec. Quite a lot of draft proposals as well as issues in consensus phase.

  • Kjetil: What level of detail should we go into with these issues, depending on the audience?

  • Sarven: Business as usual. Pick one, Kjetil.

  • TimBL: We have the process that's nomadic writing. We need the process which allows us to have a matrix of features that can go into the spec, and which release of the spec it can go in. We need to track whether we have implementations, whether someone has written it up. Is the issue with this feature because we have written the spec or no implementation? As well as outstanding issues by the community. We need to be able to not distinguish not just the feature, but at different states, and prioritise moving unwritten thing to written up. People would be interested in knowing which feature is being released. People will see the reason the spec is not finished yet is because no one has written it up.

  • Justin: I agree. We had feedback session last week heard from implementers from in/outside. Issues they have, or needs they have from the spec. A list of needs we heard, that'll be crucial to what goes into which versions. Best first step taken is listening to what people are implementing; what they need or are running into from limitation standpoint.

  • Sarven: issues at different level. some are core architectural design decisions.

  • Kjetil: we did not add such a process yet because we were focused on only 0.9 and 1.0.

  • Henry: For context: I developed the predecessor to WebID in 2008; in the past few years I have been working on PhD to develop access control in Solid; and in the Solid ecosystem I have been working mainly with the auth-panels. The past year on the panels has led me to come up with one issue that I think is both central but also that should be really easy to solve too, that I would like to bring up here. #326 - this is a problem that come up in my server implementation. It concerns a problem with default ACLs, which I used to be a skeptical about, but which I now think is actually a really important feature for Solid. The issue is how to find the active ACL from a resource. Currently, this is taking 2n+1 HTTP requests for a client. But the issue also shows how we can brings WAC and ACP together. This is because ACP also has an efficiency problem - one highlighted by Kjetil: it requires the same acl content to be copied all over the place. How? ACP requires every resource to have an access control resource, which could be the exact same document over and over, doubling the number of resources on the web. So ACP would benefit by also having a default access control resource. An efficient way to get to the default is there, nearly specified in the WAC spec now already. All it needs is for us to agree on a name (in the solid name-space hopefully). That is my nearly no work project I would like to propose gets on these milestones soon. It is almost done.

  • Sarven: would be good to get implementations or intent.

  • TimBL: it is an optimization .. most servers seem to use caches instead of doing lots of deep paths at all. When there are a huge number of similar things they wont' be too many levels deep. Anything is going to be much less than log.

  • Henry: 2n+1 are the number of requests that a client has to do if it follows WAC's discovery process for default ACL. So it is an important optimization problem that will affect every client. There is no reason for a client to have to do more than one request. Actually, 0 requests is the best - which can happen when the default is cached. Many Solid Pods may only need a few rules for the whole POD: 1 rule for family members, 1 for work perhaps. It could be placed at the root of the POD, and all of the resources could point to that.

  • ... My feeling is that there is a philosophical misconception that is biasing a lot of this discussion and so stalling Solid and access control. I have the feeling that ACLs are thought to have to be private, visible only to the controller. But ACLs can also be public. For example: a public service may want to set rules for all resources tagged over 18.. that is public info. Somewhere in the history of Solid there seems to have been a closing of the option that access controls can be public. That makes it difficult to not create siloed apps. The fundamental problem I'm seeing in Solid. I thought it'd be good to bring up here.

  • TimBL: Ah so you will be happy that ACP allows ACLs to be readable and writeable.

  • Henry: A good to hear that. I am not sure about the latest version of ACP yet.

  • TimBL: ACP separates control read and write.

  • Henry: then that's great, and it makes the case much easier to make. We want to think of Solid clients as following links on the web. They will jump from POD to POD, and resource to resource and these clients need to figure out what credentials to present on reaching a resource. They will need to find the access control rule in one go to find out what they need to present. It is important for this to be efficient if we want to have responsive clients. Especially as this this could be happening quite a lot.

  • Sarven: readable ACLs is also possible; we have not ruled it out.

  • Kjetil: this is not in the scope of 0.9. 0.9 is basically putting into specification the behaviour that's already there. So certainly the UC is interesting and the 2n+1 case. There is a change that seems that can be introduced anytime e.g. whenever there is a problem. I don't know when that best point would be to make the change.

  • TimBL: there is some pushback from security people. The proof is much simpler .. to go through the trouble of producing proof. Never mind publishing them. the server can't afford to search them. They can determine if they have access.. it is a theorem / do the proof offline. when you bring the proof to the server and checking the proof is easier. Finding the proof can take a long time. that's the problem punted.

  • Henry: there's a whole slate of options. One just has to be aware that all have Use Cases (UC) and not all answers are good for every situation. All of that is compatible with WAC. I believe that WAC can do pretty much all the UCs we specify, with OWL or other ways. I am a big proponent of extending WAC. I understand that Solid is currently trying to keep things simple, as there is a never ending ways WAC can be extended, but for sure those types of extensions won't be for 0.9.

  • TimBL: One of the constraints on WAC. ACP people didn't like WAC because the user has the data and the task to share the data. That's complicated. In fact, WAC is very simple. Something like replacing Dropbox. You can share the top level directory, and can share with other people that can control read & write. Owners, editors, readers -- three modes. That's one of the arguments for having control as one bit.

State of Tests

  • SC: https://github.com/solid/test-suite , https://github.com/solid/conformance-test-harness

  • SC: Authors of test software can present.

  • Kjetil: The objectives between the tests are generally the same. The CTS has reporting / simpler syntax for writing; that's ongoing. Going forward, we'd write spec text and test, and always have the tests that go along with the spec. It is WIP. The test-suite is not as a conformance test suite but in terms of what is currently working. that's more of the angle but it is also useful.