DEV Community: Kevin

Designing for KaiOS - Leveraging Kiro to build an app for the next billion mobile users

Kevin — Thu, 04 Dec 2025 04:01:47 +0000

Introduction

The next billion mobile users aren't getting smartphones, they're getting $20 flip phones running KaiOS. While the tech world obsesses over the latest iPhone, over 200 million people worldwide rely on feature phones with limited capabilities but essential connectivity.

My challenge: Build BlueKai, a fully-featured BlueSky client for devices with 256MB RAM, Gecko 48 (Firefox from 2017), and D-pad navigation. No touch screen. No modern JavaScript APIs. Just the basics, and the determination to bring decentralized social networking to users in remote areas with limited data plans.

This is the story of how I used Kiro, an AI-powered IDE, and a spec-driven development approach to ship a production-ready app in days instead of weeks.

The KaiOS Challenge

KaiOS sits in a unique position in the mobile ecosystem. It powers affordable feature phones sold primarily in emerging markets across India, Africa, Southeast Asia, and Latin America. For many users, a KaiOS device represents their first (and sometimes only) connection to the internet.

But building for KaiOS means confronting constraints that modern web developers rarely encounter:

The Technical Constraints

Ancient browser engine: Gecko 48 (equivalent to Firefox from 2017) means no Fetch API, limited ES6 support, no modern CSS features
Tiny bundle budget: Target under 200KB gzipped for users on prepaid data plans where every kilobyte costs money
D-pad only navigation: No touch screen. Everything must work with up/down/left/right arrow keys and a select button
Resource constraints: 256MB RAM total, shared between the OS and all running apps
Small displays: 240x320 pixel screens in portrait or 320x240 in landscape
Global audience: Users speaking dozens of languages, including right-to-left scripts like Arabic
Intermittent connectivity: 2G/3G networks with frequent drops and high latency

The Platform Reality

Unlike iOS or Android where you can find tutorials, Stack Overflow answers, and active communities, KaiOS development is niche. Documentation is sparse. The community is small but passionate (shoutout to BananaHackers). Most developers build once and move on.

This made it the perfect test case for AI-assisted development.

Enter Kiro: AI-Assisted Development

Traditional development for a platform like KaiOS is slow. You're constantly:

Researching obscure browser limitations
Finding workarounds for missing APIs
Testing on actual hardware (emulators are unreliable)
Debugging issues that modern DevTools don't handle well

Kiro's conversational approach proved invaluable. Instead of searching documentation or Stack Overflow, I could describe behaviors in natural language and get immediate, contextually-aware solutions.

Example: Early in development, I noticed strange scrolling behavior. I told Kiro: "The cursor can start on top of the action bar and prevent scrolling." Within seconds, Kiro identified the z-index issue and provided a fix that accounted for KaiOS's specific rendering quirks.

But Kiro's real power wasn't just answering questions. It was helping me think through the entire architecture before writing a single line of code.

The Spec-Driven Approach

I adopted a three-phase workflow that kept me from drowning in complexity:

Phase 1: Requirements

Before touching any code, I worked with Kiro to define comprehensive user stories using the EARS (Easy Approach to Requirements Syntax) format:

WHEN the user logs in THEN the system SHALL authenticate using BlueSky ATP protocol
WHEN authenticated THEN the system SHALL display the user's home timeline
WHEN viewing the timeline THEN the system SHALL show posts with author, content, and timestamp
WHEN the user selects a post THEN the system SHALL allow liking, reposting, and replying
WHEN the user navigates to compose THEN the system SHALL allow creating new posts up to 300 characters

This forced me to think through edge cases upfront:

What happens when the session expires mid-scroll?
How do we handle authentication on slow 2G networks?
What if the user closes the app mid-login?
What limitations come from the ancient browser engine?
What's a typical screen resolution?

Phase 2: Design

With requirements locked in, Kiro researched both BlueSky's AT Protocol API and Gecko 48's limitations. It generated:

Component hierarchies showing how UI elements related to each other
Data models defining the shape of BlueSky posts, profiles, and threads
A shared reference document that became the single source of truth

This wasn't boilerplate. It was thoughtful architecture that accounted for KaiOS's constraints. For example, the state management design used an observable pattern compatible with Gecko 48 rather than modern tools.

Phase 3: Tasks

Kiro broke the implementation into 25 discrete tasks with sub-tasks:

Set up Preact
- Configure build for ES5 output (Gecko 48)
- Set up development server
- Add bundle size analysis
Implement XMLHttpRequest wrapper
- Create Fetch-like API using XHR
- Add timeout handling
- Implement request cancellation
Build authentication flow
- Create login form with D-pad navigation
- Integrate AT Protocol session management
- Implement session persistence

Each task referenced specific requirements and could be executed incrementally. I could work on one task, review it, commit, and move to the next while maintaining momentum without losing context.

The Most Impressive Generation: Internationalization

The internationalization system showcased Kiro's ability to handle complex, multi-faceted problems.

I simply asked: "We need to support multiple languages for a global KaiOS audience."

Kiro didn't just generate a basic i18n setup. It created a comprehensive system:

Automatic Language Detection

The system detects the device language from KaiOS system settings and extracts the language code (for example, 'en-US' becomes 'en').

Eight Languages with Real Translations

Not placeholders but actual translations for English, Spanish, French, Portuguese, Arabic, Hindi, Swahili, and Indonesian. Kiro researched appropriate terminology for each language, including technical terms like "timeline" and "repost."

RTL Support

The CSS automatically applies right-to-left (RTL) text direction and reversed flex layouts when Arabic is selected, ensuring proper display for RTL languages.

Graceful Fallbacks

The translation system checks the current language first, falls back to English if the key isn't found, and finally displays the key itself if no translation exists. This ensures the app never shows blank text.

This level of thoughtfulness (supporting RTL, providing real translations) would have taken days of research and implementation. Kiro delivered it in one session.

Hybrid Development Strategy

I discovered that different types of work benefit from different approaches:

Specs for Foundational Features

Complex, multi-component features like architecture, state management, and the AT Protocol API client benefited from the full spec-driven approach. These needed:

Cross-session context preservation
Systematic thinking about edge cases
Comprehensive documentation for future maintenance

Vibe Coding for Iterations

Once the foundation was solid, I switched to conversational "vibe coding" for:

Bug fixes ("The menu doesn't close when pressing Back")
UI tweaks ("Make the timestamp smaller and gray")
Performance optimization ("Can we lazy-load images in the timeline?")

This hybrid approach maximized both thoroughness and speed.

Technical Wins

Some solutions I'm particularly proud of:

XMLHttpRequest Wrapper

Since Gecko 48 lacks the Fetch API, I needed to wrap XMLHttpRequest in a Promise-based interface that provides modern async/await functionality while working within the browser's limitations.

Virtual Scrolling

With limited memory, rendering hundreds of posts would crash the app. Virtual scrolling renders only visible items plus a small buffer above and below the viewport, dramatically reducing memory usage.

D-Pad Navigation Manager

KaiOS navigation requires careful focus management. The navigation system listens for arrow key events and maintains a list of focusable elements, moving focus appropriately and triggering selection on Enter key press.

See the KaiOS D-pad navigation guidelines for more details.

Aggressive Caching

Users on prepaid plans can't afford to re-download content. Service Workers cache timeline posts, profiles, and media, responding with cached versions when available and only fetching from the network when necessary.

Bundle Optimization

Final bundle: 73.45KB gzipped, well under the 200KB target. Achieved through:

Tree-shaking unused Preact features
Dynamic imports for routes
Optimized image loading
Minification and compression

Learn more about optimizing apps for KaiOS.

Impact

BlueKai (bluekai.app) represents more than a technical achievement. It's about:

Bringing Modern Social Networking to New Markets

BlueSky's decentralized, ad-free approach is perfect for users on limited data plans. BlueKai makes it accessible to people who couldn't otherwise participate in the AT Protocol network.

Proving AI Can Tackle Niche Platforms

Most AI coding tools optimize for mainstream platforms (React, Next.js, iOS, Android). BlueKai shows that with the right approach, AI can handle obscure platforms with sparse documentation.

The Future of Global-First Development

If a solo developer can build a production-ready app for a niche platform in days, what becomes possible for small teams targeting underserved markets?

Conclusion

AI tools like Kiro make it feasible for small teams (or solo developers) to build for platforms that otherwise would have a steep learning curve with many paper cuts. The combination of spec-driven architecture and conversational iteration proved powerful: thoughtful design meets rapid execution.

BlueKai is open source and available at bluekai.app. Try it on any KaiOS device or in the KaiOS simulator. Built for Kiroween 2025.

Special thanks to the BananaHackers community and the KaiOS team for their documentation and tools.

Weekend Project- Building a Serverless Phishing Detector for Google's Cloud Run Hackathon

Kevin — Mon, 10 Nov 2025 04:04:47 +0000

I created this blog post for the purposes of entering the Google Cloud Run hackathon.

When I set out to build ParsePhish for the Google Cloud Run hackathon, I thought I had a solid plan: create a dual-purpose API that could analyze both emails AND URLs for phishing indicators. What I ended up with was a much more focused, production-ready solution - and a valuable lesson about the power of simplicity in AI applications.

First, what is ParsePhish?

ParsePhish is a REST API that uses transformer embeddings and GPU-accelerated similarity search to analyze email content for phishing indicators. It runs entirely serverless on Google Cloud Run with NVIDIA L4 GPUs. It was designed to be privacy-respecting and inexpensive to run. My idea was that now you could detect phishing messages without needing to send your messages to a service that you don't control.

The Original Vision (And Its Problems)

My initial idea was ambitious: why not detect phishing in both email content AND suspicious URLs? I built a FastAPI service with two endpoints:

/analyze/email - for email content analysis
/analyze/url - for URL analysis

The email analysis worked beautifully. Using SentenceTransformers and FAISS (Facebook AI Similarity Search) similarity search on the cloud GPUs, it could accurately identify phishing patterns in email text. But the URL analysis? That's where things got interesting.

curl -X POST $API_URL/analyze/url \
  -d '{"url": "https://google.com"}'
# Response: {"phishy_score": 0.8, "verdict": "Potential phishing"}

Google.com with a phishing score of 0.8? Something was very wrong.

The problem wasn't with the AI model - it was with my approach. The URL analysis was fundamentally flawed and destined to not be useful because:

Context Loss: A URL without user context is just a string - the real phishing happens in how it's presented
Domain Complexity: Modern web infrastructure (CDNs, subdomains, redirects) broke simple pattern matching and would make sure that even if I analyzed a URL in a sketchy email it would likely not do the user any good.

What I actually built

What remained after I stripped out the URL analysis feature was a laser-focused email phishing detection API that works reliably.

Here's the breakdown:

Architecture:

FastAPI backend deployed on Cloud Run with NVIDIA L4 GPUs
SentenceTransformers (intfloat/e5-small-v2) for GPU-accelerated 384-dimensional text embeddings
FAISS CPU for high-speed similarity search against known phishing patterns
Python container

AI Pipeline:

Text normalization and preprocessing
GPU-accelerated transformer embedding generation
FAISS similarity search against training corpus
Intelligent scoring combining similarity votes with pattern matching
Real-time response with explanatory details

Cloud Run Configuration:

16Gi memory + 4 vCPUs for GPU instances
Scale-to-zero for cost efficiency
HTTPS-only with automatic TLS

Check it out here:

kevinl95 / ParsePhish

ParsePhish uses NVIDIA L4 GPUs on Google Cloud Run to detect email phishing entirely serverless! Transformer embeddings + FAISS similarity search = real-time protection without storing your data.

ParsePhish Email Analysis API

GPU-powered phishing detection for email content
Serverless AI-powered email analysis using transformer embeddings and similarity search.

ParsePhish is a REST API that uses transformer embeddings and GPU-accelerated similarity search to analyze email content for phishing indicators. Built for the Cloud Run GPU Category hackathon, it runs entirely serverless on Google Cloud Run with NVIDIA L4 GPUs.

Quick Start

Prerequisites

Before deploying, you'll need:

Google Cloud CLI: Install gcloud
Google Cloud Project: Create a project with billing enabled
Authentication: Run gcloud auth login and gcloud auth application-default login
GPU Quota: Request NVIDIA L4 GPU quota in europe-west4 region
Required APIs: The deployment script will enable these automatically:
- Cloud Run API
- Cloud Build API
- Container Registry API

Deploy to Cloud Run

# Clone the repository
git clone https://github.com/kevinl95/ParsePhish.git
cd ParsePhish
# Deploy with GPU support to your Google Cloud project
./deploy.sh YOUR_PROJECT_ID

…

View on GitHub

Once you deploy it, give it a shot:

# Obvious phishing email
curl -X POST $API_URL/analyze/email \
  -d '{
    "content": "URGENT! Click here or your account will be deleted!",
    "subject": "Security Alert"
  }'

# Legitimate email  
curl -X POST $API_URL/analyze/email \
  -d '{
    "content": "Your monthly statement is available in your account portal.",
    "subject": "Statement Ready"
  }'

where of course API_URL is your deployed ParsePhish.

Where next?

I would love to prototype extensions for Thunderbird and other email clients so people can take advantage of this tool right from their favorite email apps. For now, I'm excited to get this out in front of the community to see if it can be valuable for anyone building tools that can make use of an easy-to-deploy phishing detector.

Check out my new GitLab CI/CD module- it provides certainty that when you deploy your new web feature it will work cross-browser and cause you minimal headaches!

Kevin — Sun, 12 Oct 2025 17:36:56 +0000

Web Check CI: Catch Browser Compatibility Issues Before They Break Production

Kevin ・ Oct 11

#devchallenge #hacktoberfest #opensource #webdev

Web Check CI: Catch Browser Compatibility Issues Before They Break Production

Kevin — Sat, 11 Oct 2025 22:15:22 +0000

This is a submission for the 2025 Hacktoberfest Writing Challenge: Maintainer Spotlight

The Problem That Started It All

Picture this: You've just deployed a beautiful new feature, but within hours, support tickets start flooding in. Safari users can't see your popover menus. Older Chrome versions throw JavaScript errors. Your team spends the next day debugging compatibility issues that could have been caught before deployment.

This exact scenario inspired me to build Web Check CI - an automated browser compatibility scanner that integrates directly into GitLab CI/CD pipelines.

What Makes Web Check CI Special

Web Check CI stands out because it is the first CI/CD module of its kind available for GitLab! It's built on Google's Baseline initiative, the new standard for web platform compatibility. Instead of guessing which features are safe to use, developers get authoritative answers based on real browser support data.

Key Features:

One-line setup in GitLab CI/CD pipelines
Scans JavaScript, CSS, and HTML for compatibility issues
Configurable baseline years (2023, 2024, 2025)
Smart feature detection using regex patterns, not just keyword matching
Inline merge request comments showing exactly where issues exist
Allow/deny lists for team-specific rules

Example of Web Check CI running on a real GitLab repo

How It Works Under the Hood

Web Check is both a CI component for GitLab and a powerful CLI tool. The architecture combines three powerful Node.js libraries:

Commander.js - Clean CLI interface with automatic validation
Glob - Smart file discovery that skips node_modules and test files
Web-Features - Google's comprehensive database of 1000+ web platform features

The scanning process is sophisticated yet fast. It checks every web feature against actual code usage, not just mentions in comments or documentation.

Here's some sample output you can expect from WebCheck CI:

❌ Found 2 baseline issues:
🚫 Explicitly Denied Features:
  app.js:11 - document-write
    document.write('<p>This should be caught</p>');
    → Explicitly denied

⚠️  Baseline Compatibility Issues:
  app.js:14 - popover
    element.popover = 'auto';
    → Not in baseline 2024 (available from 2025)

Real-World Impact

Since launching this month, Web Check CI has:

500+ weekly downloads from NPM
Published to GitLab Component Catalog for seamless integration
Achieved high test coverage

Why I'm Passionate About This Project

Web compatibility shouldn't be an afterthought. Every developer has experienced the frustration of browser compatibility issues breaking user experiences. Web Check CI transforms this reactive debugging into proactive prevention. Not every developer has time to track which features work where. This tool brings Google's authoritative compatibility data directly into everyday workflows.

How You Can Contribute

Web Check CI is actively seeking contributors! Here are some ways to get involved:

Try it out: Run npx @kevinloeffler/web-check on your projects
Add it to your GitLab CI: Use our component for automated scanning. You can add it with just a few lines!
Report issues: Found a bug or false positive? Open an issue!
Improve feature detection: Better regex patterns for CSS/JS features
Platform integrations: GitHub Actions, for example
Documentation: Examples, tutorials, use case guides

Getting Started

NPM Package: @kevinloeffler/web-check or click here
GitLab Component: loefflerlabs/web-check-ci/templates/web-check.yml@v1.0.8 or click here
Repository:

Kevin Loeffler / Web Check CI · GitLab

Web Check CI automatically enforces Google's Baseline web compatibility standards in your GitLab pipelines. It scans your JavaScript, CSS, and HTML for unsupported features and reports issues directly...

gitlab.com

Basic GitLab Integration in your GitLab CI YAML file:

stages:
  - lint

include:
  - project: 'loefflerlabs/web-check-ci'
    ref: 'v1.0.8'
    file: 'templates/web-check.yml'

variables:
  BASELINE_YEAR: 2024
  SEVERITY: major
  DENY: "document-write"

What I've Learned as a Maintainer

Building Web Check CI taught me that developer experience is everything. The tool needed to be:

Zero-configuration for basic use cases
Highly configurable for advanced needs
Fast and reliable for CI/CD environments
Clear and actionable in error reporting

The most rewarding part? Seeing developers discover compatibility issues they never knew existed in their codebases.

Join Our Community

You can find the repo and contribution guide on GitLab!

Let's build a more compatible web together.

Fun project I put together this week in response to the rise of Quishing, or QR-code phishing. QRTrust is a free progressive web app that scans QR codes and checks the URLs they encode against the PhishTank database.

Kevin — Sat, 12 Jul 2025 01:08:43 +0000

Kevin

Jul 12 '25

QRTrust: Privacy-First QR Scanner with Phishing Detection

#webdev #javascript #cybersecurity #vite

Comments

3 min read

QRTrust: Privacy-First QR Scanner with Phishing Detection

Kevin — Sat, 12 Jul 2025 01:04:05 +0000

QR codes are everywhere, including restaurants, events, payments, and marketing materials. They have become endemic since the end of the COVID lockdowns. But have you ever wondered where that QR code is actually taking you before scanning it? That's the problem I set out to solve with QRTrust, a privacy-focused Progressive Web App that scans QR codes and checks URLs for phishing threats before you visit them!

Quishing

Many of us have heard about phishing, where websites and emails pretend are created that pretend to be a real service or person. Quishing is similar, except with QR codes and it's a growing problem worldwide, including where I live. People post QR codes pretending to be a service letting you pay for parking, order food, pay for fuel, but instead they are collecting your information for scams and identity theft.

How QRTrust Works

QRTrust provides a simple, privacy-first solution:

Scan QR codes using your device's camera
Check URLs against PhishTank's community-driven phishing database. QRTrust does not log addresses from users, and it is fully open source so you can verify! Plus, if you want, the whole thing can deploy to Netlify with a few commands if you want a private instance- check out the link to GitHub at the bottom of this article.
Get clear feedback: Safe ✅, Suspicious ⚠️, or Unknown ❓
Make informed decisions with detailed warnings and safe browsing options. QRTrust does not immediately navigate to the linked website- it lets you choose. You'll get presented with the full, human readable URL as well as what we found on PhishTank.

It's also a progressive web app, which means you can install it on any device you please- no app store required.

Try it live: qrtrust.fyi

Architecture & Technology Stack

Frontend Technologies

CSS3 with Custom Properties - Modern styling with gradients and animations
HTML5 - Semantic markup and PWA manifest
Vite - Fast build tool and development server

Core Libraries

@zxing/browser - QR code scanning using device camera

Backend & API

Netlify Functions - Serverless functions for CORS proxy. This is necessary because PhishTank does not allow websites to make client-side requests. This made it simple to check URLs without worrying much about the backend.
PhishTank API - Community-driven phishing URL database

Progressive Web App Features

Web App Manifest - Native app-like installation. Launch it right from your homescreen, and I don't have to worry about submitting to app stores.
Responsive Design - Works on Android and iOS.

Open Source

Check out the code on GitHub!

kevinl95 / qrtrust

Privacy-focused PWA for checking if QR codes lead to known phishing sites

QRTrust

A privacy-focused Progressive Web App (PWA) that scans QR codes and checks if they lead to known phishing sites before you visit them.

🚀 Features

Real-time QR Code Scanning - Uses your device's camera to scan QR codes
Phishing Detection - Checks URLs against PhishTank's database of known phishing sites
Privacy-First - No URLs or personal data are logged
Progressive Web App - Install on your device like a native app
Mobile-Optimized - Responsive design for all devices
Security-Focused - Clear warnings and safe browsing recommendations

🔍 How It Works

Scan QR Code - Point your camera at any QR code
URL Analysis - The app extracts the URL and checks it against PhishTank's database
Safety Assessment - Get instant feedback
- ✅ Safe - URL appears clean, safe to visit
- ⚠️ Suspicious - URL found in phishing database
- ❓ Unknown - Unable to verify (service unavailable)
Informed Decision -…

View on GitHub

I had a lot of fun over the long weekend putting this together! I think it can be a valuable tool for teachers, freelancers, and anyone who routinely receives email attachments they could better manage from their Google Drive.

Kevin — Tue, 27 May 2025 03:02:52 +0000

Kevin

May 27 '25

Drop It Like It’s Hot: Sending Email Attachments Straight to Google Drive using Postmark

#devchallenge #webdev #api #postmarkchallenge

Comments 3

6 min read

Drop It Like It’s Hot: Sending Email Attachments Straight to Google Drive using Postmark

Kevin — Tue, 27 May 2025 02:16:34 +0000

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

What I Built

Teachers, freelancers, and inbox zero purists rejoice: I built EmailDrop, a one-click AWS deployment that turns incoming emails into automatic Google Drive uploads. With Postmark's new inbound webhooks, AWS Lambda, and a little OAuth wizardry, attachments fly straight from your inbox to your Google Drive. In this post, I’ll walk through how I built it using Postmark, CloudFormation, Google Drive, and serverless tools, and how you can deploy it with zero manual code.

Why use EmailDrop?

Deploys with a single click, no coding required (see the demo below and deploy in minutes!)
Have your students submit their homework direct to your Google Drive, and without having to give out your real email address
Process documents from coworkers, employees, or customers without having to manually download attachments and upload them for editing and storage
Set up a photo folder for special events like weddings, birthdays, and more!

Demo

EmailDrop is a CloudFormation stack with some Python code that will simplify your email inbox. First, however, we need to gather some information from Google. Then, we'll click a Launch Stack button that will deploy all of the infrastructure- no coding required. Then we'll configure Postmark and wrap up. Let's go!

Go to Google Cloud Console

Visit https://console.cloud.google.com/

Create a Project

Click the project dropdown → New Project
Name it (e.g., PostmarkUploader)
Click Create

Enable the Google Drive API

Go to APIs & Services → Library
Search for Google Drive API
Click Enable

Configure the OAuth Consent Screen

Go to APIs & Services → OAuth consent screen
Choose External
Fill in:
- App name
- Support email
- Developer contact email (these can all be your personal email)

Add yourself as a test user using the Audience page on the sidebar
Click Save and Continue

Create OAuth 2.0 Credentials

Go to APIs & Services → Credentials
Click Create Credentials → OAuth client ID
Choose Web application
Skip the redirect URI for now — you'll add it after deploying the stack
Click Create
Save the Client ID and Client Secret

Deploy the CloudFormation Stack

Click the "Launch Stack" button above!
Name the stack anything you wish.
Fill in the parameters:
- GoogleClientId: (from step 5)
- GoogleClientSecret: (from step 5)
- GoogleDriveFolder: (optional) Name of the folder to store attachments
- LambdaTimeout: (optional) Default is 60 seconds. Increase for large attachments (up to 900s)

- Agree to let AWS create new IAM resources and click `Create Stack'. EmailDrop will take several minutes to deploy.

Add the Redirect URI

Once the stack is deployed, go to the Outputs tab in CloudFormation
Copy the OAuthURL output

Return to Google Cloud Console → Clients
Click on your OAuth 2.0 client
Edit the Authorized redirect URIs
Paste in the URL you copied from the stack output
Save changes

Complete the OAuth Flow

In the stack outputs, find the OAuthURL
Open it in your browser
Click the link to begin the authentication flow, as shown above.

You will get a warning that Google has not verified this application. Click 'Continue'
Approve access to Google Drive
The Lambda will exchange the code for tokens and store them

You can now close this page, authentication is finished!

Create a Postmark Account

Sign up at postmarkapp.com
Create a new server (or use an existing one)

Set Up Inbound Email Processing
- In your Postmark dashboard, navigate to Servers → Your Server Name → Default Inbound Stream
- Navigate to Setup Instructions
- Note your unique inbound email address

Configure Webhook URL
- From the Settings page, find the Webhook URL field
- In the CloudFormation stack outputs, find the PostmarkWebhookURL value
- Copy this URL and paste it into the Postmark Webhook URL field
- Check the box that will send the JSON payload to your Lambda function. EmailDrop parses this JSON to extract the attachments.
- Save your changes

Test the Integration
- Send an email with attachments to your Postmark inbound email address
- The attachments should be automatically uploaded to your Google Drive folder
- Check the Lambda logs in CloudWatch if you encounter any issues

Code Repository

kevinl95 / EmailDrop

Automatically upload attachments to emails sent to your Postmark inbound email address to Google Drive

EmailDrop: Postmark to Google Drive Attachment Uploader

This application automatically uploads email attachments from Postmark to Google Drive. When emails are sent to your Postmark inbound email address, any attachments are automatically saved to your specified Google Drive folder. The system uses AWS Lambda, API Gateway, and Secrets Manager to handle the OAuth flow and file uploads.

Architecture

Postmark: Receives emails and sends attachment data via webhooks
API Gateway: Provides endpoints for OAuth callback and Postmark webhook
Lambda Functions: Handle OAuth flow and attachment uploads
Secrets Manager: Securely stores OAuth refresh tokens
Google Drive API: Destination for email attachments

Setup Instructions

1. Google Drive API Setup

1.1 Go to Google Cloud Console

Visit https://console.cloud.google.com/

1.2 Create a Project

Click the project dropdown → New Project
Name it (e.g., PostmarkUploader)
Click Create

1.3 Enable the Google Drive API

Go to APIs & Services → Library
Search…

View on GitHub

How I Built It

This project started as a simple idea: I wanted to extract attachments from emails and send them to Google Drive automatically. Drive does not offer this feature natively. Postmark’s Inbound Webhooks made that possible with a clean, reliable way to receive structured email data, including base64-encoded attachments, via a JSON payload.

I used AWS CloudFormation to make the whole serverless solution deployable in one click. The stack provisions:

An OAuth token exchange Lambda: Handles the OAuth 2.0 flow with Google, exchanging an authorization code for tokens. It outputs a working Google OAuth link via CloudFormation so users can grant access easily.
An upload Lambda: Triggered by Postmark’s inbound webhook. It decodes the attachments and uploads them to the authenticated user's Google Drive using the Drive API.
An API Gateway: Routes the Google OAuth redirect to the token exchange Lambda function.

Here's how it works:

To keep things simple, I made sure the user experience didn't require running any local code or setting up servers. Once the stack is deployed, the user just needs to:

Set up a Google Cloud project.
Deploy the CloudFormation template with their OAuth credentials.
Complete the auth flow by visiting a link output by the stack.
Configure Postmark to send inbound emails as a JSON payload to the webhook.

All credentials and logic are encapsulated in AWS Lambda functions using Python 3 and the standard library, keeping dependencies minimal. Tokens are stored in Amazon's Key Management Service, which lets EmailDrop securely manage all information needed to authenticate with the Google Drive API.

My experience with Postmark was great, the inbound webhook fature is fast and extremely easy to consume. Having the full email (plus parsed fields and attachments) delivered via HTTP was a huge time-saver compared to working directly with IMAP or polling APIs. Being able to extract content from emails in a structured way will make a number of projects and tools much easier to build, and I look forward to using Postmark's inbound features again!

Data Broken - Opt out of the data broker nightmare with Privotron and Amazon Q Developer

Kevin — Mon, 12 May 2025 02:59:23 +0000

This is a submission for the Amazon Q Developer "Quack The Code" Challenge: Crushing the Command Line

What I Built

Privotron is a command-line automation tool that helps users opt out of invasive data broker databases. It targets the expanding industry of data brokers, which collect, buy, and sell personal information, including home addresses, health conditions, religious or political affiliations, and behavioral profiles, often without meaningful consent.

Opting out of these services is legally permitted in many jurisdictions but is intentionally made tedious: websites are inconsistent, forms are buried, and requests often require multiple steps. Privotron automates these processes, using browser automation to simulate human opt-out actions, saving users time and frustration.

Privotron is built on a modern Python stack that leverages several powerful libraries for browser automation and configuration management. At its core, the application uses Playwright, a robust browser automation framework that provides cross-browser support and reliable DOM interaction capabilities. The command-line interface is implemented using Click, which enables sophisticated argument parsing and validation with minimal boilerplate code. For configuration management, Privotron employs PyYAML to parse broker-specific YAML files, allowing for declarative definitions of opt-out workflows. The architecture combines declarative configuration with imperative execution, allowing for a flexible and extensible system that can adapt to the varied requirements of different data broker opt-out processes.

Crucially, Privotron is designed to be pluggable and community-driven. I've provided a detailed broker contribution guide to make it easy for users to add support for new brokers. The long-term goal is to create a crowd-sourced library of automation plugins. Currently, Privotron has three different data brokers to start.

To this end Amazon Q Developer has been instrumental in making this application easy to extend by non-developers, allowing for the use of human-readable YAML "playbooks" that explain exactly how the opt out should work. It also was crucial at helping write clear documentation with meaningful examples. It also automated adding a number of convenience features, like user profiles so users do not have to re-enter their details each time the repo updates with new data brokers. Let's dive in and see how it works!

Demo

Here is a simple example of what a data broker opt-out form looks like. Many are far more invasive, asking for social security numbers and other sensitive pieces of information. While it doesn't look like much, the goal of Privotron is to fill out as many of these as possible with minimal user intervention. Every broker is unique and it can take a great deal of time to locate and work through each opt-out form, which is one of the main inconveniences Privotron attempts to alleviate. To this end, the CLI asks for some basic information it can combine in various ways to answer the various questions these forms may throw at it.

Users give Privotron some personally identifiable information. This data is sensitive and is only used by Privotron to fill in data broker forms, and is only stored if the user requests in a local profile file that they can delete at any time.

Upon invoking Privotron with their profile or their information, Privotron will open a web browser and automatically start working through data broker opt out forms. Through clever lists of "actions" in each broker playbook, it fills required fields and handles various buttons and checkboxes. Using the user's own computer and residential IP helps alleviate some of the anti-bot measures these data brokers take, as shown above. I hope in the future to add better support for working through captchas and other anti-bot measures.

Many brokers require users to select what records to remove. This requires some manual user intervention to validate the records they want deleted. Privotron will prompt the user and will continue when the user wishes to. This gives broker contributors flexibility in handling sites that have non-deduplicated data where users may come up in various different records they may wish to delete.

Below is an example of the simplest opt-out playbook currently in Privotron. It shows how the playbooks are human readable and easy to debug.

name: United States Phonebook
slug: unitedstatesphonebook
url: https://www.unitedstatesphonebook.com/
required_fields:
  - phone
  - zip
steps:
  - action: navigate
    url: "https://www.unitedstatesphonebook.com/contact.php"
  - action: fill
    selector: '[name="number"]'
    field: phone
  - action: fill
    selector: '[name="zip"]'
    field: zip
  - action: click
    selector: '[value="Request Removal"]'
  - action: wait
    seconds: 5

Code Repository

kevinl95 / Privotron

Framework and tool to make it easier to opt out of data brokers

Privotron

Privotron is an open-source framework and automation tool designed to help individuals reclaim their privacy by opting out of data brokers. Data brokers collect, store, and sell personal information without explicit consent, posing significant privacy risks. Privotron makes the opt-out process easier by automating browser interactions with data broker websites.

Why Privotron?

Privacy Protection: Data brokers collect and sell your personal information without your explicit consent
Time Saving: Manually opting out of dozens of data brokers can take hours or days
Automation: Privotron automates the tedious process of filling out opt-out forms
Tracking: Keep track of which brokers you've already opted out from
Community-Driven: Easily contribute new broker configurations to help others

Installation

Prerequisites

Python 3.13 or higher
poetry (for dependency management)

Installing Poetry

If you don't have Poetry installed, you can install it using one of these methods:

Recommended (Official installer):

curl -sSL

…

View on GitHub

How I Used Amazon Q Developer

I primarily interacted with Amazon Q Developer through the excellent official extension for Visual Studio Code.

Amazon Q Developer was instrumental in helping add a number of quality-of-life features, as well as helping expand Privotron's "actions", which are the different ways it can interact with a Data Broker's webpage. A good example of this is how, once I got the core of the application running, Amazon Q was able to understand the data I was asking for from users and build me the profile feature that prevents users from needing to re-enter their information. All I needed to do is explain the feature, specify a minor detail that I wanted Click to have a new optional CLI argument, and Amazon Q built the feature for me as you see it in the project today:

I also used Amazon Q Developer to help me handle edge cases in browser automation. As you can imagine, broker websites vary widely. I would frequently copy and paste new pieces of broker UI HTML into Amazon Q and it would update Privotron to handle these new edge cases. Here's an example of how it made the state selector action, which handles dropdowns for US states that are common on broker opt-out forms, much more flexible in seconds once I gave it an example of what I was trying to handle:

Here's the mapping it came up with, saving me some tedious manual work:

I was also able to ask it to make convenience functions for me. I already was collecting the user's first and last name, but needed to easily be able to fill in forms asking for the users full name. Amazon Q handled this new convenience action like a champ, and even anticipated that I may want the user's full name listed in the format "Lastname, Firstname" without be even asking!

Finally, Amazon Q Developer understood my markdown files and the code well enough that it wrote an excellent broker contribution guide which you can find in the repo right now! It has meaningful examples and describes the various actions Privotron can take on a broker opt-out page, making it the cornerstone of my strategy to crowdsource additional broker opt-out playbooks.

Amazon Q Developer saved hours of work and automated away the tedious bits of cleaning up a project to show off, putting me much farther ahead with this project than I would have otherwise been. It also anticipated a number of edge cases and conveniences that I likely would not have added in my first cut, making Privotron far more useful in this initial iteration than it otherwise would have been.

Did you know that you can discover where the businesses behind the products in your grocery store operate just by looking at the barcode? I’ve developed OriginTrackr, a free Progressive Web App that allows you to explore more about your favorite products!

Kevin — Wed, 26 Mar 2025 00:21:11 +0000

OriginTrackr: Explore where products come from with KendoReact

Kevin ・ Mar 24

#devchallenge #kendoreactchallenge #react #webdev

OriginTrackr: Explore where products come from with KendoReact

Kevin — Mon, 24 Mar 2025 02:48:28 +0000

This is a submission for the KendoReact Free Components Challenge.

What I Built

OriginTrackr is an innovative progressive web app (PWA) designed to help consumers discover where the products they purchase may come from. There is a global movement to understand where the products we buy are coming from, or where the companies that make the products we buy every day are based. Built with React and powered by KendoReact components, the PWA brings together an intuitive interface that allows users to scan barcodes on products as they shop which reveals where the companies making or packaging the product's business is based. This can reveal trade connections that might not be apparent even if the product is labeled with where it is packaged or made. Recognizing the challenges of unreliable Wi-Fi in supermarkets and retail environments, I developed OriginTrackr as an offline-capable PWA to ensure users can access crucial product information without the need for a constant internet connection. Once users visit the application the KendoReact components, country code lookup table, and other assets are cached for offline use- no sketchy store WiFi required! Whether users are scanning a product’s barcode on the go or exploring detailed origin data, OriginTrackr ensures they can do so efficiently and offline.

OriginTrackr checks the prefix of barcodes against hundreds of country codes using react-barcode-scanner and a locally cacheable list of country codes. While a country code doesn't tell you where a product is necessarily made, it may inform consumers about where their money is potentially going as it does indicate that the business packaging or making that product is present in the country they registered their unique identifier with the GS1.

Check it out:

Demo

You can try OriginTrackr out on your phone, tablet, or laptop right now at OriginTrackr.com!

OriginTrackr has a modern, clean UI using KendoReact components. The first thing you are greeted with is a button that will let you start scanning barcodes. You will be prompted for permission before it begins using your camera:

OriginTrackr will display a popup letting you know where this barcode was registered, giving you an idea of where the business is based:

Once you get this notification, you can take OriginTrackr offline- no data connection or WiFi required!

You can also install OriginTrackr as an app by pressing "Add to Homescreen" from the settings menu in your browser:

Of course the whole application is open source, so you can check out how I did this on GitHub!

kevinl95 / OriginTrackr

Find out where the products you're buying come from, just by scanning their barcode

OriginTrackr - Find out where your product choices are coming from using your camera

A modern web application to help you better identify where products come from during your errands! It lets you scan the barcodes on products using your cell phone camera and then uses the UPC to tell you where the product is coming from. It does this entirely offline- you can visit this page while you have internet and then re-visit the page while avoidng spotty or non-existant supermarket internet and still be able to see where your products are coming from!

Overview

Built with modern web technologies and featuring KendoReact free components, OriginTrackr provides a robust and user-friendly interface.

Technologies

Frontend: React
UI Components: KendoReact free components

Features

Barcode scanning
UPC lookup by country
Offline-capable
Allows users to store scans they would like to remember to a handy data table. Items in this table are stored…

View on GitHub

KendoReact Experience

KendoReact Free Components were leveraged throughout OriginTrackr and made building an intuitive UI quick and easy. Here are some of my favorite components:

AppBar from @progress/kendo-react-layout

OriginTrackr uses the AppBar to display a header and footer for the page, providing space for branding as well as providing the user a link to the source code for the application. It's my hope that this helps drive pull requests and community involvement in the project.

Card from @progress/kendo-react-layout

I don't feel that it's good practice to immediately ask users for access to something as sensitive as their camera when they first load a page. At the center of OriginTrackr is a card with a button that lets the user decide when they're ready to start scanning for barcodes. This then prompts the user for access to their camera, and also lets me expand the card to show the camera's output. It makes it clear that the majority of the user's interactions will be taking place in the center of the screen.

ExpansionPanel from @progress/kendo-react-layout

I wanted to provide a space where users could optionally store scanned barcodes that they've seen in case they wanted to review where the products in their shopping cart came from later. I didn't want this to take up much room on the screen, so I put it in a collapsible expansion panel. This made it easy to keep the UI clean and manageable.

Dialog from @progress/kendo-react-dialogs

Users are given a dialog with the country's flag and name where a given product's barcode is registered once OriginTrackr successfully identifies it. It makes it very clear to the user that scanning was successful, and provides a way for me to prompt them to save this product for later. Countries and barcodes are saved locally in the user's browser. The Dialog component made making this whole interaction very easy to implement as it needed minimal customization to achieve my main objective - let the user know quickly where the product they're holding came from.

Notification from @progress/kendo-react-notification

I'm very excited that OriginTrackr works offline, but struggled to figure out how to tell the user that a website can work offline. It's not intuitive, and most users aren't used to using pages in their browser this way. The KendoReact notification widget made it easy for me to tell the user the moment the service worker finished caching assets for offline use that they would be able to use this app offline. It let me put the information somewhere accessible but non-intrusive. It also made it very easy for me to let the user know if something was wrong of if their browser does not support offline features or PWAs.

Delightfully Designed

The Progress ThemeBuilder helped me get the UI I wanted for my app customized quickly. One of my favorite things about it is that I was able to start with a nice set of preset colors that go together from the styles menu. I chose Default Green, as it had no obvious conflicts for color blind users and because given the subject matter green is a calming color.

Something that was bothering me while building Default Green, however, is that the success color is also green! I wanted it to be visually distinct from the other green widgets in my UI. Fortunately ThemeBuilder made this easy. I selected the success color from the dropdown and was shown all variants my users may encounter:

Using the color picker, I changed it to cyan which was currently unused in my UI.

Conveniently, all other success colors changed hue with it! I didn't need to go through and decide which hue was better for emphasis or hovering- ThemeBuilder did that for me. As an artistically challenged individual, I am thankful.

You can see this color throughout OriginTrackr's UI, as well as the excellent Default Green. I hope you find it calming and the intentional uses of color intuitive!

Create your own Censorship-Resistant Links for X and More!

Kevin — Tue, 18 Feb 2025 03:00:58 +0000

Are you tired of social platforms blocking important links? Whether you’re trying to share information or simply want to keep control over your links, I’ve got a solution for you. In this guide, I'll show you how to easily create a censorship-resistant redirect link that you can use anywhere — without needing to write a single line of code!

What’s the Problem?

Platforms like X (formerly Twitter) can block or censor links to certain sites like they recently did to Signal.me, even when those links contain important information. A link shortener or redirect may work in the short term, but sites like Bitly and TinyURL create new single points of failure when platforms block them instead. What we want to do instead is leverage unique domains, like one you may already own for your blog or business. You could also register one for free! We will then deploy a simple, free redirect function to Netlify (a free cloud hosting provider) that will redirect to your intended page for sharing on social media. This way we create an unwinnable game of whack-a-mole for sharing important information.

What You’ll Need

A custom domain — You can get one for free (I'll share how in a moment).
A Netlify account — Don't worry, it's free and easy to sign up!
A GitHub account — again, free and easy to set up.
No technical experience required — Everything is set up for you!

Step 1: Get a Custom Domain (Optional, But Recommended)

While you can use the default Netlify subdomain, I recommend registering a custom domain. Having your own domain makes the link more trustworthy and as we discussed it will be less likely to be blocked. You can get a free domain from services like:

No-IP – Free subdomains (yourname.ddns.net) with CNAME support.
- ⚠️ Requires renewal every 30 days for free accounts.
EU.org – Free .eu.org domains with full DNS management.
- ⚠️ Requires manual approval, which can take time.

You can follow the instructions on these sites to get a free domain.

A professional domain can only cost you a couple of bucks a year though – .me and .info domains, for example, can be had for less than $5 annually! Here's a non-exhaustive list of places to look:

Namecheap – Frequently offers $1 .xyz or .online domains.
Cloudflare Registrar – No markup, sells at wholesale prices.
Porkbun – Regularly has $1–$3 domain deals.

Registration is a quick process, and there are plenty of tutorials available on these sites if you need help buying your first domain.

Step 2: Deploy to Netlify

This part is easy! You don’t need to worry about setting anything up yourself — everything is already configured. Just follow these steps:

Go to the FreeLink repository on GitHub.
Click the "Deploy to Netlify" button:

If you haven’t already, sign up for a free Netlify account.
Click "Connect to GitHub" and sign in with your GitHub account (or use one of their other providers)
When prompted, paste in the URL you would like your domain to redirect to into the form:

Click "Save & Deploy" and wait a few moments for Netlify to set everything up.

Once deployed, you’ll have your own censorship-resistant redirect link that you can use anywhere!

On a successful deployment, you can click "Open production deploy" to try your new redirect page out!

Step 4: Add your Custom Domain

Once the application is deployed,

Click "Site Overview" in the side bar
Scroll to "Set up your Site" as shown:

Click "Buy a new domain" or "set up a domain you already own". If you registered a new domain, the registrar should provide you with the necessary DNS settings. Follow Netlify's on-screen instructions to connect your domain.

Once connected, your redirect link will use your custom domain instead of the default Netlify subdomain.

Conclusion

That’s it! You’ve now created your own censorship-resistant link using Netlify, and you didn’t need to write any code. Simply deploy the project, set your redirect URL, and you’re ready to go.

With your own custom domain you’ll be able to share links that can’t be easily censored. Feel free to share your new link with friends, family, or the community!