 So, I wrote Ether's JS. The idea is it's a complete, simple, tiny library. It's a replacement for Web 3 and Ethereum JS. If you use either of those, you can use this instead. So some quick history. I was writing an in-browser equivalent of MetaMask, but this was before MetaMask existed. I want something like in-browser, DAP browser. So by the time I included all the libraries that I needed, this page was 7.4 megabytes to download. There's a lot of bugs back then. I think somebody was mentioning in the other talk earlier that one out of 120 addresses were computed wrong from the private key, so it just produced unspendable monies. The other big thing, especially back in the day, if you wanted to build a DAP, I mean it was really simple. So all you had to do is download Geth, wait three days for it to sync, and once that was done, connect to it and do all this other stuff, and now it'll probably work. You might have to blow the database away a few times and, like, re-sync from scratch. It's easy. No worries. Trying to get around that. The other big issues, all the libraries, Web3, etc., were LGPL, GPL, like random weird licenses that were really not conducive to proprietary software, which means that if we have things that eventually occurred like Hyperledger that start making their own versions of it, which would be weirdly incompatible, just because we didn't let them join in the first place. So that was the idea, basically, that sort of idea. Also documentation was like nil. So the highlights of Ether's JS. So it's tiny. It's over the wire. It's actually about 89 kilobytes right now, not 88. But it handles mnemonic keys, private keys, JSON wallets. It tries to really do anything you could do if you were trying to build a wallet or framework or basically anything you want to do in Ethereum, it supports. It's ready to use. One thing that the other options didn't offer, especially at the time, was like a disk package that you could just, like, jam in a browser and be off to the races. You had to browser-fy all these libraries to make things work. Test cases. Most libraries around the time, again, even today have between like 83 and a couple hundred test cases. I'm currently clocked in at 20,000, give or take maybe 50 or 60 test cases. A lot of them are procedurally generated. Love to talk about that for anybody afterwards who wants to find out more about how to procedurally generate test cases. Providers. Going back to the syncing of full node, providers, you should be able to use anything you want. You can use JSON or RPC, but there's things like Ether scan and technically my crypto, you could just kind of tie into their back end. There's no reason why you can't just use these other sources of truth. Another big difference from people coming from Web 3 is that signers and providers actually go more to this in the next slides, but as a quick overview, signers and providers are very different, but there's different types of signers. E&S support is a first-class citizen. Again, I'll go more into that in a few slides. ABIV2, this ABIV2 has been available on Ether's JS for over a year now. I was kind of talking up last year at the previous DevCon, again, lost documentation and everything. All dependencies are MIT licensed, which meant a few of the libraries that existed like RLP encoding at the time, again, were only available as GPL or LGPL, so like those things were rewritten so that they could be MIT licensed. How many, okay, can't read the clock. Anyways, so yeah, going back to providers, there's lots of different types of providers, EtherScan, Infira, JSONRPC, IPC, Web is coming soon. There's a Web 3 provider, which you can, if you have a currently, current existing Web 3 app, you just jam that provider, wrap it in a Web 3 provider, and now you have an Ether's compatible provider you can use for any of these sorts of things. Fallback provider, we're coming with a smart provider soon, which will, for example, get quorum against multiple backends, because right now you're trusting APIs, you're trusting EtherScan tells you the truth. What if they're hacked, or you click that, I accept turning off SSL protection, basically, when you're at Starbucks, so that's the idea of providers. Providers are very high level, very only talking to what you'd expect a blockchain to be able to tell you, which is very separate from signers. Signers are where your private key lives. The idea that your private key should live in the same memory space as the thing that's just talking to the network and doing crazy things just seems inherently unsafe. So we let wallets be a private key and a monic. For example, Firefly, the hardware wallet we design, or Ledger Nano Wallet. These are just other types of signers you want to be able to use to carry on and do your work. This was a weird decision. I'm actually curious why this was originally designed. Basically, when you send a transaction in Web 3, you get back a transaction hash. So, for example, if you send a transaction to the geth node, and you say value this, data that, the geth node is figuring out the gas price for you, the nonce, all that extra stuff, but all you get back is a opaque hash. So you actually don't know what it chose for you, especially in the case of like gas congestion. You actually don't know what was used, so you can't even know if you need to replay the transaction at a higher gas cost. Importantly, all that information was signed by the geth node, so it knew all that information. It simply just hashed it and threw all that stuff away and gave you back the hash. So I think it makes a lot more sense to return the hash. This gives you a lot of advantages. The biggest one being that if you deploy a contract, you can instantly know what the, thank you. You can instantly know what the contract address is going to be once it's mined, right? That's kind of what the slide explains, I'm getting ahead of myself. But yes, the last thing I said applied to the slide. This for me, I often go on record saying if ENS is the only thing that comes out of Ethereum, that Ethereum has been a wild success. Like ENS, people, again, talk to me afterwards, like I will talk for hours about how ENS is like the biggest game changer in the crypto space. Like I don't even care about, yeah, yeah, exactly. Yeah, yeah, yeah. ENS, go get your stickers later, everyone. So ENS is really cool because you get these named things. It's kind of like dynamic linking. It means that if your app depends on a contract, you can actually, you can choose static if you want to put an address in there or dynamic if you want to use an ENS name. But it means if you update your contract, all those places you've deployed code, including maybe ENS, where there's a hash and you can't ever actually change it, just continue to work. Your upgraded contract goes off to the races. It's happy and functioning. So you can use it anywhere. If you're sending a transaction, if you have an ERC 20 token contract and you've got a two address and amount, that two address can just be rickmu.firefly.eath and it will be parsed for you and figured out at deploy time. Calling a contract is already asynchronous. There's no additional cost. Yes, human readable APIs. Okay, I'm at three, I guess. So I always thought this was also a strange idea. We have this machine readable code in the form of solidity. So we have all these signatures that are machine readable and actually sort of human readable. And so we take that machine and human readable code and we turn it into this machine readable code. It's complicated, so this is a simple ABI. It's six kilobytes worth of JSON, which is kind of ludicrous, as opposed to it's human readable and machine readable. Just use the solidity contract. So if you look, I can't point to the thing, but this is like all you need. You just need the signatures. We can parse that for you and figure out what the ABI should be. And the nice thing is if you look at the source code, thank you, thank you. You understand what this contract is doing. Most of the time you pull a big opaque piece of JSON in and now the rest of the code, you totally don't really know what's going on. Whereas this is very obvious what the ABI's are available to you. If you just use them, makes code readable. I think readability is very important, especially in terms of audits and like just trust. So, sorry, I think I'm almost through my slides, sort of. But ABI v2, so like I said, we've supported ABI v2 for over a year now. That's basically you can pass structs in, arrays of strings. It's actually kind of cool. Web3 now supports it. If you take a look at Web3's implementation, it's require ethers slash utils slash ABI coder. It's an awesome solution and it means we have like one good working solution that everyone can use. And we're off to the races. Da, da, da, da, da. Extra is promise friendly. You can basically pass promises in anywhere you can pass a thing in. A lot of blockchain things are asynchronous. So for example, if you have a transaction, one of the things you pass in is a nonce. Well, you can just pass in a promise that resolves the nonce as your nonce. And again, everything's asynchronous. It can be resolved. Bit39 mnemonics, we support English, Spanish, French, Italian, Japanese, Korean, and both simplified and traditional Chinese. Yes. Utilities. We've got lots of utilities for dealing with, oh, one minute. OK. ABI code, yeah. So basically stuff, these slides will be available online. I try to make everything as possibly available as I can. And the rest are just examples. I was not really planning to show these off. These are just in the slide deck. So when you look at the slides afterwards, you can kind of get an example of it's easy to use. You just pick it up and start using it. There's no syncing nodes. There's none of a, you don't need metamask or anything. It just works out of the box. And done. So questions? I think I have a minute maybe, half a minute.