Coding... in public... sorta

For the past couple of weeks, there's been an idea that's been bouncing around in my head that refuses to let go. It involves building some software, which takes time for me to over-design... and I honestly don't have a lot of free time in between everything. So the only way that I'm going get the idea out of my head is to devote some time to think it through and blast it onto a page. Since the intersection of tech, software, data community, and "failing in public" is the perfect intersection for this newsletter, I'll share bits of what I have as I go.

First, the idea is a fairly simple one. The one sentence elevator pitch is this – chat-roulette (wait, do people even remember that fad?), but with calendar invites, for data folk (or any other group of people that opt into a list thing).

The impetus is that at work someone wrote a bot that did this for a bunch of quantitative researchers, and it is surprisingly fun to spend a chunk of time with someone you've never met before but have some common ground on. This is true even for someone like me who has major difficulties holding conversations without scaffolding. So I'd love to see something kinda like that, but for a bunch of random data folk across the world.

You'd think that there's some kind of open source free solution for this problem but... nope. I've searched and can't find anything. There's some slack/discord bots, some paid services that seem to approximate what I'd want to see, but nothing that I could just have and host on my little web server for minimal cost and effort.

It seems... much to my consternation... that if I want to scratch this itch, I'm going to have to do it myself. That sucks.

So today, I'm asking readers for some feedback, feel free to ping me on social media, send an email, drop a comment, whatever to let me know what you think about whether I should even spend energy on building (and eventually open-sourcing) something that solves this particular problem or not.

Join me as I vent a bit of product/software design thoughts onto a page to think them out

Rough sketch

Here's what I think such a hypothetical project needs to accomplish to reach MVP:

• Users need to opt in by registering a basic account with the system so they can store their preferences
• Users need to express/save the following things:
  • An email that can receive calendar invites somehow
  • Times they are free and would be able to hop on a chat/call with someone
  • Their time zone because everything a user sees is in local time
• A database that stores all these user preferences
• Code that runs weekly that does matchmaking of users based on
  • Whether they have overlapping available time slots
  • Have the two people already been scheduled together recently
• Code then sends meeting invites to every pair of people a week ahead of time to give people chances to renegotiate time
• Everyone handles their calendar quirks somehow

In theory, it's possible to slap together a prototype with spreadsheets and manual labor. This is especially true if we wanted to see if data people actually wanted to meet each other. But from the people I've spoken to, there seems to be enough data folk around who might be interested in using such a tool. So let's just skip the market validation stuff and think software...

Surely... building something like this can't be too difficult... right? Well... From the research I've done so far, things get significantly more complicated once you're in the weeds.

The weeds

Authentication, calendars, meeting services

Registering user accounts isn't particularly difficult. But things get significantly more wonky if you want to send meeting invites to people.

For example, let's say we simplify things and just standardize on using google accounts and google calendar, since the meeting feature is free and most people have a gmail account somewhere. gCal doesn't just let rando people create calendar events onto other people's calendars – calendar spam is an actual problem they deal with. So according to the gCal documentation, the app needs permission via oauth2.0 from the user to allow access to their calendar? Did I ever mention I hate OAuth2.0 and have huge amounts of trouble working with it?

Let's forget Google and see if there's alternatives... Zoom meetings is in a similar position, requiring people have a zoom account along with corresponding OAuth tokens.

Okay, okay, let's stop with the proprietary software – .ics files, iCal is a standard so we can just generate them and send them to people. Right? Well, it seems possible enough to send emails with .ics files to people that gives a meeting at a certain date/time between two people. But you'd still need to generate a meeting link somehow with a 3rd party service provider.

Maybe the whole calendar thing is a mistake and we should look to alternative communication methods. For example, we have a discord server. Discord has capabilities for voice and video calls. It's possible to have a bot registered to ping specific people when they're supposed to meet and maybe set up a channel for them. This would let us send an .ics file over to people for their calendars, but we wouldn't have to bother generating meeting links via API. This again punts the issue onto another 3rd party provider, but one with very different semantics.

I'm honestly not sure which way is the more flexible way of doing things. I might have to somehow punt on this decision with an abstraction layer.

Service architecture

So obviously there needs to be a simple web app for users to sign up and manage their preferences. The trickiest part will be building out an actual UI that lets users express what times they're free. Since I have zero front-end or design skills, this is the scary part. Ideally you want users to indicate 30-minute chunks of time that they're typically available, across multiple days of the week.

That frontend will talk to an API backend that does all the actual operations and interacting with the database that holds the data model that supports allowing the system to efficiently query out who is available when. There'll have to be a lot of UTC and local time conversions involved. Ugh.

Then, aside from the frontend, and database, we'll need a backend service that does the heavy lifting of running regular weekly matching jobs to send out invitations to the correct people. If we go the discord bot route, we'd also have to run checks regularly so as to ping people on discord when meeting time arrives.

One question I have is whether any of this architecture can be done with serverless services. Probably? I'm not exactly sure how it all hangs together, but most things aside from the database piece can probably work that way. Maybe all of it if we trade the relational database with a key-value store

Then there's the problem of sending large amounts of email. The more users there are, the more likely you'll have to use an actual email sending service instead of a free SMTP service like gmail. Getting flagged as spam would be something like a death sentence for such a service. This probably means API integration with a mail sending service like Sendgrid/Mailgun or something else to help you manage the sending of emails and removing bounces.

Things to figure out

Probably the key decision that everything hangs on is what sorts of meeting invites are going to be sent and via what system. Everything else is pretty "trivial" once those bits are figured out. If various OAuth flows are needed, that'd be best handled in the registration flow. If we aren't going with calendars at all, then we can focus the energy on creating a discord bot or something.

So I still need to figure out the underlying tech to make this happen. If anyone reading this happens to know people who can point me in a good direction, tell me. I obviously don't write robust software for a living so I'll be reinventing all sorts of stupidity along the way.

I guess we're gonna see how far this brainworm goes.