Aaron Parecki

Lots of people are suddenly finding themselves working from home, and need to join video conferences from their living room or home office. Here are several tips to improve your virtual meetings and presentations on a budget! I'll start with some things you can do for free to improve your Zoom meetings. If you're recording virtual conference talks from home, or hosting live webinars, you'll definitely want to upgrade to a nicer camera, so take a look at my recommendations for the best video kits under $500 and under $1000!

Table of Contents

• Improve Your Audio for Free
• Improve Your Video for Free
• Upgrade Your Audio for Under $100
• Upgrade Your Video for Under $100
• Complete Budget Video Kit Under $500
• Complete Video Kit Under $1000

Free

First, here are some things you can do to improve your meetings and presentations without spending any money.

Improve Your Audio for Free

Mute yourself when you're not talking. This is probably the #1 recommendation especially for people who are new to working remotely. You would be surprised how much of a difference this makes for everyone else on the call. It can be hard to recognize this since you don't hear your own audio on the call, you can't really tell how much your background noise is spilling into the call for everyone else. This costs nothing, so there's really no excuse not to.

Sit inside your closet. Really the goal here is to reduce the number of flat surfaces around you. Flat surfaces will lead to more echoes, so whatever you can do to reduce the number of large flat surfaces the better. Sitting inside your closet will surround you with the soft non-reflective surfaces of your clothes and you will sound much better! Even the professional radio hosts are recording from their closets right now. If you can't fit in your closet, then you can hang blankets up on your walls to reduce the number of flat surfaces in your room.

Here's a recording comparing the audio quality between recording in a room with flat walls and recording in a closet. This was recorded from the built-in microphone on my laptop. Listen to these with headphones so you can hear the differences better!

Room

Closet

Improve Your Video for Free

Here are some tips for improving your video quality without spending any money. And it turns out that these tips also apply even if you have fancy cameras!

Use a window as a light source. Sit with your face towards a window so that it illuminates your face, or sit parallel to a window. The goal here is to use the light from the window to get some light on your face.

Whatever you do, don't sit with your back to a window, because you'll be horribly backlit and will look like a silhouette.

Avoid bright lights in the background of your video. Bright lights in the background like ceiling lights or windows will make the camera struggle to get a good exposure on your face.

Set your camera at eye level, not below. Set your computer or phone so the camera is at approximately eye level so that we're not staring at a view of the underside of your chin.

Avoid a cluttered background. This one can be a trick to balance with the idea of avoiding bright lights in the background depending on the layout of your room. And my photos above are not a good example of this at all. But if you can find a place where the background of your video is relatively plain, like a flat wall or closet doors, the camera will have a better time focusing on your face, and people won't be distracted by looking around your room.

Upgrades Under $100

If you're ready to spend a bit of money, here's what you can do for under $100.

Disclaimer: Many of the links in this post are affiliate links which means I get a small commission if you buy items from these links. I am very selective about products I recommend, and I have not been paid to endorse any of these products.

Upgrade Your Audio for Under $100

Use headphones. Using headphones, even ones without a microphone, will significantly improve your calls, since it will make sure the sound coming from your computer can't be picked up by the microphone. A classic problem with video conferences is if your computer sound can be picked up by your microphone, other people in the call will hear an echo of themselves, which is incredibly distracting.

Again, you won't be able to tell that it's your fault this is happening, because you don't hear your own audio on the call. Literally any headphones will do, in fact you probably already have some sort of headphones so this may not cost you anything additional anyway. I'm not going to give you a specific recommendation on headphones because anything is better than nothing.

Use a headset microphone. The next best thing you can do is to use a separate microphone other than the built in computer microphone. Moving the microphone closer to your face will pick up more of your voice and less background noise. Anything is better than nothing in this category, plus a headset microphone will usually come built in to headphones, so you get the previously mentioned benefits as well.

This $30 pair of headphones with built in microphone is a pretty affordable option! By no means are these the highest quality headphones or microphone, but again it's better than not having it! Generally headsets around this price range will be best for cutting out background noise on your end, even though the audio may sound "tinny" compared to a better microphone. Remember, when you're on a call, it's more important that your voice comes across cleanly without background noise rather than sounding like podcast-quality audio.

Headset Audio

Your iPhone EarPods will work too. Of course if you already have AirPods or fancier noise cancelling headphones, those are fantastic options too, but since they're more than $100 they aren't my top recommendation in this category.

AirPods

Bose QC35

Upgrade to a studio microphone. The Rode NT-USB Mini is a $99 studio-quality USB microphone. Plug this into your computer and you'll instantly be able to use it in recording apps like Garage Band, or use it as an audio source in Zoom, or even use it as a microphone in browser-based video conferencing software. This microphone sounds fantastic, and is a huge upgrade compared to headphone microphones. You'll want to make sure you sit a few inches away from the microphone to get the best sound out of it.

Here's an audio sample from the Rode NT-USB Mini microphone. For $99 this is hard to beat.

Upgrade Your Video for Under $100

Get a good webcam. The best you can do at this price is upgrade to an external webcam instead of the built in laptop webcam. This will give you a significant boost in quality, but only if you have also followed the advice in the "free" section above to make sure you have good lighting! Two solid options for external webcams are the Logitech C920 and C922, they're roughly equivalent, so get whichever one happens to be in stock, since they're both pretty popular right now. There's a handful of other cameras in this category, ranging from $50 to $300, but frankly you won't get that much better video out of the more expensive ones, so if you're interested in spending more, I'd recommend saving up for a more significant upgrade.

I have noticed that the Logitech camera tends to overexpose my face when there's a bright light on my face, but regardless, the image is much sharper and has less noise than the built-in webcam. Plus it's easier to avoid staring up your nose with an external webcam that can sit on top of a separate monitor.

Use your DSLR or mirrorless camera as a webcam. If you already have a DSLR or mirrorless camera with clean HDMI out, then you can use it as a webcam by buying an HDMI capture device. The best option at this price range is the Elgato CamLink 4K, if you can find it in stock anywhere. You can usually find it for between $99-$129. This of course assumes you already have a nice camera, but if you don't yet, that takes us to the next section.

Complete Budget Video Kit Under $500

So, what does $500 get you? Now we can upgrade a few different parts, and add some lighting as well!

The next upgrade from a webcam is the camcorder style cameras. A Canon Vixia R800 ($210) will get you a much better picture than a webcam, but you'll also need to spend money on an HDMI capture device to get the video into your computer.

You'll notice a sharp increase in the image quality with a camcorder compared to a webcam. It does a much better job with the exposure, and there is a lot less noise in the picture as well.

If Sony is more your thing, then you might check out the Sony CX405 Camcorder, a similarly sized and priced camcorder to this Canon, however the CX405 doesn't have a microphone jack so you'll have to use a microphone connected to your computer instead.

You can also attach external microphones to the Canon Vixia to get good audio without having to wear a headset. You'll want to get the microphone as close to your face as possible, and a great way to do that is to mount the microphone on a scissor arm so that it floats just above your head out of the frame.

We can even throw in some LED lighting and still come in under $500! Adding an LED panel will give your video a boost when you don't have good natural light from a window.

You might notice the harsh shadows on the backdrop now, but that's because I'm sitting only a few feet away from it. The farther away you are from the backdrop the less shadows you'll see. However, this is one of the drawbacks to these kinds of small LED panels compared to using a large window or larger LED light.

• Canon Vixia R800 ($210)
• Elgato Cam Link 4K* ($129)
• Movo VXR10 Shotgun Microphone ($39)
  (the Rode VideoMicro is good too, but it's almost double the price, and I think the Movo sounds better anyway)
• Neewer Microphone Suspension Arm ($14)
• Thread Adapter 5/8" to 1/4" ($5)
  to mount the microphone on the suspension arm
• 8-Foot 1/8" Audio Cable ($7)
  to plug the microphone into the camera
• Iwata GS-01 Bi-Color LED Light ($46)
• 2x 40" Selfie Stick Tripod ($34, $17 each)
  one for the camera, one for the LED light
• Total: $484 View the kit!

You'll be able to go a long way with this kit! You can even use this for doing pre-recorded conference talks, or high quality streaming on Twitch.

The nice thing about using camcorder-style cameras is they're optimized for long-running recordings and being plugged in to a power outlet. While you can definitely get better quality video out of a DSLR or mirrorless camera, you'll need to add an external power supply, and make sure there's no issues with the camera overheating when being in video mode constantly.

Keep in mind that using the Elgato Cam Link (or really any HDMI capture card) requires a pretty fast CPU. The Cam Link specifically requires at least a quad-core i5 processor.

The Movo shotgun microphone is a very different kind of microphone compared to the Rode NT-USB Mini. For one, this has an 1/8" output and is made to connect to cameras rather than computers. It's a shotgun style microphone, so it will capture your voice even if you're farther than a few inches away, although it's extremely directional so if you turn your head away from it the sound will drop off sharply.

If you need a slightly taller and more stable tripod, I would go with this 54" Selfie Stick Tripod, although it's big enough it's really not practical to use as a selfie stick anymore. The 40" tripod holds up the camera fine if extended only about half way, but starts to get a bit unstable once it's at its full height. The 54" one will hold it up no problem at the full height.

Why do I not recommend GoPros? GoPros are optimized for being action cameras, which includes things like being waterproof, shooting high frame rates and slow motion, and downloading footage into smart phones. These are not features you need in a camera for live video, so it doesn't make sense to pay the premium for them. Also, while they do have an HDMI output, it's not necessarily realtime, and will be delayed anywhere from 1/4 to 1/2 a second, plus you'll still need an HDMI capture card to get the video into your computer.

Complete Video Kit Under $1000

If you're willing to spend another $500, the next things I would upgrade are the camera and the lighting.

Cameras can quickly eat up a huge chunk of any budget, it's just a matter of how much you want to spend on them. In order to stay under our $1000 target, I would go with the Lumix G7 camera for $500 with the kit 14-42mm lens.

This is a fantastic entry-level mirrorless camera, and hard to beat at that price. You will notice a huge difference in the image quality with this compared to all our previous cameras.

You'll notice another sharp step up in quality between these cameras. There is again much less noise in the picture from the Lumix, and it's a lot sharper as well. It also tends to do better at worse lighting conditions. Both of these photos were lit with the 1'x2' LED panel linked below.

Once you start getting into this range of cameras, there will be some other things that we'll need to upgrade as well. For example we're going to need a stronger tripod, and also will need an external power supply for the camera so that we don't have to rely on its batteries.

• Lumix G7 with 14-42mm lens ($498)
• USB Power Adapter for Camera ($23)
• 2x 56" Aluminum Tripod ($114, $57 each) one for the camera, one for the light
• Elgato Cam Link 4K ($129)
• Movo VXR10 Shotgun Microphone ($39)
• Neewer Microphone Suspension Arm ($14)
• Thread Adapter 5/8" to 1/4" ($5) to mount the microphone on the suspension arm
• 8-Foot 1/8" Audio Cable ($7) to plug the microphone into the camera
• Rollable 1'x2' LED Panel ($160)
• Total: $989 View the kit!

This light is a 1x2-foot LED panel that rolls up into a small case for travel. Using a large light like this placed relatively close to your face will give you much softer light than a small light source. It's also of course far brighter than the small LED panel we looked at before as well.

With this kit, you'll be the best-looking participant on your remote meetings, you'll have fantastic quality livestreams on Twitch and YouTube, and you'll have a high-quality setup for recording videos that you edit on a computer later.

This is already a fantastic upgrade to your home office video rig. If you already had some of these items and have some extra money to spend, here are the next things I would recommend upgrading if you can afford it:

• This $60 Innogear microphone arm is a lot sturdier than the $14 Neewer arm, and is worth the little bit extra.
• Replace the $129 Cam Link with the $300 Blackmagic ATEM Mini, which is a 4-input HDMI switcher that has a USB port that acts as a webcam. It's unheard of for a device like this to be so cheap, typically these kinds of 4-input switchers are $1000 or more. If you're interested in learning more about how this device can make your live virtual events much more dynamic, check out my video on YouTube!
• Upgrade the lens from the 14-42mm kit lens to the 15mm Leica lens ($448). This lens opens up to f1.7 so you can lower your ISO and get a nice blurry background. This is the lens I use in most of my YouTube videos.
• Mount everything to a single pole arm on your desk and ditch the tripods. This will require about $200-300 of mounting brackets and various accessories, but Caleb Pike made an excellent video tutorial on all the parts you'll need.

If you want to take your home studio to the next level, check out my video on YouTube for a complete behind the scenes tour of how I host remote workshops from home!

I hope this post has given you some ideas on how to make better videos from home! Follow me on YouTube for more tips and tricks for getting the most out of a home office studio!

I've been working towards making Meetable more useful to others by making it easier to configure and deploy. I took a few shortcuts during the initial development that let me finish it faster, primarily by offloading authentication and image resizing to external services. While that's great for me, it means it requires setting up two additional projects if someone else wanted to get it running.

Today I made a few changes to make this a lot easier for others to install by removing some of these dependencies.

Meetable now can handle its own image resizing with no configuration! This is probably slower than using the external go imageproxy project, but this way there is no additional setup needed. I even made it use the exact same API, so you can launch Meetable with the built-in image resizing and switch to the external option later.

I also added a new option for logging in, so users can log in with their GitHub account now as well. It's actually a global configuration option as to whether you want to use the built-in GitHub authentication or the external authentication option using Vouch Proxy, so it's up to the site administrator which one to support. Thanks to some refactoring I did to make this work, it should also be possible to add additional options in the future, such as Twitter login.

Thanks to these two changes, you should now be able to install Meetable on a wide variety of hosting options! My next project is going to be getting it ready to deploy to Heroku to make it even more accessible!

At this point, if you're at least a little familiar with Laravel or Composer, it shouldn't be too difficult to set it up! Give it a try and let me know what you think!

https://github.com/aaronpk/Meetable

It's been a few weeks since I launched the new events site for IndieWeb events! In that time, the community has already hosted 7 events, and scheduled 15 more! I've continued to push a few minor changes to the site since the launch, primarily around discovery of events with tags.

The home page now lists a few "significant" tags at the top. These are tags used by two or more upcoming events. 

This strikes a good balance between having list that isn't overwhelmingly long, and also provides a good experience for discovering events when clicked. I wanted to avoid the case of clicking a tag and finding only one upcoming event.

I also added a new page "Discover", which for now shows just a list of tags in a sort of tag cloud. I spent some time on the sorting of the list, which places tags used in more than one city up front, and then tags used in just one city are sorted alphabetically afterwards.

The size corresponds to the number of events with that tag. You can see that they aren't sorted strictly by usage frequency. I think this does a pretty good job of showing tags relevant across a wide geography up front, then narrowing to the more specific city tags afterwards.

Open Source!

I had always intended on making this project open source, but I wanted to tidy up a few things before doing that. I initially had an ambitious list of making this an easy out-of-the-box solution at the time I made it open source, but I wasn't able to finish that list in time. Instead, I scaled back my open source goals to at least just have a nice README with installation instructions, even if the installation process still relies on too many moving parts than I am comfortable with.

Today I am releasing the project as open source under the MIT license! The project is called Meetable, and I've even registered the domain meetable.org to eventually launch a one-page website about the project there.

There are instructions on installing and configuring it, including full documentation of the config file.

I've also made a new milestone on the GitHub project for "Version 1.0" where I've collected all the things I want to do before I consider it really usable by others.

So I hope you will join me in continuing to make this site better! And hopefully it will be useful for other communities as well!

I'm super happy to announce the launch of a new website for IndieWeb events at events.indieweb.org!

This website is a place to find and post events for the IndieWeb community. Historically, we've used the IndieWeb wiki to collect events for the community. There are definitely some benefits to this approach, but there are also quite a lot of downsides.

My goal with this new website was to capture the best parts of a community wiki for events, while streamlining the process for creating events and making it easier to find what you're looking for as an attendee.

The rest of this post describes the motivations and design decisions for the website. If that is not interesting to you, you can stop reading now, and just know that it should be a lot easier to find and create IndieWeb community events going forward at events.indieweb.org!

Why do we need a new website?

Over the last year or so, I've spent a lot of time talking with organizers of the local IndieWeb events like IndieWebCamps or Homebrew Website Clubs. We've also grown a considerable amount this year, adding new organizers and expanding into new cities.

As we've been onboarding new organizers who are hosting events in their city, I continually see people struggling with the current process of listing an event on the wiki. It's not at all their fault either! Here's an example of what it takes to post a new Homebrew Website Club event, as described on the wiki.

If your event is not on a "regular" Homebrew Website Club day, then you'll need to add a new date to the wiki template of HWC dates, which means editing this template:

Create a page on the wiki for the event, the easiest way is to find a past event and copy the page and modify it for your city. That involves editing a page that looks something like this:

One part of this process that usually gets messed up is that the wiki markup needs to include the h-event Microformats HTML inside the wiki page. This enables some automation that we have, such as generating the IndieWeb newsletter with photos from the event.

It's far too easy to forget to add a closing </div> or forget the particular syntax for expressing dates and times in HTML and Microformats. I also personally think that it's not very friendly or accessible to make event organizers deal with this kind of low-level markup, and creates a barrier to people who would otherwise enjoy organizing meetups.

If you have a website that supports posting events on it yourself, then you're also encouraged to create an event post on your own website and link to it from the wiki.

Then, you need to make sure the event page is added to indieweb.org/Events so that people will actually find it. That also enables some of the automation like having the bot add it to the home page summary and adding it to the newsletter. Thanks to some wiki template wrangling by gRegor, it is at least a little easier to get the wiki markup right since you can use templates for it:

In practice, relatively few people have actually done this, and usually this ends up being done by either gRegor or Tantek.

At the end of all of this, attendees are left with an experience for discovering and RSVP'ing for events something like this.

Visit indieweb.org/Events to see what's coming next, and you're presented with a list like this:

I'm no designer or information architect, but even I can tell that this page is lacking in some very basic structure that would make it friendly to viewers.

If you manage to find a meetup in your city and click on it, then you visit the event page for the full details.

This now presents its own list of challenges.

• The "When" section at the top lists a time range, but in reality each location sets their own times so you have to double check below
• You have to scroll through several other cities listed on the page to find the details for the one you're looking for
• There's just a lot of visual clutter here, largely due to being constrained by the wiki environment

So needless to say, this is not a very good experience for event organizers or attendees.

We've talked about trying to improve this situation at various organizers meetups in the past, but never came up with a conclusive plan. I decided that it would be my personal goal to launch a new website to solve these issues so that we can go into 2020 with a much nicer experience for events.

I am happy to say I believe I have addressed nearly all the issues with our current system, while still making it as flexible to use as the wiki.

Here's a quick overview of roughly the feature set of the new events website.

Finding Events

List of upcoming events - the home page is a list of all upcoming events

Archive pages - past events can be found by browsing a year page or month page.

Tag pages - events can be tagged, and tag pages show all events with that tag! This can be used to create city pages showing events only in that city, for example: #austin.

iCal feeds - every page has an iCal feed you can add to your calendar! You can add the home page iCal feed to get a list of all events, or you can add a tag page feed to get just events in your city.

Microformats - of course every page is marked up with h-event Microformats, so you can subscribe to this in software that supports that vocabulary, or use it as an API for getting events from this website for things like the IndieWeb Newsletter.

Authentication - if you're logged in to the IndieWeb wiki, then you're already logged in here!

Wiki-like editing - anyone who is logged in can add and edit all the details of events, just like if it were a wiki page.

Event Permalinks

Events have their own permalinks which have the following features:

Cover image - events can have a cover image that shows up at the top. These are always cropped to a fixed size for consistency.

Photo gallery - photos can be added to the event page, and they show up as a nice photo gallery. The first photo is shown full width, and then below that is a grid with the rest of the photos.

The photos can be clicked to view larger, and you can also add alt text for the photos as well. The photos can be re-ordered by dragging them around if you're logged in.

You can either upload photos to the event directly, or you can add photos by posting them on your own website and sending a webmention to the event page!

Related blog posts and comments - event pages can show related blog posts about an event, which is a fun way to capture what people have written after an event. See IndieWebCamp Amsterdam 2019 as an example. If you want to add your own post to an event, just link to the event page and send a webmention!

RSVPs - RSVPs are handled in two different ways. If you're logged in, you'll see an "I'm Going" button on upcoming events. You can click it to add yourself to the RSVP list immediately. The event pages also accept RSVP Webmentions so you can RSVP from your own website.

HTML and Markdown description - the main page for the event supports Markdown and a limited subset of HTML tags for formatting. You can use this to provide full details of an event, or even add things that aren't otherwise supported by the website.

Add to calendar - every upcoming event has an "add to calendar" button which provides both an iCal event as well as a like to add to a Google calendar.

Timezone converter - for events that have a specific start time, the time links out to a page that shows that time in multiple timezones. This is mainly useful for virtual events like Virtual Homebrew Website Clubs, or if you're trying to remotely join another event.

The time of the event is shown along with the time of the event in the timezone your browser reports. Below that is a list of the equivalent times in all timezones used by other events in the website.

URL Design

One of my main goals with the event URLs was that I wanted them to be meaningful to humans. This means communicating some context about the event from the URL alone.

That means avoiding the URL patterns from Twitter and Instagram which are just a random string.

I opted to go with the pattern: YYYY/mm/slug-id. This conveys a rough approximation of the date of the event (year and month only). The slug is a generated slug from the name of the event, converting everything to lowercase and removing non-alphanumeric characters, separating words with hyphens. The id portion is a unique identifier for the event which doesn't change after it's created.

If a post is updated to have a new name, a new slug is generated. Because the permalinks only rely on the unique ID, it doesn't actually matter what your enter for the year or month or slug portion of the URL, you're always redirected to the canonical based on the ID in the URL.

The only thing about this that I'm not entirely happy with is the random ID at the end. I feel like it's taking the easy way out with URL routing at the expense of being friendlier to look at. The upside is that a lot of technical challenges become a lot easier doing it this way, I don't have to store a list of past slugs to support redirects for example, so I thought it was worth the tradeoff in this case. I put it at the end because when a portion of the URL is shown in Twitter or Slack for example, you'd be able to see the most meaningful parts of the URL even if the end is cut off.

Creating an Event

I wanted creating an event to be as straightforward as possible. To start with, there's a giant "Add an Event" link in the top navigation bar, which is already an improvement.

One challenge I quickly ran into was that adding fields for all the information needed about the event quickly turns into quite a large form. I didn't want to split it into multiple pages, so instead I broke the page into sections.

To start, you enter the name of the event, and optionally add a cover image. The image will be cropped and a preview will appear immediately.

Next, you'll add information about the location of the event. Ultimately these are just regular text fields, but the "search for a location" box on top can help you automatically fill them out by looking up a location.

If you start typing in that box, it will use the Google Maps autocomplete API to find venues matching your search.

Clicking on one of the options in the list will then fill out the details in the rest of the fields, and you'll see a little map appear as visual confirmation.

Of course you're free to not use the venue search at all and just type in the details manually. Or for virtual events with no physical location you can just enter "Online" as the venue name.

Next up is adding the date and/or time of the event.

If you do use the autocomplete and select a venue, then an additional bonus is that it finds the matching timezone for that location as well.

This is where it gets a bit tricky. I've made a couple of design decisions around date handling to simplify both the data entry as well as presentation of dates and times for events. I'll describe those in detail a bit later.

Lastly, you can add a link to the event's website if it has one, add a description, and add one or more tags.

You'd want to include a link to the event's website if for example it requires that you register for tickets to attend the event. Since IndieWebCamps require ticket registration, we'll be linking out to the individual IndieWebCamp's page to buy tickets. We've been using a pattern of YYYY.indieweb.org/city for a few years now, and it's worked out pretty well. But if you're adding something like a Homebrew Website Club that doesn't have its own website, you just leave this blank and this page effectively becomes the canonical link for that event.

The description field supports markdown and a limited set of HTML tags for formatting. For events with their own website, I'd recommend leaving this description relatively short. But if you want this page to be the canonical event page, feel free to use multiple headers, embed images, and make it look as nice as you want.

Tags are a great way to collect related events so they can be found easier. I'd definitely recommend adding a tag for the city of the event, such as "austin", so that people can then visit the tag page to find events in their city. You can also add tags like "indiewebcamp" or "hwc" which then provide a quick way for people to find all upcoming Homebrew Website Clubs regardless of location.

Clone event - in order to support quickly adding recurring events like Homebrew Website Clubs, you can click the "Clone Event" button on a previous event, and quickly make a new event by changing only the details you want.

Date and Time Handling

Deciding how to handle dates, times, and timezones was one of the most challenging parts of this project. If you've ever dealt with building systems that handle times and timezones you'll know what I mean.

I decided to have essentially four distinct ways an event can present its date/time on this website.

One-day events - an event that takes place during some portion of one day. This is intended for things like evening events, one-day IndieWebCamps, or other full-day conferences. To create this event, enter only the start date, and enter a start and optionally enter the end time.

Depending on whether you enter a start and end time, the event date will be displayed as one of the below:

If you don't enter a timezone, then these times are considered "floating times" or "local times" and the system doesn't know when it actually occurs. The iCal feed that it produces will also output it as a floating time, leaving out all timezone information. Calendar apps should add this as either a floating time in your calendar, or snap it to your local timezone when you add it. That can cause some edge cases such as when you add an event in the future that will be in a timezone different from where you are when you add it.

If you add a timezone when you create the event, then it will display the timezone there as well as include it in the iCal feed, and you'll avoid the floating time issues.

Multi-day events - an event that spans more than one day, such as multi-day conferences.

I took the liberty of deciding that in this case, the times of the event are never shown. In practice, I find it to be more confusing than helpful when an event is shown as being "January 20, 8:00am through January 21, 5:00pm". Does that mean I am expected to be there overnight? What time do things wrap up the first day? etc. etc. Instead, it's far more helpful for the overall date range of the event to be displayed at the top, and then elsewhere provide the detailed day-by-day schedule. This is how we've handled it with our pages like IndieWeb Summit which show the date summary at the top and a detailed schedule grid below.

So to create multi-day events, you only need to enter the start and end dates. Even if you enter times, they will be ignored by the system. The timezone is also unnecessary in this case because it's not needed in order for something reading the feed to show the same date range.

That will be displayed without any time or timezone information.

If the date range spans a month boundary, then both month names appear of course.

In this case, the iCal feed also omits the times and timezone. That means adding it to a calendar app adds it as a floating date. I've had Apple Calendar and Outlook both mess up multi-day events when there's a timezone specified, so that it looks like the event starts at 5pm local time the previous day, which is really confusing. This should prevent that from happening.

Open Source

My goal is to eventually open source this project so that others can use it for their own community. I'm actually planning on running a copy of it on oauth.net to collect OAuth community events as well.

That said, I feel like it's not quite ready to open source, so I'm holding off on that for the time being. Here are some of the things I need to solve before I'm ready to publish this.

• Create a web installer - I'd like the installation experience for this to be more like WordPress and not require command line configuration. The installer should walk you through checking system requirements, setting up the database, etc.
• Drop dependency on go imageproxy - The go imageproxy that this uses for quickly resizing images is great, but it's a barrier to setting this project up. This project should download and resize images it needs and serve them locally.
• Add authentication options - Right now the only authentication option is looking at the HTTP Remote-User header, which is a great way to tie this in to existing authentication systems. I'll need to provide alternatives for people who don't have an existing authentication system already.
• Theming/Styling/Customization - The design of this project is intentionally minimal, my goal is to allow some flexibility in styling it to match an existing website. I'm not sure what form this should take (WordPress themes are way more than I want to do), but some amount of customization is necessary.

Replacing the use of the IndieWeb wiki for events

My goal is to not have any 2020 events on the IndieWeb wiki! I think this project is far enough along that it can effectively do everything the wiki can do around events and more.

I've already added all the upcoming 2020 events that were on the wiki into the new website. Going forward, it should be significantly easier adding events on this website rather than the wiki. There will only be a little bit of cleanup to do around some of the automations such as the list of upcoming events on the home page and the newsletter.

I'm sure there are some things I forgot to address while building this, so if you're an organizer of any IndieWeb events, please do let me know what I may have missed.

So let me know what you think! I'm really excited to have finally launched this after spending so long designing and building it. Thanks to everyone who helped me talk through the early prototypes of this idea. I'm hoping it makes for a much better experience for everyone who hosts and attends IndieWeb events!

Trying to understand OAuth often feels like being trapped inside a maze of specs, trying to find your way out, before you can finally do what you actually set out to do: build your application.

While this can be incredibly frustrating, it’s no accident that OAuth is actually made up of many different RFCs, building upon each other and adding features in different ways.

In fact, the “core” OAuth spec, RFC 6749, isn’t even called a specification, it’s technically a “framework” you can use to build specifications from. Part of the reason for this is because it leaves a lot of things optional, and requires that an implementer makes decisions about things like which grant types to support, whether or not refresh tokens are one-time use, and even whether access tokens should be Bearer tokens or use some sort of signed token mechanism.

This has often been quoted as the biggest failure of OAuth, but is also a large part of the reason OAuth has been successfully deployed at the largest companies at scale over the last 10 years.

OAuth has been patched and extended a lot in the last decade of experience deploying systems using it. It’s been extended in ways the original authors could never even see coming. Keep in mind that when OAuth 2.0 was published in 2012, the iPhone 5 was brand new, the latest browser from Microsoft was Internet Explorer 9, single-page apps were called “AJAX apps”, and CORS was not yet an established W3C standard.

Since 2012, the web and mobile landscape has changed dramatically. More people access the internet from mobile devices than desktop devices, single-page apps are an extremely common way of creating web apps, and countless password database breaches have time and again demonstrated that storing passwords is dangerous.

The Evolving OAuth 2.0 Landscape

To address this changing landscape, the OAuth community has patched and added to the OAuth spec over the years. The OAuth core spec (RFC 6749) defines four grant types: Authorization Code, Implicit, Password, and Client Credentials. It used to be the case that the Implicit grant was recommended for both JavaScript apps as well as native apps.

It became apparent that a better solution was needed for mobile apps, so PKCE (RFC 7636) was created to provide a way to use the Authorization Code flow without a client secret.

Later, “OAuth 2.0 for Native Apps” (RFC 8252) was published, which recommends that native apps use the Authorization Code flow with the PKCE extension.

A new class of device arose along with a need to use OAuth with them: devices that have no browser or lack a keyboard, such as an Apple TV or YouTube streaming video encoder. An entirely new OAuth grant was created to address this, called the Device Grant, published as RFC 8626.

There are even more patches currently in the works. I am writing a draft for best practices for single-page apps, and the latest Security Best Current Practice (BCP) is currently in the final call. The single-page apps draft recommends using PKCE with JavaScript apps and says you should no longer use the Implicit flow. The Security BCP effectively deprecates the Implicit flow as well as the Password grant out of OAuth entirely, and further recommends using PKCE even for web server apps.

So what started out as a list of four grant types has had things added and removed, and now looks more like this.

Which, if you look closely, actually ends up distilling down to this:

So what we’ve effectively done is taken the core OAuth RFC, added and removed things, and turned it into an entirely different set of recommendations. The problem is that it requires reading far too many RFCs to understand this landscape.

If you want to implement a secure OAuth solution today, it requires reading: RFC 6749 (OAuth 2.0 Core), RFC 6750 (Bearer Tokens), RFC 6819 (Threat Model and Security Considerations), RFC 8252 (OAuth for Native Apps), RFC 8628 (Device Grant), OAuth for Browser-Based Apps, OAuth 2.0 Security Best Current Practice, RFC 7009 (Token Revocation), RFC 8414 (Authorization Server Metadata), and if you’re also implementing an OAuth server, then you need to read RFC 7519 (JWT), JWT Best Current Practice, JWT Profile for Access Tokens, and probably some others that I forgot. That’s a lot of material.

Why not OAuth 3?

So why am I suggesting an OAuth 2.1? Surely we should instead scrap this existing work and create something simpler and more streamlined?

As it so happens, that effort is already under way as well, being led by Justin Richer under the name Transactional Authorization, or TXAuth, and likely to end up as OAuth 3. That effort takes a completely greenfield approach, rethinking how OAuth and all its related specs and extensions such as UMA might look if everything were not tied to being an extension of the original OAuth 2.0 RFC 6759. I’m definitely in support of this effort, there are a lot of nice patterns that emerge when you look at it this way, but as we all know, creating a new spec from scratch is not a quick process, much less getting broad adoption within the industry. So while effort on OAuth 3 is under way, which will take literal years to finish, there is room to tidy things up with OAuth 2 in the mean time.

Creating OAuth 2.1

At the OAuth working group meeting in Singapore last month (IETF 106), I led a discussion about OAuth 2.1 and what it should encompass.

My main goal with OAuth 2.1 is to capture the current best practices in OAuth 2.0 as well as its well-established extensions under a single name. That also means specifically that this effort will not define any new behavior itself, it is just to capture behavior defined in other specs. It also won’t include anything considered experimental or still in progress.

There was a general agreement from folks in the room that something like this is needed, and following the official meeting, I led a two-hour breakout session where a dozen or so of us dove into more details and started making a plan.

Torsten, the author of the Security BCP made a comment which I thought framed the discussion well. His goal for OAuth 2.1 is that it should make the Security BCP irrelevant because it already includes everything the Security BCP says. In other words, there should be no need to document the most secure way to implement OAuth, since that should be the only option available when you read the spec.

What is OAuth 2.1?

We still need to discuss the specifics about what form this document will take, whether that is going to be an entirely new RFC that replaces RFC 6749, or a BCP that references the other specs, or something else entirely. However, the overarching goals are:

• Give people a starting point which lays out a clear path for what they will need to read
• Reduce the number of documents people have to read to understand OAuth and implement it securely
• Get rid of the irrelevant content in old RFCs that has been deprecated, so that readers don’t get through an entire section only to discover a later RFC deprecated it
• Labeling libraries or products as OAuth 2.1 is a lot simpler to understand than having to figure out whether it accurately implements OAuth 2.0 and all the desired extensions

The specifics of what will be included in OAuth 2.1 are still up for discussion within the group, and will be in the agenda of the upcoming IETF meetings. The starting point for these discussions is roughly the below.

• Start with OAuth 2.0 Core, RFC 6749
• Include OAuth 2.0 Bearer Tokens, RFC 6750
• Adopt the Security BCP, which removes the Password grant and the Implicit flow
• Require PKCE for all client types, not just public clients (defined in the Security BCP)
• Adopt the native app and browser-based app BCPs
• Include the Device Grant as a top-level grant option available (RFC 8626)
• Include Token Revocation (RFC 7009)
• Include Authorization Server Metadata (RFC 8414)

If an authorization server intends to interoperate with arbitrary resource servers, such as OAuth services and open source projects, then there is an additional set of requirements that includes:

• Token Introspection (RFC 7662)
• JWT Access Tokens (current working group draft)
• JWT Best Current Practice (current working group draft)

Of course all of these points are currently up for debate, so if you have feelings about them, you should definitely join the mailing list and discuss them!

Currently the biggest question for the group is whether or not OAuth 2.1 should make technically breaking changes. It definitely won’t define anything new itself, but if you look at what the Security BCP says, it requires PKCE for all authorization code grants, even for confidential clients. Since most current deployments of OAuth 2.0 only support PKCE for public clients, that means most current deployments will not be compliant with OAuth 2.1 out of the gate. There are arguments on both sides of this, which was a large part of the discussion during the breakout session last month, with no clear consensus.

These are the kinds of questions that will be discussed in the coming months within the group. If you have thoughts, I would be more than happy to hear them! Feel free to send an email to the list directly, or even write a blog post in response!

I’m excited for this work to kick off, and looking forward to many more discussions going forward!

Now is your chance to join and ask me your OAuth questions!

💻 Tuesday 11am-12pm PST: OktaDev Office Hours

📕 Wednesday 10am-1pm PST: Intro to OAuth 2.0 with O'Reilly

🔐 Thursday 11am-12pm PST: Protecting Your APIs with OAuth

Okta Developer Office Hours

Tue Dec 10 11am-12pm PST

Join myself and Okta coworkers for our latest edition of virtual office hours! We'll be streaming on YouTube and taking questions via the chat! Make sure to subscribe to OktaDev on YouTube and click the bell icon to be notified when we go live! You can ask us anything about OAuth or user management in .NET!

Hands-On Introduction to OAuth 2.0

Wed Dec 11 10am-1pm PST

In this three hour workshop hosted by O'Reilly, I'll be covering the basics of OAuth 2.0 and working through the most common grant types. We'll be doing some exercises to demonstrate the OAuth flows from scratch. Access to this workshop requires an O'Reilly Safari Online subscription.

Protecting Your APIs with OAuth 2.0

Thu Dec 12 11am-12pm PST

In this free webinar, I'll be diving in to how you can use OAuth to protect your APIs, talking about things like how to use JWT access tokens and the tradeoffs that come with them, how to design scopes to allow granular access, and how to leverage a microservices architecture protected by OAuth at a gateway.

We'll be giving away a copy of my book to one lucky winner as well!

Register now!

I realized I have been avoiding leaving tips in Foursquare because I didn't have a good way to post them from my website. So today I added the ability to syndicate my posts as Foursquare tips.

I have three different ways my posts can end up as tips on Foursquare:

• I can reply to one of my checkins
• I can reply to a Foursquare venue URL directly
• I can send the text of a checkin itself as a tip

That last one is interesting, because it doesn't quite map to the normal way tips end up on Foursquare. But I realized that sometimes I write text in my checkins that is actually more like a tip anyway, so I wanted to give myself that option.

I'm probably most likely to use the first option of replying to one of my own checkin posts to leave a tip. Since my checkins appear in my reader, I can actually post directly inline from the reader to go back and leave tips.

I also made the decision to not try to syndicate these automatically, instead I have to manually click the syndication option before my site will attempt to syndicate the post.

Here's what a checkin post on my website looks like:

And here's what that tip looks like syndicated to Foursquare:

Overall this was pretty straightforward to do. The hardest part was dealing with finding the Foursquare venue URL from my own internal storage of my posts for the three different options.

The Foursquare API for this is reasonably well documented (Add a tip to a venue), but there were a few gotchas. It's not immediately obvious from that page that you need to include the access token as a post body parameter, and you also need to include an API version string. These are documented elsewhere in their docs, so it didn't take too long to find, but if you just start out reading the specific API method you want to use, it's not mentioned there at all.

There is also a parameter in the API docs called "url" which is described as "A URL related to this tip" with an example value of "http://blog.zagat.com/taco-survey-results-are-here". At first I was excited that I may be able to link my Foursquare tips back to my website. But every time I tried including a URL in the request, I got back a generic error "bad tips/add request". Leaving out that parameter made the API call work. Oh well.

So hopefully this will encourage me to leave more tips on Foursquare! I find the tips very helpful when I travel, so I'm happy to contribute back to this data set!

At IndieWebCamp Amsterdam I finally implemented unlisted posts for my website! This has been on my list for a while, and is a prerequisite for being able to do fancier things like posting full photo albums to my site, so I decided to take the plunge and finally get this done.

There has been some brainstorming about this for other Micropub clients and servers already, which was a very helpful start.

I made a couple decisions about how this should work on my site that I am not necessarily completely set on. I wanted to document this before I forget and look back at my code months later and think "why did I do it this way?"

On my website, an "unlisted" post:

• Does not show up on my home page, or any "channel" page like /notes or /articles
• Does not show up on date or month permalinks
• If the post is tagged, it does not show up on the tag pages
• The post will still show up in searches
• The post will still send webmentions for any links in the post
• The post will not be delivered to my ActivityPub followers at all
• The post still uses my same URL scheme, which uses sequential numbers after the date, so these unlisted posts are still enumerable

That last point is very intentional. I don't want to accidentally start treating unlisted posts as a form of access control. I don't want to pretend they are not public. If I had used some sort of longer non-enumerable string in the URL, then it has the risk of looking like a secret URL, and I may be tempted to treat it as a form of private post. Instead, I want to implement private and protected posts as truly protected by requiring the viewer to log in to view them.

I'm on the fence about whether unlisted posts should show up in search. My reasoning is that the act of typing in a search term means you're looking for a particular thing, which is very different from browsing my home page or even tag pages. On the other hand, YouTube implements unlisted posts by making them truly not discoverable unless you know the URL (hidden from search, lists, recommendations, etc). I think I'll leave it like this and see if I'm comfortable after using it for a while.

Implementing this on my site wasn't very hard, because I had quite a bit of ground work laid already. The interesting thing was the cascade effect it had once I wanted to go and actually post an unlisted post. I decided to add a dropdown to Quill, the app I use to post most of my content on my site. However, since many other people use this app too, I didn't want to just add this dropdown if other websites won't recognize the field. So I had to add a mechanism to Quill to ask your website whether it supports unlisted posts.

We have some precedent in Micropub with this kind of thing around querying the Micropub endpoint for which kinds of posts it supports. Quill uses this to disable some of the posting interfaces for servers that don't support those kinds of posts. Micro.blog added this earlier this year so that if you're using Quill with Micro.blog, you will only see the posting interfaces that Micro.blog can handle.

This is the new dropdown in Quill:

If your Micropub endpoint returns "visibility" in the config query, then Quill will show this new dropdown in the note interface!

Special thanks to @sebsel for talking through some of this brainstorming with me during IndieWebCamp!

The new draft spec at OAuth.xyz outlines a potential way to completely re-think OAuth from the ground up.

The XYZ spec, also nicknamed Transactional Authorization, effectively consolidates all of the different variations of OAuth that have evolved over the last decade, and plugs up a few security holes as well.

OAuth 2.0 has served us well over the last 10+ years, and has even been extensible enough to evolve to meet the new requirements of things like mobile apps and apps running on devices that don't have a browser or keyboard. It's hard to imagine that OAuth was originally created before the iPhone existed! That said, this extensibility has sometimes come at the cost of additional complexity, or at the cost of security. Many of the original assumptions that were made while designing OAuth 2.0 no longer apply, and the world of online security is very different today than it was 10 years ago.

The XYZ spec takes everything the industry has learned from OAuth 2.0 and OpenID Connect over the years and consolidates them into a uniform pattern, reducing reliance on less-secure communications channels, and building in flexibility in a consistent way.

If you're interested in the details of XYZ, the website oauth.xyz does a great job of laying out all the use cases with examples.

This post is not an overview of what XYZ is. Instead, what I'd like to talk about today is a suggestion for extending XYZ even further to encompass some additional use cases that have emerged, specifically about adding the user's identity information to the core protocol.

Identity has always been part of OAuth

OAuth was never intended to communicate information about the user who logged in to the app. This is a common point of confusion, usually wrapped up in the "authorization vs authentication" discussion. OAuth was originally created to give third party apps access to a user's account to read or write data at the API.

Naturally, many apps that want access to a user's resources also want to know who that user is. What ended up happening is most OAuth APIs added an endpoint that returns profile information about the user when requested with the access token. You can see this in common APIs like GitHub, Instagram, and Twitter. These were all developed independently, so they all work slightly differently and return data in slightly different formats.

GitHub

https://api.github.com/user
Authorization: Bearer XXXX

{
  "login": "aaronpk",
  "id": 1234,
  "node_id": "MDQ6VXNlcjE=",
  "avatar_url": "https://avatars3.githubusercontent.com/u/113001?s=460&v=4",
  "gravatar_id": "",
  "url": "https://api.github.com/users/aaronpk",
  ...
}

Instagram

https://api.instagram.com/v1/users/self/?access_token=XXXX

{
  "data": {
    "id": "1574083",
    "username": "aaronpk",
    "full_name": "Aaron Parecki",
    "profile_picture": "https://scontent-dfw5-2.cdninstagram.com/vp/a37666da4d6b670a849e7b77235e4d56/5DCD3710/t51.2885-19/s320x320/52837124_579812379154942_8897415153306304512_n.jpg?_nc_ht=scontent-dfw5-2.cdninstagram.com",
    "bio": "OAuth hacker",
    "website": "https://aaronparecki.com",
    "is_business": false,
    "counts": {
      "media": 1572,
      "follows": 285,
      "followed_by": 505
    }
  }
}

Twitter

https://api.twitter.com/1.1/account/verify_credentials.json

[
  {
    "id": 14447132,
    "id_str": "14447132",
    "name": "Aaron Parecki",
    "screen_name": "aaronpk",
    "location": "30,000 feet",
    ...
  }
]

OpenID Connect

OpenID Connect is built on top of OAuth 2.0 and provides a mechanism for applications to get the identity of the user that signs in. It does this in two ways.

The idea of returning profile information given an access token was standardized in OpenID Connect in the "UserInfo Endpoint". When a provider supports this endpoint, a client can send an access token and get back a representation of the authenticated end user.

OpenID Connect UserInfo Endpoint

https://authorization-server.com/userinfo
Authorization: Bearer XXXXX

{
  "sub": "https://aaronparecki.com/",
  "name": "Aaron Parecki",
  "email": "aaron@parecki.com",
  "preferred_username": "aaronpk",
  ...
}

This ends up looking very similar to the provider-specific endpoints that we looked at above.

OpenID Connect ID Tokens

The other way OpenID Connect deals with identity is by defining a new type of token, an "ID token". The ID token is defined as a JSON Web Token (JWT) that encodes the user's profile information. This ID token is then returned in response to an OpenID Connect request, either returned in the redirect URL using the implicit flow, or returned alongside the access token using the authorization code flow.

In the case of the implicit flow, the application that receives the ID token needs to validate the JWT signature and all the JWT claims, because otherwise anyone could drop an ID token into an application to be signed in. This is a standard part of the plain OpenID Connect workflow.

Applications that also need an access token in addition to the ID token should be using the authorization code flow to obtain the access token, otherwise they are at risk of the access token leaking.

So if an application is getting both an access token and ID token, the simplest way is to get both via the authorization code flow, so that both tokens end up being returned in the response to exchanging the authorization code at the token endpoint. This ends up looking like the below.

POST /token
Content-type: application/x-www-form-urlencoded

grant_type=authorization_code
&code=XXXXXXXXX
&redirect_uri=https://example-app.com/redirect
&client_id={CLIENT_ID}
&client_secret={CLIENT_SECRET}

{
  "access_token": "SlBV32hkMG",
  "token_type": "Bearer",
  "expires_in": 3600,
  "refresh_token": "2xMBxBtEp3",
  "id_token": "eyJhbGciOiJSUzI1..."
}

The interesting part about this is that in this case, the ID token validation step can be skipped completely, since validating it would provide no additional benefit. The application already knows it's talking to the right server, it knows the response is coming from that server, and the connection can't be tampered with since it will be made over HTTPS. This means the application can just extract the data it needs from the ID token and use it directly.

The problem with this approach is that this is essentially providing the application with a point-in-time snapshot of the user's profile information. If their profile information changes, there is no way for the application to get that update unless it either fetches the information from the userinfo endpoint or if the user signs in again. While this may only be a minor annoyance for things like the user's name, it is potentially dangerous for other profile information such as what groups a user belongs to, or other things the application may be relying on to modify its behavior based on the logged-in user.

It also means that the entire profile information for the user is pushed to the application whether it needs it or not. And again, while this may not be a big deal if the only profile information sent is the user's name and email address, it can be potentially a lot of data such as groups, roles, or other provider-specific information that the authorization server may have about the user.

Identity in XYZ

While we're re-thinking OAuth from the ground up, we should also re-think how identity is handled within the system, while drawing from the experience of widely deployed systems. Rather than returning an ID token with potentially stale or large amounts of user information in the authorization response, let's return only the minimum necessary for the application to function, and let it request additional information that it needs when it needs it.

Transaction Request (Authorization Code Exchange)

In XYZ, the application takes the interact handle it got from the redirect and makes a POST request back to the authorization server to get an access token. (Described in Transaction Request.)

POST /authorize
Content-type: application/json

{
  "handle": "80UPWY2NM33OMUKMKSKU",
  "interact_handle": "CuD2MrpSXVKvvI6dN2awtNLx-HhZy46hJFDBicG4KoZaCmBofvqPxtm7CDMTsUFuvcmLwi_zUN70cCvalI6ENw"
}

We'll extend the response as described next.

Transaction Response (Access Token and User Identity)

In addition to the access token being returned, the user identifier can also be returned in the same response.

The transaction response can include just the unique user identifier along with the access token.

{
  "access_token": {
    "value": "UM1P9PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0",
    "type": "bearer"
  },
  "user": {
    "id": "5035678642"
  }
}

This property is analogous to the "sub" property in an ID token. This value MUST uniquely identify this user within the system, and MUST be consistent when the same user logs in to the same application. The value MAY vary for the same user when logging in to different applications in order to preserve the user's privacy, preventing different applications from cross-correlating users between apps. (This is based on the deployed behavior of several APIs such as Facebook's "app-scoped IDs" and Apple's app-specific user ID and proxy email address.)

If the application needs to know profile information about the user, it can get that from the userinfo endpoint using the access token it just obtained.

We can go one step further and also return the userinfo endpoint at the same time as returning the user's unique identifier, avoiding the need for the app developer to hard-code this value in the app or find it in a separate discovery spec.

{
  "access_token": {
    "value": "UM1P9PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0",
    "type": "bearer"
  },
  "user": {
    "id": "5035678642",
    "userinfo": "https://authorization-server.com/user/5035678642"
  }
}

This provides the additional advantage of the opportunity for the authorization server to use a unique URL per user if it wants (although that is by no means a requirement, since the access token will need to be included in the request too).

If the application then wants to discover profile information about the user, it can make a request to the userinfo endpoint with the access token:

GET /user/5035678642
Authorization: Bearer UM1P9PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0

{
  "id": "5035678642",
  "name": "Aaron Parecki",
  "nickname": "aaronpk",
  "email": "aaron@parecki.com",
  "photo": "https://aaronparecki.com/images/profile.jpg",
  "zoneinfo": "America/Los_Angeles"
}

This ensures that the application knows that it can get the latest version of the user's profile information whenever it needs to by continuing to make requests to the userinfo endpoint, and prevents the temptation to treat the initial snapshot of the profile information as authoritative.

If we don't address this need in XYZ, we'll risk ending up in the same situation we're in with OAuth 2.0 where providers end up implementing their own snowflake APIs to let apps find the user's profile information anyway.

tl;dr This is a good move for users in the iOS ecosystem, and is primarily designed as an alternative for apps that currently use "Sign in with [Facebook/Twitter/Google]" to avoid leaking sensitive user info.

Yes, Apple is entering the OAuth ecosystem as a new identity provider. Turns out every iOS user already has an Apple account, so why not enable users to sign in with an account they already have?

Most of the time the way apps use OAuth providers is just to identify users. This is designed to be an alternative to using Facebook/Twitter/Google for that purpose.

This is distinctly different from the case where an app wants you to sign in with your Google account so that it can manage your calendar. Or sign in with Snapchat to apply a filter to your profile picture.

Those use cases are more along the lines of what OAuth was originally intended for: letting apps access your account without giving them your password.

Over the years, apps started to use OAuth to identify users because it's a quick way to find out and verify someone's Twitter/Facebook/etc account without having them type it in. This turned out to be bad for users' privacy:

Once an app knows your Twitter username or your email address, they can sell it to advertisers, or track your activity across other apps. Apple's approach provides a unique scrambled email address to the app, preventing this.

Now you may have heard people concerned by this clause from the new App Store Review Guidelines:

Sign In with Apple [...] will be required as an option for users in apps that support third-party sign-in when it is commercially available later this year.

Sign In with Apple is a good thing for users! This means apps will no longer be able to force you to log in with your Facebook account to use them.

This does not mean that Apple is requiring every app to use Sign in with Apple. This does not mean that apps that want to manage your Google Calendar will have to also add Sign in with Apple.

Yes, this is a little additional work for app developers to support another OAuth provider, but is really not that different from supporting both Twitter and Facebook, or Snapchat and Instagram.

At the end of the day, the benefit of signing in to apps is to be able to save stuff to your account so you can restore it later, and to get email notifications.

"Sign In with Apple" provides apps with both those features without revealing any more information about you than necessary.

So yes, Sign In with Apple is a good thing for user privacy, and will be a better user experience overall.

Is Apple using their position as gatekeepers of the App Store to force adoption of "Sign In with Apple"?

Yes.

Is this a bad thing?

No.

Does this affect you if you don't use an iOS device?

No.

Does this benefit people who have an iOS device?

Yes.

Will we see other OAuth providers follow suit and start randomizing email addresses and user IDs returned to apps? I hope so!

Ironically, Facebook first started doing this a few years ago when they launched app-scoped user IDs.

Anyway, if you're curious about what this will look like, I wrote a sample app that uses Sign In with Apple so you can see how it works.

What the Heck is Sign In with Apple?

Sign In with Apple is based on OAuth 2.0 and OpenID Connect, and provides a privacy-friendly way for users to sign in to websites and apps

developer.okta.com

So you just published your conference talk videos on YouTube, and you want to add captions. YouTube will use speech to text and try to add their own captions for you, but it's pretty hit or miss, especially for technical talks where there's a lot of proper nouns or jargon in the talk. The good news is there's a much better solution, and one that provides benefits to your in-person audience as well!

You can hire a captioning service to transcribe the speakers' presentations live during the event, providing a display of the captions on a separate display at the conference as well. 

There's a real person at the other end of the screen, listening to everything the speakers are saying and typing really quickly. (There's a special keyboard and years of training that go into this, but there are plenty of resources online if you're interested in learning!)

I've worked with a few people who do captioning for these events, and they're always fantastic. If you run a conference, check out StenoKnight and White Coat Captioning and hire them for your next event! They can either send someone out in person to be at the event and do the captioning right there, or they can connect via Skype and do it all remotely.

Typically they'll provide you with a web page that you can pull up on a large monitor at the venue to display the captions in real time for the in-person audience. This is of course great for people who are deaf or hard of hearing, but is also really helpful for audience members who are not native English speakers, since often times the presenters will talk too quickly to be understood.

At the end of the conference, ask the captioner to send you the plain text files of everything they typed. This will just be a regular text file, no fancy formatting. Here's where the magic happens.

Adding Captions to YouTube Videos

YouTube has a special feature which will match up typed text with the speech it recognizes in videos, doing all the work of syncing your captions with the video timings automatically. If you have a clear audio recording and accurate text, it does a surprisingly good job. Here are the detailed steps to take your plain text file and turn it into captions on YouTube.

First, launch YouTube Studio.

Click on "Videos" to show the list of all the videos uploaded.

Choose the video you want to add captions to.

Click the sidebar option "Transcriptions".

Then click "Add Language". We don’t want to use the autogenerated captions at all, since the live captionist does a way better job.

That adds a new row to this table. Click "Add" under "Subtitles".

A new window opens. Choose the "transcribe and auto-sync" option. That will let us paste in the transcribed text.

Copy the captions of the presenter into the box. Make sure the text you paste from starts and ends with the words the video starts with, or YouTube gets confused trying to line things up.

Once you do that, click "Set Timings".

This part takes a few minutes, so go make a coffee or tea, since you’ll need it for the next step. You can refresh this page to check if it’s done. It will look like this while YouTube is busy with it.

Finally when YouTube has finished thinking, it will appear as a draft you can edit.

Now YouTube has done its magic, and matched up the typed text with the spoken words! It usually does a pretty good job of it. Click on the draft and you can see what it's done.

You could probably publish this at this point, but I like to do a manual review of everything to make sure it looks good. You can play the video to review the captions and timings (check out the keyboard shortcuts which can really help speed up this step).

Keyboard shortcuts:

• SHIFT+SPACE - start/stop
• SHIFT+LEFT / SHIFT+RIGHT - skip forward or backwards by a second

While reviewing, I’m mainly looking for the following:

Did YouTube leave any dangling words that could otherwise fit into the previous caption?

For example, this would look better if the word "fit," was in the previous caption frame instead of starting a new caption frame with the end of that phrase.

In that case, just move the word to the other caption frame.

Are there any obvious typos on technical terms or proper nouns? 

The live captionists do a pretty good job, but occasionally some typos slip through.

If the presenter has any long gaps in between sentences, sometimes YouTube gets confused about the timing.

You can find some of these spots by visually looking at the waveform compared to the length of text in the caption. (In this particular example this happens to be accurate but it usually looks similar to this when it’s wrong.)

Once you’re happy with the transcript, click "Save Changes".

Now you need to delete the auto transcript so that only the good transcript is left.

You first have to click "Unpublish".

Then you can click "Delete Draft".

And confirm.

Now there is only one set of captions, the good one! You are finished, congrats!

Now when people watch the video on YouTube and enable captions, they'll be seeing what the live captionist typed during the event! 

I've been helping Donut.js record their meetup talks for about 3 years now. It's been a fun way to experiment with various video recording setups, and the talks are always great so it's nice to have those recorded.

I've always used a smaller kit compared to the rig I bring to large multi-day conferences. But lately I've had to hand off some camera gear to their volunteers since I've been out of town on work trips for most of the meetups this year.

I've been looking for smaller and smaller gear to make this easy to transport, cut down on setup time, but also so that it can be operated by someone without a lot of experience with the gear. I've tried a few iterations of kits for them, but so far the most reliable way to record the meetup is using a camcorder, a separate device to capture the presenter's slides, and a separate audio recorder, then sync up everything in post.

In an ideal world, I'd be able to hand them a small box and a video camera, they could plug everything in, and it would record a single stream mixing in the presenter's slides, the video camera, and the audio. Here's a little diagram showing what I'd like in an ideal world.

The video camera and presenter's laptop connect to the "magic box" via HDMI. We use a PA in the venue, which has an XLR output, and that needs to connect to the magic box to get audio into the mix. Lastly, I want the presenter's laptop HDMI to pass through to an output so that we can feed the venue's projector from the box. The box should be able to record the video output to an SD card or hard drive. I don't need it to be able to livestream, but bonus points if it can.

Part of the goal is also to cut down on post-production time. Right now I have to sync the audio and video (automatically) in Final Cut or Premiere, then line up the recording of the slides manually. It ultimately isn't that bad, but does mean the whole process takes around an hour for the three talks. Ideally I could record a mix of the video and slides already combined into a single video so that the only work is trimming the start and end, and adding the title slides. Here's a snapshot of the kind of layout I'd like to make.

This means scaling the slides and scaling and cropping the video. I would settle for a side-by-side layout like the below, where both are scaled but not cropped.

My last requirement, and one that rules out a few otherwise great devices, is that I need the device to be simple enough to operate to explain in a single page of instructions. I need it to be plug the HDMI and audio inputs in, then turn on the device, and hit record. Once I've set it up once, it can't require any configuration on site.

So far, I haven't been able to find a device that can do all of these things at the same time. Here's a list of all my requirements:

• Two video inputs (camera and presenter's laptop)
• Presenter's laptop needs a scaler
• Pass-through from the presenter's laptop input to an output to feed the projector
• Audio input via XLR
• Can do side-by-side video from two inputs, or at least picture-in-picture
• Can record locally to an SD card or hard drive
• Simple enough to operate by someone not trained on the device with just a one-sheet of instructions

Here are a few setups that I've tried or investigated.

Epiphan Webcaster X2

This device is so close to being perfect. It has only one HDMI input, but you can also plug in a USB webcam as a second camera. While that's obviously not going to be as good quality as a real camera, I would consider it good enough for this use case. The Webcaster X2 is the device that made the screenshot above with the text "My Great Presentation", so you can see that it's able to scale both the HDMI input as well as the USB webcam. Here's where it fails:

• It can't record locally at all, even though it has an SD card slot. It can only stream, and I'm not willing to risk the recording based on the venue's internet connection.
• It doesn't output audio over the HDMI out, so you can't even connect an external recorder to it.
• Audio input is limited to either the HDMI input or the USB webcam, no option to feed a separate audio source in. I would need to use an HDMI audio injector with it to accomplish the diagram above.

I'm also not a huge fan of the fact that it's actually an Android device, but it is pretty well done anyway, and mostly you can ignore that fact while using it.

Total cost: $300 for the Webcaster, but this doesn't really apply because it can't record locally at all so it's not really an option.

Decimator DIY Box

At a recent conference I recorded, I hacked together a DIY version of the box using a few components.

• Atomos Ninja Blade HDMI recorder
• Decimator MD-HX Scaler
• Decimator DMON-QUAD multiviewer
• Decimator MD-LX HDMI/SDI Cross-Converter

The inputs are connected with short HDMI extenders to expose them to the outside of the box.

This makes setup super easy, since you just plug in the three HDMI connectors and you're good to go. In this conference we were using a lav mic that fed into the camera, so the audio was coming in via that HDMI.

The scaler handles taking whatever resolution peoples' laptops throw at it and convert it to 1080p, plus outputs that back out for the projector. The multiviewer then takes the scaled computer output and the HDMI camera and creates an image with two smaller windows of each video. It's also able to select which one to use audio from. The output of the multiviewer goes into the Atomos recorder to record the final output.

This worked well, but is kind of a clunky solution, plus wouldn't work for Donut.js where the audio needs to get fed in separately from an XLR cable. That'd require a few more pieces of hardware such as an HDMI audio injector or such.

Total cost: $300 scaler, $300 multiviewer, $100 cross-converter, $500 HDMI recorder: $1200 plus some cables and maybe also an audio injector.

Roland VR-1HD

I haven't actually used this device yet, but it comes very very close to being a perfect solution based on all the videos and reviews I've seen.

It has three HDMI inputs, and one pass-through port which is perfect for feeding the projector.

It even has an XLR input on the side which we can use to input the feed from the PA.

But here's what it's missing:

• It can do picture-in-picture, but one source will be full screen and the second will be small. This means the camera would always overlap the slides rather than be side by side.
• It has no built-in recording capability, so it would require connecting an external HDMI recorder to capture the program out, or connect it to a computer and use that to record.

Switching between picture-in-picture and one of the HDMI sources can be done with the physical buttons on top, and would be easy enough to instruct people how to do.

I suppose I could live with picture-in-picture instead of side by side, but I would feel better about that if it also had built-in recording to an SD card.

By the time you add an external recorder, you're spending $1500 on the VR-1HD and $500 on the recorder, for a total of $2000. 

Tricaster Mini

The Tricaster is definitely an all-in-one solution, but I'm ruling it out immediately since it requires quite a lot of configuration to get running and isn't something I would consider handing off to a volunteer. It's also quite expensive at a baseline price of $6000.

Blackmagic ATEM Television Studio

The Blackmagic ATEM is my goto for larger events, and I do really like it. However, it's still a bit too complicated to hand off to someone to use. It doesn't have built-in recording, so you have to pair it with an external recorder. It also doesn't have a built-in scaler so you need that for the slides too. 

It also can only do picture-in-picture, not side by side video. In order to do that you need to step up to the much larger and more expensive devices.

I haven't actually put together a complete parts list for what it would cost for this option because I don't think it's viable at all. The ATEM TVS is $1000, the recorder is $600, and the scaler is $300, so the base cost before all the other accessories you'd need is $1900.

Computer with OBS

I'm including this option in the list just so people don't tell me I forgot it. It turns out this isn't actually a very good solution, because it won't be an all-in-one box, and also is kind of complicated to operate, requiring a monitor and keyboard and mouse. 

Trying to do this on a laptop isn't really feasible since it requires two HDMI capture cards plus a USB audio interface. I wouldn't trust Windows to do this since it's very easy for a Windows computer to accidentally start running auto-updates at inopportune times. Running Linux is an option, but would then likely require more explanation to people using it. 

I would want to be able to configure the computer to launch OBS on boot and restore a saved configuration, so that there is no fiddling with software to get it running.

Overall I feel like there are too many moving parts and different ways this can fail, and also would require a lot of plugging wires in so the setup time would actually be pretty long.

SlingStudio

I've actually used the SlingStudio at Donut.js quite a bit myself, and it is again almost perfect. 

• Good: It can record to an SD card as well as stream live. 
• Okay: It has only one HDMI input, but the cameras connect wirelessly from a transmitter. 
• Okay: It has an 1/8" audio input, so you need something to convert the XLR input to 1/8", which is annoying but acceptable.
• Bad: Like most products, it can do picture-in-picture but not side-by-side video.
• Bad: The iPad controller is decent, but is not quite simple enough to hand off to someone else without a bit of training. Mainly the awkwardness comes from toggling into picture-in-picture mode.

The total cost of this setup is:

• $1000 for the SlingStudio
• $300 for an HDMI transmitter
• ~$100 for something to convert the XLR to 1/8" audio
• $300 for an iPad to control it
• Total: ~$1700 

Epiphan Pearl Mini

The Epiphan Pearl Mini sure looks like a fantastic device. I haven't tried it out myself, but I've looked at a bunch of reviews of it. It actually seems like it's the only thing that actually ticks all of the feature boxes.

• It can do side-by-side layouts from two inputs
• It has an XLR input for audio
• It can record to an SD card
• It can be operated from the touch screen, where you tap on the layout you want to switch to
• The HDMI output can be configured to pass through one of the inputs, so that I could feed the projector
• You can even add images and text graphics would would be perfect for producing the final layout in the device

The only thing I am not clear on is what happens when you first boot it up. I am hoping that it would restore the last used configuration and be ready to go immediately.

Really the only downside to this is the cost. It's a $3500 device, which is good for what it can do, but also still quite a lot of money. After this much research though, I'm coming around to the idea that maybe it's worth it.

So I think out of all of these options, the best is the Pearl Mini ($3500), and second best is the Roland VR-1HD with external recorder ($2000).

I'd be curious to hear your thoughts on this! Did I forget about any options? Is there a new device that's come out that I don't know about yet?

Write a blog post response or ping me on Twitter to get in touch!

If I ever do find the perfect solution, I will be sure to post a review video on my YouTube channel!

My previous avatar was almost 3 years old, and I was getting tired of it. I decided to replace my avatar on my website for my IndieWebCamp Austin hack day project. But if you know me, you know I can't do anything the easy way. For my hack day project I made the avatar on each post in my website change depending on the emoji I use in the post!

I've had a page on my website for a while now that shows all the emoji I use in my posts. It's sorted by most frequently used emoji.

If you click on an emoji, you can see all the posts that include that emoji, kind of like a tag. This has been pretty fun, but I wanted to take it one step further.

Before I left for Austin, I did a little photo shoot at home. I took pictures of myself making a bunch of faces, and even with a few different props like a mug of beer, eating a pizza, holding an umbrella, etc. I added all these pictures to my admin interface and mapped them to the emoji I frequently use.

(There's a bunch more, but I'll leave that to you to find them!) And now, whenever a post includes an emoji, it will swap the photo that's used as the avatar! Here are a few highlights.

I'm looking forward to being surprised when I forget this exists and randomly use an emoji in a post and see a different photo!

If you'd like to see the video of my demo of this feature, and the rest of the demos at IndieWebCamp, you can watch them here!

I had a great time at IndieWebCamp Austin this weekend! Thanks to everyone for joining us this weekend, and special thanks to Manton for organizing!

It's already been a year since IndieAuth was published as a W3C Note! A lot has happened in that time! There's been several new plugins and services launch support for IndieAuth, and it's even made appearances at several events around the world!

• Micro.blog added native support for IndieAuth, so your hosted micro.blog account is now also an IndieAuth provider
• Dobrado launched native support for IndieAuth
• The IndieAuth Plugin for Drupal launched in the beginning of the year, and has had several releases since then
• The IndieAuth Plugin for Grav adds support to your Grav site by delegating to indieauth.com
• The IndieAuth Plugin for WordPress had a major rewrite and supports IndieAuth natively now

I presented IndieAuth at the W3C Workshop on Strong Authentication & Identity in December, and even published a video of the talk afterwards!

At API Days Global, oauth.io presented a session including IndieAuth.

Josh Hawxwell gave a talk at NottsJS called Indie What? where he covered several IndieWeb building blocks including IndieAuth.

In July, I wrote a blog post called OAuth for the Open Web, where I detailed the technical solutions IndieAuth provides on top of OAuth to enable it to work in a more open and less corporate environment.

In October, I published Dweb: Identity for the Decentralized Web with IndieAuth on the Mozilla Hacks Blog.

So here's to a productive year for IndieAuth in 2018! Looking forward to seeing what new developments come up in 2019!

Inspired by cleverdevil's monthly summary pages, I started working on my own version of them on my website!

My month permalinks have shown a calendar grid of all the posts I made during that month for a while, but it's not particularly easy to skim that and actually understand anything from it.

I had recently added a summary of my modes of transport for the month, which is a fun way to see how much I bike in a month compared to how much I'm in airplanes.

Today I added a few new sections below the calendar.

First is a list of all the photos I've posted that month. They are displayed in the same style as my photo albums, which are full-width justified, uniform height. It's a neat trick I learned from Flickr, and provides a nice looking photo grid of uniform height without cropping any images.

The next section shows a map view of all my checkins for that month. I didn't want to show a pin for every checkin, since that would be too many pins on the map clustered too close together. So instead I started by grouping by city name. That works pretty well when I travel to a few different cities in the month. 

The problem with that approach is if I don't leave Portland for a whole month (it rarely happens these days but still), then the map looks like I didn't even leave a single spot. So instead, I actually group by latitude and longitude rounded to the nearest 0.1 decimal. 

That way when I don't leave Portland, at least it shows a few map pins around the city. 

I should probably switch this to use an actual map pin clustering algorithm, but this was easy and is good enough.

Below that is a section that shows a list of my "popular posts". I decided to rank my posts based on the number of interactions they've received. Replies are weighted the highest, followed by reposts then likes. So if something gets 10 replies, it will beat out a post with only 1 repost. I chose these weightings pretty arbitrarily, spot-checking a few months of data at a time. We'll see how I feel about it after some time.

So I'm pretty excited to launch this! Thankfully I already had enough things indexed in my database that it didn't require a lot of backend changes, it was mostly just UI and design work. We'll see how this feels for a few months and maybe there will be more things I want to add to it later, but this feels like a good start!

Thanks to cleverdevil for the inspiration!

For the past week or so, I've been getting a series of Pingbacks from a spam blog that reposts a blog post a couple times a day as a new post each time. It's up to about 220 copies of the post, each one having sent me a Pingback, and each one showing up in my reader as a notification, which also causes it to be sent to my phone.

Since I use webmention.io to handle my incoming Webmentions (and Pingbacks), this would be the best place to block the site, rather than filtering it out in my reader or my website. 

Webmention.io previously had no way to actually completely block a domain. As Webmentions have started growing in popularity, it's become obvious that we need more tools to combat spam and abuse. While this site was actually sending me Pingbacks, the same applies to Webmentions.

Today I added a new feature to webmention.io to allow people to entirely block a domain, and delete any webmentions received from that domain. 

From the dashboard, you can click the "X" on any recent webmention, or you can paste a URL from one you've received in the past. You'll be taken to this screen where you can either delete just the one webmention, or entirely block the domain.

Once you've blocked the domain, it will show up in your blocklists page!

I hope this helps others keep out spam as well! I'm sure looking forward to never seeing that notification on my phone again!

Today I launched some updates to OwnYourSwarm, the service that sends your Swarm checkins to your own website. It does this by watching your Swarm account and sending checkins to your site via Micropub. 

Private Posts

I made two changes to how OwnYourSwarm can handle private posts. Private posts are currently an experimental feature in Micropub, accomplished by adding a new property to posts called "visibility". The WordPress Micropub plugin already has support for this property, so if you use WordPress you can start using this feature today!

If you mark a checkin in Swarm as "off-the-grid", now OwnYourSwarm will include visibility=private in the Micropub request. Your website can recognize this property and handle setting the post as private.

There is an additional checkbox to have OwnYourSwarm always mark the post as private. You can use this to import all your checkins to your site as private posts in case you don't want all your checkins public on your website.

Automatically Add Tags to Posts

Like OwnYourGram, there is now a way to have OwnYourSwarm always include a list of tags in your checkins. You can use this to automatically set your checkins into a specific page on your website by adding the tag "checkin" for example.

Webmention Settings for Comments

By default, OwnYourSwarm will always try to send Webmentions for any responses to your checkins, such as when someone likes or comments on your checkin, as well as when Swarm itself shows the little tidbits like "11 weeks in a row at coffee shops" awarding coins.

There are now two additional settings you can use to decide whether you want to receive Webmentions for either type of responses. If you'd prefer to not get the Swarm coins, you can disable that. If you'd prefer not to have anybody else's comments appear on your checkins, you can disable that as well.

I also added a user agent string when OwnYourSwarm sends webmentions so that you'll be able to identify the HTTP requests in your server logs.

Hope you enjoy continuing to own your checkins!