 Hi Rudy, so I'll be talking on Application that we build known as RCB so RCB is a IC bouncer and we implemented it we want to implement it as a RC bouncer as a service so Before starting off with the talks, so let me introduce myself. So I am Saiyan Chaudhary. I am from India and I work with the federal engineering team as a federal infrastructure engineer and This is my Twitter handle, GitHub URL and my email ID So let me give you a background of the talk. So we started off with the project called Varta. Varta is an Indic word which means to talk in Hindi and The aim was to build an open communication and a collaboration tool for humans so that So that on top of open protocols, right? So we chose RC as our platform and We also had a prototype working on we built it on MeteorJS and we ran it for One year and then last year we had to stop it and because we hit some issues because of its monolithic code base and so since it was a prototype and MeteorJS was also in its development stage and so we hit a lot of issues while writing code and then issues were like we when any When there was any issues we had to we could not restart a part of that particular application and we had to go for restarting the complete application as a whole and also The maintaining connections with the server IC servers was very was becoming painful in the long run. So So we chose to rework on this thing and Started of working with ICB So this is Varta. So we had we made a responsive UI on top of Bootstrap Twitter Bootstrap and it was working really good until it hit the issues which we faced last year so why a bouncer so bouncer is a Bouncer is a basically a proxy between your IC client and your IC server which accepts all the traffic and it all the messages pass through passes through that particular IRC bouncer the IRC bouncer basically resides in a remote server where Which is always online so that if you all if you even if you disconnect your IC client It can keep logging your messages and keep a like it's like a ghost for you on the internet So but why another bouncer? So We were we did a couple of research while doing on bounces and we saw that there are a couple of bounces like ZNC, but We did not want to reinvent the wheel But we saw that the things we which we needed was not there in the existing bouncer some was like multi-hose bouncer So if you know of in free nodes so free nodes Restricts your current number of connections to 50 and if you want to increase that connections You need to do go through a long process. So instead we thought of Supposed thought of a multi-hose system where suppose you get exhaust on a particular host So it would automatic scale to Scale to another host so this was the thing which we wanted for a bouncer and then When when the condition for multi-host comes in the scenario the data synchronization between those bounces get tough so We thought so we also faced this issue issue in the existing bounces and So there's no consumable and same API for any of the bouncer so cut all the current bounces have API to At the max create a user or delete a network or anything like that on that level But there's in it. There's no way to control your browser at the whole So we wanted something in which we get a person can Automatically create its own IRC client of the on that top on top of that particular API. So we started writing a API on top of IRC be also and Most of the if you start configuring ZNC, it's really tough to start configuration So we wanted something that is easy to deploy easy to configure and easy to maintain So these were the reasons for which we started off working with IRC be so As I told you like so we have basically Python pine boys and since Python 3 is is the latest version of Python right now, so we started building IRC be on top of Python 3 and we use a sync IO a combination of a sync IO and Python 3 in IRC be and the features that We want we which we have as a In the which we have and also we have been since it's in the building process So some features are to be implemented in next few months. So Currently we have a distributed and auto scalable System in place so whenever we have whenever Particular my host get exhausted So we automatically try to scale it to another level and if the if there's no need of that host we try to scale down also at the same time and So then we have a web CLI and we have web and a CLI to Control your bouncer. It's not that great right now, but in the future it will be so the CLI is pretty much good But the web is test we are working on the web part right now. So it would be good in next few Weeks maybe so we are planning for to do a release in next month and Right now, it's really easy to manage. So you just need to fire a few commands and your bounces is ready to go and So consumable by external services, so we plan to have like So we plan to make that API so that API I was talking about so we are building an API on top of ICB so so that using that API endpoints the people outside People can actually build their own IC client on the top of that particular API. So the architecture we plant is Like this so we have a lot of so those are the IC client which actually connect to a load balancer So the use of the load balances that in it runs on 80 or a 443 443 port So it's helpful Because it can be accessible from anywhere and this scenario we have seen that in many Indian colleges the ports like the IRC port or the gate port is usually blog. So in that scenarios Students actually find it helpful to connect to something on the internet itself on 80 port so we have a load balancing place and those and then We have this cluster of bouncers which actually connect to the IRC servers and Then we have the CLI through which an admin as CLI and a web console through which an admin can actually add network create users and Actually manage the bouncers But if you see right now so this is actually a data store which might not be visible properly and so You might see that this Bouncers web console and CLI is kind of divided into components, but how do they actually communicate? So recently if you have heard of Facebook Facebook Gave a new proposal on a framework called flux. So basically it's a unidirectional directional Data flow the so they propose that there should be a unidirectional data flow so whenever there is action the data passes to the dispatcher and the data store is updated and They the data store actually emits out events based on which the view is re-rendered again, so We implemented a similar thing on the Server side, so whenever a bouncer wants to connect to Suppose they want to update a network, so it makes a initial initialization call To the data store wired to via the dispatcher and once the data store is updated it actually events signals to all the Components and the consumer which are actually listening to this particular events can actually work on those messages and suppose they can Disconnect a bot update a bot or do operations based on that particular event so the current status is we did a 0.1 release recently and we have a basic authentication support in which the IC client is can connect to this particular IC bouncer which through access token and Through and then we have support for multiple connections multiple clients through the same IC server So if you connect through X chat or it see the so it uses the same connections to connect to the IRC server and Then we have a like I told we have a CLI in place So it we are building on with the CLI also so since it's a 0.1 release. We have a lot of scope in future and Let me explain like what's the way ahead so As I told you like a free node restricts the number of connections to a from a particular IP so After talking to the free node guys, they told that if you have an IDent server if you do identification So we give a increased number of connections that you can do so we are planning to build an IDent server and then This is kindly we are implementing like I told we have we are planning to implement a flux architecture on the server side, but this is actually done which we have which we will be releasing in 0.2 release and Autoscale to avoid maximum connections per limit IP limit. So this is basically dependent on IDent server. So We will be so once the IDent server is done. We will be working on this third issue So on the bigger picture if you know so after IACB is stable, we will be working on Varta again and So that Varta will be use case so IACB will be use case for Varta and if you know Fedra is working on a communication tool for its Fedra contributors known as Fedra hubs, so Fedra house will be having an IACB widget through which all the Real-time chat that is happening over the Fedra channels can be seen so We are having a plan to integrate Fedra house with IACB in sometime future so Right now we are two of us are currently working on this project. So the more the hands it would be better so how can you join so we are working on IACB ground up there are plenty of tasks to do and This is the github repo which we have under the Varta organization. You can look up for the issues on Varta on the IACB repo and Start contributing to it. We also have an IACB channel called hash Varta. So You can come down and bring us there also. So my IACNIC is sign. So you can come down and ping me there So, yeah, so the free note channel is hash Varta The code rep is in Varta slash IACB and we also have a mailing list for discussion, which is on Google groups So you can join in there and post any questions that you have So that's all from my side. So any questions? So I think I can end this talk. Thank you