Bulldozer Report (04/26/2022)
Tags: web3, solana, opensource, blockchain
Published: 2022-04-26 13:34:38

This is our first post here in dev.to as an organization, make sure to give us some love!

## TLDR;

- We are releasing a [new version of Bulldozer](https://bulldozer.heavyduty.builders/).
- It comes with a new UI that matches our brand.
- We're exploring web2 tech for better Dapp UX.
- It introduces collaborators and real-time updates for all clients.
- We added workspace treasury to pay for the rent of all accounts inside a workspace.
- We're working on a GitHub integration that enables Bounties.
- Bulldozer CLI and API are on the way to boosting local development.

Looking for a thread-like post instead? We got you fam.

{% embed https://twitter.com/HeavyDutyBuild/status/1518704121896787974 %}


## Intro

If you've been following our moves, you know what's up with Bulldozer, but let's make a quick stop to remind us about it. 

> Bulldozer is a low code platform to build Solana programs powered by Anchor. Our goal is to make it possible for "no-code" contracts to actually land. While making the experience fun and almost game-ish, with a bit of real-time collaboration to make things :fire:.

Back in 2021, we won 2nd place for Solana's IGNITION Hackathon and since then, we quit our 9-5 and went nose-diving into web3.

Our initial version was basically a prototype, which we have been constantly tweaking and improving, looking for a specific UX. 

Take a look at our latest promotional video and make sure to like it!

{% embed https://www.youtube.com/watch?v=vK8nYC1ilNc&t=2s %}

## Real-time collaboration

For us, real-time collaboration is a huge thing. We started using the RPC's socket events which in localhost worked fine, but we kept hearing from more seasoned Solana developers to not trust those events. 

Guess what? As soon as we started testing in devnet, all kinds of weird shit started to pop up. Some events were not coming through, we didn't know why, so we decided to take a step back and follow what Jordan told us in Prague's HH. 

> Dude you should go web2 on it.

This was hands down the best thing we could've done, we didn't go full-on web2 tho, we just created what we called the **Broadcaster**, a topic-based WebSocket Server that enables clients to propagate their transactions to other clients.

![real-time updates of two clients using bulldozer](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/8alscqriwqb10hxqttwm.gif)

It works like a charm, but when we were talking to Jordan back then he said: 

> How would you show each "collaborator" cursor in real-time?

You can imagine our faces after hearing that. 5 minutes before we weren't even considering showing the cursors in real-time. Even though we felt the **Broadcaster** was a valid solution, since then we knew that we'll need more power to get to a Figma-level of collaboration.

The **Broadcaster** kept clients synchronized. But we had an issue, you could only interact with your own workspaces. This brings up the next new feature.

## Collaborators

We know that building software is all about joining forces with other builders. Being able to collaborate with others makes the job easier and more enjoyable. This is how Bulldozer does it:

- Workspace owners can add builders as collaborators.
- Workspace owners can approve and reject collaborators.
- Builders can request the **collaborator status**.

![a list of collaborators in bulldozer](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/1q0fmpzmecsckkvlyary.png)

For now, there's generic workspace-wide write permission. Our goal for a future release is to have fine-grained permissions and roles, enabling more intricate and complex development processes.

This leads us to a new concern. If there are multiple collaborators working together and each of them pays rent for the accounts they create, we have to either:

- Prevent collaborators from closing accounts and getting back their rent.
- or; Allow collaborators to close accounts that could potentially break a workspace.

Since both options sucked so bad, we went back to the whiteboard to discuss a better alternative. 

## Workspace Budget

> What if there was a way for the workspace to pay for the rent? 

Follow us here, each workspace has a "budget" at a PDA, anyone can donate to a workspace's budget and we'll later use that budget to pay for rent. On paper it sounded really nice, it turns out it wasn't that straightforward to implement, at the moment Anchor doesn't support PDA payers. 

Our current solution is basically hammer-fisted:

- The collaborator pays for the rent.
- Budget charges back collaborator for expenses.
- The workspace owner can withdraw from the budget.
- Closed accounts rent goes back to the budget.

![workspace budget](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/f58fhmvz0qt9ecqfp4qg.png)

We know we have a solid solution here, but can you imagine paying the rent with any token that you want? We do. Right now we're limited to using only SOL for the rent, but we're thinking of something more versatile. Something that allows the workspace budget to accept multiple tokens while Bulldozer makes a user-transparent swap transaction at the moment of paying rent. 

## What's next?

If you know us, you already know it, we are just getting started. Right now we're cooking some really good shit. Our website is getting re-done, we just started sending a newsletter, and we're already working on a new set of features.

### Github Integration

In order to decentralize the way software development works, we need to have a good incentives program. This could potentially lead a huge number of developers to transition toward a new way of working.

That's why our current focus is to set up a bounty program that's baked into Bulldozer, but at the same time has a high level of compatibility with GitHub. This way our bounty program will be available not just for Bulldozer but for other projects.

> The GitHub Integration is halfway there, we have a potential name for it already: "Drill".

### Bulldozer CLI

Bulldozer right now has a major ergonomy issue when it comes to local development, every time you change something on your program, you have to re-download and manually replace the things that changed.

Our focus with Bulldozer CLI is to give builders the basic tools they need for an improved local development experience:

- Build a workspace
- Deploy a workspace

### Bulldozer API

When we started with Bulldozer we had decentralization as a top priority, as time passes we realized that some parts can be centralized in-order to boost UX. In the current state, Bulldozer generates the workspace files on the client without an external API. 

While this works, we can't "build" the workspace. Clients have to download, manually compile, and only then they can deploy. We want to change this by introducing an API that returns:

- Source files for a workspace
- Compiled output for a workspace

NOTE: All these API functionalities are coming from the CLI but we need an interface that we can interact with through the web client.

Don't take our word for it, check it out yourself! It's OSS.

{% embed https://github.com/heavy-duty/platform %}

If you get this far, join our Discord. There's so much more where this came from.
{% embed https://discord.gg/bKma7wSzUd %}

[Follow us on Twitter](https://twitter.com/HeavyDutyBuild) to stay up to date.