IPFS multi-gateway experiment in Chromium 

<h2>What is combat robotics?</h2>Like everyone, Little Bears have hobbies, interests, and fandoms. And we like to share - it’s quite fun to see what others are into! The avocation I’ve come to be known for around the virtual office is combat robotics[1]: people build machines and have them fight each other in an arena.If you’re unclear what I’m talking about, and you happen to be in the US, there are a handful of names that&nbsp;might&nbsp;be familiar:<ul><li><a href="https://hackmd.io/@Evv6iNEZRz-r2TavEyAnTg/rkURlGbBh">BattleBots</a>: The longest-running (in multiple incarnations) major TV show about combat robotics, and now the only one still active</li><li><a href="https://www.nhrl.io/">NHRL</a>: The premiere competition series</li><li><a href="http://sparc.tools/">SPARC</a>: The only major association of combat robots tournament organizers in the US. Even if your club doesn’t participate in the committee that writes these rules, they nonetheless almost certainly follow these rules or only deviate slightly</li><li><a href="http://robogames.net/index.php">RoboGames</a>: The biggest competition on the West Coast, the only competition with a weight class that has the same building rules as BattleBots, and the only major US competition with the dubious distinction of having had an arena breach</li><li><a href="https://robotruckus.org/">RobotRuckus</a>: A super cool tournament</li></ul>If none of this sounds familiar to you, just imagine bolting power tools to RC cars and having them tear each other up.In just about any other fighting competition I can think of, the entrants are about as similar as possible physically. With most bot competitions, though, the intentional mismatch is part of the charm. Sure, there’s weight limits and various other rules, but restrictions breed creativity. I love the variety of different designs and approaches people take - and figuring out what works well against what, and under which circumstances.It’s also the only spectator competitive hobby[2] I can think of that has a real audience and for which most of the “stars” are world-class engineers in their day jobs. One could do worse for heroes, if you ask me.<h2>Dipping our toes in</h2>But I’m not just a BattleBots&nbsp;<a href="https://snug.moe/notes/9eamjkzjrg">super</a><a href="https://gitlab.com/jbt/bot_data/-/blob/main/src/rel/fight.rs">fan</a>. I’m also a member of Team Halfway.You see, my eldest child, Susy, and I got it into our heads that we’d like to try our hand at building and competing ourselves. Neither of us has any real background in this stuff, so we agreed to build from a kit. And not just any kit; we went with the most popular one,&nbsp;<a href="https://www.fingertechrobotics.com/proddetail.php?prod=ft-viper-v2">Viper</a>, for which I knew Team Witch Doctor had published a&nbsp;<a href="https://www.youtube.com/watch?v=OkAU8hRgrwQ">series of tutorial videos</a>. And we did it in its simplest configuration (as a wedge).Thus was born…<figure class="image image_resized" style="width:75%;"><img src="https://storage.googleapis.com/little-bear-labs-media/born_1e4eea3f9e/born_1e4eea3f9e.jpeg" alt="born.jpeg"><figcaption>Building in progress…</figcaption></figure>Henry!<figure class="image"><img src="https://storage.googleapis.com/little-bear-labs-media/henry_7bf4e34aa9/henry_7bf4e34aa9.jpeg" alt="henry.jpeg"><figcaption>Here’s Henry!</figcaption></figure>If you’re wondering why it’s named Henry, you’re in good company - I also wonder this.We did some limited&nbsp;testing at home.<figure class="media"><oembed url="https://www.youtube.com/embed/hfgolB0yn3k"></oembed></figure>Building it is half the fun, as they say (or they should say, anyhow).<h2>Team Halfway hits the road</h2>Once you have a combat robot, it’s not long before the arena beckons. So last spring, Susy and I took Henry on the road to get into the ring for the first time at the “Delta Nine Delivery: State of Franklin Robot Rumble.”It was a long drive to northern Tennessee, but rather pleasant. Susy couldn’t remember having been in the Appalachians before, so that was a nice side experience.<figure class="image"><img src="https://storage.googleapis.com/little-bear-labs-media/hills_f3477e7cbe/hills_f3477e7cbe.jpeg" alt="hills.jpeg"><figcaption>Appalachian vista</figcaption></figure>On a side note, because it took place on April 1st, my wife let some people know I “took her child across state lines” to enter them into “a fight-to-the-death tournament operated by a drug ring.” Technically the only factual error is that the (legal) dispensary was the main sponsor but not&nbsp;operating&nbsp;the event, but you can see why the claim was nonetheless quite misleading.<figure class="image"><img src="https://storage.googleapis.com/little-bear-labs-media/meltingsign_29fa99c114/meltingsign_29fa99c114.jpeg" alt="meltingsign.jpeg"><figcaption>A long drive</figcaption></figure><h2>The big show</h2>We arrived at the site at exactly the moment registration was to begin. We talked to an organizer, claimed a table, and got set up. We triple-checked that Henry was working in the testbox, charged the battery, etc.<figure class="image"><img src="https://storage.googleapis.com/little-bear-labs-media/entered_aef5713e0b/entered_aef5713e0b.jpeg" alt="entered.jpeg"><figcaption>Ready to do battle</figcaption></figure>But it turns out we weren’t just a rookie team; we were at a tournament run by rookie organizers. So then began a period of unclear length waiting for them to be fully set up.<figure class="image"><img src="https://storage.googleapis.com/little-bear-labs-media/arena_14415cb19f/arena_14415cb19f.jpeg" alt="arena.jpeg"><figcaption>The arena set-up</figcaption></figure>That did give us plenty of time to scope out the competition.<figure class="image"><img src="https://storage.googleapis.com/little-bear-labs-media/pits_bf9786ff9c/pits_bf9786ff9c.jpeg" alt="pits.jpeg"><figcaption>Competitors at the ready</figcaption></figure>And chat up our neighbors.<figure class="image"><img src="https://storage.googleapis.com/little-bear-labs-media/multibot_6c7cc223ef/multibot_6c7cc223ef.jpeg" alt="multibot.jpeg"><figcaption>Meeting some friendly little bots</figcaption></figure>&nbsp;<h2>Let the battle begin</h2>Eventually things got rolling with the Fairyweights: bots so small (150g max) that they’re generally seen as having a&nbsp;higher&nbsp;barrier to entry than the Antweights like Henry. I particularly enjoyed the very cute flippers having to fight each other. Flip. Flop. Flip, flip, flop. It doesn’t quite translate to video very well.Eventually, Henry’s first match was at hand. Henry was up against Carbon Monoxide, a pretty nasty undercutter with control issues. You can see the sections of the event most closely related to Henry&nbsp;<a href="https://libre.video/videos/watch/182540b9-f84c-42a8-855d-1f73af96f1cd">here</a>. But here’s a behind-the-scenes summary.<figure class="image image_resized" style="width:25%;"><img src="https://storage.googleapis.com/little-bear-labs-media/carbon_monoxide_b5b03c307e/carbon_monoxide_b5b03c307e.png" alt="carbon_monoxide.png"><figcaption>Competitor #1: Carbon Monoxide</figcaption></figure>All those occasions of talking to the TV at home was decent preparation to offer advice as the coach-in-the-corner during the fight. One aspect I didn’t consider, though, is how very audibly close you are to the opposing team. I was able to hear&nbsp;their&nbsp;adviser’s commentary, which at one point gave me some awareness of what their plan was. I got very soft-spoken with my advice from then on.In general, a floor-scraping wedge like Henry should do pretty well against an undercutter, as they can redirect the opposing weapon (horizontal motion to vertical), causing the opponent to lose control and damage themselves. And that did happen, kind of. However, Carbon Monoxide was prepared to be violently thrown around the arena repeatedly, and Henry’s simple plastic “armor” was unable to hold up to their weapon.After the match, Henry’s wedge was completely gone. The top armor was cracked with a piece missing. There was damage to a wheel. The chassis itself (the aluminum holding the whole thing together) was bent and actually cut at one point. A wire was pulled. There was a decorative eye missing - though apparently the announcer got his hands on it and added it to his hat, much to Susy’s amusement.When we got back to the our table in the pits, we had a very sober assessment of the damage. The tournament was, after all, double-elimination. Upon first look, I couldn’t envision how on earth we could fix this. We didn’t have spare parts. We didn’t have an awful lot in the way of tools beyond the stuff used to build it in the first place and a few tools I happened to have around the house for non-bot reasons. I hate to admit it, but I was tempted to suggest we drop out of the tournament.But I kept that thought to myself. This was a decision for the team captain to make, and I would follow their lead. And Susy wanted to cobble something together. It was a struggle and a half, I’ll tell you. We sourced “parts” from other people’s trash. We borrowed tools and screws. We made trip after trip to the test box to see if maybe this time it would kind of work ok enough.After a few hours of nearly non-stop motion on our team, we got Henry to a point that Susy was willing to call drivable, or at least as drivable as it was going to get. The new “wedge” was one kind of plastic, thoroughly covered in duct tape, then another kind of plastic, covered in several more layers of duct tape. We never did replace the eye; rather we dubbed it “Zombie Henry,” as it was clearly completely dead and had kinda-sorta come back to life, but in a hobbling sort of way.We got the duct tape idea from our neighbors, who pointed out that it can blunt the force of a spinner, and by that point we were able to look up our next competitor and see it was another horizontal. I still had my doubts about this strategy, as it gives up on the ramp’s deflection capabilities. That said, one can’t really question much, much more experienced competitors, especially ones already lending tools, especially under such time pressure. And the team captain seemed to agree, so I wasn’t going to push the issue.We did get a&nbsp;bye&nbsp;- we had a round without an opponent to match up against, which helped with the repair time.<h2>Ready for round two</h2>The next matchup was Henry versus Pluticorn’s Revenge.<figure class="image image_resized" style="width:25%;"><img src="https://storage.googleapis.com/little-bear-labs-media/pluticorns_revenge_8ca1c7c3af/pluticorns_revenge_8ca1c7c3af.png" alt="pluticorns_revenge.png"><figcaption>Competitor #2: Pluticorn’s Revenge</figcaption></figure>This bot was a two-wheeled undercutter with its weapon axis rather close to its center of mass, which seems a little less fashionable these days, even if I still prefer it.It didn’t take long to see how Henry was going to hold up this time around. Pluticorn’s Revenge was able to slice right through our makeshift front panel with ease. After only 26 seconds of a nominally two-minute fight, Henry was no longer able to move at all (we would later learn a wire had been sliced). Susy turned to me and said, “Oh, no!” as it was clear what was happening. At this point the question was really whether to allow the opposition to continue to beat on Henry and get counted out, or tap out early to salvage what was left of the bot. As this was our second loss, there was no longer any strategic point to tapping out, as I had discussed with Susy on the way in - it was really time to leave it all on the table. But, on the other hand, clearly there would be no conceivable way to win the match. Also, standing there&nbsp;not&nbsp;driving, and watching your bot get bashed, isn’t a ton of fun.So I simply asked Susy, “Would you like to tap out?” The opponent heard our conversation and stopped driving to turn and listen in. Susy tapped out, and it was over.<figure class="image"><img src="https://storage.googleapis.com/little-bear-labs-media/defeated_6a91045cc5/defeated_6a91045cc5.jpeg" alt="defeated.jpeg"><figcaption>All tapped out</figcaption></figure>As an aside: BattleBots doesn’t have tapouts. Sometimes the competitors will have a gentlemen’s agreement and the to-be-winner will simply wait for the count-out. Other times, Riptide feels the need to do nigh-irreparable damage to Shredderator, and there’s nothing anyone can do about it, because them’s the rules. It’s just one of the ways the TV show differs from typical competitions.So yeah, we didn’t exactly tear up the world with a mind-blowing winning streak. But I think we put up a respectable effort, learned some, and had fun. And while the drive was longer than I would prefer, it did give us plenty of time to chat/bond/make memories, and that’s a win of its own.<h2>What comes next?</h2>Well, there’s two plans, which we may advance in parallel.On one hand, there’s a pretty significant competition at DragonCon in September we may want to participate in. That’s enough time to do a somewhat significant build, but knowing that unforeseen failures come with breaking new ground, we’re reluctant to do the big ambitious thing. So for now, we plan to fix and upgrade Henry instead. In particular, the plan is to get the pre-packaged&nbsp;<a href="https://www.fingertechrobotics.com/proddetail.php?prod=ft-viper-h-spinner-addon">horizontal spinner add-on</a>. On one hand, that’s kinda cool because Susy always liked Tombstone on the show. And on the other hand, it’s perhaps somewhat ironic/poetic if you look at the opponents we lost to in our first go-round.The bigger plan hearkens back to the early days of Susy, Lily, and I watching classic BattleBots together. They both went through the mental exercise that lots of new fans do: “What would I build?” Without my prompting, they both sketched up their ideas, which I think is quite cool. What is perhaps even cooler: it sounds like Susy wants to make “This Side Up” a reality (but at one pound rather than 250 pounds). It’s going to take some time to do that right, especially since neither of us have the background for this.Because mistakes are easier to fix in software than hardware… because custom parts are easier to order if you have a CAD drawing… and perhaps at least a little bit because I’m a software guy and find it less intimidating… I insisted we start the lengthy process of bringing This Side Up to life with a little CAD. We haven’t even finished that part, but here’s a sneak preview of the unfinished first draft:<div class="raw-html-embed"><figure class="video">
 <video autoplay="" loop="" playsinline="" src="https://storage.googleapis.com/little-bear-labs-media/tsu_616f57344e/tsu_616f57344e.mp4"></video>
 <figcaption>The next bot takes shape…</figcaption>
</figure></div>Our next bot may be just a plan and a gif at the moment, but one thing I learned from this first foray into competition is that planning, building, and driving with my team captain is an adventure worth undertaking.<hr>Notes:1. I feel the need to insert a minor note on terminology. I’m not in love with the term “combat robotics,” especially since search engines often think you’re asking about machines of war, but it’s the most accurate of the widely-used terms. For example, if you look it up on Wikipedia, you’ll see they call it&nbsp;<a href="https://en.wikipedia.org/wiki/Robot_combat">Robot Combat</a>. And that immediately begs the question over whether these machines are, in fact, robots.Much ink has been spilled, and an entire&nbsp;<a href="https://podcastindex.org/podcast/46851">podcast</a>&nbsp;founded, over arguments about what does or does not count as a “robot.” On some level, it doesn’t matter. In my opinion, that podcast’s definition is ridiculously too narrow, but nonetheless most of the machines we’re talking about here aren’t robots, which is why I call them “bots.” Software “bots” are called that because they have some attributes of robots (in particular, automation), but lack other features needed to be robots (hardware). These machines are the exact inverse - they are extremely similar to robots physically, but in most cases lack automation.You would be permitted to enter a true robot into a combat robotics competition, by the way, as long as you follow some safety precautions (see&nbsp;<a href="http://sparc.tools/wordpress/wp-content/uploads/2019/SPARC_Robot_Construction_Specifications_v1.3.pdf">rule 7</a>), but few people do. It might seem counterintuitive to refer to a non-robot activity as robotics. It actually works, though, as “robotics” means “<a href="https://www.wordnik.com/words/robotics">The science and technology of robots, their design, manufacture, and application</a>”, and there is no doubt that the technologies and techniques at play here certainly do transfer over to building true robots.&nbsp;2. I’ve also made a point to avoid the word “sport”, which to me is a&nbsp;<a href="https://en.wikipedia.org/wiki/Game_theory">game</a>&nbsp;which is also an athletic competition. Soccer, basketball, tennis, and boxing are all clearly sports by this definition. Combat robotics isn’t particularly athletic - the question is similar to whether “e-sports” are sports, and I think not. As an illustration,&nbsp;I would claim discus throwing isn’t&nbsp;a sport for the opposite reason - it’s certainly an athletic competition but I wouldn’t consider it a game.

The adventures of Henry and Team Halfway

In October I had the opportunity to visit Lisbon for LabWeek2022, a decentralized conference hosted by Protocol Labs (PL). It was a chance for folks across the Protocol Labs Network to come together and learn from a wide array of presentations, meet each other (perhaps for the first time), and talk about the future of various PL projects. I had only been working with PL for two weeks leading up to the conference, so I was excited to use the event to jump-start my work with them.Both Little Bear Labs and Protocol Labs are fully remote companies, which means in-person interactions with coworkers and clients are few and far between. As I reflect on the time at LabWeek, it’s these face-to-face conversations that were the most valuable part of the week. As I looked for my seat before the first day’s opening talks, I realized that I was sitting behind my primary contact at PL, and got to meet him for the first time. Throughout the week I had a chance to talk with several other folks from PL working on projects adjacent to my own. In a world where all of my professional collaborations are virtual and the work itself sometimes feels intangible, these in-person meetings provided a sense of substance and realness to my upcoming project with PL.I was also very fortunate to have my coworker Jared Cole join for several days of the conference, and we spent time debriefing our conversations while also exploring different parts of Lisbon. The flexibility of taking video calls from home is great, but it’s hard to overestimate the value of occasional long-form conversations in person. Our discussions over dinners and hilly walks helped us both better understand the people we’d been talking with and how our own work interacts with the new technologies being built around us. It was interesting to hear his perspective on the conference from the POV of a design strategist (<a href="https://littlebearlabs.io/perspectives/the-why-behind-the-what-going-beyond-the-tech-at-ipfs-camp">you can read his reflections here</a>) versus my experience as an engineer.&nbsp;I hope the future holds more opportunities for in-person meetups with clients and fellow coworkers. There’s something special about the thinking and ideas that come from these spontaneous conversations, which can be lost in our more focused and discrete virtual meetings. As I’m immersed in my work with PL now, the connections I made with the team in Lisbon have made the work even more interesting and meaningful.&nbsp;

The value of real-life connections: LabWeek2022

The vast majority of my design career has run parallel to technology, from the early web to robots to satellites. But it’s been a while since I’ve gotten my hands dirty; I don’t recall the last time I wrote a line of code. So I wasn’t sure what I would experience at a conference centered around the InterPlanetary File System (IPFS). What I did know was that our team’s been doing some pretty interesting stuff with Protocol Labs, so IPFS Camp (Part of Protocol’s LabWeek2022) conference was sure to be thought-provoking, at the very least.<figure class="image image_resized" style="width:50%;"><img src="https://storage.googleapis.com/little-bear-labs-media/jared_blog_post_inline_image_8f42c1ea1a/jared_blog_post_inline_image_8f42c1ea1a.jpg" alt="jared blog post inline image.jpg"></figure>Emerging into the Lisbon airport, I found myself surrounded with banners for Filecoin, an IPFS-based cooperative digital storage and retrieval system. I had no idea what these banners might mean to others attendees, but for me they seemed to promise something grand… and perhaps a bit hard to wrap my head around.&nbsp;I met up with my colleague Ryan, tech lead at Little Bear Labs, at the event space (Convento do Beato, a beautiful former convent). After a quick COVID test, made my way to the main stage. All around me were excited conversations about blockchain consensus mechanisms and the relationship between IPFS and IPLD... not at all my areas of expertise, so I was feeling a bit out of place. Thankfully, that changed quickly.After a brief welcome, the first speakers took to the stage to discuss decentralization and human rights, and I was immediately riveted.<ul><li>Jonathan Dotan talked about Starling Lab and the vital role of decentralization and data immutability in the fight against misinformation and our ability to capture, verify, and preserve history.&nbsp; &nbsp;</li><li>Next up, Phoebe Poon talked about the future of decentralized publishing, specifically how it supports pro-democracy media in Hong Kong.&nbsp; &nbsp;</li><li>Finally, Xavi Vives shared his experience of working against censorship in Catalonia, spending two years building a censorship-resistant voting system in absolute secrecy.&nbsp;</li></ul>All of this, in the first 15 minutes of the conference. It dawned on me what a non-developer like me would find here: the&nbsp;why behind all the emerging tech people were chattering about.Over the next few days, I learned about an array of projects enabling new horizons in human rights, art, games, and language learning. As someone that only speaks one language (despite my valiant DuoLingo attempts), I was particularly interested in the listening-based language learning project OmniLingo (built on top of Mozilla’s Common Voice).&nbsp;Of course, most sessions were deeply technical presentations that made a lot more sense to an engineer like Ryan (be sure to <a href="https://littlebearlabs.io/perspectives/the-value-of-real-life-connections-labweek2022">check out his reflections on the conference too</a>), although I did get to hear&nbsp;<a href="https://ranger.mauve.moe/">Mauve Signweaver</a> actually explain the relationship between IPFS and IPLD. But IPFS Camp was ultimately about more than the technology — it was a chance to see how all this stuff is making an actual impact in the world.&nbsp;Sitting in a cafe near Lisbon Cathedral, I scribbled down my notes in an attempt to document the last three info-packed days. IPFS Camp was billed as a gathering for the entire IPFS community, and while I may not have left the conference with a new technical skill, I certainly came away with a new perspective on how I fit into that community. Seeing the big picture of IPFS gave me a deeper appreciation for the work we’re doing with Protocol Labs to build things that don’t yet exist — but will make a profound difference for people’s lives when they’re realized.&nbsp;

The why behind the what: going beyond the tech at IPFS Camp

I grew up with a startup in the basement — my dad’s online consumer goods store. Back in the early dot-com era, the idea of buying stuff from someone you’d never met was a scary innovation for a lot of people. Working for my dad’s company is where I fell in love with software engineering: creating tools to deliver on technology’s promise to make connecting with other people easier.&nbsp;&nbsp;But I didn’t think of myself as an entrepreneur in my own right. I headed into a pretty traditional silicon valley career, with stints at Yahoo! and Mozilla. I learned a lot about my craft as an engineer — but I also learned that the long hours and narrow focus on one company’s products didn’t allow me to do everything that mattered to me.After my second kid was born, I was at a crossroads. I wanted a place where I could do interesting work that was rewarding, not draining. I was in that space where you’re dreaming about something without reality being a factor, so you can actually envision what you want without constraints. My dad had always told me I could do more for my family — and make a bigger impact in the world — by founding my own company, and I decided it was time to figure out how to do it.&nbsp;The vision that came together wasn’t just about what I wanted to build — it was about how I wanted to work with colleagues and clients. Of course, I needed a name to start building a business. The name I originally wanted was copyrighted by someone else, so I had to think of something new. That’s not a very cool story. But what is cool is that it led me to land on something that truly reflects what the company is now: a constellation of experts coming together to create something bigger, better, brighter.&nbsp;Little Bear Labs has evolved a lot over the years, and three core principles have remained beacons from the start.&nbsp;<h2>1. Interesting work with awesome people</h2>At the outset, I was doing what most entrepreneurs do at first — taking on everything myself and putting in 80-hour weeks. That’s not sustainable, so when it was time to scale up Little Bear Labs, I focused on two things: the kinds of projects I wanted to work on and the people I wanted to work with.&nbsp;Every person you bring into your vision brings a unique set of skills. It’s a super fun challenge to figure out how to best apply them so everyone benefits: the individual, the business, and our clients. As we’ve grown, we’ve added more and more breadth of expertise. And that’s affected the flavor of our work, allowing us to take on a wider range of projects more aligned with our vision.The people who’ve joined Little Bear Labs want to work on something meaningful and challenging — and those are the kinds of projects I pursue. I love giving people opportunities like that, and it’s important to me personally as well. After all, I’m an engineer, so I like to build. As a team, we’re not just looking at the future — we’re building it together.&nbsp;<h2>2. Remote collaboration</h2>Little Bear Labs was a fully remote company from the start. It was a matter of wanting to get more done. I used to commute for three hours a day; working at home gave me back that time. And creative developers are happier and produce better when they have freedom to balance the need for extreme collaboration and extreme focus. So a remote team isn’t just about work-life balance (although that’s important, too) — it’s genuinely a competitive advantage.&nbsp;The whole industry has moved in this direction now, so it’s interesting to reflect on how big a deal it used to be. Just a few years back, we’d get hundreds of applications for a remote job posting, because that kind of opportunity was hard to find. Who knows, maybe my passion for improving real-time applications began when I recognized that remote collaboration is just a better way to work.&nbsp;<h2>3. Open source development</h2>Coming out of Mozilla, open source was baked into my identity. I saw first hand how important it was to collaborate with peers in other companies to build something excellent. And I see it in the work we do with clients every day at Little Bear Labs.&nbsp;You don’t have to be a bleeding-heart open source devotee to recognize that the collective expertise of developers from all over the world lets us all do exponentially more. A lot of the satisfaction of engineering for everyone at Little Bear Labs is getting better at our craft and seeing how much cool stuff we can do. That means making contributions to the industry as a whole, not just a single company.&nbsp;<h2>Evolving a better way of working</h2>It’s funny to start something with an intention and then look back five years later to see how much has actually come true. People who genuinely enjoy working with each other, interesting and meaningful projects, delivering excellence for our clients, seeing how far we can reach, and going even beyond what we thought was possible.&nbsp;And even as we grow, I’m not very interested in bigger at all costs. I’m interested in better at all times. Working the way we do is just inherently rewarding, personally and professionally. Like chosen family, you get to pick who you want to be part of your universe. For me, building this company is also building community, among my colleagues, our clients, and the wider open source world. And doing that in a way that makes business sense on a practical level — because that’s how we get to take seemingly impossible ideas and make them into reality.

A better way to better work:  3 founding principles for Little Bear Labs

<h2>Discover faster, better SFU testing</h2>Selective Forwarding Units (SFUs) are used heavily in video, audio, and data communications. We use them in many of the popular communications applications as part of our daily routines.&nbsp; When things are going smoothly, we see and hear each other without any interruption. Other times, audio and video can lag, or even stop, leaving a breakdown in communication and general user dissatisfaction.What if it were possible to simulate communication among peers during CI or testing? What if you knew the maximum number of peer connections or the total load a SFU could handle?&nbsp; Suddenly you'd be able to allocate more servers when thresholds are reached and avoid any communication downtime.This is exactly the problem we’re solving with the load test server. It allows you to benchmark your SFU so you know its limits — allowing you to act, not react, to problematic scenarios.The server was built with Chromium WebRTC internals so that every connection is like a real browser/application connection. We included a powerful and easy-to-use gRPC API to make adding peers a breeze. To make the API even easier to interact with, we developed a NodeJS SDK for seamless integration into your continuous integration pipeline.Headless browsers can test SFUs today, but they have limitations, as well as a big footprint. We pulled out the guts of the browser's WebRTC stack to eliminate the large application size and unnecessary running services. Now you can test more connections (over 1,000) per load test server, and save on operating costs in the cloud.We invite you to put the load test server into action and discover what you can do with it. <a href="https://littlebearlabs.io/perspectives/load-testing-with-mediasoup">Check out this article</a> for a step-by-step walkthrough on testing your mediasoup SFU, and dig in to the <a href="https://github.com/arcas-io">repositories on GitHub</a>.

Announcing our open source load test server

Want to find out exactly how much your your SFU can handle? We’ve built an open source load test server that solves the limitations of SFU testing with headless browsers, so you can test over 1,000 connections per load test server. <a href="https://littlebearlabs.io/perspectives/announcing-our-open-source-load-test-server">Take a look at this overview</a> for more details — and if you’re ready to put it to use, read on.Arcas load testing depends on GStreamer version `1.18.X`&nbsp;being installed on your computer. If you do not have GStreamer installed you can use the following links to download:NOTE:&nbsp;At this time only GStreamer versions `1.18.X`&nbsp;are compatible with this demo.<ul><li>Linux</li><li>Please see the GStreamer&nbsp;<a href="https://gstreamer.freedesktop.org/documentation/installing/on-linux.html?gi-language=c">installation guide</a></li></ul>MacOS will need to install both of the following: &nbsp;<ul><li><a href="https://gstreamer.freedesktop.org/data/pkg/osx/1.18.6/gstreamer-1.0-1.18.6-x86_64.pkg">https://gstreamer.freedesktop.org/data/pkg/osx/1.18.6/gstreamer-1.0-1.18.6-x86_64.pkg</a><a href="https://gstreamer.freedesktop.org/data/pkg/osx/1.18.6/gstreamer-1.0-devel-1.18.6-x86_64.pkg">https://gstreamer.freedesktop.org/data/pkg/osx/1.18.6/gstreamer-1.0-devel-1.18.6-x86_64.pkg</a></li><li><a href="https://gstreamer.freedesktop.org/data/pkg/osx/1.18.6/gstreamer-1.0-1.18.6-x86_64.pkg">https://gstreamer.freedesktop.org/data/pkg/osx/1.18.6/gstreamer-1.0-1.18.6-x86_64.pkg</a></li><li><a href="https://gstreamer.freedesktop.org/data/pkg/osx/1.18.6/gstreamer-1.0-devel-1.18.6-x86_64.pkg">https://gstreamer.freedesktop.org/data/pkg/osx/1.18.6/gstreamer-1.0-devel-1.18.6-x86_64.pkg</a></li></ul>After installing both of those packages, please run the following commands in the terminal:<pre><code class="language-plaintext">mkdir -p /usr/local/opt/gst-plugins-base
ln -s /Library/Frameworks/GStreamer.framework/Versions/1.0/lib /usr/local/opt/gst-plugins-base/lib
mkdir -p /usr/local/opt/gstreamer ln -s /Library/Frameworks/GStreamer.framework/Versions/1.0/lib /usr/local/opt/gstreamer/lib</code></pre>To get a mediasoup SFU up and running quickly, let's pull down some skeleton code from&nbsp;https://github.com/arcas-io/arcas-load-test-mediasoup-example.<pre><code class="language-plaintext">git clone -b skeleton https://github.com/arcas-io/arcas-load-test-mediasoup-example.git cd arcas-load-test-mediasoup-example/src</code></pre>Let's start by creating an entry file:<pre><code class="language-plaintext">touch index.js</code></pre>Using your favorite editor, import the SDK and mediasoup signaling code:<pre><code class="language-javascript">import { Session } from "@arcas/sdk";
import { deviceLoaded, createProducerTransport } from "./signaling.js";</code></pre>Now let's define some test defaults:<pre><code class="language-javascript">const LOAD_TEST_COUNT = 100;
const TEST_SOAK_TIME_S = 10;
const SOCKET_URI = "https://127.0.0.1:3000";
const SERVERS = ["[::1]:50051"];</code></pre>The `LOAD_TEST_COUNT`&nbsp;is the number of producers we want to create that will send video to the mediasoup SFU. The `TEST_SOAK_TIME_S`&nbsp;is the number of seconds to keep the test running. The `SOCKET_URI`&nbsp;value is set in the `server/package.json`&nbsp;file in the `start`&nbsp;script. The `SERVERS`&nbsp;value is set in the `package.json`&nbsp;file in the `server`&nbsp;script. In future posts, I'll show you how to scale the Arcas Load Test servers to increase the load test capacity.In this test, we're configuring it to create 100 producers (peer connections) that will produce video in the Arcas Load Test server for a total of 10 seconds. Feel free to modify to test how much load the SFU can accommodate.Using the `Session`&nbsp;class in the SDK, create the session:<pre><code class="language-javascript">const session = await Session.create({
	name: "First Session",
	servers: SERVERS,
	protoPath: "/proto/webrtc.proto",
	logLevel: "NONE",
	pollingStateS: 1,
});</code></pre>We're giving the session a name: `First Session`. This will come in handy in later posts about using the Arcas Portal. The other important session variable is `pollingStateS`. This tells the Arcas Load Test server to poll the internals for stats every `1`&nbsp;second. You may want to increase this if scaling the Arcas Load Test servers.We can now start the session to let the server know we're ready to start sending some load:<pre><code class="language-javascript">await session.start();</code></pre>The next step is to wait for the device to load before engaging the producers. The remaining code creates `LOAD_TEST_COUNT` producer transports and holds the test for `TEST_SOAK_TIME_S` seconds.<pre><code class="language-javascript">await deviceLoaded(SOCKET_URI, async (device) =&gt; {
	const TEST_INTERVAL_S = 1;
	let TEST_COUNTER_S = 0;
	
	// create LOAD_TEST_COUNT producer transports
	for (let i = 0; i &lt; LOAD_TEST_COUNT; i++) {
	await createProducerTransport(device);
}

const interval = setInterval(async () =&gt; {
	TEST_COUNTER_S += TEST_INTERVAL_S;
	
	const stats = await session.getStats();
	const num_sending = stats.session.peer_connection_state.num_sending;
	const elapsed_time = stats.session.elapsed_time;
	console.log(
		`num_sending: ${num_sending}, elapsed_time: ${elapsed_time} seconds`
	);
		
	if (TEST_COUNTER_S &gt;= TEST_SOAK_TIME_S) {
		clearInterval(interval);
		await session.stop();
		process.exit();
		}
	}, TEST_INTERVAL_S * 1000);
});</code></pre>That's all the code you'll need to write for this test.The next step is to install and start the mediasoup SFU. Before we install the server, ensure that you meet the requirements:<ul><li><a href="https://mediasoup.org/documentation/v3/mediasoup/installation/#requirements">https://mediasoup.org/documentation/v3/mediasoup/installation/#requirements</a></li></ul>To install the server:<pre><code class="language-plaintext">cd server &amp;&amp; yarn</code></pre>The installation may take several minutes downloading and compiling the mediasoup source code.Once that's done, start the mediasoup SFU:<pre><code class="language-plaintext">yarn start</code></pre>You should see the output:<pre><code class="language-plaintext">&gt; mediasoup-server@0.1.2 start /arcas-load-test-mediasoup-example/server
&gt; PORT=3000 WS_HOST=127.0.0.1 SERVER_HOST=0.0.0.0 node index.js

server is running on 127.0.0.1:3000/ws
creating mediasoup worker
mediasoup router created in worker</code></pre>In a separate terminal window in the `/arcas-load-test-mediasoup-example` directory, start the Arcas Load Test server:<pre><code class="language-plaintext">yarn &amp;&amp; yarn server</code></pre>Note:&nbsp;If this produces an error loading gst-plugins-base, make sure your GStreamer version is 1.18.x and that you have followed the installation instructions above.With both the mediasoup SFU and the Arcas Load Test server running, we can now start the test. In a separate terminal window in the `/arcas-load-test-mediasoup-example`&nbsp;directory, kick off the test:<pre><code class="language-plaintext">yarn start</code></pre>You should see the test output:<pre><code class="language-plaintext">num_sending: 100, elapsed_time: 1
num_sending: 100, elapsed_time: 2
num_sending: 100, elapsed_time: 3
num_sending: 100, elapsed_time: 4
num_sending: 100, elapsed_time: 5
num_sending: 100, elapsed_time: 6
num_sending: 100, elapsed_time: 7
num_sending: 100, elapsed_time: 8
num_sending: 100, elapsed_time: 9
num_sending: 100, elapsed_time: 10
✨ Done in 10.96s.</code></pre>Note: The first `num_sending`&nbsp;may be less than 100 as the service ramps up.You can now stop the mediasoup SFU and the Arcas Load Test server if you don't plan to run further tests.That was easy, right? We wrote some code to engage signaling of the mediasoup SFU and started and created a session in the Arcas Load Test server. We then created producer peer connections that actually send video streams on the Arcas Load Test server.In future posts, I'll detail how to monitor the SFU during the test. Until then, happy testing!

Announcing our open source load test server

Discover faster, better SFU testing

A better way to better work: 3 founding principles for Little Bear Labs

Load Testing with mediasoup