# Sign in With Ethereum Community Call #13

### Date: 2022/03/31
### Agenda:

- [General] Reader Notes & Updates
- [General] Introductions
- [Show & Tell] SIWE Updates (ENS IdP, Discourse, Go, Next.js, Harmonizing our core APIs, Broke out parser logic, passport.js, templates)
- [Q&A]

## Relevant Links
- [Documentation Portal](https://docs.login.xyz)
- [ENS DAO Draft Proposal](https://discuss.ens.domains/t/ep10-executable-a-dao-governed-identity-server/11125/24)

## Reader Notes and Updates

- SIWE 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 languages and plugins, 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.

## Introductions
[Seb] - Background is logistics and founded several ventures. Didn't use blockchain in the past but very curious about the Sign-In with Ethereum standard and Spruce's technology.

## Updates
- [Rocco] - First thing to cover - the Sign-In with Ethereum ODIC IdP that is DAO-governed. The proposal went up on March 1st to the ENS DAO has passed. There was first a vote on Snapshot that passed and it also passed on Tally. We're happy to report that this is moving forward. This is how we would create a DAO-governed identity server to align incentives with users. This would be for folks that are looking for more traditional forms of integrating.
- From our side, we'll be reporting on our existing architecture (like the one hosted by the Auth0 marketplace), setting up that actual IdP on a managed account, fully outlining the process via Cloudflare, and related to that, forming that Subgroup on the ENS DAO and outlining a retroactive grants process. I'll be leading the initial charge on that and soliciting interest from the ENS community. We'll also be working on onboarding and maintenance materials.
- [Rocco] - The other thing to mention quickly is the Discourse plugin. We have our Discourse plugin live as Spruce, and you can use it on a forum to allow users to create new accounts and authenticate with their keys, or associate their Ethereum account with an existing account on the forum. Just want to plug this for any self-hosted Discourse instance. You do need an email due to the flows being rigid with Discourse. Handing it over to Oliver for a few other updates on the technology side.
- [Oliver] - Hey everyone. We also released a `siwe-go` core package, and it's available on github now. We're also harmonizing our core APIs to standardize how SIWE messages are handled in a unified way. We also broke out our parser and made it a standalone package to reduce the dependency footprint from our library.
- We're also about to finish our passport.js integration for SIWE to use it as a passport authentication strategy. We expect to release it very soon. We're exploring how to create templates for development frameworks like React and Vue, and we now support NextAuth.js. For this we provided a tutorial on how to integrate, and i'll share my screen and show you how the demo works.
- [Shows off the NextAuth SIWE example in a demo]
- So that's basically it from my end. I'll hand it back to Rocco.
- [Rocco] - There are two other things. We also released a bit of research we did, specifically on where it would make sense to target Sign-In with Ethereum integrations. Specifically, we were looking at the trends with ENS users, like the types of applications that they're using on-chain because you can track these metrics. A lot of them were coming from NFT platforms and games - both of which have authentication flows. These NFT projects will have games for their holders which will make sure the user has the actual NFT to play the game. This kind of flow can be SIWE enabled. As always, we make these findings public.
- One last thing - we're still continuing our integrations with wallets. As Spruce, we're working with a few wallets on interfaces for SIWE. It's not only unifying the way in which the signing format is for users, but it's also about creating safer interfaces for users. The wallet can say "I recognize that as a valid EIP-4361 message, I can now serve a user this sign-in interface." It's making sure the signing message is clear enough, and working with wallets on this. Extension wallets in particular can handle domain binding to ensure phishing attacks aren't taking place. From our end, that concludes the last major updates.

## Q&A
- None today