– DRAFT –
Linked Web Storage

Introduction & Announcements

TPAC Meeting

acoburn: This is a time-sensitive matter as we need to respond by Wednesday, June 17th
… TPAC is this fall, in october

https://www.w3.org/events/tpac/2026/
… If we want to reserve time for the WG to meet in person we need to request this.
… Do we want any slots? We probably do.
… There are slots on all days, except Wednesday.
… You have to decide which are acceptable. Everyone wants to meet on Tuesday & Thursday.
… Monday and Friday are more likely to be accepted. But attendance may be lower due to travel.
… One slot for a joint session with the CG perhaps.
… How many do we want for the WG as a dedicated slot?

jeremycaine: Can you explain, there's a f2f meeting like we had in London?

acoburn: This would be akin to our F2F meeting, we would have a set agenda.
… WG members would be welcome as well as other interested observers.
… This is typically the time when WGs want to have a F2F meeting.
… Last year TPAC was in Japan, this was challenging to many. So we had our meeting in Belgium.
… In order to have a F2F meeting we would select some number of slots.

jeremycaine: We had two days in London, so probably 8 slots?

acoburn: This is also an opportunity to meet with other WGs. E.g. VC, FedId, Accessibility, ...
… If we were to ask for many slots, that might make it challenging for our WG members to attend other meetings.
… The meetings run in parallel, and there are a limited number of rooms.
… If we were to ask for 11 slots, we wouldn't be likely to get all slots.

<Zakim> elf-pavlik, you wanted to ask about Social WG/CG

<elf-pavlik> https://www.w3.org/wiki/Socialwg/Collection_Comparison

elf-pavlik: We were discussing to meet with the Socal Web WG/CG.
… For example the collections could work across LWS and ActivityPub, that is a challenge.
… It would be a good idea to coordinate this work.

<acoburn> TPAC

acoburn: In the open issues on the repo you can see the requested slots by each group.

jeswr: I would propose three joint sessions.
… One for the LWS WG and Solid CG to cover the work items that would be incubated, a second on identity on the web with FedID, VC, LWS and Social Web WGs, and the third is LWS and Social Web WG (like pavlik proposed)
… So maybe 8 hours, with three hours reserved for these joint sessions.

acoburn: So that would be 8 sessions, which run for 1,5 hour each.

<Zakim> AZ, you wanted to mention that the Autonomous Agents on the Web CG will meet at TPAC and would like to liaise with LWS WG at some point

AZ: I would like to mention that the Web Agents CG just had a meeting
… We were discussing what we could do at TPAC.
… Looking at the various groups, one of the candidates was LWS.
… I'm not sure we need a joint meeting at TPAC.
… But it would be good that the two groups meet online, maybe before or after TPAC.

<acoburn> +1 for joint meeting/discussion

<jeswr> +1 for joint. I am working a lot on agents personally and using Solid and LWS specs in that

acoburn: @AZ could you propose some topics for us to discuss?

<jeremycaine> +1 propose 3 x LWS (approx 0.5 working day at 4.5h) plus 5 x LWS with others (per Jesse)

acoburn: I would like to wrap this up in the next 5 minutes.

laurens: I would like to keep at least 4 slots (ideally 5) for LWS, given implementer feedback, test suite and moving towards CR.

<jeremycaine> +1 for 5 slots, with 3 for joint

<jeswr> +1 for reserving 5 LWS slots

<ericP> +1 for 5

acoburn: What does the WG think of 5 slots for LWS WG meetings only.

<elf-pavlik> +1 hybrid if possible

acoburn: They will be hybrid, but I cannot guarantee the timing.

<AZ> I'm not going to be present at TPAC (because ISWC) but ok with 5 slots

acoburn: I can take the lead on requesting this.
… Are there non-acceptable time slots?

<jeremycaine> +1 to laurens suggestion

laurens: Maybe exclude the slots on Friday afternoon, and the first slot on Monday morning.

acoburn: I'll make the request.
… We'll have to request a joint session with the Solid CG. Someone more involved in the CG should take the lead.

elf-pavlik: I can do that.

acoburn: We should avoid conflict with other LWS or Solid CG meetings.
… Could you take the lead jeswr on the other joint sessions?

jeswr: Can I make that request?

acoburn: It does say group chairs. But it's probably fine.

Vote: Relationship to OAuth2 PR#169

acoburn: This should be fairly easy.
… This PR adds a single line to the core specification
… clarifies that the baseline is OAuth2.

<acoburn> PROPOSAL: to merge PR w3c/lws-protocol#169 OAuth relationship

<gb> Pull Request 169 Clarify relationship to OAuth 2.0 (by acoburn)

<elf-pavlik> +1

<gibsonf1> +1

<ericP> +1

<eBremer> +1

<jeremycaine> +1

<acoburn> +1

<TallTed> +1

<laurens> +1

RESOLUTION: to merge PR w3c/lws-protocol#169 OAuth relationship

Vote: Remove Unstable Features section PR#168

acoburn: At present we have a section for unstable features
… It includes inbox, notifications, profile negotiation, ...
… I am just removing that entire section.
… There is a question about where notifications are defined.
… They are an actual feature, so that should be linked in the core specification.
… Should we remove that unstable features section?
… I believe we should rather make that remark inline than in a separate section.
… Any questions?

<acoburn> PROPOSAL: to merge PR w3c/lws-protocol#168 Unstable features section

<gb> Pull Request 168 Remove 'Unstable Features' section (by acoburn)

<ericP> +1

<jeremycaine> +1

<elf-pavlik> +m

<gibsonf1> +1

<dmitriz> +1

<eBremer> +1

<acoburn> +1

<laurens> +1

<TallTed> +1

<elf-pavlik> +m

<elf-pavlik> +1

<ryey> +1

RESOLUTION: to merge PR w3c/lws-protocol#168 Unstable features section

Vote: Auxiliary Resources PR#165 / PR#167

acoburn: There are two competing pull requests here.
… The first one is from Wouter, who is not here today.
… I think we do need to discuss it.
… The second PR is from Pierre-Antoine who is also absent today.

<eBremer> +1 pausing vote

acoburn: We should probably pause the vote.

TallTed: I agree with pausing the vote.
… I don't have a particular issue with either one.
… But it is unclear what the issues are with the former that necesitated the later PR.

acoburn: My understanding is that, in almost every case, the two are practically the same.
… There is a case where an LWS storage for a data resource is storing a resource with the media type application/linkset.
… And then separately has its own linkset, there is no way for the client to distinguish both.
… In Wouter's PR a client would not be able to negotiate between a data resource that is a linkset and the associated linkset for that resource.

<Zakim> elf-pavlik, you wanted to comment on this edge case

elf-pavlik: It is important to clarify these scenario's
… This should also be part of a test suite.
… For the edge case, this only affects implementations that choose to use content negotiation.
… So it doesn't affect all implementations probably.
… But this is probably an edge case.
… I would like to know if there's a functional difference.

acoburn: I would encourage people to engage with these PRs.
… Focus conversation on PR #165.

<gb> Pull Request 165 Define aux & meta in terms of representations (by termontwouter)

acoburn: Any other comments?

Discussion: Should Notifications document go into LWS Core?

acoburn: This should be easy.
… Notifications are currently in their own document.
… Should this be moved into core.
… Or is there a subset?

laurens: to me it's whether this is a requirement or optional
… currently optional
… are there other optional features in core?

<Zakim> elf-pavlik, you wanted to suggest that subscription types should stay separate

elf-pavlik: I agree mostly with laurens
… I would at least keep the subscription types out of the core.
… And to keep in mind the evolution of the specification over the next X years.

acoburn: Right now there are a couple of things that are optional or semi-optional in the core specification.
… One of these is the access requests feature.
… It had previously been in a separate document.
… That feature does reference notifications.
… As long as we're keeping access requests in the core specification, I would bring in the core of notifications in the specification.

ACTION: laurens to propose a way of bringing the core of notifications into lws-core as a PR.

<gb> Created action #175

Discussion: Issue Backlog Triage

acoburn: I would love to have (a subset of) this group to take e.g. Friday afternoon to go through these issues.

<elf-pavlik> I closed #114 which was done via PR

<gb> CLOSED Issue 114 TotalItems: count MUST be exact: propose to SHOULD (by bjdmeest) [ready-for-pr]

acoburn: And work this number down.
… So that we can have the propose-close tag assigned to those issues that should be resolved.
… And if needed continue the discussion with the WG if members feel like the issues aren't resolved.

<jeremycaine> +1 a working group working session :-)

acoburn: I'll send out an e-mail to the WG list to coordinate.

<TallTed> +1 to triaging. I will join if not blocked by a previously scheduled session.

Discussion: Virtual Resources Issue#150

acoburn: Is this in scope for the core of LWS, or can this be defined outside of it.

ryey: That's also the reason I raised this as an issue rather than a PR.
… I don't think the full scope of virtual resources should be in LWS 1.0

<acoburn> +1 on making sure LWS core doesn't prevent this

ryey: I do hope LWS 1.0 wouldn't prohibit implementers from implementing virtual resources.

<Zakim> gibsonf, you wanted to ask ryey to give some use-cases for virtual resources

gibsonf: Could you give some use cases for virtual resources?

ryey: Something that looks like a resource but is not managed by the LWS service.
… For example a vector store.
… You may want a way for a client that is "AI-enabled" to access some of your contents through another interface.
… Those vectors are an alternative representation of the data in your LWS storage.
… The client should not know where they are stored, as long as they are accessible from your storage.

laurens: I do think the services in the storage description could also solve many of the same use cases.

jeremycaine: I'm trying to understand whether virtual resources are like a symbolic link.
… The HTTP methods on that target resource are going to be different to the virtual resource managed by the LWS server.

<Zakim> acoburn, you wanted to add some example use cases

jeremycaine: Is it a symbolic link or a link to an API endpoint?

acoburn: I think there's quite a bit of incubation needed here.
… This would be great to discuss with the CG as well.
… I think of it more as a function, e.g. pass through to 1 resource, 7 resources, some file somewhere, ...
… From Inrupt's perspective we've implemented this.
… It is useful in particular contexts.
… But probably doesn't need to live in the core.
… Also, we don't want to prevent this.

<Zakim> ericP, you wanted to draw LWP parallel

ericP: I want to point out LDP was developed to account for this.
… Our motivations are probably different from LDP.

<Zakim> ryey, you wanted to talk about service discovery

ryey: For the service descriptions a virtual resource will use them.
… An explicit pointer to an external API is not the best option.
… For symbolic links, that depends on the flavour.
… It is a different representation so it should at least be like a hyperlink.

acoburn: The consensus is that this is viable, but not for the core of LWS. We should keep this issue alive as to keep it in mind.