---
# System prepended metadata

title: 'Sign in With Ethereum Community Call #5'

---

# Sign in With Ethereum Community Call #5
### Date: 2021/11/04
### Agenda:

- [General] Reader Notes & Updates
- [General] Introductions 
- [Demo] login.xyz Example
- [General] Q&A

### Reader Notes:
- Moving the call schedule to twice monthly for 30-minutes each call.
- If you're interested in being listed as a supporter, reach out either on Discord or on Twitter. 
- The Discord is still open for any async chat about SIWE.
- 'Try it Out' going live tomorrow on login.xyz, shortly after will have things documented to get it up and running for any user that wishes to take it off the shelf.

### Introductions
- [Drew] - Hey everyone, third call I've been on. Big fan of what you have going on, background in mechanical engineering. Been in the NFT space since Februrary and all-in on Web3.
- [Gene] - Gene and heard about Spruce from ConsenSys Academy. My idea for my final project has been done really well by this team and now I want to get involved. I'm passionate about distributed storage and the promise it gives -- especially interested in issues around retention and permanence of data, metadata, and identity. 
- [Lachlan] - I work on XR and VR in big tech, but also I work on web standards. Also a big fan of Ethereum and have been since 2016. SIWE effort prompted me to push it as potentially a good thing to move forward with in the web space. The issues of identity and user control are coming to the forefront. 
- [Zach] - Hey guys - I'm Zach, research analyst at Messari and fellow pizzerian. I'm going to try to get on the future calls, big fan of identity and a big push for reputation. For a long time I think identity and reputation were a downstream bottleneck. We're getting to the application layer now and that's when identity is really going to play a critical role. 
    - [Rocco] Yeah in the past it used to be connect your wallet and transact, but now we're moving into a time with more contextual transactions which require richer forms of identity. 

### Demo
[Screenshare of login.xyz website]
- One of the major parts of this call was us wanting to show off the demo. As you may recognize, it's the regular site, we have a number of additional new supporters listed since the last call. 
    - Now on the site there will be a `Try it out` section for folks who are curious about what it looks like for a user. Hit the button, Web3 Modal pops up, we support WalletConnect, MetaMask, Portis, Fortmatic, Torus, and Coinbase Wallet. For the sake of the demonstration, I'll use MetaMask.
- [Wayne] This is exactly to the spec, we even use the ABNF grammar specified in the spec to interpret the message. That's what's going to ship standard to the library we publish to NPM (SIWE). We picked a very composable architecture but we wanted to have it available for example applications. The library itself is pretty small, and very auditable. That should be coming along soon. 
    - Here we have login.xyz wanting you to sign in. We have the parameters as they must be ordered, and we have a mandatory chain ID in case there's a smart contract wallet because you need to know what version of the network you get the smart contract from. That's the full request - and we wanted to strike the balance to make it human readable and make it machine readable enough. 
- [Rocco] Now once I sign this, we then have a session established with my wallet. If you do have an ENS name or avatar, it will show up. Sign out button is present as well.
- [Wayne] What's happening is that we're getting a cookie in the frontend browser to access a centralized server. Now you can vote for your favorite emoji (the demonstration allows a user to vote for an emoji and saves the choice)
- [Rocco] Our options are a unicorn or a rainbow, once you submit that, you'll see who's winning. If I sign out and sign back in with Ethereum, my choice and results are here. That session has been established with me and my identifier. We encourage folks to try it out and give us feedback to make sure everything is working. We've tested across a number of major wallets as well. It should take only a few seconds to test. 
- [Wayne] I also wanted to contextualize that you're looking at the tip of the iceberg. The implementation of these libraries is really fast - most of the work that was done was setting up 50 plus calls with people and seeing their needs. We will be publishing our research on the wallet support as well. Hopefully it will help the ecosystem understand where we are. 
    - The work ahead is to improve the documentation so it's straightforward to understand. We're going to package this into passport.js, the auth0 marketplace so any service already relying on these for authentication, they can add the SIWE strategy to make it easy to adopt it. Finally, we will be working on a central identity provider server to be hosted by a neutral third party.
- [Rocco] One of the goals too is to make sure this goes as far and wide as possible with Web2 services. We want to make sure that the reach is there and possible. 
- [Wayne] This is a good time to stop for any questions. 
### Q&A
- [Greg @ rivet] - Really nice work and thank you for all the effort you're putting into this. 
- [Wayne] - Joel - I see you might be on the call, can you talk about your capabilities extension spec? Recently we were in the SIWE discord and Sergey posted a link with respect to how you can use this request structure to access more resources in a permissioned manner.
- [Sergey] - [CACAO](https://github.com/ChainAgnostic/CAIPs/pull/74) We expect SIWE to be widely adopted, and we at Ceramic have a lot of work on access control in a proper way. Currently the only proper way in a highly decentralized environment is the object capability model. We decided to merge these two together and the result is the spec that we posted to CAIP. Hopefully it can be come a CAIP standard. We expect this to be adopted by other blockchains (sign in with NEAR, Tezos, whatever) - the same as SIWE. 
    - The main roadblock for us was how we actually represent the capability as an IPLD object. It's customary to exchange IPLD objects, so this spec is actually a simple representation of SIWE as an IPLD object and the way to transform a string signed by a user into a machine readable representation. This IPLD representation let's you chain multiple capabilities together and let's you exchange them between the services / servers in an interoperable fashion. We expect usage of that as a cornerstone of the next iteration of Ceramic. We think it's a good idea to use SIWE as an initial sort of capability that runs an Ethereum account as a did:pkh that grants the dapp the ability to do something with the user's data. 
    - For us it's a new approach of permissioning in highly adversarial environments. I think it's a good idea to read that, to read an upcoming blog post on what it means. Feel free to contribute to it on the Ceramic discord. 
- [Wayne] Thank you so much for presenting that, really excited to see things being built on top of the spec. Capabilities models will be in vogue again. One of the best papers on this is Keynote by Matt Blaze which described this model 20 years too early because it was based on public/private keypairs.
    - Thanks so much for coming to the weekly call, if you have more questions please use the chat in the Discord. 