It has been some days since I last touched my compositor codebase, so we’ll start by checking out how Make works to make it easy for us to be building the project. If you’re a C expert already and you’re comfortable with Meson or other tool, feel free to use it instead. I’m using Make because it’s the easiest for beginners (like me).

Also, we’ll be using the clang compiler for this project. GCC should work just fine, yet I’ve heard clang has better error messages.

Setting up The Project

Make files are shell scripts with rainbows and unicorns. Compiling a C project usually includes a lot of chaining commands, which we’ll use Make to do. Make sure to have clang, make, and pkg-config installed in your system. You’ll also need wayland-server and wlroots-0.19. Note that in Ubuntu at least, wlroots is distributed as wlroots-0.19 and not as wlroots.

To begin with, create your project directory and put these things in it:

src/
    main.c
.gitignore
Makefile

In our main.c file, let’s put a basic main() to run our code.

int main(void) {
    return 0;
}

Then in our Makefile, let’s write this (indented with tabs, spaces won’t work):

# Variable for all the Clang flags we'll be using. It enables warnings, makes warnings fail to
# compile, enables wlroots unstable features (wlroots has lots of things marked unstable), and
# enables AddressSanitizer to help us catch memory bugs.
CFLAGS = -o build/compositor --std c23 -Wall -Wextra -Wpedantic -Werror -DWLR_USE_UNSTABLE \
	-Iwayland -g -O0 -fsanitize=address -fno-omit-frame-pointer

# Our build script, we just make an out dir and compile our main.c file.
build:
	mkdir -p build
	clang src/main.c $(CFLAGS)

# This tells Make that `build` is a command and not a file we want to output.
.PHONY: build

If you run make or make build in your terminal, it should output a binary you can execute at build/compositor.

Now that that’s done, time to start building our compositor!

Our First Compositor

Every wayland and wlroots compositor has a wl_display ruling it all. It handles the event loop and incoming connections. Let’s create one!

#include <assert.h>
#include <wayland-server-core.h>

int main(void) {
    struct wl_display *wl_display = wl_display_create();
    assert(wl_display);

    return 0;
}

That piece of code doesn’t compile just yet. That’s because we didn’t specify any dependencies in our Makefile. Let’s update it.

DEPENDENCIES = wayland-server wlroots-0.19
DEP_SRC_FLAGS = $(shell pkg-config --cflags $(DEPENDENCIES))
DEP_LIB_FLAGS = $(shell pkg-config --libs $(DEPENDENCIES))

FLAGS = $(CFLAGS) $(DEP_SRC_FLAGS) $(DEP_LIB_FLAGS)

# Our build script, we just make an out dir and compile our main.c file.
build:
	mkdir -p build
	clang src/main.c $(FLAGS)

We use pkg-config to get the compiler flags needed to compile using our dependencies. Unlike other programming languages like Rust or Python, we don’t get a nice manifest with dependencies in there, rather point the compiler to where those dependencies are in our system. pkg-config lets us do that dynamically instead of hardcoding values.

Back to our display, we’re not accepting any incoming connections yet, though, so let’s start it. Wayland connections come in through a socket, usually at /run/user/1000/wayland-0 (replace 1000 with your Linux UID). I’m on GNOME shell, which means I’m already running a Wayland compositor, so I’ll customize my socket’s name to way-nyeki.

const int socket = wl_display_add_socket(wl_display, "way-nyeki");
if (socket != 0)
    return 1;

Now yes, time to start our compositor.

#define _POSIX_C_SOURCE 200112L  // setenv() is POSIX-only, we enable it with this flag
#include <stdlib.h>
// -- snip --

int main(void) {
    // -- snip --
    
    // This env var lets clients know what socket to use to connect to the wayland compositor.
    setenv("WAYLAND_DISPLAY", "way-nyeki", true);
    wl_display_run(wl_display);
    
    // Once the compositor is done running, disconnect everyone cleanly.
    wl_display_destroy_clients(wl_display);
    wl_display_destroy(wl_display);
}

FINALLY. We got a compositor that runs, let’s run it! make build in your terminal will yield your new compositor under build. Paste build/compositor to run it, and…

It does nothing. But hey, it doesn’t crash!

Rendering Something

Compositors are useless without rendering something, so let’s get to rendering such something.

Wlroots has a wlr_backend type which handles outputs and inputs. It supports 4 different backends: DRM (directly to your screen), libinput (we won’t be touching inputs yet), wayland (rendering our wayland compositor inside another wayland compositor, as a window), and x11 (same as the wayland one but for x11).

Wlroots can automatically choose the backend we’ll need, so we’ll just do that. It requires a reference to the event loop, so we’ll also grab it from our wl_display.

// -- snip --
#include <wlr/backend.h>

int main(void) {
    // -- snip --
    assert(wl_display);
    
    struct wl_event_loop *wl_event_loop = wl_display_get_event_loop(wl_display);
    assert(wl_event_loop);
    
    // The NULL is a pointer to extra options. We don't need to pass any.
    struct wlr_backend *wlr_backend = wlr_backend_autocreate(wl_event_loop, NULL);
    assert(wlr_backend);

    assert(wlr_backend_start(wlr_backend));

    // -- snip --
}

Now, before we keep going like this, our compositor state is growing big, so let’s make a type to hold it all.

struct nye_server {
    // Wayland stuff
    struct wl_display *wl_display;
    struct wl_event_loop *wl_event_loop;

    // Wlroots stuff
    struct wlr_backend *wlr_backend;
};

int main(void) {
    struct nye_server nye_server = {0};

    nye_server.wl_display = wl_display_create();
    assert(nye_server.wl_display);

    nye_server.wl_event_loop = wl_display_get_event_loop(nye_server.wl_display);
    assert(nye_server.wl_event_loop);
    
    // The NULL is a pointer to extra options. We don't need to pass any.
    nye_server.wlr_backend = wlr_backend_autocreate(nye_server.wl_event_loop, NULL);
    assert(nye_server.wlr_backend);

    // -- snip --
}

Also update all references to those variables. Great.

Tracking Outputs

Now, before we can render something, there’s a topic I have to introduce: Outputs. In your normal compositor-to-your-screen setup where the compositor is the one you’re actually using (and not a nested one like we currently have), each output usually corresponds to a monitor. Since at the moment we’re running out compositor nested inside another compositor, each output will correspond to a window our compositor has within the wayland compositor.

Our backend will fire an event for us to listen to when an output is created, and another one when that output is destroyed (window closed, monitor unplugged). Wlroots keeps some track of this internally, yet we’ll also keep a reference to those output handles plus some state of ours to store extra state for our compositor.

The wayland library uses linked lists to store stuff, so we’ll use those too. wl_list is the type used for nodes within them. Let’s create one for our outputs, and also a wrapper output type.

struct nye_server {
    // -- snip --

    // Our stuff
    struct wl_list nye_outputs;
};

struct nye_output {
    struct wl_list link;  // nye_server::nye_outputs

    struct nye_server *nye_server;  // Easy access to our compositor state.
    struct wlr_output *wlr_output;
};

Now, let’s initialize our linked list.

int main(void) {
    // -- snip --
    assert(nye_server.wlr_backend);

    wl_list_init(&nye_server.nye_outputs);
    // -- snip --
}

Great! That’s an empty list, though. We need to add our outputs when they appear, so let’s add an event listener for it.

Event listeners in wayland are wrapped in wl_listner types. We’ll call ours on_{resource}_{action} (unless there’s no {action}) to make it clear which does what.

// -- snip --
#include <stdio.h>

struct nye_server {
    // -- snip --
    
    struct wl_listener on_output_add;
};

static void on_output_add(struct wl_listener *, void *) {
    printf("New output!\n");
}

int main(void) {
    // -- snip --

    wl_list_init(&nye_server.nye_outputs);
    // Set the wl_listener's callback to our new function.
    nye_server.on_output_add.notify = on_output_add;
    // Hook our new listener to the backend's new_output event.
    wl_signal_add(&nye_server.wlr_backend->events.new_output, &nye_server.on_output_add);

    // -- snip --
}

Try running the compositor with make build && build/compositor. You’ll now see the following gets printed to the terminal:

New output!

That new output represents our wayland window just created.

Now, the window is there but not rendering anything yet. It’s very possible that in a compositor like Hyprland you don’t have a way of seeing it. In GNOME shell, nothing pops up on the screen, but the application bar shows an extra empty VS Code window.

Now, back to our on_output_add function, we need to store new outputs in our nye_server::nye_outputs list. We’ll first get a reference to our nye_server through the wl_listener reference our callback gets and cast the void * to the original wlr_output type.

static void on_output_add(struct wl_listener *wl_listener, void *data) {
    struct nye_server *nye_server = wl_container_of(wl_listener, nye_server, on_output_add);
    struct wlr_output *wlr_output = data;
}

Ok but wait a sec, what’s wl_container_of doing here? Black magic, plain and simple. It’s said that it uses some forgotten spells to get back arg2 from arg1 via arg2::arg3’s offset in memory.

Anyway, now we have our wlroots output and our server, we can create our nye_output wrapper and store it in our nye_server.

static void on_output_add(struct wl_listener *wl_listener, void *data) {
    // -- snip --

    // It's gonna outlive the function's call, so it goes to the heap.
    struct nye_output *nye_output = calloc(1, sizeof(struct nye_output));
    nye_output->nye_server = nye_server;
    nye_output->wlr_output = wlr_output;
    // Connect em `wl_list`s.
    wl_list_insert(&nye_server->nye_outputs, &nye_output->link);
}

Great! Now we have them tracked.

Output Modes

As we said before, wayland outputs are usually monitors. Such monitors have properties like refresh rate, height and width, and other properties. Before we can use our outputs for apps, we need to do two things:

1. To set the output’s mode (outputs can have many supported ones or none)
2. To create the wl_output global for apps to use those monitors.

Wlroots makes this dead simple, starting with setting the mode:

static void on_output_add(struct wl_listener *wl_listener, void *data) {
    // -- snip --
    wl_signal_add(&nye_server.wlr_backend->events.new_output, &nye_server.on_output_add);
    
    struct wlr_output_state wlr_output_state;
    wlr_output_state_init(&wlr_output_state);
    wlr_output_state_set_enabled(&wlr_output_state, true);

    // Nested wayland outputs don't have modes. We commit an empty state if that's the case.
    if (!wl_list_empty(&wlr_output->modes))
    {
        // Outputs can have many supported modes, we pick the preferred one (biggest, fastest).
        struct wlr_output_mode *wlr_output_mode = wlr_output_preferred_mode(wlr_output);
        wlr_output_state_set_mode(&wlr_output_state, wlr_output_mode);
    }

    wlr_output_commit_state(wlr_output, &wlr_output_state);
    wlr_output_state_finish(&wlr_output_state);

    struct nye_output *nye_output = calloc(1, sizeof(struct nye_output));
    // -- snip --
}

And at the end of our handler function, we add this line to create the global:

wlr_output_create_global(wlr_output, nye_server->wl_display);

Great! This is a bit of code that won’t produce any visible changes, but it’s the foundation for our rendering in a minute.

Last but not least, our code currently leaks memory. We store outputs when they’re created, but we don’t free that memory when an output is destroyed. Let’s create a listener that takes care of that.

struct nye_output {
    // -- snip --
    struct wl_listener on_output_del;
};

static void on_output_del(struct wl_listener *wl_listener, void *) {
    // More memory dark magic.
    struct nye_output *nye_output = wl_container_of(wl_listener, nye_output, on_output_del);

    // Remove the output from the linked list and unlink our handler.
    wl_list_remove(&nye_output->link);
    wl_list_remove(&nye_output->on_output_del.link);

    free(nye_output);
}

static void on_output_add(struct wl_listener *wl_listener, void *data) {
    // -- snip --
    nye_output->wlr_output = wlr_output;

    nye_output->on_output_del.notify = on_output_del;
    wl_signal_add(&wlr_output->events.destroy, &nye_output->on_output_del);

    wl_list_insert(&nye_server->nye_outputs, &nye_output->link);
    // -- snip --
}

Rendering Something (Now Yes)

Unfortunately, to render apps we still have some chunk (we need to implement XDG and I haven’t yet learned to do that). BUT, don’t leave me yet, we’ll make our window render some colors to see if we’ve done everything correctly up to now.

In an unhappy world, we’d need to do OpenGL/Vulkan rendering by hand. Since this is a world that’s bright and full of love, though, wlroots gives us a nice API that handles all of the ugly part without us having to touch it.

Wlroots’s Scene API allows us to create a tree of nodes, which can be surfaces or rects, to draw on a screen without handling all the raw graphics ourselves. We create a wlr_scene for our whole compositor, then one or more wlr_scene_tree to place our drawables in. For example, we could have a tree per monitor, or a tree per workspace, or even both combined.

We’ll keep it simple and go for a single tree (the one that comes by default with wlr_scene) for everything to begin with. Let’s create a new scene and store it in our server state.

// -- snip --
#include <wlr/types/wlr_scene.h>

struct nye_server {
    // -- snip --
    struct wlr_scene *wlr_scene;
    // -- snip --
};

int main(void) {
    // -- snip --
    assert(nye_server.wlr_backend);

    nye_server.wlr_scene = wlr_scene_create();
    assert(nye_server.wlr_scene);
    // -- snip --
}

Outputs need to be made available for our scene, so lets create the wrapping wlr_scene_output and store it in our nye_output. We’ll also destroy it when the output is deleted.

struct nye_output {
    // -- snip --
    struct wlr_scene_output *wlr_scene_output;
    // -- snip --
};

static void on_output_del(struct wl_listener *wl_listener, void *) {
    // -- snip --
    wl_list_remove(&nye_output->on_output_del.link);

    wlr_scene_output_destroy(nye_output->wlr_scene_output);

    free(nye_output);
}

static void on_output_add(struct wl_listener *wl_listener, void *data) {
    // -- snip --
    nye_output->wlr_output = wlr_output;

    nye_output->wlr_scene_output = wlr_scene_output_create(nye_server->wlr_scene, wlr_output);
    // -- snip --
}

Great! Now, we still haven’t made our scene render, so let’s get to that.

If we were handling rendering by hand, we’d need to handle synchronization, buffer rotation, and many ugly parts of it. However, wlroots makes our life full of happiness and rainbows by giving us an on_frame event callback we can use to render without worrying about all that.

struct nye_output {
    // -- snip --
    struct wl_listener on_frame;
    // -- snip --
};

static void on_frame(struct wl_listener *, void *) {}

static void on_output_del(struct wl_listener *wl_listener, void *) {
    // -- snip --
    wl_list_remove(&nye_output->link);

    wl_list_remove(&nye_output->on_frame.link);
    
    wl_list_remove(&nye_output->on_output_del.link);
    // -- snip --
}

static void on_output_add(struct wl_listener *wl_listener, void *data) {
    // -- snip --
    nye_output->on_frame.notify = on_frame;
    wl_signal_add(&wlr_output->events.frame, &nye_output->on_frame);

    nye_output->on_output_del.notify = on_output_del;
    // -- snip --
}

Now yes, once an output is created, on_frame() will start getting called every time we have to draw.

NOW YES! Time for the part where we actually get something drawn on our screens. Our on_frame just needs to call wlr_scene_output_commit() and send done callbacks to clients when the frame is done being rendered.

static void on_frame(struct wl_listener *wl_listener, void *) {
    // More black magic!
    struct nye_output *nye_output = wl_container_of(wl_listener, nye_output, on_frame);
    
    // Draw everything our scene output has pending to the actual output.
    wlr_scene_output_commit(nye_output->wlr_scene_output, NULL);

    // Once our frame is drawn, we let our clients know so that they can start drawing their next
    // frame.
    struct timespec now;
    clock_gettime(CLOCK_MONOTONIC, &now);
    wlr_scene_output_send_frame_done(nye_output->wlr_scene_output, &now);
}

Okay, finally, our time has come. Compile, run, and…

New output!
compositor: types/output/swapchain.c:15: create_swapchain: Assertion `output->allocator != NULL' failed.
Aborted                    build/compositor

No please don’t leave yet I’m begging. Happens to be that rendering in wlroots requires a renderer and an allocator. They’re easy to create, yet we didn’t so this failed. Let’s create them quickly.

// -- snip --
#include <wlr/render/allocator.h>
#include <wlr/render/wlr_renderer.h>

struct nye_server {
    // -- snip --
    struct wlr_renderer *wlr_renderer;
    struct wlr_allocator *wlr_allocator;
    // -- snip --
};

static void on_output_add(struct wl_listener *wl_listener, void *data) {
    // -- snip --
    wlr_output_state_set_enabled(&wlr_output_state, true);

    wlr_output_init_render(wlr_output, nye_server->wlr_allocator, nye_server->wlr_renderer);
    // -- snip --
}

int main(void) {
    // -- snip --
    assert(nye_server.wlr_scene);

    nye_server.wlr_renderer = wlr_renderer_autocreate(nye_server.wlr_backend);
    assert(nye_server.wlr_renderer);
    nye_server.wlr_allocator = wlr_allocator_autocreate(nye_server.wlr_backend, nye_server.wlr_renderer);
    assert(nye_server.wlr_allocator);

    // -- snip --
}

NOW YES! I PROMISE THIS TIME IT’LL WORK. Compile, run, and…

IT WORKS! A black screen gets displayed in your screen. Apps can’t render anything yet, but we went from an invisible window to something shown in our screens, great step!

I said we’d render some colors in our screen, so let’s get to that.

Rendering Colors

We’ll render a red square to test whether our rendering is actually working. This will be a rect in our scene which we’ll create after creating the scene object, in our main().

int main(void) {
    // -- snip --
    assert(nye_server.wlr_allocator);

    float color[4] = {1.0, 0.0, 0.0, 1.0};  // RGBA
    struct wlr_scene_rect* wlr_scene_rect = wlr_scene_rect_create(
        &nye_server.wlr_scene->tree,
        100,
        100,
        color
    );
    wlr_scene_node_set_position(&wlr_scene_rect->node, 0, 0);
    // -- snip --
}

When you re-compile and re-run the compositor, you’ll see that a 100x100 red sequare is now shown in the compositor’s window.

Exitting the Compositor

You may have noticed that when you close the compositor’s window instead of Ctrl + C-ing the program, the program will keep running. This is because the compositor doesn’t depend on a window to be running. To exit the compositor, use Ctrl + C in your terminal.

That’s it for now! The next part of this series will cover how to get apps to draw windows in our compositor. That’ll require to implement XDG, which I haven’t investigated in depth yet.

If you have found any bugs in the code I showed, or have any suggestions, feel free to open an issue in GitHub. Good luck!

I also made the Product Hunt launch draft for Duckity for tomorrow (actually today, it’s 12:31 AM) and attempted at doing the same with TinyLaunch but their site was broken. I’ll wake up early tomorrow to post it in Hacker News and upload it to all the other sites in the list that I did not put Duckity in today. I also started writing about it in my new /dev/null account.

Something I notice is that in my head there’s this worry of this not being a strong enough problem, but every now and then I see someone complain about it. E.g. today. Reading a Paul Graham blog post on how to start a startup I learned, more like re-realized, that Duckity may be too complex. That’s why the next code thing I’ll be working on will be adding a few templates to get started with instead of making people configure things from scratch.

I have a little amount of worries about things, but none is going to stop me from launching as many times as I need to launch, each time improving from the past time.

There’s not that much to write in my head today, only that I really hope I get that YC interview but that I’ll be working like there’s no YC in the meantime. My plan for the next few days:

• Launch on Product Hunt
• Launch on Hacker News
• Figure out TinyLaunch
• Keep posting about it on /dev/null
• Grab that Hacker News list of sites to post your product in and make noise
• Launch again this Friday, since Product Hunt is making it a day where you can relaunch many times

Also, I was feeling this anxiety I could not tell what was. I was feeling like I was less because I saw all those guys (Garry Tan and friends) being so successful and having done so much and doing so well and knowing so much and that demotivated me, but I realized that them having that knowledge and experience doesn’t mean I can’t have it too. Anxiety vanished.

I’m also thinking of more and more things to scale Duckity. These will include:

• Global scaling, since now Duckity is a regional cluster thing,
• Adding teams for organizations to manage apps,
• Adding easy benchmarking for developers to know what speeds VDFs will solve at in each device,
• SELF-HOSTING!
• React Native SDKs,
• A bunch of templates to pick from,
• A default basic policy when creating apps

They’re not listed in order of importance. Also, the Duckity pro pricing is listed at $49/mo yet I’m worried that’s too high for a developer tool, so I gave the Product Hunt launch an 80% discount code for the first 100 users (holy discount innit) for the first 6 months.

I’m looking forward to making everything go great! First launch of as many as needed. Good luck with whatever you’re building!

I had a user tell me that they would not test Duckity because they didn’t know whether it worked. The two problems I had addressing this properly were simple:

1. I thought I had little way to prove credibility since I had little security background,
2. In Payphone (past successful project of mine), I knew users were onto something when more than one of them brought up the same issue. This was only one guy, so I was quicker to filter it out.

I’m still on time to fix it, yet I’m also going to have to be asleep soon since tomorrow I have to wake up early to launch Duckity on Hacker News and review Product Hunt comments.

About the problem more in detail, the landing page has a section that speaks about how it works, but it does little to dive into any more details. Move that to the very top of my priority things to work on, it’s getting tackled tomorrow first thing.

Zero. None. Nothing. No signups, no comments, no upvotes, and 1-2 visitors an hour. Steady, but that’s it.

So, time to figure out what went wrong. And I barely got any clicks to the Product Hunt launch, which tells me I likely had an issue with either discoverability or the tag line.

Product Hunt had at least 660 product launches today. Duckity is #660, that’s how I know. They recommend not asking people for upvotes, otherwise you’ll be flamed, so I was a good boy and didn’t overtly promote it everywhere. Mistake #1, bring your people with you beforehand.

I had posted about what I’m doing yesterday in /dev/null. Not enough. Without an actual follower base or hype, they won’t come after you next day, so I have to build a little follower base to get me started before the next launch.

I am getting clicks on /dev/null and twitter, and my cold emails got clicks too. Yet zero replies? Actually, my cold emails got the most clicks out of them all. When I wrote them by hand, obviously. The only opinion I got on Duckity beforehand was that they didn’t know whether it worked, and that’s a fair complaint. I’ll be working on it as I said on my earlier blog posts.

Also, I’m thinking credibility may be that issue stopping people from answering my emails.

OKAY WAIT. The Hacker News launch is giving me a spike of clicks, so I’ll post an update if something interesting happens. If nothing gets posted, assume nothing happened.

Either way, I’m starving and these are the things I’ll be working on next:

• Going to get developers by hand
• Fixing the credibility problem, as talked about earlier today

Good luck with whatever you’re building!

P.S. I’ve read somewhere within YC that a founder who has time to blog doesn’t have time for their company. There’s some sort of truth on that, I gotta start working x2 now that I lowered anxiety.

Now, I’m biting my nails out of anxiety right now. A bit of context, I’m living with my parents, they have told me they’ll kick me out when I turn 21 (March 26th), and this startup is all my plan for life. If it fails? New startup. And the next one. And the next one. Until one makes it. And when one takes off? To the moon, Mars, Venus, wherever I make it reach. And then, it’ll be time for the next one.

Thing is I have no plans on how to fund myself once the limit comes. I don’t really know how my parents will behave about it. And I just really hope I don’t have to get a job, because my life is going to be startups.

So, back to YC. I applied, not because of avoidance, but because I get easily distracted when anxiety comes up. Either way, distraction or not, YC application is almost complete, and I’ll complete it before the deadline. I’m finishing this Duckity guide, and YC did make me think about lots of things. I’ve been watching some videos of their Startup School, and it has left me thinking even more.

I’ve been working on Duckity for almost a year and a half now. In that period of time, not all of it has been productive work (in fact, most of it, until I got a therapist). That was no more than 4 months ago. I built Duckity as I would have built my other apps, which works great yet is missing the startup side of things.

For example, until about a month ago I knew nothing about marketing. I knew nothing about landing page copy. I didn’t know cold email outreach was a thing. I didn’t even have a logo, leave alone a landing page. I’ve been learning a lot about it for the past month or two.

Something that relieves me is that I seem to fit everything they mention they look for in a startup. Resilience? I’ve promised myself to launch no matter what, and I’m keeping up with it. How to make money? I have my plans. How to get users? That’s why I’m launching in two days. I’ve been able to fill out practically every question they asked in their application form, except for the equity and legal entity part which I haven’t thought of yet because it’s all a one man job up to now.

I wanna dump some thoughts on it before I eat my fingers off. So basically, I’ve been working on the product under anxiety for way too long, which means I’ve been detached from the company part of the company for quite a while, and now I’m starting to remember everything I had thought of when I was starting out because launch day is coming.

They asked for a pitch of the product, obviously. I don’t have a polished salesy one, so I dumped what’s in my head. You’ll ask me, “you don’t have a polished pitch two days away from launch?” Yessir. Thing is the anxiety about the birthday deadline has been eating up part of my mental bandwidth, and I’m launching anyway because no point in not launching. I have a working product I can sell.

The pitch I have in the application at the time of writing is this:

Duckity protects applications’ login forms, signup forms, and other sensitive forms and actions without having to ask users to click on buses. Instead of prompting them with puzzles, Duckity sends over a cryptographic challenge that’s meant to be automatically solved. The challenge is completely invisible and it’s just math, so it works in any platform without the user having to do anything. Instead of using hashcash or other probabilistic proof of work algorithms like competitors do, Duckity uses VDFs, which give you more predictable amounts of work (and therefore delays) that other algorithms don’t give you, therefore making tuning the protection for UX way easier. Captchas are usually bad at customization, too. You usually have to trust some black box AI with “99.9% accuracy guarantees” which in practice are unverifiable, and they give developers a “confidence score” without much guide on how it’s calculated, so decisions on what to block are mostly a guess. Duckity is cryptography and waiting to slow down bots and make scaling attacks costly instead of trying to guess who’s a human and who’s not. VDFs are at the core of Duckity, then developers can create and customize policies which define not only how hard & slow those challenges will be to solve, but also at the rates that can be issued and settings that allow a single attacker trying to pass as many to be correlated across identities. The idea behind that is that you usually don’t really care if it’s automated automated access or not, rather whether it’s doing what a normal person would be allowed to do. What’s the issue with an agent sending messages to someone’s friend on behalf of the human? Not much. It’s an issue when an agent or bot is used to mass spam people. But it would be a problem if a person did that mass spamming by hand too, so no point in just saying bots = bad, humans = good. Duckity makes it hard to scale automated attacks by both using cryptography and by allowing developers to define what allowed usage looks like. I believe that’ll be more useful as more people transition towards delegating more work to AI.

You may be thinking “holy yap”. Yeah, me too. That’s a mix of how the thing works, what it does in theory (i.e. my original pitch), and the direction I figured out I’d go as I wrote it down.

I don’t use AI agents, yet that last line is quite interesting. I hadn’t thought of it until I was writing down the pitch. I have been told a bazillion reasons why it won’t work by my parents. Bazillion falls short, even. But everyone has excuses not to do things. That’s why I’m launching anyway, and not like those opinions have any weight anyways. My parents aren’t gonna be using Duckity, they barely even know how it works.

YC guys also mentioned “we’ll see” and “we’ll figure it out” as really nice things for a founder to have. This person, let’s call them X, is struggling with what career they’ll follow. They have no clue and their parents are pressuring them a lot. So I told them “let’s start a company”. Yeah, I’m learning myself, yet we’ll figure it out. I didn’t even know what company to start, I just knew we’d do something to get moving. They like seals, find them cute, and I’m a programmer, so it had to be an app. They suggested a seal-related game, I’m down for it, and after a while they suggested to make a seal restaurant game, something like some other videogames they play. So we got to work, I told them we’d get something ready to publish in a month or less and set the release date to Nov 14th. We work on it at night once every three days, and we have some stuff working already. It’ll be ready for that date.

I’m sharing that experience because it’s literally what YC says to like. Even if YC doesn’t pick me, and I’m planning for them not to, I’m launching Duckity. I’m gonna make it work, and it WILL work. Launch date is on Tuesday and I’m launching anxiety or not. If you’re some YC guy reading this, hi! And if you’re not some YC guy reading this, also hi!

Ultimately, everyone has a reason to say no. Actually doing things is what really matters, and trying and learning everything you can and getting better every second. I have no proof in the startup world, yet no doubts either. Good luck with whatever you’re building!

1. Some keybinds seem hardcoded into the compositor,
2. The settings app’s hotspot doesn’t allow wifi + hotspot even when my network card supports it,
3. The settings app’s keybinds aren’t as customizable as hyprland’s without touching the CLI,
4. Hyprland breaks. It breaks MANY times. Way too many. Some day they just decided to ditch their config format and went for Lua. Lua’s great, yet only 1 version to migrate everything before catastrophe wasn’t nice. And it seems coded for the vibes, which I don’t like.
5. Went to the Hyprland Discord server to ask for help with some issue I had, I got greeted with jokes from the dev and no help at all. Welp.

So I set sail to build my own compositor.

For context, I had tried implementing my own wayland compositor with Smithay and Rust before, but they all just seem to have absolutely zero “newbies click here” step-by-step guide to get to work, the wlroots docs are just a bunch of method lists, it’s not a nice experience for someone getting started.

It’s not impossible to get started with it, in fact it’s quite easy. The only issue is the lack of docs, so here I am. Writing this for myself to learn as I go, and hopefully it becomes useful to you too.

It’s worth noticing that at the time of writing this I have a compositor accepting connections but not doing anything useful with them, it just renders a black screen. I have not yet implemented XDG shell yet, though, so it makes sense stuff hasn’t been rendering.

This is the first post of a bunch I’ll be writing as notes for myself not to forget and better internalize what I learn. Also notice that I am a beginner to C as well, though I have experience with Rust, Python, and the dreadful JavaScript.

These posts will also be based on what I learned reading from Drew Devault’s blog. Issue with it is that many APIs have since changed considerably, so many parts of the code snippets provided in those examples just don’t work anymore.

Feel free to raise an issue in this blog’s GitHub issues if you notice any typos or other mistakes.

Duckity begun because I wanted to start a company. I dropped out of university after a year of systems engineering because I knew I wanted to live my life coding what I like and enjoy, not working for someone else. I failed every subject at uni because I didn’t even try, so I told my parents I’d make an app.

I had no clue what app I would make, though, so to get started I started making a cute journaling app in React Native that was zero-knowledge encrypted. All good, first version was ready, so I bought my Google Play developer account with some $25 I had gotten for my birthday, uploaded my app, and went on Payphone to get a bunch of testers. Got em testers, waited the 14 days, and submitted my app to the play store for review.

The review got rejected. Why, you’d ask me? Thankfully, I had set up analytics in the app as one of those cool things I was trying out, and it helped. Authentication was made with Logto, which opens a browser tab to log in, and that wasn’t working for Google Play reviewers, so they just left it there.

So basically, Logto had to go. Logto was one of those things I was also trying out, because in practice it was a bit cumbersome to integrate. Things weren’t as smooth as a native ORM model. So I started building my own auth endpoint. Then I realized I’d need a CAPTCHA or I’d get holy spammed. It was zero-knowledge encrypted already, which meant I had barely any knowledge of who was who.

Also, I’m an obsessed-with-ux guy. If it doesn’t work perfectly, I change it. And CAPTCHAs were one of those triggers. reCAPTCHA? Put a webview. hCaptcha? They’re there for Discord, and it’s hell to use there. Cloudflare? Same as reCAPTCHA. There was nothing there that could just be invisible and smooth on UX. I also tried Altcha, but it solved challenges on my phone in, hear me out, from 1 second to 35 seconds. That’s their landing page demo, so I assume they were nice on me. I didn’t want to hear about them again.

I went ahead and asked ChatGPT “hey, how do I make my own CAPTCHA” so it told me that there’s either PoW and all the browser-based ones. I liked the PoW idea, so I started playing with some hashing algorithms and hashcash. It worked, it was really easy to make, it was native. But it varied wildly in solving times. Add a bit? The time didn’t grow up linearly, more like exponentially. So how am I even gonna tune something like that?

I played with SHA-256, Argon (bad idea), Blake. None was good. SHA-256 showed the UX variety which was bad. Argon means it’s dead easy to overwhelm the validation server. Blake somehow never solved because the first bits weren’t perfectly random. So I asked ChatGPT if there’s anything like PoW without those drawbacks. And after a few tries, it mentioned VDFs.

VDFs, for context, are a bunch of recursive math functions that are sequential. I.e., you can’t use two CPU cores to go faster. That means an attacker with OpenAI’s GPU farm won’t solve VDFs in a nanosecond while you in your Galaxy S1 take 4 business days for it to solve. It’s pretty much a loop of N iterations where each iteration depends on the previous one, so you can’t just go ahead and skip some steps or try to parallelize it. It’s all gonna depend on your CPU speed. Those N iterations are the “difficulty/hardness” of a VDF “challenge”. I.e. what Duckity tweaks with your policies.

I initially went for Sloth. It’s simple and works. It did its job. The whole original implementation was on Sloth. I made the control plane in FastAPI with Tortoise ORM (I have a template on GitHub if you happen to be curious) and the data plane with Rust and Axum. I had originally built it on TurboStore, which is great for that stuff. Cache cleanup did not scale well at all, but it is hella fast. Then I wanted to make it distributed while adding a caching layer directly to the database, so I started working on the design.

After a while of designing it and working on implementing it, I realized that Redis was gonna be the quicker development choice, so I put TurboStore on hold and migrated to Redis. Actually, I rewrote the data plane at least 3 times, which again, not good at all. That’s one of the many lessons I’ve learned.

I also later migrated to Wesolowski VDF after hearing something about side channel attacks on Sloth VDF, so to be sure and not having to migrate later on, I went ahead and made it Wesolowski VDFs instead.

Remember how I originally needed Duckity for a React Native app? Well, I haven’t yet made one, because I haven’t been working on that app ever since. I’ve told myself I’m launching that app, though, it’s just paused, so I’ll write that React Native SDK sooner than later.

Well, fast forward to about a month ago, I had to make a landing page and I had no clue how to make one that sells. I learned a few things by asking ChatGPT:

• It has to be customer-outcome oriented. The customer wants to know how it serves them, not really how other than to know you’re not a faker.
• That’s it.

But whatever, I’ll learn once it’s up. So I set up Umami and started sending cold emails. At first I went to publicapis.dev and started going one by one checking out if I could get emails to send to from their websites and keeping track of them in a Google Sheets doc. First day I sent 4 emails in about 4 hrs, because I was learning how to write the cold emails properly. Day 2 I sent like 8. Yet, that was being wayy too slow. It was hours and hours of work for a few emails, so I found out Hunter God knows how.

Hunter’s a great platform. It has a free tier, and I used up all of those 50 credits in my first month. For context, a credit is more or less equal to one email you get to cold email, so that was about 50 emails. I kept sending cold emails by hand, which was taking me too much time, getting me no replies, and I couldn’t use that time on something else. So I checked out their sequences tool to make email templates and send them out, but I had 3 issues:

1. Their templating is extremely basic, you can’t do more than basic substring replacement. It makes those emails smell like autogenerated from kilometers away, and people like to be talked to by humans, not robots.
2. Their AI reviewer was not reliable at all. I wrote an email, it said “great! not spammy, sounds human,” etc. I changed one word and it went “nah, hella spammy, nobody’s gonna read this.” Someone who knows more than I do about marketing may not find this issue big, but as a thing I was relying on, not good.
3. Time to send those emails. I had read that company emails (i.e. @duckity.com) get better reply rates than free personal ones (i.e. @gmail.com). And Hunter required a paid subscription to send emails via SMTP.

So I had an issue. I also had issues with my emails reaching the spam folder with my custom SMTP server, so I decided I’d have a better time having some established provider host my email. And Zoho Mail was quite good! Their free tier gives me up to 5 email addresses for my duckity.com domain, so I set that up. SMTP is only available on paid plans, but Hunter doesn’t integrate with SMTP for free anyway, so not a big loss.

So Hunter wasn’t gonna work for the email sending thing, and I had my Zoho Mail set up. I went ahead and built my own little cold email app with FastAPI and Jinja! It lets me do everything I needed Hunter to do, like scheduling, and it imports my leads from Hunter. Plus, email templating is with Jinja and I made it so that I can add custom fields to leads, so I can personalize cold emails even more. The thing had:

• Sequences with many steps,
• An email scheduler,
• Email frequency limits,
• Automatic email sending via the Zoho Mail API,
• Listening for incoming emails and stopping sequences for a lead on reply,
• Jinja email templating (with a basic highlighted editor),
• Custom fields to label leads,
• Basic analytics,
• A conversation viewer in-app

The UI was very basic HTML, CSS just enough to place stuff where it should go. It didn’t even have multi-user support because it was just for me. I wrote my emails, I left it running for some days, and once all emails were sent, I had no replies. Days passed, no replies.

I told myself that after ~50 emails sent, no replies was little evidence, but I had a problem. I didn’t know of a reliable way to scale it up. Today I think I could go through GitHub and checking out those people who have public emails, but by now I have left aside the cold email strategy for a while.

I got v0 to make me the landing page, and I liked the style. Made some tweaks with v0 over the course of some days, yet at the end of it all, it was obviously AI-generated. Google refused to index it. And the copy was so generic. So I ditched it.

That v0 landing page was after another landing page I had made, but I was getting anxious so I wasn’t being able to finish it. And it was looking too playful so I worried it wouldn’t get me any serious customers. Anyway, with that hand-made landing page I joined a lot of programming Discord servers and posted it in every showcase channel I found. Yeah, it’s not open source, yet I broke some rules for the sake of it.

And it worked. I got 3 users to sign up, which was great news. And even more, I had ended up restraining from posting in every server because I was worried I’d fuck up my opportunities so I didn’t use them. Bad mistake too.

I never heard back from those 3 users, but at least I got them to sign up, which is great. It means that worked. I also DMed one guy making an anime API, and I made a few mistakes like claiming they don’t use a CAPTCHA when they do, but only in their signup form while I only checked their login form. Mistakes and all, they replied with a decently-long message.

The message was great. They said they wouldn’t try Duckity out, but they told me why, which is great.

• They didn’t know whether Duckity actually works,
• They didn’t want to have to add me as a processor and update their privacy policy,
• They didn’t know what data I collect or process,
• They didn’t know how I collect and process data.

All useful information, so I added all that info as FAQs to the landing page. In the end they didn’t sign up, but I got all of that useful information.

Fast forward to 2 weeks ago, I started working on a new landing page after ditching the AI-generated one. I wanted to be really creative, after all Duckity’s branding is meant to get out of that serious security corporation vibe and be more approachable and friendly. So I made it slides-like, with Rubik and Rubik Glitch fonts, with a bright yellow background, and cartoonish buttons.

God knows whether it’ll sell, yet it’s done and works. I finished it some days ago. It’s now indexed on Google, unlike the AI-generated one. Now that it’s done and launch is coming soon (next Tuesday), no point in getting anxious over it.

Anxiety was a big, big thing during these almost 2 years of working on launching a company. Mind blocks, freezes, stress 24/7. Now I’m getting to the launch date, and only because I read everywhere that you have to launch ASAP. I was trying to get something done perfectly, but that just won’t get me anywhere since there’ll always be something to do. I cut off everything that was pending from my project manager tasks list, and worked to get it launched soon.

Right now, I’m finishing a guide on how to tune policies. It’s Friday, I have today and tomorrow to work on Duckity, then I’ll use Sunday to keep playing with wayland and wlroots (check my previous blog post), then Monday to work on Duckity and polish all I need for launch on Tuesday. I’ll be launching on Hacker News, Product Hunt, Indie Hacker, and Reddit to begin with. Maybe TinyLaunch too. I’m also gonna need to start blogging to work on SEO.

Anxiety. I’ve said it already, it’s a big one. Throughout these almost 2 years, anxiety has been on me most of the time. Yet, I know I’m not giving up, so I’m still figuring out how to handle it. My main complaint about it is how it makes it harder to learn when it’s all about learning. And it has slowed down my progress many, many times. But hey, never giving up and never stopping.

I live with my parents, and they’re not making it easy either at all. They’ve insulted me consistently, cut my wifi so I can’t work at home nor out of the schedules they want me to, have told me all the ways they think it won’t work, how they see everyone fail, not nice. But welp, this company will take me out of here, and if it’s not this one, the next one will be. Or the next one. First thing I’ll buy once company costs are covered is some big fat juicy hamburger.

Welp, whatever. Back to coding. I feel like I should be writing a conclusion but I don’t have anything to say because I drifted when anxiety hit. Good luck with whatever you’re building!