The Neighborhood: Rethinking Ethereum Data Access

Transcript

Hello and welcome everyone. My name is Peter Robinson. This is the Ethereum engineering group meetup. Today we've got Dennis Vapen and he is going to tell us all about um Ethereum data and how you can um get that process that without using subgraphs. So an alternative to subgraphs. So, um, Dennis, before you lead off, um, on your talk, would you like to introduce yourself? >> Yeah. Yeah, absolutely. So, I'm Dennis. Um, I'm head of research at the indexing company. The indexing company is uh has been around for the last two three years and we're trying to focus on the data problems in in crypto. Um right now

we're building the neighborhood and the neighborhood is a data processing network that um processes um all data from all these different chains and it's it's as you said alternative to to subgrass but uh it can do way more but more about that later. uh I've before I joined crypto around 2018 I was a data analyst in human resources market research and when I went into crypto and to do more research on data itself but I had troubles getting that data or especially at scale um I had to either like dab into like APIs or didn't find the the data I was

looking for while I assumed it was all on chain. I could read it from a block explorer. So I figured out there's something that could be improved in the solutions that fetch that data from the these different chains. Um so that's when I started um doing more research and then I met Brock, the the founder of the indexing company and fast forward almost two years now. Um we've been building this uh this product together. >> Hey, brilliant. So um yeah that it sounds really good and it sounds like you're well placed to give this talk as well. So um can't wait. So please you know show us show us your um slides and

your demo. >> Absolutely. Yeah. Let me get that on screen. Um there we go. >> So um as said we're we're building the neighborhood with the indexing company. Um, but let's let's start with what's happening in crypto all the time. So, every crypto company and basically every developer in in crypto needs onchain data. Um, it's on the blockchain. It's publicly available, but getting that data is often a costly process. If you do raw RPC calls, you still have to filter. you still have to call that RPC

for historical data and you have to do the decoding and then um after loading it you have to do all these transformations. So what crypto is actually missing is a bit of like an ETL pipeline that a lot of data engineers or developers would know in web 3 if they worked those jobs before. Um but right now in crypto people are often just reselling data. Um they put it onto their network. Um, that's what a lot of the decentralized solutions do. Although, in my opinion, they're not really decentralized. It's it's still a very centralized way of of like storing data and then processing that actually locally. Um, but they

store it on network or they store it in a database and then it's often better structured. But now you have to ping an API um to fetch that data and that data isn't fitting for your model. um you have to transform it a lot and it can be super costly if you want to do that at at scale. So the alternative is what these companies do is they build it in-house and they um spel spend like thousands or or even millions for some companies at a year on having that data infrastructure getting access to the data and processing it after um then they have to build their own tools and there's uh a lot of elements to that that can break at latency

and then uh I think one of the most underestimated problems is that there is a lot of uh a shortage of good data engineers and people who understand um the data from all these blockchains. So what most indexing solutions do is they they spin up a subgraph. Um nowadays we also have sub streams that work from those graphs or its APIs. Um the problems with that is that if you have to change your pipeline. So let's say you're listening to one contract and now I need to add another one. You have to reindex you have to load it again into subg graph. It it it might have downtime

and uh it gives you very specific schema which you then still have to pull from that subgraph or retrieve from the subscreen and then transform after. So there's uh latency problems, there's redeployment problems, there's there's some downtime. Um and uh if you now want to do that at a multi-chain scale, that becomes a problem. Um because now you have to run like tens or like 20 subgraphs. So what we've did bit did with the neighborhood is we've built a network that basically listens to more than 120 chains and that network just focus on processing that data. So it's basically the ETL for

crypto where you take a raw block of data, you transform it with JavaScript and you have full control over which contracts uh which events um and then you can transform that in the same step. From there we can send it to wherever these developers want it. So it's often a Postgress database but it can also be a Kafka stream or you could do link towards a big query or web hooks if you want to do alerting um and it that way you can make it fit for a very small use case. So let's say alerting, you just want to have alerting on one smart smart smart contract flows that um are above

like 1 million uh from like maybe a stable coin or you can ingest the whole chain um into your own database. And one of the benefits of this network is that all these small nodes are processing the data in parallel. And that way the um no chain or no block is intermingled with each other. It's like you can do this at scale for all these different customers that use the network because everybody has their own logic and that's gets sent directly to them.

So the result uh from this is that we uh now have more than 120 chains on boarded. It's regardless of VM. So it's not only EVM. We can also do ST uh chains like Salana or MUVM. But of course um what we see being used more most demand is for for EVM chains which also makes it uh easier to make tooling for us because now we can focus on um filtering on events decoding those events and picking exactly those um that right data out of the raw block data. Um we can also for example do metadata from a block. So um that that is often um

something that people don't store but I think a lot of builders sometimes validators or um analytic systems need. So some of the use cases that um where this can be applied is is basically anything that needs onchain data. that um u wallets of course are a good um point for a user like if they ask us what do you need indexing for? Uh wallets are often a good starting point because they want to see their own transactions. They want to see their holdings.

Um trading systems um there's a lot of um interest now in low latency trading systems from these chains. There's arbitrage opportunities between chains. So um we're focusing on also solutions where we can do very low latency especially with the the mini blocks and like the the small shreds coming in where we want to run indexers locally next to the node and pick up that data directly. Um what we're also seeing is there is more DAB chains. So you need very flexible infrastructure to tap into those chains. Um, D5 protocols are often like classic use case. So, we pick up

the events and these smart contracts specifically. Um, agent systems where um, agents need contacts or they do something onchain. Um, so they have to listen to onchain events, act on it, and then that activity that's onchain, they'll pick it up again. Um, so on both sides, there's indexing needed. Uh and with these flexible pipelines, you can actually um start listening to all these new agents quickly. So you just add a new wallet um to that pipeline to monitor and suddenly that's a new agent you're listening to. Um and then finally analytics and monitoring. Uh if you want to do alerting, if you want to build

your own dashboards, um you need this kind of ETL. So, um that's it already for this these slides, but I I want to um do a live demo, but maybe uh Peter, if there's some questions beforehand, I can um answer them. >> Uh yeah. Yeah. So, I'll open it up to other people first. Does anyone have any questions? Okay, whilst people are thinking about questions, so I'm just trying to think

through the actual architecture of your system. So is the idea that um say with a mutable chain we've got, you know, a essentially a blockchain you could think of it as. And so we would run a node or as part of the neighborhood that would um like sit next to one of our nodes on the network and that would pump data into the overall the neighborhood network. Is that how it works or that that is actually uh spot on to what we're uh building out? So um yes uh so so for now we just run the network internally but uh we're opening up right

now. So what will happen is there is a lot of access compute basically everywhere in your browser but also let's say on a validator node. So you have this server where you have your node running, but you can install a neighborhood node next to that which only taps into that compute uh when it's um it's it's an access. So um it's more of a coordination mechanism to see like where that compute is available and now can use that to take data from blockchain. What is different is you don't have to source that data directly

from your own node. That can happen if you want a very like a very low latency indexing. Um but what we actually can do with this whole network is we could source the data like the raw data from somewhere else, send it to that small node, it processes it and then sends it back to the network. Um so that that could even mean that you run an Ethereum node but you're processing data from arbitum um next to it. It's just that we um can then tap into that compute we can reward those users for it. Um but even better for example if you want to um let's say get the whole history of

Ethereum you can of course get that from your own node but you're very limited in throughput. What we what you can do is ask the network um this is where it has to end up. This is my database and it then sources that from all these different nodes. So your node might take part in that computation uh for getting that data but it source it from maybe like thousands of other nodes too. Um and then with that parallel processing that means you can process this data very fast. So for example, we've done backfilling for Ethereum in under an hour, like the whole history of the chain, which uh is uh often um I I I I I think that's probably the quickest um

we've seen. Um and then often the bottleneck is actually the database on the users end uh instead of the network because it like scales linearly that compute. So there's even more innovative things that we could do is uh once we have more and more nodes in this network, we eventually can do a d like dashboards that are databaseless where you just source it from the raw block data, transform it on the fly and then send it to the database without needing the data infrastructure behind it as as a database where it just sits. Um so that's quite unique. Um but yeah for

that we just need to open up the network. Others need to come in and um start running these nodes. >> Yeah. >> Okay. Licky please ask your question. >> Uh hi um just want to more clarify in comparison to the sub graph you mentioned um is that m let me know if my understanding is correct. Is it like for subgraph you need to put in the query so that it will only fetch for the specific information you want which the pros will be like uh uh the storage will be less because you're only storing the data

that you want but the cons is like it like you mentioned that um every update you need to indexing again and on the other hand uh in your system it will be storing uh everything so that um it it's uh it can uh it doesn't have this uh reindexing. Um so my question will be like first it would that means it would take like the downside will be it takes more uh space. Um the second question is uh uh uh uh yeah I forgot. Yeah, maybe just this one. Yeah.

>> Yeah. So, so, so just to be clear, you don't need to store all data, but um it it depends on the use case, but in some cases, we actually store less data than a subgraph. So, how basically a subgraph works if you you launch one is you put in a script um that starts the indexing. The subgraph is basically just a database that is hosted for you with limited control over the data schemas and the API. Like the API is always graphql. Um but it doesn't respect any query patterns into that. Um you can do that a little bit in the script. So the script defines what you want to index.

That can be contracts or events like an AI but then it's always in that structure. um a lot of subgrass solutions you just like give the contract AI and then it prints a lot of tables which you never need. So there's also a lot of access in holding that data even in a subgraph even if if it's a small contract. Um and then you have this very specific database for that one use case and now you need to pull that data with an API. Of course, that's been solved already a bit with with stuff like substreams from some of these parties. Um, but then you basically process data from the

blockchain, you put it in a local database, and now you have to pull it again or stream it again to another database, which is weird. So, what we're trying to do here is skip that whole step of the subgraph. And then the only thing that matters is the transformation being done. So that's script. So what we do is we listen to the raw block data. We do the transformation uh and the JavaScript code. I'll I'll show you in a bit during the demo. And then we put it directly in your database. So there's no storage in between and no query layer in between. But now you can put it in your own database. And that's where you have all freedom over what to do with the

data into what data schemas you put them into what queries you can run uh how you expose that to the rest of the world. Um whereas like just with SQL and a database connection or through an API if you want to try to have that more public uh um different different ways to interact. So it's in a way we try to you know meet you where you are where you have want to have that data eventually anyway. Um yeah so so uh and one of the benefits is like if now that data pipeline is just running over like raw data now you can actually um start changing that pipeline on the fly. You

can start adding events and then the next block that comes in start indexes that event. So let's say a new user connects to your application. Um you already were monitoring like 10,000 wallets uh and users for your application. A new one connects. You now have like uh a new wallet you add to the list and then the next block that comes in gets indexed automatically. You don't need to redeploy. You don't need to filter after on the query. It's just like you get the new data in your database or wherever you want that. So, um yeah, but I think it's it might be good to show um one of our examples right now to um we we have on the website um

docs.indexing.co we have examples where we go from the whole flow from the chain to the database. Um and one of the first step is basically setting up a contract address filter which is um basically what we're going to do here is we're going to index a um on Ethereum and um most transactions on a just go to the pool contract and if you index the pool contract and filter on that and then listen to certain events events you basically have most events you're

interested in for A. So um let me quickly show you the A pool contract. It's this address uh on Ether scan. Um you can see important events here. I'll zoom in a little bit. Um repay supply withdraw. So some major events and it is decently active. Um so that also helps us and it's the the pool v3 contract here.

Um so the first step is basically creating a contract filter and it's actually super simple where we just insert data which is that contract and uh now it starts filtering every block on that value. So if a block comes in and doesn't have that address as a value uh in there somewhere, it skips the block and it doesn't process that for your configuration basically. So uh let's start deploying that um um filter basically. So this is the

filter. I can also try to reach this a little bit. Here you go. You send it off. It says success. So now we have a registered filter. Then the next step becomes having you can get the filters just so you see if it's if it has processed. So we process that. It says like hey we're listening to this data. So that's the contracts filter. The next one and that's basically where the magic happens is we do the transformations.

So um we have this transformation code here which listens to that block. So the block comes in here. It goes through all the transactions, even goes through the logs and then um this is where we built some tooling to just listen to the logs directly and see which events. So it matches the event signature um the the encoded version with the the version in the block, sees if that is one of the events we're interested in, and then decodes that. So now we're not only listening to the block but also

filtering on specific events we're interested in from that specific contract and then we can also process that and put it in a format that we want. So this is basically our data schema that will be put out to our database later on. So we have the block, we have the chain, we have some transactions um and and that's the um um the data we're basically getting from this pipeline. So it's only a few lines of code, but um then you already have basically a pipeline.

What uh I can deploy that I can test that transformation. Um, if I send this off, I basically um test this on um this block on Ethereum. It adds that filter uh from that contract and now we're getting uh some data back from that specific block. So, so if you know a specific transaction, you can test against that like, hey, I know I'm interested in this transaction. Does my logic work to pick that up? And we have the reserve data updated. We have liquidation call. Um, so that way we can

actually verify this is correct. There are other ways to do this. So, for example, uh I can take this event and uh sorry, this function and we have a console.indexing.co. We can go to um Ethereum here and now we have a more like interactive um version. So you can see what's in the raw block here. Uh but if I execute this code here um it should start finding the last block where some of this data was in.

You can also preview a certain block number if you really want that. Uh but now it's just like picking the last block. So um now we see that one of the last blocks which was this block over here contain the reserve data updated and a borrow event. So um with that um you can also verify if this code is working but you can also start changing that. So let's say we might not be interested in the block number. Um or I want um let's say I don't need the lock index here. I take that out of the code. I execute it again and we directly see the pipeline being

updated because lock updated is now gone. um or if I want to do like decoded data or chain name something like that we execute that and it directly updates that in there's no block coming in here but here we have it we have decoded data and we have chain name basically so that's how fast you can apply these transformations and basically redeploy that then with these these APIs. Um, so that's what we're going to do right now. We're going to register the transformation

and that actually deploys uh the transformation itself. Uh so the transformation we just saw now it's available. And then the next step here is basically what I should do to get it into my database. So now we're actually sending it off as a pipeline. Um we're deploying it right now. And let me quickly see. Yeah, it's it's deployed right now. Um because enabled true. It's also true for polygon. I added the thin here because there might be more events coming in. Um, and then in a bit I'll show you that in my

database. But we already basically went through all these steps. We tested the transformation. We registered transformation. And now we're going basically to part two where we send it to a database. I already set up the database itself um uh with a table. But luckily in this um in this tutorial we have um an example how to set up the table but you can basically just define the um basically this is the data schema from the output. So your output is just

your data schema. So that's how you can alter those transformations to make sure you end up with a data schema you want. Um and then finally um we deployed it and now it's going into the database. So let me quickly share another window where I have my database over here. There we go. Um, and now there's basically data coming in in real time um, from these different blocks. So, if I refresh this, uh, we now see new blocks coming in with these being the

latest. Um, let me quickly get that number into my block explorer. Uh it's it's funny enough because like ether scan at this moment I'll drop it in the chat um for maybe the next block that comes in um says this block is still unfaled um but we already have the data here in the database. So um the indexing is being done now faster than ether scan can load that data into the block explorer. So one of the use cases with this technology is like we can actually power block explorers. We have done that for the block explorer once upon where we did around like 20

um 22 chains at some point in real time and then combined it with various other data points. But yeah, I can um quickly send it transaction here in the chat. Um let me quickly see. Um so the transaction I just copied. Um like that's one of the transactions that's being indexed um at the moment.

So yeah, that's that's basically a whole pipeline. Yeah. can keep refreshing it. Um I think um for now only Ethereum is coming in because I haven't added the Polygon contract. Uh I think it's a different one for a um but the Ethereum data is is coming in in real time. Are there any questions on like this demo or what can be done with the transformations?

Uh I'll go first cuz um say rather than just the list of you know the events or you know as they're happening if I wanted to have say what are the outstanding payments owing on that a contract. So you know not what's been open and then closed but you know what is outstanding. Is there a way of you know processing the events and then you know like just having the the the the net effect?

>> Yeah. Uh I I I mean with uh uh Yeah. So so basically an aggregation on the database. Is that what you mean? >> Yeah. Yeah. That that is what I mean. Yeah. So for instance Yeah. Anyway, yeah. Yeah. Aggregation on the data and processing of the data and then just having the the output of all of that. >> Yeah. So, so one of the the things that we um what we offload basically is the responsibility of the storage. So, um normally you would store the data into a subgraph and pay for that storage. But now you're responsible for that in your

own database. Um but you can do similar things in your own database with these aggregations. So let's say you're indexing this a pool and you want to uh compute DVL. Well then we backfill that whole pool which is basically the same as reindexing that according to that data schema. We keep on the real time too. So now you can also have the updates and then that TVL that aggregation is basically just the the the aggregation of all those transactions in that pool uh specifically for a certain uh token or even maybe that user. Um but that those

are the query patterns that you can optimize for yourself depending on your own needs. But that also then means is like you can use that for analytics like this but also if a user is connected to your your DAP or your front end somewhere you can just listen to the single transactions. So um it's a bit of a combination of like single transactions that are coming in or those aggregations. Um but in general that means you can be very flexible with that data. If you own all that raw data in house, you now have the freedom to to do with it whatever you want. Um where it's aggregating

listening to single events, putting triggers on top. Um and otherwise you would have to build that after you know you pull it from an API or pull it from a subgraph. So, it's a slightly different way of thinking, but once you get it, it's I now own my data and I now can do uh whatever I want with that in my my applications. >> Yeah. Okay. Um are there other questions before I fire some more questions in? >> Yeah. May maybe I have to add something to this. So, so one of the things I mentioned was the database was processing.

Um, what we eventually can do and we actually have done it internally with our network too is um let's say a wallet holding. So, normally the holdings in your wallet is is a sum of all your transactions um on EVM. um what if we can get you all your data on the fly uh without storing that in a database and then having to aggregate that. So basically do the aggression step in the network. Um normally this would look like we load all the data from this wallet. We then aggregate that as a second step in the database and then expose that to developers or um or the user and now they can see their own

holdings. Uh a lot of solutions now have to just like expose that as a materialized view in a table and then resell that. Well, one solution we've built is what if we can just source all those blocks in the fly, then do that aggregation step again in our network and just give you that data, which then means we can not only give you the wallet holdings, but also specific coins. Uh, and it's just like processed from raw block data. And we've done that at the speed of APIs um where um the network just processes it and that's only possible because of that parallel processing. So um that is a simple use case um but we want to go

deeper but for that we we need to have access to more parallel compute and more people to start running these nodes. Uh and that that's that's still in development. We're actually raising around right now to continue doing that. Uh otherwise we'll get there um just through through normal means of business like running the servers for people and then developing it it with them. But yeah, um it's on the road map to build that out for now. >> Yeah. Okay. And I I um >> Yeah, Mark, go ahead.

>> Um thanks. Yeah, sorry I missed the start, so hopefully you haven't already answered this. Um I was going to also ask the aggregation question. Um but um often the aggregation's done like you get lots of events, but the events are talking about maybe progress through a state machine or something. Um then you want to know the current sort of state um um of of the contract after it's been through those various events. Um but the other kind of aggregation you get is like just in terms of reconciliation for like transfers or or whatever for balances. Um so that was but I think you've kind of answered that already.

The what you're saying is that the client does that in the database just themselves. >> Yeah. There's there's multiple paths there like if you want to get the current state I think in those um like those questions you could also just ping ping the contract itself right like there's often methods you can can get it >> uh what we have under the hood exposed to this network is a huge aggregation of like all these different RPCs >> so uh we we sometimes have done that give uh customers um access to that RPC C layer um and then they they can ping those those methods. What we even better

can do uh we don't have that fully exposed in this like in our documentation but we've we've built those pipelines where um a block comes in needs additional like metadata or data from a onchain does async RPC calls and merges that with other blockchain data. Uh so we we definitely have the option to do um basically API calls in this transformation layer. It might slow it down a bit because then you have an async request. Uh but you you you sometimes don't have to hold the whole state to to do like fetch that data. Um >> Right. Right. But your um sorry and maybe and this is probably something I

missed but um is this just event data or is there also a way of kind of accessing debugger level data from um from DVM execution? >> Um >> like the state of like one thing I'd often like to see is like what's the state of this this mapping um at this at this earlier time or whatever. Um >> yeah um I I might want to you know feel free to send me an email with a with a specific example because it's very often very specific and how to solve that. So sometimes that is actually having the whole state in your database and then basically you replaying that or querying

certain moments. uh sometimes it is a combination of pinging the the contracts and getting the data or and then >> basically build some of the calculations that are happen on chain offchain. >> Um so yeah it's I can't really answer that. Um but it's it's all an option and and yeah uh that's where we do a lot of uh conversations with builders like how do you get there with this tool? It's not only events. No, it's like anything that's there in the raw block. So, let me quickly show you that here. If I go to the template full block, um wait, that's let me just reset it and

and do it again for Ethereum. Everything that's there in the full block we can fetch. Um so here we it returns a full block. So here you have like level uh header level data. We have here transactions in this block. Uh we have the receipts. We have the traces. There's often builders that are in need of those specific traces. Um um like all of that data that's what we can fetch. Uh it's just that a lot of builders are mostly just interested in the specific events. Um, so we built some tooling to to like get that out.

Um, >> yeah. Okay. one perhaps easier um thing that it would be I think Rick this would be very helpful for as well um like if you've done a API update and you've changed some of the event um parameters or whatever u but you want to get a a kind of consistent view now of of across both a API versions then these sort of transformations I guess you could build that sort of unified view >> exactly yeah >> and and and that's that's you're tapping into a major difference with subgrass if if then you um have to like do the AI change it start reindexing it it might not match up anymore

>> um with this you can just say like hey I have this event signature my change but I still know it's like the withdrawal event >> so now you can there also different ways to express that but you can always say like hey it's just the withdrawal event and put the data in this column in my database it's the same um or uh create a new column in my database that is like second event >> just depends on the query patterns but at least you have the freedom >> and you don't need to reindex it you can just like >> switch on the pipeline and from now it's like different schema.

>> Yeah. >> Yeah. Cool. Thanks. >> Okay. Um, Leki had the same question I had and that's cost. So, um, I think he was he's probably thinking DAP cost if you know if I'm an application, how much does it cost? And I guess as well if I'm got a brand new blockchain, new roll up or whatever, how much does it cost anything to um have your chain added to the chains that people can get data from?

Yeah, it depends a little bit, but for example, we already have like 120 chains. So, in a lot of cases, highly likely that the new chain is live uh already being indexed. Um, but if you want a new chain, we can basically onboard that within a day. Um what we do for real-time indexing is we do basically without cost unless you really want you know tens 20s new chains added like that's a different scale but if you want a new chain just let us know and and we'll um we'll add it um because it's fairly agnostic in what data comes in um of

course it's optimized for some EVM with some tooling but we can also do the nonvm chains Um so yeah there's no not really a lot of cost in attaching a new chain in general our cost model um for a builder is basically how much blocks are being processed like that's regardless of chain. So um that's why that filtering and on certain events, contracts or wallets is super important because if data is not in a block, we don't process that and thus it is in the cost uh for running it through these pipelines and uh it's a very efficient model. You only pay for the processing that is um is

being used by you and the data you're receiving. Um, but then also if you need more or different data from a block, so let's say you're indexing AI and unis swap and they're both in the same block like there's unis swap trades and there's a um withdrawals or transactions, you only pay for processing that block because we're looking at the data anyway and picking data out. Um so this is where it becomes um very scalable also in cost at scale when you're interested in different sources of data in like these pipelines.

Um but even if you're like a small builder and your your DAP isn't doing a lot of transactions yet, you only pay for the the blocks that are uh being processed. So it also scales with onchain usage for you as a developer. Um so there's definitely some use cases where builders only pay a few few you know 10 or or 20 bucks per month because they don't have a lot of uh data to monitor. that that's why we've built a selfs serve like with the documentation they can just get an API key and serve these contracts um events and just get a pipeline running without us uh having to to um intervene but of course we're

always open for questions. Yeah. >> Okay. Fantastic. Makes sense. Um yeah. Okay. So I think you've answered the questions I had. Um, are there any more questions for Dennis? >> Oh, wow. Looks like everyone's happy, which is good. >> Awesome. >> Yeah. Um, so why don't you present those last few slides so I can we can um talk through what's coming up next.

Yeah. So, there is a merch store and um yes. So, please um if you're after a new t-shirt, this is the place. Um next slide please. Uh we've got some talks coming up. Um so, in um golly, just a week's time, I'm going to have to get my skates on. I'm going to be talking about 7702. Um and um yeah, so that is the new EIP that's part of PETRA. Um and then after that we've got the um circles currency protocol which is a new thing um which is should be interesting. And then we've

going back to our um DeFi and openness um and you know crypto uh roots um of um decentralized communities. So um valuing invisible work. So I think that that should be uh really good, really invigorating. And um if you are watching this and you're thinking, hey, we were developing some interesting tech. We should have a talk on the meetup. Please get in contact. Um and you know, maybe you can be two weeks after September the 24th. Um so there. Uh next slide, please.

Yep. And those are the social links. So, if you're watching this on YouTube, um you can join the meetup and ask tricky questions live uh which um can be helpful. Um there is a Slack workspace and from time to time there's example code. So, um yeah, it'll you can get that there. And that's it. So, thank you again, Dennis. That was a fabulous talk. Um I think everyone has learned about a new technology. So that's great. Thank you.

>> Awesome. Yeah. Thank you for having me on here and thanks for listening. >> Yeah. All right. Well, with that, I'll see everyone in another week or so's time. Bye-bye.