# Sign in With Ethereum Community Call #16

### Date: 2022/07/21
### Agenda:

- [General] Reader Notes & Updates
- [General] Introductions
- [Show & Tell] General Updates (Small fixes and updates, SIWE 2.0.4/5, Wallets, ENS Community IdP, Capgrok)

## Reader Notes and Updates

- SIWE TypeScript library is out and can be found [here](https://github.com/spruceid/siwe).
- The [Discord](http://discord.gg/WjvuYqvm5Y) server is always open for questions and those that wish to participate.
- We're working on support for different templates, languages, and more - please reach out if you're interested in a SIWE integration.
- Documentation: if you're about to embark, let us know what you think would be best to include! All feedback is welcome.

## Updates
- [Rocco] - Welcome to the 16th Community Call.
- [EIP-4361](https://eips.ethereum.org/EIPS/eip-4361) is now in the `review` stage after being in the `draft` stage. For the longest time, one of the worst parts was when folks went to the EIP and thought it was dramatically going to change due to the `draft` flag. There weren't going to be major changes to the specification. We've now gone through the process and we want to shout out the EIP reviewers that helped us get this moved to the next stage. We had to move one of the WC EIP-1328 from `draft` to `review` in order to move EIP-4361 forward because it was a dependent EIP. The next phase for the base spec is to get it to `last call` and finally `final` in order to hammer it in. This doesn't count any extension specifications that might come out. We can now avoid any questions about it being a draft and we have even more confidence here.
- [SIWE 2.0.4](https://github.com/spruceid/siwe/releases/tag/v2.0.4-beta) is now released (2.0.5 with a quick fix). Specifically, it enables backwards compatibility with older versions of SIWE such as 1.1.6 in use.
- [Wayne] - In the previous implementation, it was called `validate()` - because when you sign in with Ethereum there may be more sophisticated verficiations, we decided to go all in on `verify` in order to clarify any semantics. We have left the `validate()` function in with a warning message so it works as expected and people don't have to change names, but they will get a warning message to change this. When we speak to folks that need more sophisticated forms of verification, this speaks greatly to that.
- [Rocco] - If you go for the `beta` tag, you will be given the 2.0.5 release. We'll still be making minor updates on the core library.
- Wallet work - we're working with one wallet on specific interfaces for EIP-4361 formatted messages. In this case, the wallet will tell you you're signing in and the user will have a lot more context when interacting with services. When a user signs into a service, it won't just be "sign the message". The base text of the SIWE request makes it clear about the action in the message to be signed, but we'd rather have the wallets have custom interfaces that tell the user they're signing in. This also includes domain binding where the wallet warns you if you're being phished and requires multiple confirmations if the domains don't match.
- Additionally, we're working with a multisig provider to allow login on behalf of a multisig. A good example of this is where a DAO has to put up a proposal on a DAO platform -- how does a member of that DAO log in on behalf of that DAO on the platform? In this case, there will be a workflow for a user to sign in and represent a multisig in order to take some form of action. This is active work that's going on and we hope to have more information on this on the next community call.
- [ENS Community IdP](https://discuss.ens.domains/t/updates-on-ep10-community-run-identity-server-june/13480) updates: we recently posted our June update which included more information on the deployment of the server, the documentation updates and more. It had a witnessed deployment by two members of the ENS community and a member of Spruce, and as we add additional improvements, we will likely need to have additional witnessed deployments. We'll be asking more folks from the community to be witnesses to this deployment and get added to the host where the server lives to have checks on it. The retroactive grants process is still a work in progress and should be formalized soon - we're setting a few things up now with respect to that. We'll be supporting things like hackathons, bounties, and more.
- The repo is public under `spruceid/ens-oidc` and draws from the `spruceid/siwe-oidc` which is our lightweight OIDC server implementation.
- [Discourse Fixes](https://github.com/spruceid/discourse-siwe-auth/issues/15): recently there was an issue with the Discourse plugin which was located in the setup itself. A person from Communiteq had a bit of information a few lines to add to the configuration to fix it. The fix has now been added to the setup instructions in both the Readme and documentation. We're currently talking to the Discourse team in order to get it to be an officially supported Discourse plugin. We know many folks don't self-host so we want to make sure this is an available option as well.
- Additionally, we'll be updating `wagmi` in the `siwe-next-auth-example` as well. There's an open PR from `scottrepreneur` who we thank for it to get the ball rolling. We'll be moving in to finish up this PR and keep it moving with the update.
- [Dapp Building Research](https://forms.gle/acHczvgz3Uf187j29): Spruce is currently conducting research on how folks build applications in order to better serve Sign-In with Ethereum. We encourage folks to fill it out - it should only take 2-5 minutes at most.
- [Jacob Ward - Spruce] [Capgrok demonstration](https://github.com/spruceid/capgrok) - if you want to use SIWE to authorize every user action - you have two options. Either have them sign every single action, or you can use SIWE to delegate to a session key which will sign on behalf of the user. The first option isn't great because it would require signing every action, but in the second option, the session key can sign instead with consent. In this we want to restrict the actions that the session key can perform so it's not everything. We wanted to encode these capabilities into the SIWE message so it's understandable by the user, but also in a way that a machine can read it.
- That's what we're calling "capgrok". Capabilities for humans to read - at the moment it supports SIWE, but you can build a set of capabilities you want to delegate to a session key, and then you attach these to a SIWE message. Here in the statement, we encode these capabilities for the user to read, and in the resources are the actual encoded instructions. We have namespaces for credentials, etc. in the statement for the user.
- [Rocco] - Cool - thank you for presenting that Jacob. As Jacob just mentioned, we'll have an EIP we're drafting about this and a blog post for folks to go back and reference. We can open for Q&A now or end early.