Forem: Ansell Maximilian

Pipfolio: Pip-Boy Inspired Web Portfolio

Ansell Maximilian — Fri, 30 Jan 2026 09:10:05 +0000

This is a submission for the New Year, New You Portfolio Challenge Presented by Google AI

About Me

First and foremost, I'm a big Fallout fan, specifically Fallout: New Vegas. As proven by my playtime on Steam:

With the current ongoing season of the Fallout adaptation TV show centered around New Vegas, I could not think of a better theme for my new portfolio to show off my skills as well as my interest in a single glance.

Portfolio

Here's the live website: https://pip-boy-portfolio-978859030334.us-west1.run.app

Here's the repo if you're interested: https://github.com/AnsellMaximilian/pip-boy-portfolio

How I Built It

I built this entirely using Google's AI Studio. I must say it went very well. I'll give you the exact first prompt I gave it word for word. No planning; just natural language:

As you can see, I kept it simple at first just so I could see the design it would cook up and, if needed, adjust if I weren't satisfied.

Crucially, I gave it sample images of the actual Pip-Boy to give it some inspiration:

The current app looks a lot more advanced that what this first prompt created, but thanks to AI Studio's version history feature, I can show you exactly what it built the first time around:

As you can see; it's already pretty good. But it was far from finished. So after a few more prompts and adjustment... I ended with something like this:

To look at the full thing, make sure to visit the deployed version above.

What I'm Most Proud Of

AI Studio really got it perfect at the start. The theme, colors, and the terminal effects all really sell the vibes well.

I tried to get it to maintain that design to the very end, and it worked great!

I really like the contacts section disguised as the "Radio" menu in the Pip-Boy:

Something cool that happened during development: I basically gave a link to my old portfolio website and asked it to parse it and put my skills there into the S.P.E.C.I.A.L section in the Pipfolio, and it did exactly that.

From a Single File to a Full Chrome Extension Using Kiro

Ansell Maximilian — Tue, 02 Dec 2025 01:09:06 +0000

Quick Demo

Introduction

There have been an increasing variety of coding agents recently. Each one getting more integrated and comprehensive than the last. I've been lucky enough to have been able to try a couple of these not only on my own free time, but as part of an implementation task at my work to integrate these agents into some of the development workflows.

I remember trying CrewAI, a multi-agent AI system, and trying to hack together our own coding agent. It did well enough... but it's not what CrewAI was meant for.

Then Codex came along and did what our hacky system did way better and more precisely with fewer errors. The learning experience was valuable nonetheless. Because that's what it was meant for. It reads your codebase and prepares itself with the right context.

Then I saw over on Devpost that there was a hackathonfor one of the newest coding agents around the block: Kiro

What Is Kiro?

Plainly, Kiro is an AI-powered Integrated Development Environment. So unlike codex it comes with a full coding environment and extra purpose-specific features on top of it. Those features include but are not limited to:

Creating agent hooks: Agent automation that runs after a specific trigger that you set. For example, you can literally ask Kiro to create an agent hook that updates test files every time the relevant files change; Kiro will automatically create this hook for you.
Steering docs: You can ask Kiro to generate steering documents for your project. This will give Kiro AND yourself a better understanding of the whole structure of your project. I find this is especially useful for older projects you've inherited from other devs. This way you don't have to waste much time studying legacy code.

Actually, why even read the docs yourself. Just ask Kiro about the codebase. Now thanks to the steering docs, it can answer your questions better and more accurately. E.g. "How are the real time messages handled within this application? Where did they place the socket listeners?". You no longer have to trace it down from the very beginning of the app flow.

Spec-Driven Development

Here's what I think sets apart Kiro from other coding agents: Spec-Driven Development. A common denominator between most of the coding agents is how you usually approach development: vibe coding.

You say what you want, and the agent gives you the code: prompt -> code. But Kiro, while still providing the option to vibe code, provides a more thorough alternative. This is spec driven development:

Prompting in this mode won't get you code straight away; instead, Kiro will think through your request(s), plan accordingly, create an appropriate spec folder, and fill it with relevant specification documents, namely:

This will be generated for you to review before you move on to implementing the code. That's what I really like about this. That buffer stage you can utilize to check if what the agent is planning to do matches with what you want.

Beside basic implementation, it will also require and list thorough testing that it will execute for you. So once you're satisfied with the spec, you can go ahead and start the tasks in the tasks.md.

Kiro will also fix any errors it finds during testing

What I Built

I had noticed that I had been losing my ability to focus lately. Reduced attention spans and easily distracted -- basically that brainrot thing people keep mentioning online. It had been hard to pry my attention off just doom scrolling and opening X/Twitter. It was literally impossible for me to do a focus session without getting distracted.

Then I saw this really good video on dopamine detox. The essence is basically this: My brain has been getting too much frequent high-dopamine, fast reward activities -- like scrolling Reddit or watching Shorts. My brain got used to these and basically dampened my receptors towards sustained, low-intensity reward over time. That's why I couldn't stay focused on my work for a long time.

It also said that my brain would benefit more from a more rigid system of work THEN reward. It also said it would benefit from gamification. That's the core fusion/chimera idea this project.

An Chrome Extension that Combines Productivity with Fun

I then came up with "Soulful Sessions". A Halloween themed Chrome Extension that combines those two core ideas: work THEN reward AND gamification.

I also came up with a unique concept/theme surrounding the core functionality of the extension. To stick with the prompt's Halloween theme: I came up with the center idea of "soul collecting".

This is one of the most underrated benefits of Kiro. Allowing me to put more attention to the creative side of this project.

You play as the "Soul Shepherd", a benevolent grim reaper-like character who collects souls and lead them into a better place. You have stats like Spirit (attack), Soulflow (how fast you idly generate resources), and Harmony (basically critical chance).

There's two types of gameplay here:

idle: where you generate "Soul Embers" (main currency) passively. The idea is the Soul Shepherd collects "content souls". Souls that are ready to move on. So there's no effort required. You just generate Soul Embers based on your current stats.
bosses: where you battle a "Stubborn Soul", souls that are not ready to move on yet, even though it's their time. These are like campaigns or bosses on games. Each boss has a unique name, backstory, and "Soul Resolve" (health points).

You defeat these Stubborn Souls by doing "Focus Sessions". A period you start during which you cannot visit discouraged or blocked sites you've set in the settings. After each focus session, you deal damage to the boss according to your stats.

For example: let's say I've set facebook.com as one of the discouraged sites, and youtube.com as one of the blocked sites.

During a focus session, if I tried to visit Facebook, I'll get a light warning saying my session has been compromised and that my rewards have been reduced. But I'll still be able to click around in it, since I only have it as discouraged.

If I visited YouTube, since it's in the blocked list, I'll actually be immediately redirected to a special page saying I can't visit it. So no chance for me to actually get distracted by YouTube.

Then, once the focus session is over, depending on a couple of factors including whether or not my session was compromised after visiting a discouraged or blocked site, I'll get my rewards, which are the Soul Embers we talked about and "Soul Insight", the XP with which you level up.

Then we enter "Break Mode". This is the reward part of work THEN reward. We'll be able to do lots of things during this period, including using the Soul Embers we generated to upgrade skills and buy cosmetics: "Themes" and "Sprites" (your Soul Shepherd's unlockable skins).

If you leveled up, you also get skill points to use on upgrading your skills. Since upgrading skills using Soul Embers gets exponentially more expensive as you do it.

That's the core of the app, but I'll show you screenshots of the whole extension a little further below. For now let's talk about developing using Kiro:

Starting with One Manifest File

Alright, I've rambled on long enough. Let's get to coding-- or rather let's let Kiro get to coding.

I actually made it a point to let Kiro do most of the coding and debugging. A sort of "stress test" for this new tech I've discovered. To that end, I gave Kiro almost next to nothing to start with: A Chrome extension manifest JSON file.

Looking back, I probably could've given Kiro an empty folder and it would've still worked.

Then I turned on Kiro's spec mode and gave it a MASSIVE and detailed description of my whole app. I basically listed the entire extension idea I had after a couple hours of brainstorming.

Here's a glimpse of my first prompt:

---
Core Fantasy & Tone

You are a **gentle Grim Reaper** type – more guide than killer.

* You help **Content Souls** (peaceful, ready-to-move-on spirits) pass on.
* You work to calm **Stubborn Souls** (bosses) who cling to unfinished business.
* Everything is **spiritual, emotional, non-violent**: persuasion, soothing, guiding, not attacking.

Think of Death as a mix of therapist, guide, and cosmic janitor.

---
TRUNCATED

...AROUND 400 MORE LINES OF IDEAS AND FEATURE REQUESTS...

---

Daily User Experience (End-to-End)

1. User installs extension.
2. Opens Options Page:

   * sets focus length (e.g. 25 min)
   * lists distraction sites
   * sets goals/tasks/subtasks
3. Clicks extension → Popup:

   * chooses task to work on
   * starts focus session
4. During session:

   * popup locked with simple message
   * background tracks time & distractions
5. Session ends:

   * notification: “Your ritual is complete.”
   * popup shows rewards (Soul Insight, Soul Embers, boss progress)
6. Break:

   * user checks game, upgrades stats, watches idle souls being collected
7. After break:

   * nudged to start another session
   * rinse, repeat: this is their new Work → Reward / detox loop.

Again, I really wanted to stress test my new friend, Kiro, here. It generated a giant spec for me and listed a whopping 42 tasks in the tasks.md.

I looked through the documentations and then when satisfied, I ran all 42 tasks.

Sidenote: Creating an Agent Hook
Quick detour! I wanted to mention that I created a automatic hook to help organize my commits as Kiro performs the tasks it gave itself.

And yes, you can ask Kiro to create a hook for you. This worked well enough, except that agent hooks and tasks all fall under one category: a task. So when you simultaneously queue all your tasks, this agent hook will only be queued at the bottom (after all the tasks) and therefore you'll only activate this hook for the last task.

I'm sure there's some hack you can do though, maybe instead of queuing all the tasks, you could let Kiro do that. Maybe create a last commit file, let the previous agent hook to also update that commit file and create another hook triggered by changes in that commit file to automatically start the next task.

Detour over!

Okay, where were we? Kiro ran all 42 tasks. It generated all the code and respective tests it outlined in the requirements. It executed all the tests. Here are some important observations I made:

Kiro will prepare your project and install all the necessary packages for testing, if hasn't already.
Kiro will proactively fix all errors generated by the tests.

Okay, so it did its 42 tasks. How'd it do? It IS a big requirement list!

Can I load the extension?

Debugging with Kiro

Actually, I ran into some loading errors (can't remember what -- sorry!) from the first version generated by Kiro from that task list.

No surprise there though. The scope was so large it was practically guaranteed. Let's see if we can let Kiro fix it itself. Enter vibe coding with Kiro. That's right, I haven't forgotten about it.

So I simply copied the error Chrome gave me and gave it to Kiro. I don't even remember what it did, but it searched through my codebase again, thinking and talking to himself, and then... it's fixed! I can load the extension without issue.

Pretty impressive!

Initial MVP

Before I show you the final product, I'd like to show screenshots of the first working iteration Kiro generated for me. Just to show you how it did, and how it compares to the final product:

Main Popup UI

This is the main UI where you start your focus sessions. It also lists all the important details about your current status. Skills, levels, Soul Embers.

Popup During Focus Session

Just like I asked it to, it disabled all game UI while focus session is active, so you can't even get distracted by the app itself.

Discouraged and Blocked Sites

This is what happens when I visit a site I listed as "discouraged". It does exactly as requested, giving a small warning to persuade players to get back to focusing.

And this is what happens when I enable strict mode and visit a site listed as "blocked". Blocks are stronger than discouragement because it literally prevents me from visiting blocked sites by redirecting me to this special page. I call it "hard blocks" instead of the previous "soft blocks".

Break Time

Once focus session ends, you'll get a notification and the popup now goes into "Break Time" mode. This is the reward part of work THEN reward. During this limited reward time, you'll get to upgrade your Soul Shepherd using Soul Embers or skill points you gain from leveling up.

If you have enough, you'd also be able to buy cosmetics during this time.

And as you can see, you will have done some spirit damage to the Stubborn Soul, resulting in its Soul Resolve (health) dropping some points.

Options page

Here are some features on the options page Kiro generated for me, including task management and distraction management, where you add sites to your "block list":

Task Management Tab

Distraction Management Tab

Statistics

Theme Change

Here's the popup after I unlocked a theme and applied it, just to show it worked:

There are a bunch of other tabs in the options page, but I'll skip those just because it's getting long.

Scroll down to see the comparison to the final product.

Adding Features with Kiro

I was pretty impressed already by the first iteration of my extension Kiro produced. I had used vibe mode to fix bugs and make minor adjustments.

But let's go beyond that. As in real projects you're unlikely to be done with just one iteration, no matter how flawlessly it went.

Let's add a feature. I wanted to calibrate reward and boss damage calculations (Soul Embers and Boss Damage) based on the initial algorithm Kiro gave me. I wanted to easily check how much I earn through idling and through boss fights at different player and skill levels without having to actually level up-- a way to simulate player status and circumstance. Because doing it manually while waiting for focus sessions would take ETERNITY!

So I went into spec mode again and asked Kiro to make this feature for me, and to add a new spec. Because this feature is big enough for me to want to be thorough.

I asked it to create a "dev screen", separate from the extension, which can simulate player levels and skills and allow me to see how many rewards and how much damage would a player at any level or skills would get and do without having to do actual focus sessions.

I also specifically asked it to draw from the same sources and functions as the actual extension, so everything kept consistency, and so Kiro would only need to test in one place.

Of course, it generated the appropriate spec documents for me. I then subsequently ran all the tasks so Kiro could do it's thing.

Here's what it made me:

And this time it worked straight away. It gave me a script to build and run it at port 3000.

Again, this proves that Kiro works beyond just initial spec generation and implementation. You could use this on existing projects to add new features.

Captaining the Creative Ship with Kiro Vibe Code

This is the most precious part for me. Sometimes I really enjoy the creative process more than the engineering part. And Kiro allowed me to focus on that creative part!

And in this particular project, I really think I came up with a concept and theme that I seriously enjoy and am proud of! It's simple but coherent, and I like the terminologies I came up with.

Thanks to Kiro, I could keep expanding upon the initial concept of "soul collectiong" while it translated my ideas into working code. While it worked on my code, I could let my mind travel back to the concept and come up with new stuff. And I did!

The boss bestiary or gallery screen was something I got the idea for while Kiro was doing its thing running tests for me!

Final Product

I won't go into details for features already established in the MVP section, but I'll explain any additions I requested Kiro beyond the first iteration.

Main Popup UI

Popup During Focus Session

Discouraged and Blocked Sites

Break Time

Options page

Here's something interesting: In the statistic options tab, I asked Kiro to add a player card feature. Something concise and pretty to show off current progress using spec mode.

At first it designed the card on its own, as I didn't give it any direction. It looked nice enough, but not what I envisioned.

So I drew a simple design on MS Paint and gave it to Kiro since you can paste pictures there.

Here was the design:

And finally after a few vibe code back-and-forth, here's what I ended up with:

Not bad, eh?

Boss Bestiary or Stubborn Soul Gallery

And finally before I published I had a quick idea I wanted Kiro to implement. Most games with a variety of bosses always have a gallery of sorts you can view to look back on your progress and the road ahead. Here it is:

A list of bosses you've unlocked, guided (defeated), and ones you'll get to unlock after leveling up.

When you click on an unlocked boss/Stubborn Soul:

To give player more motivation and direction, I added locked content for each boss for players to reveal once they've "defeated" each Stubborn Soul:

Final Conversation: A heartfelt dialogue where the Soul Shepherd helps each Stubborn Soul find peace and acceptance before they move on.
Resolution: A narrative epilogue that describes how the soul finally finds peace and moves on.

Here's an example just for the first boss; I don't want to spoil any more:

Conclusion

I definitely see myself using Kiro beyond the challenge context, especially when I want to focus on concept more than implementation. I also would like to try integrating MCPs into Kiro. Next project! Maybe I'll integrate it with my local database so I don't have to explain schema structures to it-- a pain point I'm way too familiar with when it comes to code agents.

How to Use Appwrite in Android Jetpack Compose

Ansell Maximilian — Thu, 24 Jul 2025 04:47:26 +0000

Introduction

I love Appwrite. My first hackathon was actually from Appwrite (using Appwrite) 2 years ago, and I've been using it ever since.

It has basically every basic feature that you could want for a backend as a service and serves as a perfect base for almost any kind of app you could want to create.

It has a very generous free tier and therefore is really good for prototyping app ideas. And when you're ready for production, you can easily upgrade!

However, I've only been using it for creating web applications. Recently I've started to take interest in mobile development, specifically using Jetpack Compose.

I thought Appwrite would be perfect to help me on my learning journey. I would have a ready backend and can just focus on learning the fundamentals of Jetpack Compose Android development.

That's why I made this article.

Who Is This For?

Ultimately, this is for my future self and anyone else who might want a quick overview of how to integrate Appwrite into a Jetpack Compose Android application.

Note that I'm writing this as a beginner, but I will try to make sure all the info are objectively accurate.

At the end, I aim to have an article that I can look back to and get back a basic understanding fairly quickly when I'm rusty.

How This Is Going To Work

The tutorial is going to be heavily based on this quick start guide by Appwrite with a few adjustments.

For each new major Jetpack Compose/Android concept we encounter, I will explain it clearly within the current context without digressing too deep into other topics.

At the end, we will have the same result as the original article, which is a working Login Page that uses Appwrite. Spoiler:

Of course, I won't just be regurgitating the same info as the original article: I will be explaining each concept clearly based on my objective understanding to add value to this article.

As a side note, it would definitely help if you came from a web background (like me), because I use a lot of analogies comparing this to web development, especially front end.

Prerequisites

Android Studio
Basic Programming Knowledge
Appwrite Account

Integrating Appwrite

Let's actually get into it.

Create Android Project

If you'd rather clone a starting project, here's a link to my repository.

In Android Studio, create a new project. When given the prompt to choose a template, choose "Empty Activity".

Name the application whatever you want, but pay attention to the "Package name", as this will be used somewhere else later. Leave the other settings as the defaults:

Create Appwrite Project

Go to the Appwrite Console and create a new project.

Create a New Android Platform

This is actually a very important step. Just like if you were creating a web app -- where you'd need to create a web platform and add allowed domains, you need to add an Android platform and fill in the appropriate details from your actual Android app, namely the package name (I've found that the "Name" is irrelevant and that you can fill it with whatever you want).

Without this step (or by filling in the wrong package name), you'd get an invalid origin error.

Add Dependency

Just like you'd use NPM libraries inside your React projects, you can add existing libraries here in your Android project. Specifically, you can add the Appwrite SDK as part of your project so you can use existing code that the Appwrite team wrote to easily communicate with your project.

There are two build.gradle.kts files in your Android project, but you need to add the dependency to the one in the app level: <your project>/app/build.gradle.kts.

implementation("io.appwrite:sdk-for-android:8.1.0")

At time of writing, this is the latest version of the Appwrite SDK, but if you ever want to use the latest version, look it up in the respective library page where it is hosted in the Maven Repository.

Appwrite Singleton

In the same level as MainActivity.kt, create a new Kotlin file and call it... whatever you want. I'll call mine Appwrite.kt. Fill it with the following:

package your.package.name

import android.content.Context
import io.appwrite.Client
import io.appwrite.ID
import io.appwrite.models.*
import io.appwrite.services.*

object Appwrite {
    lateinit var client: Client
    lateinit var account: Account

    fun init(context: Context) {
        client = Client(context)
            .setEndpoint("<YOUR_PROJECT_ENDPOINT>)
            .setProject("<YOUR_PROJECT_ID>")

        account = Account(client)
    }

    suspend fun onLogin(
        email: String,
        password: String,
    ): Session {
        return account.createEmailPasswordSession(
            email,
            password,
        )
    }

    suspend fun onRegister(
        email: String,
        password: String,
    ): User<Map<String, Any>> {
        return account.create(
            userId = ID.unique(),
            email,
            password,
        )
    }

    suspend fun onLogout() {
        account.deleteSession("current")
    }
}

In Kotlin, you create singletons using the object keyword. You create a singleton because you'd never need another instance of this object ever again.

Once it's initialized, it will be available anywhere, and you'd never need to reinitialize it again.

Appwrite separates its APIs by services. Here, Client is the core or foundation that all services use. This makes sure the service actually communicates with the right project.

Account is one of Appwrite's many services, used for handling authentication.

So, in summary:

You create a singleton called Appwrite
You give it two properties (client and account)
Those two properties have the lateinit modifier:

We use lateinit because we are defining the properties as "non nullable". Meaning it has to have a value: instance of Client and Account respectively.

We could make it nullable by doing something like var client: Client? = null. But then we'd have to do null checks every time we want to use it: client?.doSomething().

So a compromise is lateinit: we are basically saying to the compiler: "Listen, I promise you it's not going to be null when I use it. I'll initialize it first. This won't be null." The error then goes away.

Why can't you just initialize it immediately in the singleton?

Because the Appwrite client requires Context, which you can't get inside the singleton. It needs to be provided where context is available, like activities.

We create suspended functions onLogin, onRegister, and onLogout:

It's suspended because the code inside it is asynchronous, i.e. registering a user. You need to add suspended because you call other other suspended functions.

This also allows you to await these functions and perform actions based on the timing of its execution:

try {
    onLogout()
    showSnackbar("Logged out successfully")
} catch (e: Exception) {
    showSnackbar("Failed to log out: ${e.message}")
}

This way you only show the snackbar ONCE you've actually logged out.

Inside these defined functions, you call the account service's built-in methods, provided by Appwrite.

Create Login Page

The template we choose earlier provided a MainActivity. As declared in the AndroidManifest.xml file, this will be the activity loaded when you build and run the app:

<activity
    android:name=".MainActivity"
    android:exported="true"
    android:label="@string/app_name"
    android:theme="@style/Theme.AppPost">
    <intent-filter>
        <action android:name="android.intent.action.MAIN" />

        <category android:name="android.intent.category.LAUNCHER"/>
    </intent-filter>
</activity>

We'll replace the default activity with the following to create a login page:

package your.package.name

import android.os.Bundle
import android.widget.Toast
import androidx.activity.ComponentActivity
import androidx.activity.compose.setContent
import androidx.activity.enableEdgeToEdge
import androidx.compose.foundation.layout.Arrangement
import androidx.compose.foundation.layout.Column
import androidx.compose.foundation.layout.Row
import androidx.compose.foundation.layout.fillMaxSize
import androidx.compose.foundation.layout.fillMaxWidth
import androidx.compose.foundation.layout.padding
import androidx.compose.foundation.text.KeyboardOptions
import androidx.compose.material3.Button
import androidx.compose.material3.MaterialTheme
import androidx.compose.material3.Scaffold
import androidx.compose.material3.Surface
import androidx.compose.material3.Text
import androidx.compose.material3.TextField
import androidx.compose.runtime.Composable
import androidx.compose.runtime.LaunchedEffect
import androidx.compose.runtime.getValue
import androidx.compose.runtime.mutableStateOf
import androidx.compose.runtime.remember
import androidx.compose.runtime.rememberCoroutineScope
import androidx.compose.runtime.setValue
import androidx.compose.ui.Alignment
import androidx.compose.ui.Modifier
import androidx.compose.ui.platform.LocalContext
import androidx.compose.ui.text.input.KeyboardType
import androidx.compose.ui.text.input.PasswordVisualTransformation
import androidx.compose.ui.tooling.preview.Preview
import androidx.compose.ui.unit.dp
import your.package.name.ui.theme.AppPostTheme
import kotlinx.coroutines.launch

class MainActivity : ComponentActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        enableEdgeToEdge()

        Appwrite.init(applicationContext)

        setContent {
            AppPostTheme {
                Scaffold(modifier = Modifier.fillMaxSize()) { innerPadding ->
                    LoginPage(modifier = Modifier.padding(innerPadding))
                }
            }
        }
    }
}

@Composable
fun LoginPage(modifier: Modifier = Modifier) {
    Surface(
        modifier = modifier.fillMaxSize(),
        color = MaterialTheme.colorScheme.background
    ) {
        val context = LocalContext.current

        val coroutineScope = rememberCoroutineScope()

        var user by remember { mutableStateOf("") }
        var email by remember { mutableStateOf("") }
        var password by remember { mutableStateOf("") }

        LaunchedEffect(Unit) {
           coroutineScope.launch {
               try {
                    user = Appwrite.account.get().email
               } catch(e: Exception) {
                   Toast.makeText(context, e.message, Toast.LENGTH_SHORT).show()
               }
           }
        }

        if (user.isNotEmpty()) {
            Column(
                modifier = Modifier.fillMaxSize(),
                horizontalAlignment = Alignment.CenterHorizontally,
                verticalArrangement = Arrangement.Center
            ) {
                Text(text = "Logged in as $user")
                Button(onClick = {
                    coroutineScope.launch {
                        Appwrite.onLogout()
                        user = ""
                    }
                }) {
                    Text("Logout")
                }
            }
        }else {
            Column(
                modifier = Modifier.fillMaxSize(),
                horizontalAlignment = Alignment.CenterHorizontally,
                verticalArrangement = Arrangement.Center
            ) {
                TextField(
                    value = email,
                    onValueChange = { email = it },
                    label = { Text("Email") },
                    modifier = Modifier
                        .fillMaxWidth()
                        .padding(16.dp)
                )
                TextField(
                    value = password,
                    onValueChange = { password = it },
                    label = { Text("Password") },
                    modifier = Modifier
                        .fillMaxWidth()
                        .padding(16.dp),
                    visualTransformation = PasswordVisualTransformation(),
                    keyboardOptions = KeyboardOptions(keyboardType = KeyboardType.Password)
                )
                Row(
                    modifier = Modifier
                        .fillMaxWidth()
                        .padding(16.dp),
                    horizontalArrangement = Arrangement.SpaceBetween
                ) {
                    Button(onClick = {
                        coroutineScope.launch {
                            try {
                                Appwrite.onLogin(email, password)

                                user = email

                            } catch (e: Exception) {
                                Toast.makeText(context, e.message, Toast.LENGTH_SHORT).show()
                            }
                        }
                    }) {
                        Text("Login")
                    }
                    Button(onClick = {
                        coroutineScope.launch {
                            try {
                                Appwrite.onRegister(email, password)
                            } catch (e: Exception) {
                                e.printStackTrace()
                                Toast.makeText(context, e.message, Toast.LENGTH_SHORT).show()
                            }
                        }
                    }) {
                        Text("Register")
                    }
                }
            }
        }


    }
}

Like I said, I won't digress too far into other topics and I'll stick to what's on the code. For example, I won't go into other activity cycles like onDestroy, etc.

In summary:

We override the onCreate lifecycle method. It's the first one called among the others, which makes it perfect for initializations (like our Appwrite singleton)
Since we override onCreate, you want to call the original onCreate to make sure everything works as intended super.onCreate(savedInstanceState).
Then you initialize the Appwrite singleton with Appwrite.init(applicationContext)

This is the perfect place for initializing our singleton because in modern Jetpack Compose apps, there usually only is one activity. And onCreate is the first lifecycle that's called.

This means that, for this simple app, you likely won't be calling the singleton's methods before it's initialized.

You provide the init method with applicationContext: applicationContext inherits from Context, which provides app specific information. Appwrite likely needs this for using SharedPreferences (similar to local storage in the web) for storing auth tokens. Context allows Appwrite to find where this is located for your specific app.

Other things can have Context as well, but applicationContext is safe because it lasts the whole lifetime of the app, as opposed to an Activity's Context which may be destroyed during the run of the app.

setContent is where you "draw" your page/activity.
AppPostTheme wraps around everything to provide the theme of the app, like primary color, background color, etc. This will be called different things depending on what you named your app. An app named "Super App" will have SuperAppTheme.
You create the LoginPage composable

The @Composable annotation marks it as a composable. This means that the function will "describe your UI". Composables are where you "write" your UI.

LoginPage first calls Surface, a built-in composable. You provide it with MaterialTheme.colorScheme.background, the value of which will be determined by your theme.
You get the local context using LocalContext.current. This will resolve to the current Activity's Context as that's where login page is called
You create a coroutine scope: val coroutineScope = rememberCoroutineScope()

Coroutines are where you write asynchronous code. In this specific case, inside the composable, you use rememberCoroutineScope.

This allows running asynchronous code to survive recompositions. That's when the composable redraws itself after state change.

You declare states

Ooh boy this took a while to fully understand.

var user by remember { mutableStateOf("") }
var email by remember { mutableStateOf("") }
var password by remember { mutableStateOf("") }

You use var because you want to reassign these at some point.

You use mutableStateOf so that it will trigger recomposition after change. (Making sure UI updates after state change).

You use remember to make sure the state change survives said recomposition (within the same composition).

You use by because without it mutableStateOf would've required you to use variable.value instead of just variable to access the state.

You use LaunchedEffect to check if you have an active session after the app is run

LaunchedEffect is a side-effect handler that gets executed every time its dependencies change.

In this case, there are no dependencies so you put Unit in it. So the code will only get executed once during the first composition.

You use it because a user might have an active session, so you get the current user and if they exist, you assign their email to email.

You also use coroutineScope.launch to make sure the fetching of the current user doesn't get interrupted by recomposition, i.e. if, while fetching, the user updates the input values.

Conditional UI rendering

You use an if else statement to render different UI based on whether or not a user is logged in (whether the email state is empty or not)

Composables (Column, Text, Button, etc.)

You arrange your UI by calling composable functions. Some composables like Column take in other composables and arrange them in certain ways.

Some composables directly render UI and add interactivity, like Button and Text.

Modifier is used to style a composable. Like the style property in HTML or React elements.

Using coroutineScope to run suspended functions in the Appwrite singleton

Conclusion

If you were following along, after creating the template project with an empty activity, you should have done these things:

Created the Appwrite singleton in Appwrite.kt
Modified the MainActivity.kt file to create a login page.

And if you run the app, you should have something like this:

If you register an account and subsequently log in, the login form will disappear and be replaced with this (thanks to conditional rendering):

Here's the final code.

Office Space: Actual Office Space

Ansell Maximilian — Fri, 18 Jul 2025 09:28:59 +0000

This is a submission for Frontend Challenge: Office Edition sponsored by Axero, Holistic Webdev: Office Space

What I Built

I went goofy and very literal for this one. Please don't take it super seriously, but I do want to provide some value to this article.

The challenge was to create a home page within the themes of "office". So, I decided to attempt to create an actual office space (desk, wall, folders, etc.) and make IT the home page.

I tried combining the art with the features (brand, navigation, upcoming events) as seamlessly as possible within the represented items inside the office (laptop, folders, desk, etc.).

Disclaimer: I am not an artist so excuse the quality of the "drawings", but the idea is there... and hopefully you can see it. Also, I didn't make it responsive.

The Home Page

Before showing you the demo, here's a quick list of what I actually included in the "office":

Laptop: for displaying promotional video of the company
Folders: main navigation where each labeled folder redirects users to a different page
Calendar: an actual calendar that lists the company's event for that particular month
Trophy: lists the company's achievements or the products features.
Banner: the company logo and name

Tech Stack

Vite
React
TailwindCSS
Shadcn

Easter Egg

Like I said I'd like to provide a little value to readers even though this is just a fun and goofy post.

Without watching the demo video or looking at the code, see if you can find the Easter egg within the main page.

Demo

Quick Video: Easter Egg Spoilers

Project Links

Screenshots

Home page

My favorite part is definitely the lamp. I made the bulb and covered the whole page with that glow. Then asked ChatGPT to create a cone shape with polygon clipping.

Laptop: Promotional Video

This is where I played around with perspective and rotation to give the illusion of 3D space. I think it worked out really well.

Folders: Navigation

I'm most proud of this one. They really look like folders. I wish I knew more about creating 3D art with CSS to make this pop out more, but this was good enough for me.

Calendar: Upcoming Events

Pretty simple. You click on a date with an event(s), and you'll see a Post-It note of the details.

Trophy: Features/Achievements

This could've done better, but it was pretty good for a first attempt.

Banner: Company Name and Logo

I really like the nail heads, especially the shine effects.

Journey

I don't remember the last time trying something silly like this. But I had a lot of fun, and it gave me a lot more appreciation for people who are actually good at making web art.

I re-learned a lot of things that I had barely used lime skew and perspective.

Overall it was just a fun experience. And coming up and developing the Easter egg was also super exciting.

Can Gemini Figure Out the Ultimate Question: 100 Men Versus a Gorilla — Who Would Win?

Ansell Maximilian — Wed, 09 Jul 2025 07:04:08 +0000

This post is my submission for DEV Education Track: Build Apps with Google AI Studio.

Spoiler: I absolutely love this new feature in Gemini. It works awesome. I've tried many different prompts for many different app ideas, and in the end I always end up with a working app that looks great, handles errors, is well-organized, and does exactly what I want.

You can test out the final app here.

What I Built

It was super big a while ago over on X/Twitter: "Can 100 men beat one gorilla?"

Most of the participants in this discussion didn't have any expertise to answer one or the other AND explain it accurately.

That's how I got the idea for this app. Why not let AI decide. It's got all the information and is really good at reasoning.

The basic premise of the app is to simulate a battle between two teams scientifically. So users will be able to pit two teams comprising of one or more characters (real or fictional) and see who the AI thinks would win, based on real world metrics.

Though any characters is valid, the driving motivation to create this app is to finally and reliably answer that question: 100 men vs one gorilla — who would win?

The Main Prompt

I started with the main prompt to get the basic features:

user inputs what the two teams are
AI simulates the result
display the result

Besides describing the main features, I also sprinkled in some commands for Gemini to include some support features and specific styling:

Error handling: I asked it to elegantly handle any errors and distinguish between all types of possible errors
Science based description: I asked it to analyze the battle scientifically and apply real-world metrics like km/h, tons, voltage, etc.
Styling: I asked it to theme the application around the concept of "Red vs Blue".

Here was the full prompt:

Create an app called "Who Would Win".  

It takes two teams (each comprising of a character OR groups of characters) by two fields: name and description.

Then use Gemini to simulate a realistic battle to the end and generate the result.

The result should describe the battle in scientific terms. 

You should map supernatural/fictional powers as close to real world metrics as you can. For example: if a character in lore somehow shoots lasers out of their eyes; explain how much heat it generates, how destructive it is, etc.

Theme the whole app around red vs. blue.

If a character is non-existent and the description is too vague or also doesn't exist, display an error. For a battle to be valid, the teams need to comprise of either recognizable characters OR created characters with enough description.

Make sure to differentiate between Gemini API error and invalid teams error.

You'll see the result in more detail below, but a quick review:

Gemini absolutely crushed it — as expected after testing it out a bunch. The main features were implemented beautifully in a responsive UI. The support features and styling requests were also interpreted and implemented correctly. The "Red vs. Blue" style was done elegantly without making the app look corny.

Enhancements/Adjustments with Gemini

After a satisfying initial prompting, I decided to test its adjustment/enhancements capabilities. Because generating a project and enhancing/adjusting it, to me, seems intuitively different enough that I needed to test it.

The first prompt didn't include image generation. Let's try adding that. Here is the prompt I entered into the code assistant panel:

Aside from text result, also use Imagen to generate an image of the battle result

Again, the result will be shown in more detail below. But to summarize: it worked really great. I expected an adjustment process like this to mess up existing code or at least change it very noticeably. But to my surprise, the UI and the previous features stayed largely the same.

It added the new requested feature very seamlessly and correctly.

Demo

Here's a video clip of my whole process of developing this whole app. Generating the initial project took about ~2.5 minutes, while the adjustments took about ~1.5 minutes.

The video doesn't contain any editing in an attempt to show you in real time the whole process of creating this app. Feel free to skip around:

Here's what the final app looks like:

My Experience

Here's a detailed chronology of my experience using Gemini's build feature, from beginning to end:

First Prompt

Pretty straightforward process. Please note that this was my first iteration of the prompt. I didn't enhance it using another AI or anything. I wanted to push Gemini to see if how much prompt engineering skills you need to produce satisfying results.

Result of First Prompt

Turns out you don't! Obviously, you can't just write gibberish and expect it to understand. But this shows that Gemini was able to interpret what I wanted from a simple and human prompt.

Everything I described in the prompt was implemented correctly and more.

Error handling

Error is handled very beautifully.

Testing Out the App

Created Files

Here's the current version of the app. I finally got to simulate the battle between 100 men and a gorilla. 100 men won!

I was super happy with the result, as I was always team "100 men".

As you can see, there is detailed, grounded, and scientific explanation of the fight with real-world metrics like strength measured in N, velocity, etc.

Enhancement and Adjustment

This is where I tested Gemini's adjustment/enhancement capabilities. Currently the app doesn't generate the image representing the battle. So I went over to the code assistant panel and added a new prompt, requesting it to add — on top of the existing features — an in image generation feature using Imagen.

It worked really well. What's amazing is that the previous code not relevant to the new feature stayed very largely the same.

Adjustment Result

Here is the resulting app after the enhancement. As you can see, the styling stayed the same, but now there's an image there.

Final Result

Here's the app in full screen. Looks great!

Putting Runner H Through the Gauntlet: Ongoing Hackathon Weekly Digest

Ansell Maximilian — Sat, 05 Jul 2025 11:35:05 +0000

This is a submission for the Runner H "AI Agent Prompting" Challenge

Introduction

I want to approach this differently. I was super interested in what seemed like ChatGPT with a ton of capabilities and access to external apps. So I wanted to share my journey of learning what Runner H is capable of.

So, in this article, I will be putting Runner H through a series of challenges with increasing difficulty to test its capabilities.

Of course, I'm not the best prompt engineer, so take my results with a grain of salt. I encourage you to try Runner H yourself.

Spoiler: Final Result - A weekly, newspaper-style digest of currently active hackathons, curated by an AI agent.

What I Built

The main goal of this article is to test the capabilities AND limitations of RunnerH. But I will have a general direction:

Fetching the latest information of the currently ongoing hackathons/challenges and organizing them

Demo

Quick Video Demo

In this section is where I'll be testing out RunnerH towards that general goal I've set it.

Round 1: Fetching Current Data

First, let's see how well RunnerH can fetch the most current data about ongoing hackathons. Let's limit it to a few platforms, namely Devpost.com and Dev.to (you are here).

Here's the first prompt I tried:

Generate a list of currently ongoing hackathons happening at Dev.to, Devpost.com, and Hashnode

Here was the result:

I searched the platforms and here's what I found about ongoing hackathons:

1. **Dev.to**: There are no direct ongoing hackathon listings found.
2. **Devpost.com**: Several ongoing hackathons are available:
    - Google Maps Platform Awards (May 20 - Jul 31, 2025)
    - GenAI Hackathon by Impetus & AWS (May 26 - Jul 10, 2025)
    - Adobe Express Add-ons Hackathon (May 19 - Jul 15, 2025)
    - PearAI Hackathon (Jun 14 - Dec 24, 2025)
3. **Hashnode**: No direct ongoing hackathon listings found.

Summary: Currently, Devpost.com has multiple active hackathons, while Dev.to and Hashnode do not list any ongoing hackathons prominently or have no active ones at this time.

As you can see, it did well fetching hackathons from Devpost, but it didn't find any on Dev.to, which is false because, as of writing this, there are several ongoing.

Let's debug!

Runner H provides live preview of its web surfer agent (Surfer H) going through its tasks (like fetching hackathon information).

As you can see it worked great on Devpost.com. It went into the specific "hackathons" page and started gathering. Why didn't it work on Dev.to?

Here's the preview from Surfer H:

You can get a glimpse of how the agent works here. It absolutely did the right thing by limiting the search on Google with site:dev.to and putting in keywords like "hackathon" and "ongoing".

But here's the problem: in Dev.to, hackathons are almost exclusively called challenges. So it makes sense it thought no "hackathons" were currently ongoing there. We can't expect an AI agent to know that.

Let's help it out a bit!

Here's the new and improved prompt where I specifically gave the agent the link to where Dev.to lists their challenges (ongoing and ended). I also gave Devpost.com a more specific URL including the filter open, so hopefully it will eliminate any chance of the AI returning "ended" hackathons.

This will be a great test of two things:

Can the agent distinguish ended challenges vs ongoing ones in Dev.to? Since they're all in the same page.
Can the agent take into account filter parameters (see ?status[]=open)

1. Generate a list of currently ongoing hackathons/challenges happening at the following platforms: 
    - Devpost: [https://devpost.com/hackathons?status[]=open](https://devpost.com/hackathons?status%5B%5D=open)
    - Dev.to: https://dev.to/challenges

Here are the satisfying result:

It went into the challenges page as expected:

Takeaways

I would say that Runner H has passed this round. It failed to fetch the correct information on Dev.to, but it was easily fixed by giving it more context and a more complete prompt.

You can't expect it to do everything! A good prompt is still needed as a starting point!

It also was able to:

Distinguish between ongoing and ended hackathons/challenges over in Dev.to
It also respected the filter I had on Devpost.com

Round 2: Using Google Sheets

A step further than just accessing and surfing the web. Let's use one of Runner H's many third party connections: Google Sheets.

First, you're going to want to connect your Runner H account with Google Sheet at https://runner.hcompany.ai/mcps:

The goal of this round is to test how well Runner H integrates with Google Sheet:

Creating a file
Creating that file in a specific folder
Compiling gathered data into a Sheet

Including folder creation as part of the prompt unfortunately didn't work end yielded this result:

And I did try enabling Google Drive. Here were the results:

So I adjusted my prompt to not include it. Here:

Create a Google Sheet named “Ongoing Hackathons” with a list of currently ongoing hackathons/challenges happening at the following platforms: 

Devpost: [https://devpost.com/hackathons?status[]=open](https://devpost.com/hackathons?status%5B%5D=open) 

Dev.to: https://dev.to/challenges

The Sheet should have the following table headers/columns:

- Name: hackathon/challenge name
- Organizer: organizer name of the hackathon (if any)
- Start date: when the hackathon/challenge will start
- Deadline: when is the deadline for submission
- Platform: either Dev.to or Devpost.com
- Link: link to the hackathon/challenge
- Prizes: the prizes to the hackathon

The results were pretty good:

However it did misplace the headers at the bottom. No worries. Let's adjust the prompt a little bit. I noticed Runner H was able to slice its task into separate processes as you saw here:

Let's explicitly ask it to section off its tasks using keywords like "first", "next", "finnally":

First, find all currently ongoing hackathons/challenges happening at the following platforms:

- Devpost: [https://devpost.com/hackathons?status[]=open](https://devpost.com/hackathons?status%5B%5D=open)
- Dev.to: https://dev.to/challenges

Next, for each, collect the name of the hackathon, the organizer, the relevant skills/programming language/framework/services, the start date, the deadline for submissions, the platform (either Dev.to or Devpost.com), the link to the challenge, and the prizes (if any)

Finally, add all entries into a Google Sheet named “RunnerH” in a Sheet called “Online Hackathons”.

It works now:

Takeaways

It mostly passed this round. It didn't seem to have the capabilities (currently) to actively create folders on your behalf.

It fumbled a little when formatting the table in the Google Sheet. Then I fixed it by segmenting the prompt into separate steps.

Ultimately, it did pretty well. It created the actual file, as told, then ,inside that file, created the actual Sheet with the correct name.

Again, take my own experience with a grain of salt. Test it out yourself and see if you can create folders as part of the steps.

Round 3: File Navigation and Updating Sheet

Let's test if Runner H can find its way around my files and correctly update a Sheet. Let's say I forgot to add a column and wanted to append it at the end:

Here's the prompt:

First, find the Google Sheet File named “RunnerH”.

Next, find the sheet in that file named “Online Hackathons”

Next, add a column at the end named “Notion Link” and fill the rows with “None”

Works pretty great:

Takeaways

With the correct prompt, it was able to find its way to the desired file and update it accordingly. This one is a pass ✅

Round 4: Creating Notion Pages

Notion pages are complex with many features. Perfect for next steps, both as a challenge for Runner H as well as achieving my goal of organizing ongoing hackathons.

Disclaimer

I actually found out that Runner H can't just create pages out of nowhere. So you just can't ask it something like "Create a page and write hello world". Meaning you need to do the following before doing anything with Notion:

Create a page
Give Runner H access to that specific page
Whenever you want Runner H to use notion, reference that specific page's ID

If you don't give access to each page you want to manipulate, you'll get something like this:

Let's Actually Use Notion

Now that we have a page and access to it, we can test it out:

Let's actually start prompting towards our goal. Here's my goal for this round:

Creating nested pages: So a page within a page (within one we created manually)
Updating the Google Sheet with the Notion Link

First, find the Google Sheet File named “RunnerH”.

Next, find the sheet in that file named “Online Hackathons”

Next, find the entry for <CHALLENGE/HACKATHON> and read its content.

Next, search the web for the most current information regarding that challenge/hackathon.

Next, generate 10 project ideas that fit the challenge/hackathon prompt. Each idea should have:

- General description of the project/app/software
- Recommended tech stack
- How it fits into one or more of the winning categories

Next, under the page with ID <NOTION PAGE ID> create a Notion page called “<the hackathon/challenge name> Ideas" and fill it with the generated ideas.

Finally, update the entry in Google Sheet to the new page link under the Notion Link column

It definitely works... but the specific idea pages are not as complex as I was expecting. I tested out this prompt a bunch of times, then I got this:

Seems like we should just stick with automation for now...

But it did manage to update the Google Sheet with each Notion Page:

Takeaways

You do need to give prior access to specific Notion pages before doing anything with it. But it's not a big problem, since once you create one you can make any nested structure with your pages.

I think Runner H should definitely make updating page permissions a bit easier though, since the way I have to do it in time of writing is to disable the Notion connection and re-give it the correct page permissions.

It also updated the Google Sheet correctly.

A problem was how it struggled with creative content creation (i.e. generating project ideas). Maybe I just prompted poorly. It even made me do it outside the session:

So I'd say overall it's a pass with some adjustments.

Round 5: Putting It All Together

Since it seems to struggle a bit with creative tasks, let's keep it within automation. I also wanted to skip the Google Sheet, as it was redundant. I only did that as part of the previous rounds' requirements.

Here's my goal for this round:

Generate a notion page under in the parent page with the provided ID
Fill that page with a weekly digest of the current ongoing hackathons -- newspaper style
If page already has content, append the new page instead of replacing it

Here's the final prompt:

You are my Weekly Hackathon Digest Agent.

Fetch at least 10 ongoing or upcoming hackathons from:

- Devpost: [https://devpost.com/hackathons?status[]=open](https://devpost.com/hackathons?status%5B%5D=open)
- Dev.to: https://dev.to/challenges

    If there are fewer than 10, include as many as possible.


For each hackathon, collect:

- Name
- Organizer (if available)
- Prompt or challenge summary
- Relevant skills, programming languages, frameworks, services
- Start date and submission deadline
- Platform (Devpost or Dev.to)
- Direct link
- Prizes (if any)
- Number of days left until the deadline

If the deadline is within the next 7 days, add a label like: DEADLINE APPROACHING

Create a new Notion page under the parent page with ID <NOTION PAGE ID>

Name the page: Weekly Hackathon Digest – Week of YYYY-MM-DD

If a page with the same name already exists, add (1), (2), etc. at the end, like Windows file naming.

Inside the page, create properly structured Notion blocks:

- Add a heading block at the top: Weekly Hackathon Digest
- Add today’s date as a text block
- For each hackathon, create:
    - A heading block with the hackathon name
    - Paragraph blocks listing the organizer, prompt, relevant skills, start date and deadline, platform, prizes
    - Add a rich text block with clickable text like: “Link to challenge” using the direct link as the URL
    - If the deadline is within 7 days, add a paragraph block saying: DEADLINE APPROACHING
- Use divider blocks or spacing blocks to separate hackathons clearly
- At the end, add paragraph blocks with:
    - Total number of hackathons listed
    - Number of hackathons with deadlines in the next 7 days

Here's the resulting Notion page:

Pretty great. It used correct formatting (heading, bold text, links, etc.)

I tried using the prompt again to make sure it can append to the Notion page if there was an existing page (the result of the previous prompt). And it works:

Takeaways

After simplifying the prompts and skipping Google Sheet. I actually achieved my final goal of organizing a list of the currently ongoing hackathons/challenges in a weekly digest-style Notion page.

Conclusion

Again, I'd like to reiterate that the results of my experiment are based on my experience and my skill level in prompting. So don't take it as concrete documentation of what Runner H is capable of. Run your own experiments. You can use this article as more of a guideline.

So with that said, here were the results:

Round #1: Fetching Current Data -> ✅✅✅✅✅ I started with a very vague prompt to fetch ongoing hackathons happening at Dev.to and Devpost.com. It mistakenly thought there were no hackathons currently open over on Dev.to, even though it was not the case.

I narrowed down the problem to the fact that Dev.to calls hackathons challenges. This was understandable. A good prompt is needed as much as a capable agent is. So I adjusted the prompt to be more specific by including direct links.

The results were great. And Runner H was even capable of distinguishing between ongoing and finished challenges over in Dev.to, even though they are in the same page.

Round #2: Using Google Sheets -> ✅✅✅☐☐ In this round I messed around with folder creation. This is where I encountered my first assumed limitation.

Again, I encourage you to try it yourself to test if this was an actual limitation. Even if it is, it not too bad. The goal of creating folders in the first place is for organization. But as you'll see on the next round, Runner H is pretty good at file navigation. So in the context of automation, it doesn't impact much.

Creating Google Sheets yielded much better results. There were a couple of mistakes. Most commonly, sometimes table headers are generated in the wrong place, namely at the bottom of the actual rows.

This is rare enough that it didn't really affect my process that much, but if anyone has found a way to consistently generate table headers in Sheet correctly, let me know.

Round #3: File Navigation and Updating Sheet -> ✅✅✅✅✅ I was super pleased with this round. I had a Google Sheet file, and inside that file I had a specifically named Sheet. I wanted Runner H to find that specific sheet in a specific file... and then update it.

First, find the Google Sheet File named “RunnerH”.

Next, find the sheet in that file named “Online Hackathons”

Next, add a column at the end named “Notion Link” and fill the rows with “None”

Here is an example. The results were great and it updated correctly. So full marks in this round.

Round #4: Creating Notion Pages -> ✅✅✅✅☐ Here are some notes about Runner H's Notion integration: Runner H cannot arbitrarily create pages. Meaning you can't just ask it to create a page out of nowhere.

This is not a limitation on Runner H rather in how Notion handles integration.

Runner H can only interact with pages you've given it permission to. So if you prompt that writes into Notion, you'd need to create a base page and give Runner H specific action to that page.

Then in the prompt, you can reference it with the page ID.

In interacting with Notion itself, Runner H does a great job. It could create pages within pages within pages (as long as you have permission for the base page).

If I had to nitpick, though, it's the way Runner H handles updating page permissions. I haven't found a good way to grant access to more pages. I had to constantly disable Notion and re-enable the integration/connection and select the new page.

Round #5: Putting It All Together -> ✅✅✅✅✅

Putting it all together into I final prompt gave me very satisfying results. Here's the workflow: I run the prompt, it APPENDS a new page into my base Notion page, and finally fills it with information about currently ongoing hackathons.

I'm impressed that it appends to existing content so effectively:

How I Used Runner H

Here were the integrations I tested out during my time exploring Runner H:

Notion: for creating and writing into pages
Sheets: compiling data into tables
Surfer H: used a lot in gathering current data
Google Docs: Works pretty much the same as Notion pages

Use Case & Impact

Like I said many times, use this article as a general glimpse of the capabilities and current limitations of Runner H. And take this whole thing with a grain of salt. Hopefully this article inspires you to try Runner H on your own.

The limitations I described above might be circumvented by better prompt engineering.

Blok Tales: A Visual Novel Made with Storyblok

Ansell Maximilian — Thu, 26 Jun 2025 14:52:05 +0000

This is a submission for the Storyblok Challenge

What I Built

Inspired by Ren'Py, a visual novel engine for Python developers, I set out to bring this idea over to the web.

I call it Blok Tales. The general idea was to make making visual novels on the web very easy but still customizable should the need arise.

Storyblok was perfect for this. Storyblok allows me (and other users) to create visual novel scenes that can connect to one another and even branch out based on choices.

Storyblok allows me to ADD, REMOVE, and EDIT content from the comfort of their dashboard AND visual editor. While the headless nature of Storyblok itself allows me to modify the looks through the React application I've created.

If I need to add a scene or a dialog, I can go over to my dashboard and do it there. If I ever decide to create a whole different theme for my visual novel, I can do that too. I'll go over to my React app and change a few classes, shift a few components around, etc.

Basic Story

I want to give a very brief summary of the story I created for demo purposes. It's about a Dev in Webtopia, confronting "The Monolith" a bloated monolithic traditional CMS, which then leads to the discovery of "Storyblock" a lighter, headless alternative.

Demo

Live Visual Novel

You can try out the visual novel live here.

Storyblok Space:

Here is a link to duplicate my space: https://app.storyblok.com/#!/build/342867

OF NOTE: The link doesn't seem to be working for other users. I, the owner, can use this; but I can't figure out how to make this link public. If anyone knows, please let me know in the comments.

Code Repository:

Here's a link to my React app that renders the visual novel content from Storyblok, in case you want to create your own.

https://github.com/AnsellMaximilian/blok-tales

If you'd like to create your own design with themes of your choice, you can clone the repo and connect to your own space. Look at the README file on the repo for instructions.

Demo Video or Screenshots

Here are some snippets of scenes I created with Blok Tales:

Main Menu
Narration
Dialog with Character
Choices

Tech Stack

Here is my tech stack:

React: used to map stories and custom blocks into reusable components
TailwindCSS: used to style components
React Router: used for easily mapping URL paths to story slugs
Framer Motion: used for smooth transitions between dialogs and narrations for each scene

How I Used Storyblok

At its core, Blok Tales is smooth collaboration between my React components and my Storyblok's space, which I've configured specifically to support scene creations.

You can clone my space, or create your own using this schema:

Legend:

The container represents a scene, which is a content type
Blue icons are assets in my Storyblok space
Each white box is a block-type field within a content type (story or another custom block)
Each green block is a custom component

So, to give an example:

I have a scene (story) called "prologue"
The scene has the following:
1. Background: is an asset (image)
2. Music: is also an asset (music)
3. Content: is a block type, meaning it will be comprised of an array of other blocks.
4. Choices: is also a block, containing specifically the choice custom block
Content will have children of the following type: Narration and Dialog
Narration is just a custom block type containing one single block: text
Dialog is a little more complex. It's also a custom block; it also has text. But it has another thing: Character-- yet another custom block.
Character itself... is another custom block, which has the image field for character sprites and name.

As you can see you can create pretty complex schemes using Storyblok.

Storyblok Features Used

I want to use this section to highlight specific features of Storyblok I utilized to realize my vision to make a web based visual novel. And to do that I'll go through what creating a scene looks like. We'll use an actual scene I have in my space; it's called "Confronting The Monolith":

Creating a new content type

In Storyblok, you generate content by making stories, this usually are pages. But you can go further and generate different types of stories. This way you can distinguish between them in terms of how you render them.

For example, I render scene-type stories differently than regular pages. This gives you a huge flexibility and removes any restriction in what types of pages you want to display.

Whitelisting types of blocks to add

The above image shows me creating "content" within scenes. I want to mention a really cool feature that Storyblok provides, which is whitelisting OR limiting what types of custom blocks can be added within a block-type field.

I found this really useful both for establishing tight control over your content as well as to limit the choices when adding blocks so you don't get overwhelmed by block types you KNOW you won't need.

Anyways, for my case, I've limited the content field of my scenes to only include narration and dialog, which are basically just text boxes furthering the story forward. I can't add any other types of blocks there; this way I can be sure there won't be any expected blocks in there that will show up.

Ordering blocks

As I've said, content consists of narration and dialog. You hit right click, it moves the story forward with either a text of narration or a dialog from a character.

I want to mention how useful it was that order of these blocks MATTER. This way, if I ever need to change the order around, I can do that; and it will be reflected in the frontend immediately.

Or if I ever need to add a narration in the middle, I can do that.

Creating presets for characters

As described in the schema, each dialog consists of a character and a text of what the character is saying.

Character is another custom block type.

Another cool feature I want to mention is the ability to create presets. Obviously filling character details for each dialog will be repetitive and slow. But with Storyblok I can actually save a specific instance of a custom block with prefilled fields.

Here I've created all the presets for my characters. This way I can avoid filling the same fields with the same values each time I want my characters to talk more than once.

Creating scene references

At the end of each scene I have choices. These are custom blocks that have the following field: label and next_scene. Label is a regular text field for displaying the choice. But next_scene actually is a reference to another scene.

I want to mention that Storyblok returns only the UUID for each scene by default. To have any meaningful data returned from references you have to establish relations. Read the docs here.

Thanks to the reference block type, I can actually create branching choices and narrative decisions within Blok Tales.

Learnings and Takeaways

I had a ton of fun learning about how to use Storyblok to my advantage to create this visual novel engine.

It honestly surprised me how many features directly supported my vision and how I wanted to implement the visual novel engine.

I had some trouble with asset caching, but other than that everything went dandy!

Image editor

I want to sneak this one in real quick. The image editor is SUPER useful. Sometimes I create the character sprite backwards, and there it was. The "flip horizontally" feature on Storyblok. It saved me a ton of time.

Making Postr: Email-First App with Postmark's Inbound Parsing

Ansell Maximilian — Mon, 09 Jun 2025 01:34:01 +0000

This is a submission for the Postmark Challenge: Inbox Innovators.

Quick Video Demo

What I Built

Postr is a powerful messaging / content creation app built around the idea of email-first interaction, powered by Postmark's very own inbound email parsing feature. Instead of building a third party app where users have to sign up, learn a new UI, and understand an app -- Postr provides an alternative: most of your time using it will be done through email, the most universally understood content/messaging medium on the web.

Users can initiate threads, gather responses, and finally generate beautifully themed AI-powered email responses — all without needing other participants to ever visit the app itself.

This core idea will be useful if you need to collaborate with other people who are not as tech savvy as you or even people who aren't very easy to convince to take their time to learn a new app.

Things Postr Can Create

Postcards are the center of Postr, and a postcard is some form of content generated by a collection of responses by participants who will not be using your app at all. A specific scenario will be explained later to further explain.

Here are the three main forms of content each postcard can take:

Polls/Survey/Group Decision

Prompt participants to decide something as a group. Collect and summarize the responses to arrive at a shared outcome. Great for group planning (e.g., choosing a restaurant, date, or gift).

Tributes/Sentiments

A collaborative tribute where each participant contributes a heartfelt message. Ideal for birthdays, weddings, farewells, or celebrating someone's achievement.

Recap/Memories

Summarizes what everyone shared in response to a prompt — like reflections after a group trip, a retrospective, or how people felt about a recent event or experience.

Demo

Try out the app yourself: https://postmark-postr.vercel.app/

Here's a general workflow of how you would use this app. A more specific/realistic scenario will be mentioned at the end to help you picture it more clearly:

Login/Register

Create Postcard

Start by creating a Postcard entry in Postr. You know your way around new apps, so your group is relying on you to spearhead this.

Fill all the necessary fields such as mood, theme colors, etc. This will affect the final result of the content.

You can also add notes to influence the end result.

Postcard: Waiting for Initial Email

If you click on your postcard on the left, you can view it in detail on the right.

Right now it's in its starting state, waiting for that initial email-- that email where you prompt your participants.

Send Initial Email

You can compose the email manually, just make sure you start your subject with [postcard id] followed by your actual subject and add at least 2 CCs.

But a more convenient way is to just click the "Compose in Gmail" button, which will lead to Gmail's compose view with some prefilled attributes for your convenience.

This is Gmail's compose view. You can take advantage of its features like recipient autocomplete/suggestion.

Postcard: Waiting for Replies

Once you've sent the initial email, your postcard will enter the next stage: waiting for replies.

As you can see, it lists all the CCs that need to reply for you to send the final content email.

Now you just have to wait for your participants to respond.

IMPORTANT: Make sure to let your participants know to "Reply All" to make sure the response gets recorded

Click Send Email Button

Once all participants (CCs) have answered, a button appears. Click the "Send Postcard Email" button. This will take quite a bit, as this is the part where content will be generated.

Postcard: Content Email Generated

Once the email has been generated, you can view it directly in your postcard. But more importantly...

Final Email Sent as Part of the Original Thread

As you can see, the final generated postcard content email has been sent to you and all the participants.

Even better, it has been sent as part of the original thread. So all history of your conversation can be seen in one place.

Code Repository

GitHub Repo

How I Built It

Postr was built in Next.js with Tailwind CSS, TypeScript, Appwrite, AI email generation, and of course Postmark. But the core magic lies in how I integrated Postmark’s inbound email parsing to make email not just a feature, but the central interface.

✨ Inbound Email Parsing as the Core

Postmark allows you to set up an inbound email address (like anything@inbound.postr.app). Any email sent to that address gets parsed into a clean JSON payload that includes:

Sender, recipient, subject
Cleaned HTML and plaintext body
Attachments
Headers (e.g. In-Reply-To, References, Message-ID)

This lets Postr:
-Create new postcards based on the first inbound email
-Track threads and replies by matching headers
-Update the postcard in real-time based on replies
-Generate a final AI-crafted email that is sent to all participants

📨 Sending Final Content Email Postcard with Postmark's API

Of course, I needed to send the final generated content postcard to all the users. Postmark makes this easy with the /email endpoint. You can learn more about it here.

I want to keep everything centralized and connected. All the replies will already be threaded automatically, but I needed to make sure that the final email also gets sent as part of the original thread.

For replies, users just need to click “Reply All” in their email client, it will handle the rest. This means only one participant ever needs to open Postr to contribute.

ButI still need to think about the final email and how to connect it to the original thread. Here's how I did it:

🧵 Threading with Email Headers

One of the biggest features I leaned on is threading. Postmark gives you access to the Message-ID of parsed emails, and from there I use the In-Reply-To and References headers when sending the final reply.

But that's not everything you need for including an email in a thread. You also need to set the subject in this format Re: <original subject. Luckily Postmark's inbound parsing also includes the subject (obviously).

So what you send to Postmark's outbound API should look like this:

curl --location 'https://api.postmarkapp.com/email' \
--header 'Accept: application/json' \
--header 'Content-Type: application/json' \
--header 'X-Postmark-Server-Token: <YOUR_SERVER_TOKEN>' \
--data-raw '{
  "From": "your@email.com",
  "To": "receiver@email.com",
  "Subject": "Re: <ORIGINAL_SUBJECT>,
  "TextBody": "Text body content",
  "HtmlBody": "<html><body><strong>HTML BODY</strong>.</body></html>",
  "MessageStream": "outbound",
  "Headers": [
    {
      "Name": "In-Reply-To",
      "Value": "<ORIGINAL_EMAIL_MESSAGE_ID>"
    },
    {
      "Name": "References",
      "Value": "<ORIGINAL_EMAIL_MESSAGE_ID>"
    }
  ]
}'

IMPORTANT: <ORIGINAL_EMAIL_MESSAGE_ID> should come from the original email's Headers property (Message-ID), not MessageID in the root level. You can get this when parsing the original email

For more info on how to thread with Postmark, here's a blog by Postmark. This is what I used and it was very useful in understanding threading.

🏖️ EXAMPLE: The Family Trip Scenario

Let’s say you want to plan a family trip. You use Postr to create a new postcard of type "Group Decision," and add a note to theme the postcard around "Love". Once created, Postr generates an initial email draft you can send via Gmail to your family, with two or more CCs.

The family members receive that email in their regular inboxes and simply reply with their preferences.

One cousin says: "Let’s go to Disneyland!"
Another replies: "SeaWorld could work, but honestly, Disneyland sounds fun."

As soon as all CCs reply, Postr updates the postcard and enables you to trigger the final postcard creation — a beautiful, expressive, HTML-formatted email generated by AI based on the group’s responses.

It gets sent back to all participants in the same thread, thanks to the headers and threading. From start to finish, the entire flow happened over email — no app downloads, no learning curve.

Here's the generated content:

Conclusion

Postr was built to demonstrate how inbound email can be a first-class user interface. Postmark made that not just possible but joyful to work with. It's fast, reliable, and delightfully simple to use. I can't wait to keep building with it.

PermiShout: Recreating Twitter with Access Control using Permit.io

Ansell Maximilian — Mon, 05 May 2025 02:56:41 +0000

This is a submission for the Permit.io Authorization Challenge: Permissions Redefined

If you want to immediately get setup. Follow the instructions at https://github.com/AnsellMaximilian/permishout

What I Built

For this challenge, I decided to recreate Twitter/X, complete with access control. It's called PermiShout. Where a Shout is like a Tweet or post. I thought this would be perfect to show off Permit.io's base capabilities.

Here's the app workflow:

Home Page

Login/Signup

Complete Profile

Create Shout

Look at Profile

Follow/Unfollow

Reply to and Delete Shouts

As you can see some shouts are different than others. Some have a delete button -- that's because Permit.io has determined that the current user has the authorization to do that.

Some reply buttons are disabled and some are not. That's also Permit.io doing the work. Here's some conditions that has been set up for a user to be able to reply:

If the shout reply mode is set to "everyone" then any one can reply
If the shout reply mode has been set to "verified accounts only" then only "admins" can reply
If the shout reply mode has been set to "people mentioned" then only people mentioned will be able to reply
Everyone the user is following can reply

Demo

Project Repo

Check out the repo here

My Journey

I have to say it wasn't easy learning all the necessary topics about Permit.io. It is definitely robust and full of features you would expect from an access control library.

But will say that one of the most frustrating but intriguing part was learning about integrating Permit.io on the frontend using the permit-fe-sdk.

I finally got it to work, and it's definitely one of my favorite parts of Permit.io. And I got a custom reusable context provider out of this to use for future projects using Permit.io. Custom Permission Context Provider

Overall, this was my first time using a third party access control service and from what I've seen it's very robust and complete.

In my head I keep comparing it with the ease of access control/authorization in Laravel. Which is great! It's one of the main reasons I love using Laravel even though NextJs is my favorite framework.

Using Permit.io for Authorization

The way I'm going to structure this section is by going through the development as if I'm developing Permishout from scratch. Letting you know what decisions need to be made while developing with Permit.io. This way, you'll be able to apply my journey into your own while developing your own apps with Permit.io.

Here are a bunch of things that I want to highlight:

Planning and Setting Up
Syncing Users
Doing checks in the backend
Using permit-fe-sdk for easily displaying things based on access control

Planning and Setting Up

User Stories

So first I want to identify user stories that I want for this app:

User authentication.
Authenticated users have profile
All authenticated users will be able to create any shout and also view it
The shouter (poster/author) of a shout will be able to delete and reply to it.
Users with the role admin will be able to delete any shout
Authenticated users can follow/unfollow each other.
In Twitter/X you can set which users will be able to reply to your Tweet/Post. I want to emulate this feature, as it will show off a lot of the capabilities in Permit.io. Here's how Twitter/X handles it:
1. Everyone: everyone can reply to a shout
2. People mentioned: only people mentioned in a shout can reply.
3. People you follow: only people you follow can reply. However to demonstrate "role derivations", I'm going to make it so people you follow can always reply to any of your shouts.
4. Verified users only: For PermiShout, it's going to be people with admin roles.

Identifying Components

Now that we have our user stories, we can start identifying Permit.io components we are going to need.

Here's what I got:

Roles:
admin
Resources:
profile
This resource will just be an anchor point of many of the functionalities I'm going to implement. It's not going to hold any attributes, but it will help me identify followers/following as well as role derivations. This will be explained later.
shout
Resource instance roles:
Just a little explanation on what instance roles are: Admin would be a Top Level Role, where authorizations on it will be applied to every instance of a resource. So if an Admin has delete access to a shout, it will have that on every one.

An instance role, however, only applies to a single instance of a resource type. Here's how Permit.io structures it: resource:resource_key#role, meaning actions available to the role owner will only apply to resource with the key resource_key.

Here are the roles I have identified:

profile#owner Just the owner of a profile. Just like Twitter having you complete some data before you can Tweet.
profile#follower
profile#followed
shout#shouter: can reply and delete a shout
shout#replier: can reply to a shout This will be an important role. Since I'm going to let people you follow have the ability to reply. I will derive this from the roleprofile#followed.
shout#mentioned

Setting Up

There are a bunch of ways of setting this up. The README.md of my repo will explain it thoroughly, but I'll be brief here and just explain things that might be hard to grasp at first. We'll be using this permit object below. Remember to not use this on the frontend.

import { Permit } from "permitio";
const permit = new Permit({
  token: process.env.PERMIT_SDK_KEY,
  pdp: process.env.PERMIT_PDP_URL,
  apiUrl: process.env.PERMIT_API_URL || "https://api.permit.io",
});

export default permit;

Here's how you would programmatically create an admin role:

await permit.api.createRole({
    key: "admin",
    name: "Admin",
    permissions: ["shout:delete"],
  });

Just a note, here's the syntax for permissions: resource#action. This is basically saying, "Hey, create an admin role, which will be able to do delete on shouts. Since this is a top level role, it will apply to all instances of shouts.

Here's how you create a shout resource, along with its available instance roles:

await permit.api.createResource({
    key: "shout",
    name: "shout",
    actions: {
      delete: {},
      reply: {},
    },
    // Resource roles are used to define the permissions for each role on the resource
    roles: {
      shouter: {
        name: "Shouter",
        permissions: ["delete", "reply"],
      },
      replier: {
        name: "Replier",
        permissions: ["read", "reply"],
      },
      mentioned: {
        name: "Mentioned",
        permissions: ["read", "reply"],
      },
    },

As you can see I've created 3 unique roles here. Even though they have the same permissions, I've decided to separate them just in case I need to add more actions. Basically this code says "Hey, I want to create a resource called 'shout'. It can have 2 actions performed on it: delete and reply. A user can be a replier, mentioned, and a shouter. All 3 of which will be able to perform all available actions.

Here's how you would create a relationship between resources. This is very important. Role derivations are extremely powerful, and relations are needed for it.

await permit.api.resourceRelations.create("shout", {
    key: "parent",
    name: "Parent",
    subject_resource: "profile",
  });

The above snippet basically is saying, "Hey, create a relation for shout. The subject of this relationship is profile. I want profiles to be parents of shouts."

I got confused by this at first, so I'll try to explain it just in case you are too. Basically, imagine in your head what relationship between two resources do you want to have.

Here we have shout and profile. We'll I want to connect these as such that a profile will have many instances of shout. Let's go with "Profile is the parent of shouts".

subject_resource is the name of first parameter of create

Above is how it would translate to parameters.

IMPORANT: the name parameter can be anything. It doesn't even have to realistically describe the relationship (but it should). So I could've put owns as the name parameter just the same.

Finally, creating resource derivations. I want EVERYONE who follows a user to be able to reply to all their shouts. So, let's derive profile#followed to shout#replier.

IMPORANT: relationships are integral to derivative relationships. The above rule I want to implement means that users will have the shout#replier role ONLY if he has profile#followed on a profile AND if that profile is a parent of the shout in question.

Here's how I created that derivation in code:

await permit.api.resourceRoles.update("shout", "replier", {
    granted_to: {
      users_with_role: [
        {
          linked_by_relation: "parent",
          on_resource: "profile",
          role: "followed",
        },
      ],
    },
  });

Pretty simple. This is basically saying, "Hey, update this shout#replier role you created earlier and grant this role to users with the followed role on a profile. And only grant this replier role IF the profile has a parent relationship with the shout in question"

Syncing Users

Obviously permit.io doesn't manage your authentication. You will need a your own or a one from a third party. Like Clerk. However, this does not mean you can neglect managing users in permit.io.

Permit.io doesn't automatically know your users from your authentication system. Let's use Clerk for example as that's the library I'm using in my app.

After you've created your user in Clerk. You need also create them in Permit.io. You can do this in your login/signup logic, or you can create a separate process entirely. You know how in Twitter/X, after you sign up with your email or Google account, you still have to fill up things like username, name, etc? I'm going to take this opportunity to sync my users to permit.io

So, if a user has logged in using Clerk, and there isn't a matching entry in Permit.io, I'm going to force them to complete their profile.

Middleware in NextJs

export default clerkMiddleware(async (auth, req) => {
  const userId = (await auth()).userId;
  const { origin, pathname } = req.nextUrl;

  if (isProtectedRoute(req)) await auth.protect();

  // get project_id and environment_id
  const { project_id, environment_id } = await permitApi
    .get("/v2/api-key/scope")
    .then((res) => res.data);

  // check if user's profile is complete (based on their existence in Permit)
  let isProfileComplete = false;

  try {
    await permitApi.get(
      `/v2/facts/${project_id}/${environment_id}/users/${userId}`
    );
    isProfileComplete = true;
  } catch {
    isProfileComplete = false;
  }

  // if it's a public route, the user is signed in and the profile is complete, redirect to home
  if (isPublicRoute(req) && isProfileComplete)
    return NextResponse.redirect(`${origin}/home`);

  // if the user has not completed their profile and is trying to access a protected route, redirect to profile creation page
  if (
    !isProfileComplete &&
    isProtectedRoute(req) &&
    !pathname.startsWith("/profile/create")
  ) {
    return NextResponse.redirect(`${origin}/profile/create`);
  }
});

Here's a snippet of my middleware. This will run on most pages you go to on PermiShout. Basically, what it does is this:

Get the currently logged in user's id using (await auth()).userId
If the user has not even registered or signed in to Clerk, we can just protect our protected routes with await auth.protect()
If the user has been authenticated (by clerk), we check if they have a matching entry in permit.io We check this by using the following code:

// note that `permitApi` is just an instance of `axios`
await permitApi.get(
      `/v2/facts/${project_id}/${environment_id}/users/${userId}`
    );

If that api call succeeds, that means the user has a matching user in Permit.io. We're good. The user can access any protected and non public-only routes.
IF the api call fails, that means the user has no matching user. Permit.io doesn't know about this user. Now we force the user to go to the /profile/create route. Where I will be forcing them to create an account.

Now after filling in some info, mainly username, name, country, and year born, we handle

SYNCING USERS

in the backend or a route handler as we're using NextJS.

const POST = async (request: NextRequest) => {
  const { userId } = getAuth(request) || "";
  const user = await clerkClient.users.getUser(userId || "");
  const { username, name, yearBorn, country } = await request.json();

  const { firstName, lastName } = splitName(name);
  await clerkClient.users.updateUser(userId || "", {
    firstName,
    lastName,
  });

  const { key: createdUser } = await permit.api.syncUser({
    key: userId || "",
    first_name: firstName,
    last_name: lastName,
    email: user?.emailAddresses[0].emailAddress || "",
    attributes: {
      username,
      yearBorn: parseInt(yearBorn),
      country,
    },
  });

  await permit.api.roleAssignments.assign({
    user: createdUser,
    role: "owner",
    resource_instance: `profile:profile_${createdUser}`,
    tenant: "default",
  });

  return NextResponse.json({
    success: true,
  });
};

I'll explain a little bit what's happening here:

First, we get the currently authenticated user from Clerk (reminder that this is not a user from Permit.io -- That's what we're here for!)
Then we get all the extra attributes we want to put in Permit.io
Then--and Permit.io makes this REALLY easy for us-- we do permit.api.syncUser. Remember to match the user key for Permit.io with the id of your Clerk user. You don't necessarily have to match it, but it will be infinitely HARDER if you don't. For example, if you decide to use only the first 10 characters of your Clerk id, you will need to get those first 10 every time you reference your Permit.io user.

You can also add email, first_name, and last_name. This will also be your opportunity to add any extra attributes.

Note: I said Permit.io makes this REALLY easy because you don't have to differentiate between an existing user and one that hasn't been created. syncUser will handle it. If it exists, it will overwrite it (sync it), and if it doesn't, it will create it.

Now, since I have the profile resource set up. I want to also associate each user with one. So that's where this line is for:

await permit.api.roleAssignments.assign({
    user: createdUser,
    role: "owner",
    resource_instance: `profile:profile_${createdUser}`,
    tenant: "default",
  });

What this code does two-fold. First, it creates a resource instance of profile with the key profile_${created_user_key}. Something important to remember is that resource_instance has to be a string in the format resource:instance_key.

Secondly, this code also assigns a role to user with the createdUser key and assigns a role owner to it (the profile instance).

So now, this particular user is officially the owner of their profile and all the access control that comes with that instance role on that particular profile as well as any role derivations.

I just wanted to mention this because making role assignment and instance created in one function is really neat!

Doing Checks

An important thing to note is that checks should always be done, as in you will need to query them. Permit.io doesn't know about your code and what you're doing, they just make writing the code for checking permissions way easier. Here's an example check I do whenever a user is deleting a shout.

const isUserAllowedToDelete = await permit.check(userId || "", "delete", {
      type: "shout",
      key: shout.key,
    });

Really simple isn't it? Instead of checking multiple ALL the scenarios where a user will be allowed to delete a particular shout, we just ask Permit.io! Here, it will return true if user is an admin or if user is the owner of the shout.

These two conditions are simple. But imagine if you have multiple unique ones you have to keep track of. Imagine if a user can also be a low level moderator to delete. You have to write that check and add them to ALL parts of your code who need the check.

Anyway, if isUserAllowedToDelete is true, we proceed to delete the instance using this:

await permit.api.resourceInstances.delete(`shout:${shout.key}`);

Easy!

Using `permit-fe-sdk`

This is my favorite part. Honestly figuring out how the whole thing works felt great! Basically, this library helps you in the front end in determining whether or not a user is allowed to do something.

A similar concept exists in Laravel's blade directives:

@can('update', $post)
  <button>Delete</button>
@endcan

When Permit.io works with CASL, you can achieve the same function. But this time this is all happening in the frontend -- SAFELY!

Here are the steps. These were really hard for me to grasp and figure out, so hopefully I can explain it well:

Install the necessary packages

npm install @casl/ability @casl/react permit-fe-sdk permitio

Create a POST route handler where the permit-fe-sdk will be calling for permission checks.

Based on my own research, you want to create POST routes if you're trying to get bulk permissions. Meaning, you check for many permissions at once.

Here's mine (I'll be focusing on bulk permissions):

export async function POST(req: NextRequest) {
  try {
    const { searchParams } = req.nextUrl;
    const userId = searchParams.get("user");

    const { resourcesAndActions } = await req.json();

    if (!userId) {
      return NextResponse.json(
        { error: "No userId provided." },
        { status: 400 }
      );
    }

    const checkPermissions = async (resourceAndAction: {
      resource: string;
      action: string;
      userAttributes?: PermishoutUserAttributes;
      resourceAttributes?: Record<string, any>;
    }) => {
      const { resource, action, userAttributes, resourceAttributes } =
        resourceAndAction;

      const [resourceType, resourceKey] = resource.split(":");

      return permit.check(
        {
          key: userId,
          attributes: userAttributes,
        },
        action,
        {
          type: resourceType,
          key: resourceKey,
          attributes: resourceAttributes,
          tenant: "default",
        }
      );
    };

    const permittedList = await Promise.all(
      resourcesAndActions.map(checkPermissions)
    );

    return NextResponse.json({ permittedList }, { status: 200 });
  } catch (error) {
    console.error("Permission check error:", error);
    return NextResponse.json(
      { error: "Internal Server Error" },
      { status: 500 }
    );
  }
}

I find it useful to mention the end goal of this route. It's basically to return an object with permittedList as an array of booleans. Now you could easily just return a list of 100 trues and you'd pass all the check. But that's not what we're here for right?

We'll get to the frontend a little later, but basically we want to map resourcesAndActions to permission results. This variable will be an array of resources and actions queried from the frontend.

Each array element will have resouce, action, userAttributes and resourceAttributes. You'll want to accurately test for these permissions.

IMPORTANT: notice that I split the resource and resource key? This is because you supply them from the frontend in this format resource:resource_key. And you get it in this route as is, so you have to manually split it and then put the resource in type and the key in key. This stumped me for a while.

Okay so based on all the actions and resources we do permit.check so it will return the boolean array in the correct order.

IMPORTANT: Remember that order is very very important. You can't just be randomly doing permitionList.reverse(). The frontend wouldn't be accurate anymore in determining permissions.

Okay so we have return that list of booleans. Now what?

Setup the frontend to be able to use that route

const defaultActionResources: ActionResourceSchema[] = [
  {
    action: "delete",
    resource: "shout",
  },
];

export const AbilityContext = createContext<
  | {
      ability: Ability<AbilityTuple, MongoQuery>;
      setActionResources: React.Dispatch<
        React.SetStateAction<ActionResourceSchema[]>
      >;
    }
  | undefined
>(undefined);

export const useAbility = () => {
  const ability = useContext(AbilityContext);
  if (!ability) {
    throw new Error("useAbility must be used within an AbilityProvider");
  }
  return ability;
};

export const AbilityLoader = ({ children }: { children: ReactNode }) => {
  const { isSignedIn, user } = useUser();
  const [ability, setAbility] = useState<Ability<AbilityTuple, MongoQuery>>(
    new Ability()
  );
  const [actionResources, setActionResources] = useState<
    ActionResourceSchema[]
  >(defaultActionResources);

  useEffect(() => {
    (async () => {
      // reset it first
      setAbility(new Ability());

      if (isSignedIn) {
        const permit = Permit({
          loggedInUser: user.id,
          backendUrl: "/api/permit/check",
        });

        permit?.reset();

        const allActionResources = [
          ...actionResources,
          ...defaultActionResources,
        ];

        await permit.loadLocalStateBulk(allActionResources);

        const caslConfig = permitState.getCaslJson();

        const caslAbility =
          caslConfig && caslConfig.length
            ? new Ability(caslConfig)
            : new Ability();
        setAbility(caslAbility);
      }
    })();
  }, [isSignedIn, user, actionResources]);

  return (
    <AbilityContext.Provider value={{ ability, setActionResources }}>
      {children}
    </AbilityContext.Provider>
  );
};

Basically we want to provide an Ability object throughout the whole app. I'm using Context.Provider for this.

Remember actions and resources from the route? That maps directly to the ones in this context provider.

IMPORTANT: The check you will be able to do directly corresponds to what you supply to await permit.loadLocalStateBulk(allActionResources). If you supply it with one pair of resource and action, it will not be able to accurately check for others.

I have created a local state called actionResources, which will cause the useEffect to update and load the local state with the latest permission.

I have some default permissions I will always want to check: admin permissions. That's why I have some default action resources.

IMPORTANT: Make sure to reset it also. I've found problems if I just call loadLocalStateBulk over and over.

That's it! Just make sure you update the ability variable with the most recent permissions. Now you can use useAbility to get that ability and perform checks.

Actually using it in the frontend Let's focus on shout permissions. Admin will always be able to delete shouts so let's put that in the default array.

Now, shouts need fine-grained control as there are roles and permissions exclusive to single instances of shout.

Here's how how handled it. Remember that I exposed setActionResources in that provider and that if that array is updated, it will update local permissions. We'll that's what I'm going to do in the home page.

const { setActionResources } = useAbility();


useEffect(() => {
    const shoutActions: ActionResourceSchema[] = shouts.flatMap((shout) => 
    [
      { action: "reply", resource: `shout:${shout.key}` },
      { action: "delete", resource: `shout:${shout.key}` },
    ]);

    setActionResources(shoutActions);
  }, [shouts, setActionResources]);

That's it. This will update all our permission in the frontend so we can use them. In each shout I want to have a delete button for users who have the permission. I can use the Can component from CASL:

import { Can } from "@casl/react";

<Can I="delete" a={`shout:${shout.key}`} ability={ability}>
 <Button
  style={{ padding: 0 }}
  variant="ghost"
  className="flex items-center gap-1 text-red-400 hover:text-red-500 ml-auto"
  onClick={(e) => {
   e.stopPropagation();
   if (setShoutToDeleteKey) setShoutToDeleteKey(shout.key);
  }}
 >
   <Trash size={16} />
   <span>Delete</span>
  </Button>
</Can>

That's it. That's all I need to do. Just supply it with the action and the resource as well as the ability object I mentioned.

You can also do a standard inline check like this:

import { permitState } from "permit-fe-sdk";
const canReply =
    shout.replyMode === ShoutReplyType.EVERYONE ||
    permitState?.check("reply", `shout:${shout.key}`, {});

Conclusion

Sorry for the tangent. I was super excited getting this working on my own, especially the front end sdk. Hopefully they will keep working on it because I love Laravel blade directives. And this is exactly that in React!

Dev Dash - Recreating Dev.to with Kendo React

Ansell Maximilian — Sun, 23 Mar 2025 12:15:03 +0000

This is a submission for the KendoReact Free Components Challenge.

What I Built

When scrolling through the Kendo React docs, I thought this component list would be perfect for an app that focuses on data. Dev.to just so happens to provide an API for me to fetch its data. And I thought it would be fitting, given where this challenge is happening.

So, I built Dev Dash. It's basically a simple redesign version of Dev.to, but I also attempted to extend it with some unique features not present in the original website, with the help of Kendo React. I was however limited by the API itself.

You would login, submit a Dev.to API key, which you could find here. Then, you'll be able to use Dev Dash's features, which are:

Dashboard

Here, you'll see a some basic data about the currently authenticated Dev user (through the API key), like name, username, profile picture, etc. There's even a countdown to your next birthday celebrating when you joined Dev.to.

Here's where Kendo React will do the heavy lifting. I've arranged the dashboard in what's called a TileLayout. It's super cool! With just a little bit of setup, you can have a layout composed of tiles which you can rearrange and even resize.

I added to this by automatically saving the arrangement of the dashboard every time a change happens. So that when you go back to this later, it will remember your setup and you won't have to rearrange and resize the tiles.

Feed

This is just your regular feed, as seen in the original Dev.to site, with a couple easy filtering features, by username or by tags.

The star in my opinion is the Card component. I didn't have to much. I just plopped <Card/> along with its accompanying components such as <CardHeader/> and <CardFooter/>.

Your Posts

Here you'll see your posts, published or unpublished. I use Data Grid along with a Pager for pagination.

Here you'll view a paginated list of your posts and you'll also be able to pin your favorite uploads, which then will be displayed in your dashboard.

Now, Data Grid is available in the free tier. But there are many premium features you can add to with with a license. I actually used one particular premium feature just for comparison. And that feature is custom cell renderer. I use this to insert a "pin" button into a column for each row.

Library Feature

This section is where I extend upon what's already available through Dev.to by allowing users to organize their reading list by "library sections", identified by color and name.

I use the ColorPalette component so the user can choose from a list of colors and create a library section for you to put your reading list items in.

Demo

Live App

Repository

KendoReact Experience

Overall I really enjoyed recreating and extending Dev.to using Kendo React. I probably worked on this for about a week. And while there are a lot of things that I to implement that I didn't get to deploy, I feel like I did a lot in the timeframe I developed in.

It's definitely thanks to the very complete list of ready free components by Kendo React. I was expecting the free tier to be less extensive to be honest but was very pleasantly surprised.

I would also like to mention how easy it was switch themes. First I used the default, then I opted for Bootstrap. All it took was changing one line.

Here are the list of free components and how I used them (as well as how I feel about them):

Buttons

Of course we have buttons. I used these all over the place. Here's some unique features that I used that I really liked:

Toggleable buttons
Easily adding icons into a button by just supplying a prop into the component without worrying of putting classes for flex, etc.
Separating themeColor (primary, secondary, etc.) and fillMode (flat, outline, etc.)

Loader

I also used these everywhere. I like it. I used the large version when loading a whole page and the small version to load independent components within a page.

SvgIcon

This was really useful. There's a whole lot of icons available as SVGs. It could be expanded, but 95% of my icon needs I got from this.

TextBox

Kendo React provides a lot of versions of text inputs; however I got all I needed from TextBox.

AppBar

I love the associated AppBarSpacer component. It's really useful for arranging your AppBar without much work.

Drawer

This is really useful for navigation. The setup is easy. And of course: I like that I don't have to do much to achieve a collapsible sidebar!

Avatar

Standard avatar component. I didn't use any of the special properties Kendo React provided, but it was good enough to display the user's profile picture at the end of the AppBar.

Popup

I used this for showing extra info as well as a logout button when a user clicks on their avatar on the app bar.

Again, the it serves its purpose because I don't want to have to deal with anchoring things in elements; and this allowed me to avoid exactly that. That's always a plus.

Card

Standard card component with its associated child components such as CardHeader and CardFooter made it easy to display posts and related info.

TileLayout

This is by far my favorite component that I discovered while developing this application.

Using a tile layout you can separate your display into multiple tiles, and each individual tile can be rearranged and resized. I took it even further by allowing users to save their configuration in the cloud.

I think this makes configurable dashboards really easy.

Autocomplete

Standard auto complete component. No complaints.

Skeleton

Same with the skeleton components. Though I did notice there were a lot of variations, so that's a +.

ColorPalette

There are many available color input components. This is the one I chose. Simple. I like it.

Dialog

Standard dialog. No complaints.

Data Grid

The free version I think is good enough. I used a custom cell renderer, which was a premium function.

Pager

Free pagination tools. Cool!

TabStrip

Tab layout. No complaints.

Cycle Doodle - Web Game Powered by DevCycle

Ansell Maximilian — Sun, 15 Dec 2024 12:38:53 +0000

This is a submission for the DevCycle Feature Flag Challenge: Feature Flag Funhouse

What I Built

I built a little game called Cycle Doodle for this challenge. Here's a little background on how I came up with this web game:

This dev challenge called for us to explore the capabilities of DevCycle and what it can do for our apps. So, I thought I would further challenge myself in building this app by exclusively utilizing only DevCycle's services/features. So besides a frontend framework, which will be NextJs for this, I won't be using any other external third party services like a database, socket, etc.

Cycle Doodle is a simple web game in which you'll join one of three teams and then either draw a simple prompt on a grid with simple colors, guess what other teams have drawn, or vote/rate those other teams' drawings.

Your team will cycle through these roles every time a member of a team does one of these actions (draw, guess, vote), hence the name "Cycle Doodle".

To encourage users to choose their teams, each team will have a distinct advantage over the other:

Grid Goblins: Other teams get 100 cells in a grid, while this one gets 144, allowing for more details.
Edit Emperors: Unlike other teams, this one can edit and draw over colored cells in the grid.
Paint Paladins: Other teams get 5 colors to pain their cells, while this team gets 10.

Then users can view the gallery to see all the drawings by all the teams. The separation and advantages will allow us to see the difference in drawing quality and creativity between all the teams given a different set of tools.

A few chosen users (myself) can act as admins to edit the list of possible prompts.

How DevCycle Was Used

Assigning Users to Teams (Audience)

DevCycle allows you to create user groups called Audiences. I thought this would be perfect feature to use for my team assignment feature. This not only allows me to group each user to a different team, but also serve values differently based on what group a user is in. This will be useful in differentiating each team by their advantages.

As you can see, besides "Admin", I have three separate audiences denoting which team a user could belong too.

Then, I also made a Feature to serve certain values based on which team a user is on.

I have also made 3 different configurations for a variable within that feature. Further, I set the targeting rules as such that different audiences will get served different values. Luckily for me, DevCycle allows for the serving of many kinds of values, like JSON. For example, Grid Goblins will get:

{
  "gridSize": 100,
  "canEdit": false,
  "colors": [// colors]
}

Now, how do I actually assign these users to their chosen teams without having to go to the DevCycle dashboard each time a user chooses? Fortunately, DevCycle provides a very complete list of APIs that I can use. One of those allows me to update/create audiences.

So, since I'm already using NextJS, I can use its route handlers to securely call the the api to update which users belong in which audience.

Cycling Team Roles

Now that there are dedicated audiences for certain teams, I can reuse this as much as I want. Including in this little feature of the game. As I've mentioned, each time will have a different role, namely, Drawer, Guesser, and Voter; each time a user does a particular action for their role, the teams' roles will shift.

Well, the way I did this is the same as before -- with a feature. I made another feature called "Team Role". And instead of JSON, I will serve different strings for different Audiences. For example, at one point in time, Edit Emperors will be served guesser, Grid Goblins will be served drawer, etc.

Now, for shifting the roles, I did a similar thing as the assigning of teams. APIs! Again, DevCycle generously provided me with the perfect API. By hitting this endpoint, I can programmatically and dynamically cycle the roles of the teams.

Real Time Updates

DevCycle provides real time updates to their feature variables. So, right after I cycle through the team roles through the API, I don't even have to manually update it on the frontend. DevCycle will give the most recent value and the app will automatically pick up on the change and update it.

Saving, Fetching, and Updating Prompts

I mentioned in the beginning that I challenged myself to not use any external services like databases. Well, I didn't. But how do I store the prompts, drawings, guesses, etc. persistently and share it across all users? Well, Features to the rescue again!

Unlike the other features before, I will serve this variable to all users so they all have access to it.

Drawing

When your team currently has the "Drawer" role, this is what you will see. Simply fill up the grid with the colors you have and submit it. This will hit another different API provided by DevCycle, which is the update feature API.

I simply hit this API to update the "prompts" feature variable with how the user has drawn in the grid. Then I also cycle the team roles.

Guessing

When your team currently has the "Guesser" role, this is what you will see. Try to guess what this other team has drawn.

Voting/Scoring

When your team currently has the "Voter" role, this is what you will see. Rate the drawing from 1 through 5.

Gallery

Users can also view prompts in the gallery. See how other teams drew their prompts and see if it was guessed correctly.

Authorization

This I can see being a very important use case for DevCycle. Permissions/Authorizations. I've established that users can draw, guess, and vote on prompts.

But I want to be able to add/delete/update those prompts as well. And I can't just let any user be able to do that. What do I do to make special privileges on certain users (myself)? Because I don't want to have to update the JSON every time I want to update a prompt.

Feature and Audience are a great duo, and they've come to the rescue again. What I've done is created a special Audience and included only myself as the sole member.

I've also created yet another feature called "Is Admin". It's a boolean feature, and I serve true only to members in the Admin Audience.

This way I can determine which content to render and which action to allow based on the served value. For example:

export default async function AdminPage() {
  const isAdmin = await getVariableValue("is-admin", false);

  if (!isAdmin)
    return (
      <div className="flex flex-col justify-center items-center py-16">
        <Image src={logo} width={200} height={200} alt="logo" />
        <h1 className="text-3xl font-bold mt-16">Access Denied</h1>
        <p>You need to be an admin to access this page.</p>
      </div>
    );

  return (
    <div>
      <PlayContextProvider>
        <AdminControl />
      </PlayContextProvider>
    </div>
  );
}

Here's the gallery when viewed as an admin. There's a create button on the bottom right and a delete button for each prompt:

Demo

Here's a little demo video for my app:

Here's the live app:
https://cycle-doodle.vercel.app/

Screenshots of the application flow can be viewed above.

My Code

Here's my code repository:
https://github.com/AnsellMaximilian/cycle-doodle

My DevCycle Experience

It was my first time using a Feature Flag service, and I have to say it is pretty great.

I especially like the ability to define audiences. I also love the fact that you can serve many different kinds of values. I know being able to serve JSON values allow me to develop this whacky app without a database, but I really believe it will be useful beyond that; rendering/launching features based on more complex values other than on/off for real applications.

I also love that it provides real time updates. Really saved me from some headaches in the frontend.

Targeting rules and the fact that you can rank the order of precedence is also REALLY cool.

I also bet there will be a lot of useful custom software/extensions made for DevCycle thanks to the provided API. Maybe some in-house solution to integrate DevCycle in people's or companies' own platforms.

Additional Prize Categories

My submission also qualifies for "API All-Star", as it's a major part of the application. I use the APIs extensively: updating audience targeting rules, cycling team roles by updating a feature's targeting rules by audience IDs, updating feature variables, and so on.

Break-Time: Digital Time Capsules with Pinata

Ansell Maximilian — Mon, 14 Oct 2024 04:18:43 +0000

This is a submission for the The Pinata Challenge

Quick Links

What I Built

A lot of our footprint we leave in this world are increasingly becoming digital. I won't argue whether that's a bad or good thing, but I will say that our footprint, our memories, that we leave is important regardless if it's digital or physical.

That's why I decided to build Break Time. Break Time is a web app where you can make digital time capsules, store your digital memories, and then open them at a later date to look back on those fond memories so they aren't lost.

I call the time capsules Pinatas, named after the service used to make this app happen (Pinata). But I also decided with this term because it's apt for what it represents, a container with valuables and goodies (memories) inside which you can access by opening said container.

Example Usage

Here I'll give a quick overview of how you would use this app (I'll go into detail in a later section).

Let's say your best friend, John, and your other best friend, Jill, is about to get married in a few weeks. You get the great idea to start storing memories of the upcoming marriage ceremony up to their 5th anniversary (you're confident they love each other deeply and will last forever).

You start thinking of creating a time capsule to store those memories and then let them open it at the start of their 5th anniversary to look back on their fond memories.

However, you realize that even now most of your memories with them are digital (videos, photos, PDFs, SVGs, etc.). And you suspect it will be the same case with their marriage, considering it's 2024.

So you decide to use Break Time. You create an account, encourage your circle of friends, including Jill and John themselves to create their own accounts. You invite them to be your friends in the app.

Then, you create a Pinata (Time Capsule). You name it "John and Jill's 5th Anniversary", you create some description, such as "Hi friends! 🌸 Let’s celebrate the love John and Jill will have built over the next five years by capturing memories, well-wishes, and hopes for their future. When we unlock this capsule later, we’ll look back, laugh, and cherish how far they’ve come. Leave your messages, photos, or videos and help make this anniversary truly unforgettable!". You might even add a little thumbnail of their first date.

Next you decide who should be able to contribute to this Pinata (Time Capsule). You include all your friends to be contributors. And you set John and Jill as the sole openers of the Pinata, so only they can decide to open it. You set the minimum time to the next five years, so you force yourselves, including John and Jill, to wait and not spoil the memories before the 5th anniversary.

And then finally, after five years, after you've built up a mountain of memories, you can finally ask John and Jill to open the Pinata. Then you'll be able to download and look back on all those memories with a smile.

Other Usages

Of course the timeline doesn't necessarily have to span 5 years. You can even create Pinatas to store memories of a 1-week camping trip. It's up to you!

Demo

Video

Demo Video on YouTube

Application Flow

Home Page

Authentication Pages

Dashboard

This is where most of your data will be listed. On the top you'll see the Pinatas you've created. On the bottom right, you'll see a list of users you've added as friends. In the same place, there's also a form where you can add users as your friends by their usernames.

On the bottom left, you'll see a list of Pinatas in which others have created but involves you somehow, either you've been added as a contributor, an opener, or both.

Create Pinata

Here's where you create your Pinata. You can set its title, description, and thumbnail picture.

You can also set who can contribute to the Pinata once it has been created, as well as limit when invited users can contribute to the Pinata. You can set when allowed contributors can start contributing as well as when the Pinata will stop accepting contributions.

Then, you can set attributes related to opening the Pinata. You can set a minimum open time, which will mark the earliest date and time the Pinata can be opened. You can also set who will be required to open this Pinata. You can also omit one of these values. For example, you can set a minimum open time and omit the "openers", this way, Pinatas will open automatically when the time comes. Or you can only include allowed "openers"; this way, the Pinata will open once all the openers have opened the Pinata. Or you can combine include both these values so "openers" can only open the Pinata after the set date time.

You can exclude yourself from contributing or opening.

Viewing Pinata

Unopened Pinata

This is what you'll see when you click on an unopened Pinata. You'll see it's details. This is also where you'll contribute your digital memories/files to the Pinata (if you're part of the contributors).

You won't be able to view the files you've contributed in this state (you have to open it).

You'll also open the Pinata in this view. It's in real time so when all users open the Pinata, or the it's just time for the Pinata to open, you'll see the Pinata in the open state. See below.

Open Pinata

This is the Pinata in the open state. You can no longer contribute files, but now you'll be able to see all those memories you've created and uploaded.

Profile Page

My Code

The full code can be found on my Github

AnsellMaximilian / break-time

The Pinata Challenge

Quick Links

What I Built

Break Time is a web app for creating digital time capsules (called Pinatas) to store and cherish memories. Pinatas are opened on a future date to relive those memories, making sure your digital footprints remain meaningful.

Example Usage

You can create a Pinata named "John and Jill’s 5th Anniversary", where friends store messages, photos, or videos leading up to their 5th anniversary. Only John and Jill can open it after five years, unlocking all the memories inside.

The app allows contributors to add memories, with customizable settings for contribution timelines and who can open the Pinata.

Demo

Demo Video on YouTube

Screenshots

Home Page

Dashboard

Create Pinata

Tech Stack

Next.js for frontend and secure route handlers
Appwrite for authentication and metadata storage
Pinata for file storage on IPFS

Example Code for Route Handlers

export async function

…

View on GitHub

More Details

Tech Stack

Next.js

I'm using Ol' Reliable Next.js as my front end as well as to create a few secure route handlers for handling file upload on the client side, as recommended by Pinata.

// getting a one time use key to use in the front end
 export async function GET() {
  try {
    const uuid = crypto.randomUUID();
    const keyData = await pinata.keys.create({
      keyName: uuid.toString(),
      permissions: {
        endpoints: {
          pinning: {
            pinFileToIPFS: true,
          },
        },
      },
      maxUses: 1,
    });
    return NextResponse.json(keyData, { status: 200 });
  } catch (error) {
    return NextResponse.json(
      { text: "Error creating API Key:" },
      { status: 500 }
    );
  }
}

I would call this each time I want to upload a file, because Next.js limits on how big a file you can send on the server.

Similarly, I would call another route handler to get a secure URL for a certain file:

export async function POST(req: NextRequest) {
  try {
    const data = await req.json();
    const url = await pinata.gateways.createSignedURL({
      cid: data.cid,
      expires: 30,
    });
    return NextResponse.json(url, { status: 200 });
  } catch (error) {
    console.log(error);
    return NextResponse.json(
      { text: "Error creating API Key:" },
      { status: 500 }
    );
  }
}

Appwrite

I needed authentication as well as a place to store some metadata for the files, so I used Appwrite's authentication and database in conjunction with Pinata, so I can store extra details to files uploaded to Pinata, such as file names, cid, etc.

So I would fetch a file metadata in Appwrite (in this case, it would be a contribution for a Pinata), then I would use the resulting metadata to retrieve a file from Pinata by its CID.

const openFile = async (contribution: Contribution) => {
    // getFileURL calls the route handler that returns a signed URL for a particular file by its CID
    const fileURL = (await getFileUrl(contribution.cid)) as string;

    window.open(fileURL, "_blank");
  };

How Pinata was Used

Pinata (the service) was used for this app's main file storage. It stores a Pinata's (the time capsule) thumbnail, a user's profile picture, and, most importantly, digital contributions for the Pinata.

Here's a simplified version of how I implemented Pinata to upload/replace a user's profile picture:

// gets set on the onChange prop of an input element of type "file"
const handlePictureChange: React.ChangeEventHandler<
    HTMLInputElement
  > = async (e) => {
    if (file) {
      // get the one time key
      const keyRequest = await fetch("/api/key");
      const keyData = await keyRequest.json();

      // upload to pinata
      const upload = await pinata.upload.file(file).key(keyData.JWT);

      // delete the original profile picture (replace) by its file id
      if (user.profile.profilePictureFileId) {
        const delRes = await fetch("/api/delete-files", {
          method: "POST",
          headers: {
            "Content-Type": "application/json",
          },
          body: JSON.stringify({
            fileIds: currentUser.profile.profilePictureFileId,
          }),
        });
      }

      // update metadata on appwrite
      await databases.updateDocument(
        config.dbId,
        config.userProfileCollectionId,
        currentUser.profile.$id,
        {
          profilePictureFileId: upload.id,
          profilePictureCid: upload.cid,
        }
      );
    }
  };

Similar flow was used to upload file contributions as well as uploading Pinata thumbnails.