Skip to main content

Love Burn

· 4 min read
Damian Tarnawsky

Love Burn has hundreds of theme camps and 7k+ attendees, so in terms of scale it is about as big as regionals come. Happening February 15-18, I made the decision to make dust available for Love Burn a week beforehand based on the fact that I could see enough data to use in the app.

Hunting through theloveburn.com I could see that the team used Airtable to store data for camps, events, art etc. Airtable has a CSV export, so I built an import feature and scrubbed the data for importing camps as best I could.

Google Maps is used for placement of camps, restrooms etc at theloveburn.com so I created an import feature for the KML format. As a side note, do not use Google Maps for regionals, for Love Burn it failed under load and was blocked by Google for abuse of its terms of service. I would guess it was simply the amount of users accessing it and the fact that Google Maps is a paid product.

Love Burn Screenshots

There wasn't a strong correlation between a camp (numbered at The Love Burn) and its place on the map (that may be labelled with that number). So for camps that were given one name, but labelled with a different variation on the map it means that the map didn't always line up.

Data integrity is super important and tying data points like camps to map GPS coordinates, events, workshops etc is key to making dust useful.

For events / workshops and music I decided to manually import these based on the Airtable spreadsheets, and flyers posted by camps in the Facebook group. This process took several hours but in the end I felt like I had filtered out of a bad data and reconciled events that had ambiguous dates/times. The data was published by opening day February 15th.

There was also quite a few bug fixes I needed to make along the way including fixes for timezones. For example I was entering data on a browser in PST timezone, but Love Burn is in Miami, so EST. There were also a few reports from attendees who hadn't updated the app since using it at Burning Man, so Love Burn wasn't listed, so I added an update check on startup to ensure the latest version was being used.

This was also a chance to verify that the updated architecture of Dust worked well. Here's a rundown of the moving parts:

  • Database - Data is stored in Cloudflare D1 with environments for production, dev and local. We also use Drizzle ORM.
  • Services - Cloudflare Workers are used for administration by Event producers, theme camp leads and music leads.
  • Content Delivery - Cloudflare R2 and Caching are used for delivery of event data globally. Netlify is also used for the admin app and preview app of dust.
  • App - The dust app is built using the Ionic Framework, Capacitor and Angular (currently v17). It is open source.

We also dropped usage of Cloudflare KV as all data is now in D1.

Dust's Love Burn was launched with a post to the Love Burn Facebook group, which means limited exposure because not everyone going to Love Burn is going to pay attention to Facebook and of those that do it is likely only a small subset will see a post to the group as Facebook likes to minimize the visibility of group posts.

In any case, using Facebook and some word of mouth it appears that around 800 users installed dust for Love Burn - it's worth noting that we do not track any information in dust so these numbers are based on what Apple and Google track with the App Store and Play Store.