wip: create a client as a web component

[tylerchilds]

.nvmrc
pins a version to load with nvm use

index.html
sets up import map, calls main.js, mounts <my-wallet></my-wallet> custom element

main.js
initializes elf.js to warm up the system and attach observers to lazy-load custom elements from the current directory

elf.js
defines a function to define a custom element that serves as a root operating context, returning the operations of the system

my-wallet.js
includes relevant client deps for WAS and elf.js, has scaffolding to update a ui with identities in card format?

USAGE

these are just static files for now-- we can serve them however. In my testing, i just ran a sample python server in the client folder on port 8009

cd client
python -m http.server 8009 

and running the server

CORS_ALLOWED_ORIGINS='["http://localhost:8009"]' npm run dev

and finally by visiting http://localhost:8009/

this is connected to the latest 200 request work in #4 and #7 for #3

[changeset-bot]

⚠️ No Changeset found

Latest commit: 7799d40

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[gobengo]

DId it work for you? For me It didn't. I could run the client but the http requests it sent to server would get 5xx or 4xx response. If it had worked for you, then I think mine failing is because of some of the changes I made recently to the server and how it verifies signatures.

@tylerchilds wdyt? https://github.com/tylerchilds/wallet-attached-storage-server/pull/1/files

[tylerchilds]

DId it work for you? For me It didn't. I could run the client but the http requests it sent to server would get 5xx or 4xx response. If it had worked for you, then I think mine failing is because of some of the changes I made recently to the server and how it verifies signatures.

@tylerchilds wdyt? https://github.com/tylerchilds/wallet-attached-storage-server/pull/1/files

@gobengo The put request got a 204 for me, but the get request was a 500, so it wasn't fully working. the 204 was an improvement from after you added put support, so i at least knew the integration was improving.

[gobengo]

The put request got a 204 for me, but the get request was a 500, so it wasn't fully working.

The 500 was happening because the space controller was not a DID but a whole DID URI with hash fragment.

[gobengo]

@tylerchilds Is this the expected behavior?

If we want this to be merged as an example into the main branch, it would be ideal if the webpage was a bit more descriptive of what it is trying to exemplify, whether it succeeded in doing so, etc.

I ran it in a wrong way for a bit and the server (a rogue process that was not the intended one) responded to PUT /space/:uuid with 405. But this example didn't really complain at that error (iirc). The iframe showed a 404 page though.

Once I fixed it, now the demo shows this 'Index5' thing. If that is the 'successfully loaded' state, can you make it more clear?

[gobengo]

the example should be more useful or at least more clearly indicate it is successfully loaded vs errored (and hint the user how to evaluate it?)

[tylerchilds]

@tylerchilds Is this the expected behavior?

Yes and no-- work is wip until we get the basic integration connected and then we can put together an actually practical UI-- the SES errors are likely metamask adjacent (and I can work to improve ses compat, if that's a goal for WAS)

The 500 from your screenshots and my previous tests is now resolved.

If we want this to be merged as an example into the main branch, it would be ideal if the webpage was a bit more descriptive of what it is trying to exemplify, whether it succeeded in doing so, etc.

agreed, simplified it for now to eliminate the premature ui controls and just made the iframe full screen for now-- effectively making this a demo of rendering whatever we're immediately publishing.

I ran it in a wrong way for a bit and the server (a rogue process that was not the intended one) responded to PUT /space/:uuid with 405. But this example didn't really complain at that error (iirc). The iframe showed a 404 page though.

sorry for the churn!

Once I fixed it, now the demo shows this 'Index5' thing. If that is the 'successfully loaded' state, can you make it more clear?

Made the iframe just read "Initial Test Successful"

---

I've fixed the PR to be cleanly rebased from the upstream, but wasn't able to get back to the fully successful test seen in your screenshot rendering the iframe contents.

Current screenshot here:

Reproduction

1. run python -m http.server 8081 in examples/plan98-client
2. run CORS_ALLOWED_ORIGINS='["http://localhost:8081"]' npm run dev in root
3. visit http://localhost:8081/

Expected:

4. iframe to load "Initial Test Successful"

Actual:

4. 401 unauthorized: {"message":"This request cannot be authorized"}

[tylerchilds]

A lead on the 401 unauthorized error-- i might be doing the env var wrong for cors and npm run dev

the log ends with origin is not in CORS_ALLOWED_ORIGINS

$ CORS_ALLOWED_ORIGINS='["http://localhost:8081"]' npm run dev 

> wallet-attached-storage-server-monorepo@0.0.0 dev
> npm -w nodejs run dev


> wallet-attached-storage-server-nodejs@0.2.0 dev
> dotenvx run -f .env.dev -- node --watch ./scripts/start.ts

[dotenvx@1.44.1] injecting env (2) from .env.dev
(node:65096) ExperimentalWarning: Type Stripping is an experimental feature and might change at any time
(Use `node --trace-warnings ...` to show where the warning was created)
creating database from DATABASE_URL
database pathname is var/wallet-attached-storage-server.dev.sqlite3
Listening on http://localhost:8080
origin is not in CORS_ALLOWED_ORIGINS 

[gobengo]

@tylerchilds I haven't tested but a guess is

try

CORS_ALLOWED_ORIGINS='["http://localhost:8081/"]' npm run dev 

note the trailing '/' in the URL. if I'm parsing it with the URL constructor and then stringifying again, I think that's what will come up

update: this was probably bad advice. trailing slash is part of URL but not the origin part of the URL

[tylerchilds]

note the trailing '/' in the URL. if I'm parsing it with the URL constructor and then stringifying again, I think that's what will come up

i just tried with the trailing / and it yielded more cors errors.

in the current version, the put works, but the get fails. with the trailing /, they both fail.

[tylerchilds]

I've revised this to have compatibilty with https://sillyz.computer/app/was-hello

[gobengo]

@tylerchilds I had pushed some new features to main branch here since you branched off. That includes refactoring of the authz and support for PublicCanRead acls.

I did a mergeback from main, then updated was-hello to configure the space so there is a PublicCanRead acl applying to the resource that loads in the iframe, and got it working.

wdyt?
tylerchilds#3

[tylerchilds]

@gobengo perfect, merged on my end and tested. publishing to was on my local system from sillyz works, as crazy as that sounds.

[gobengo]

@tylerchilds It still feels like this is showing something but not necessarily plan98. Are there any plan98 web components we can put in this HTML so that once it is loading it is doing plan98 pretty looking stuff?

[gobengo]

@tylerchilds Would you be willing to add one of your awesome custom elements to the html that gets written to storage and then showed in iframe? I think it will really help highlight the plan98 part of this example.