 Okay, so I'm going to do a quick presentation on some Ethereum JavaScript stuff, and can you guys hear me okay? Is everything good? All right, cool. So it's going to be on some alternatives that are available in the ecosystem that you may not be aware of. And I think it should open you up to kind of the possibilities on the RPC layer and kind of how you want to approach designing your app or DAB. So right now the Ethereum ecosystem, especially on the RPC layer, is kind of dominated by these modules, Web 3, Ethereum.js, Parity API, Ether's.js, which was just recently released, and ETH.js, which has kind of been in the background for a little while. So to go through a bit of an overview, ETH.js is a small organization that has a few modules 15 in total, and we have one boilerplate and a few development tools, so some command line stuff as well. Everything's fully documented, everything's fully exemplified, and MIT licensed. It's production ready, although there's one module that you probably shouldn't use because it's not EIP 155, so Richard tells me. And 100% test coverage and 98% build up time as a general policy. So this is kind of the organization as a whole. And it's on GitHub, so just github.com slash ETH.js, and we have about 20 repositories. So initially a few months ago, I had gotten a little frustrated with Web 3, and I had also been working and talking with Richard Moore on a few different points, and kind of wrote a different approach to Web 3, and also a little different approach to how ETH.js was doing it at the time. And I definitely encourage you to check out all the alternatives and kind of make a decision for what's right if you do want to use an alternative to Web 3. And so basically there's a few different philosophies and things to keep in mind. So ETH.js can be used as an alternative to Web 3, but I actually like it to be used more for architecture. It's used in quite a few projects, I'll go over in a bit. I think diversity in modules and libraries kind of makes the community stronger. I think having different options and different opinions and different ways to interact with Ethereum is kind of critical to building a stronger community and stronger infrastructure. Companion libraries help influence each other's design. So some of ETH.js kind of helped Web 3.1.0, ETH.js helped me build some ETH.js stuff. So and in fact I use some of their modules in my libraries. And of course we still follow all the RPC specifications and the provider models that people are used to. But we kind of have different opinions on approaching how to interact with it. And so the way that I've kind of constructed ETH.js, at least the core interface there, is you have your contract module, filtering modules and so forth. This has become kind of a standard practice now. I have my querying layer, which combines both an RPC module and a formatting module. And basically formats all your inputs and outputs to the RPC layer automatically. And ETH.js schema is actually, I think, one of the better things that I definitely did here. So I just laid out an JSON file, the entire RPC specification and all the inputs and outputs. So you can basically take that and auto-generate the entire RPC query layer and have that in automated process. So this has kept it to be a very easy process for me to update or for others to come along and add methods and so forth. It really is all automatic. And so just a little more in depth on some of the modules, here's some providers for signing, HTTP querying, some unit handling, formatting, event filtering, contract handling, transaction signing, although definitely just use ETH.js for that because EIP 155. And accounts, so just generating and managing accounts. Although you have to be very careful because you do have to supply your own good sources of entropy. And while I do supply some sources of entropy with random bytes, which is known to be safe, it's basically you want to bring a lot of entropy to the table that's very healthy. And some util modules and some E&S resolving modules. So here's the schema that I was talking about. So this just lays out the entire RPC specification in a very data lean format. I'm not going to say it's particularly standardized, but it essentially lays out all the inputs and outputs. So if you want to take this and go into, you know, Objective C, or if you want to take this and go into another language and build an RPC layer for Ethereum, you can just take this JSON, automatically generate the whole thing. So, and I actually encourage people as well, one thing that I've found with doing a lot of these modules is it's helped people learn more about what the RPC layer is and what it's actually doing, because it's really simple. Like, what Web3's job is, or Ether's, or ETH.js is basically just to help you interact with the node on the RPC layer and format some data, and that's it. And it's a very straightforward process. Number handling and these other things are as well something that should be simple but turned out to be a little complicated for some reason. I don't know why. So here's just ETH.js kind of an action. It looks very similar to Web3. And I follow a very similar format to Web3. And other libraries don't necessarily. So just to give you an idea of what that looks like. So the modules are all designed with the same kind of documentation and standards in mind around testing and so forth and try to make the exports clean and simple and easy to update and upgrade. So basically like, you know, I wanted to build a set of modules that the community could help out with. And if anything just learn about the layer and also if they need things for certain architecture pieces they can use these modules. So ETH.js is used in production for Metamask and Fira and Truffle, mainly for certain bits of encoding and decoding and RPC layer stuff. And just to go over a little bit of the thinking behind how it's developed. So I like safe versioning where, well I call it safe versioning, where you don't have floating MPM versions across the modules. Just because I found that when modules update the MPM versions they shove up to the top and then potentially cause problems that you can't foresee. So I like to use hardened versions across MPM and just kind of keep the updating kind of slow and boring but more meticulous and more tested. All the modules are driven by what their dependencies are. So there's a lot of nice isolation between all the various modules. It's built with the Dapp and App architecture kind of target in mind. Small and concise, async only. And I try to fail as loudly as quickly as possible everywhere. Strong types as best as you can get JavaScript strong types. Although I do support some Amorphic number handling and I'm kind of looking to remove that. As well community driven design so keeping the code clean and simple and being able to be upgraded very easily. And as well trying to keep opinions off the table as best as possible and keep configurability really high across the whole stack. So a big feature and kind of a big note is that we use bn.js and not big number.js and the pros of that are that it's absolute precision by default. So it doesn't support decimals and floats which are potentially very dangerous considering that we're working with money and rounding is not necessarily the greatest thing. And it's heavily used and interoperable by Ethereum.js and Ether.js. But the cons are that it's not necessarily interoperable with big number.js, Web 3. And sometimes it accepts invalid values on prefects.hex which is somewhat dangerous but we kind of take care of that on another layer so you don't really have to think about that but it's just something to consider. So signing providers and account generation. So just simple providers to kind of shove in sign transaction packets and kind of handle accounts. We provide those too. And as for some of the dev tools that we offer, so this is a tool that I've been working on for quite some time. So it's a highly configurable multi-stage language agnostic contract deployment facility. The idea is that you have something similar to Webpack where you have this single JavaScript module to highly configured deployment stage module. And basically the idea is you take all these raw imports like JSON files, contracts, you know, things that need to be plotted out. You shove them through loaders that you can define yourself like Webpack. And then you run them through a deployment module that can basically take that data it's formatted the way you want and now you run the deployment staging the way that you want it. And then you kind of fire down at the end. And then you can output your data with simple output formatting plugins. And the result is that you get this very complex deployment staging facility for contracts that you can kind of tuck into Mocha or you can tuck into whatever testing facility you want. And you can also define your environment really easily. So you're just putting in the raw provider object and a name and your default transaction objects. And then you're just going to run that deployment sequence. And the thing is there's a lot of tools out there like Truffle and everything and they're getting better all the time. But this was essentially what I wanted from the beginning which is just the sequence tool that I could run complex deployments with and just do that in a very fluent way. It's high configurability which means there's a high set up overhead when you initially start using it. But basically once you get your deployment environment the way that you want it with the loaders that you want so Sol-C and some environment loading and stuff, then you don't have to do anything you can just reuse your same modules over and over again. So this is one thing that's going to be moved into ETS. Right now it only has about 30% test coverage and I need to get that around 100 before I move it into ETS.js. But that's called ETH deploy and that's available on my github so Silent Cisro slash ETH deploy. So a bit of the roadmap. So I'm going to move the ABI work from ETH.js just over to ETH.js because Richard Moore is literally the god you've never met yet and is amazing. So he's in the room. Personal hero. So as well the removal of buffer across the modules which should reduce the non-account handling module to around 50 kilobytes and as well better account handling and filtering. So right now I have pretty good filtering and event handling. But I think I'd like to get that better. Some people complained about certain aspects of that so that'll get improved. So I'm going to integrate some new bounties networks that are coming about. So bounties.networks is very cool and Gitcoin. And that's just for keeping the libraries updated and keeping bugs away. Removing amorphic number handling. So basically right now we support multiple kinds of types going into number handling. I think I'm just going to support probably just big numbers and while that's a little bulkier than everyone's favorite. Sometimes I prefer that just because it keeps types strong. And then as well more detailed air handling. So just I'd like the areas, right now they are pretty detailed but I'd like them to also be user friendly for new users. I think that's pretty critical to new people entering the space. And then Gitbook documentation. So right now all the documentation's in a repo through Readme's. So I'd like to move that to Gitbook. And just as well so because I have just a few minutes. So there's definitely been a lot of discussion before I just thank all the people that heavily influenced my thinking. There's definitely a lot of discussion around alternatives to Web3. I think Web3 has been quite a journey. I've been using Ethereum since Proof of Concept 5. So I've kind of sludged through the journey at every stage when Ethereum barely worked and there was no tools to now it's fantastically working and there's so many tools but still a lot of room to grow. I think the architecture is growing significantly and we have a lot of really cool stuff coming up. And I think the thing with alternatives especially having kind of a diverse set of tools at this layer is just this is like the front door to Ethereum. And it's very critical that everything works properly, that errors are thrown where they should be, they throw loudly, that early users to our technology can kind of get a great experience out of it because right now it's not a great experience. And right now we have a lot of junior devs and stuff that are definitely melting when they start using Ethereum when they shouldn't be. It should be a very simple process. And I think that we kind of need to get more realistic with our expectations and what we want to achieve, especially when it comes to just like an f-ing RPC layer that has some data formatting and some contract handling. It drives me crazy. So I think if you see more to make them better or even to do your own, you should definitely do that. You should definitely expand the ecosystem and try to help out where you can on existing modules. And once again, my personal favorites definitely lie with Ether's JS and the modules that I've been using. And I actively developed apps so I'm currently developing boardroom which has been in stealth mode for like two and a half years. Super old project. And so I'm constantly using this tech that I've been implementing. And that's kind of given me a completely different perspective on architecture. But as well, I just like to be a little more old school with my thinking. So, you know, the Unix philosophy and all that sort of stuff in mind has kind of led me to this sort of design. So yeah, just a special thanks to a few people. So Richard Moore for doing Ether's JS, Web3.js, and Fabian for, you know, manning the ship and like, holy shit, it's been just like a crazy ride. And now there's like a bazillion people in the DevCon room and not just like a hundred. And Dan Finley from Metamask and Pele and Martin Betsy and Vitalik for creating Ethereum, which I always thank at the end. I just think it's great, you know. And then Joe and Consensus for funding everything. This is my contact. And that's the link to EtherJS. And thank you.