You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It would be a helpful feedback to both Solid CG and LWS WG to have applications test agains those servers.
There are more upcoming implementations but CSS might be the most accessible at this moment
Thanks for opening this, and for the links to the PRs and the conformance pages. Testing Solid Memo against the LWS work in CSS sounds useful, both for us and as feedback to the Solid CG and the LWS WG.
I'll see what I can do about testing the implementation against what Solid Memo expects of a server. I'd most likely start with the feat/lws-next-major branch (PR #126), built from a pinned commit and run as an advisory server in our interop matrix, next to the other servers we test against. I'll report what I find here, and upstream wherever it applies.
Thanks @bourgeoa, that's helpful. Is it OK if I try Solid Memo on the live Pivot test server with a test account? I'd start by hand. I'd also like to run our browser journeys once or twice, which create a few accounts and documents.
Thanks for the test servers. I ran Solid Memo's shortest user journey (log in with a WebID, create an instance in the pod, log out) once against the solid-lws Pivot at https://pivot-test.solidproject.org:3200, with Solid Memo built with its own Solid client (solid-memo-client), in Chromium. It passes.
That run used Solid-OIDC, not the LWS token exchange. A private resource there answers 401 with WWW-Authenticate: Bearer as_uri="…", realm="…", scope="openid webid", with no resource_metadata. The client finds the LWS authorization server through resource_metadata (RFC 9728), which jeswr's fork sends since ef6d664f, the commit Solid Memo tests against. Could you upgrade :3200 to ef6d664f or later? Then the same run would test LWS sign-in too.
The run left three test accounts on :3200: j-611a4b49, j-a989a94a and one more. Each pod holds at most an empty Solid Memo instance.
Activity
ixuz commentedon Nov 5, 2026
Thanks for opening this, and for the links to the PRs and the conformance pages. Testing Solid Memo against the LWS work in CSS sounds useful, both for us and as feedback to the Solid CG and the LWS WG.
I'll see what I can do about testing the implementation against what Solid Memo expects of a server. I'd most likely start with the
feat/lws-next-majorbranch (PR #126), built from a pinned commit and run as an advisory server in our interop matrix, next to the other servers we test against. I'll report what I find here, and upstream wherever it applies.bourgeoa commentedon Nov 5, 2026
Using jeswr CSS lws PR this can be of help.
ixuz commentedon Nov 6, 2026
Thanks @bourgeoa, that's helpful. Is it OK if I try Solid Memo on the live Pivot test server with a test account? I'd start by hand. I'd also like to run our browser journeys once or twice, which create a few accounts and documents.
fix(e2e): keep the strict LWS proxy on the server it fronts
fix(solid): read the LWS profile from the profile parameter alone
bourgeoa commentedon Nov 6, 2026
You can create test accounts. No problem.
There are 3 rather stable servers :
They all run on a small VM machine with 2GB RAM
test(e2e): run the pod tests against CSS 8 with Linked Web Storage
build(deps): hold each commit of the CSS LWS fork for a person
feat(solid): find a Linked Web Storage storage as its server links it
feat(solid): make the app's requests as a Linked Web Storage server t…
feat(solid-memo-client): sign in to a Linked Web Storage storage
test(e2e): run the pod tests against CSS with LWS alone, and the bridge
docs: explain how Solid Memo works on a Linked Web Storage server
fix(e2e): keep the strict LWS proxy on the server it fronts
26 remaining items
docs: explain how Solid Memo works on a Linked Web Storage server
fix(e2e): keep the strict LWS proxy on the server it fronts
fix(solid): read the LWS profile from the profile parameter alone
build(e2e): run the CSS LWS servers on the fork's commit ef6d664f
refactor(solid-memo-client): find the authorization server by resourc…
test(e2e): sign in on the CSS LWS servers
refactor(solid): remove the Linked Web Storage bridge
test(journeys): read a deck's cards document relative to the catalog
test(journeys): run the user journeys against the CSS LWS servers
ci(journeys): run Chromium's journeys on css-lws and css-lws-only
docs(lws): leave the app's gaps to the interop report, and explain th…
test(journeys): fail Interop's journeys only on failures their server…
docs(interop): report on the servers with Linked Web Storage
ixuz commentedon Nov 8, 2026
Thanks for the test servers. I ran Solid Memo's shortest user journey (log in with a WebID, create an instance in the pod, log out) once against the solid-lws Pivot at https://pivot-test.solidproject.org:3200, with Solid Memo built with its own Solid client (
solid-memo-client), in Chromium. It passes.That run used Solid-OIDC, not the LWS token exchange. A private resource there answers 401 with
WWW-Authenticate: Bearer as_uri="…", realm="…", scope="openid webid", with noresource_metadata. The client finds the LWS authorization server throughresource_metadata(RFC 9728), which jeswr's fork sends sinceef6d664f, the commit Solid Memo tests against. Could you upgrade :3200 toef6d664for later? Then the same run would test LWS sign-in too.The run left three test accounts on :3200:
j-611a4b49,j-a989a94aand one more. Each pod holds at most an empty Solid Memo instance.ixuz commentedon Nov 8, 2026
@elf-pavlik I've added the css lws fork to the interop matrix, see my comment here #604 (comment)
Does the draft pr #604 meet your expectation for this issue you opened? Or would you like amendments before it's merged?