wip: fake keyring playground #290
Draft
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
I wanted to prove to myself that postMessage would be a viable way to communicate between an app and the keyring site, so I created two example apps and got them to talk to eachother. to try this out, in two different consoles run: console a: ``` cd examples/react/fake-keyring pnpm install pnpm run dev ``` console b: ``` cd examples/react/fake-keyring pnpm install pnpm run dev ``` then head to `http://localhost:3000` and hit "grab the keys" you should see output in the console confirming this cross-origin communication works as expected, with some TODOs that sketch out what the keyring might need to do to make this all work as expected. big open question for me - does the UCAN need to be transmitted all the way back to the app domain or can we just store it on the server as proof that a user has granted a domain access to a particular set of capabilities?
|
This pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. Latest deployment of this branch, based on commit 5b42f3e:
|
It probably depends on context, but in general I think we want more the former than the latter. Give the end-user (or their user-agent aka web browser) the delegation so they are in control of it. Don't hide it from them by storing it on their server without them having a copy. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I wanted to prove to myself that postMessage would be a viable way to communicate between an app and the keyring site, so I created two example apps and got them to talk to eachother.
to try this out, in two different consoles run:
console a:
console b:
then head to
http://localhost:3000and hit "grab the keys"you should see output in the console confirming this cross-origin communication works as expected, with some TODOs that sketch out what the keyring might need to do to make this all work as expected. I'm not entirely sure why the handler gets registered multiple times, but that's not super important for now.
Arc.-.Vite.+.React.-.23.January.2023.mp4
big open question for me - does the UCAN need to be transmitted all the way back to the app domain or can we just store it on the server as proof that a user has granted a domain access to a particular set of capabilities?
this should probably never be merged - close it when we no longer need it handy