{
    "type": "entry",
    "author": {
        "name": null,
        "url": "https://www.manton.org/",
        "photo": null
    },
    "url": "https://www.manton.org/2018/06/27/slow-start-for.html",
    "content": {
        "html": "<p>Slow start for me this morning. Luckily my Airbnb left a Stumptown cold brew coffee in the fridge. Catching up on support email before heading over to <a href=\"https://2018.indieweb.org/\">IndieWeb Summit</a> day 2.</p>",
        "text": "Slow start for me this morning. Luckily my Airbnb left a Stumptown cold brew coffee in the fridge. Catching up on support email before heading over to IndieWeb Summit day 2."
    },
    "published": "2018-06-27T10:29:23-05:00",
    "_id": "570892",
    "_source": "12",
    "_is_read": true
}

{
    "type": "entry",
    "published": "2018-07-08T23:12:52-04:00",
    "url": "https://david.shanske.com/2018/07/08/2007/",
    "in-reply-to": [
        "https://aaronparecki.com/2018/07/07/7/oauth-for-the-open-web"
    ],
    "content": {
        "text": "IndieAuth, the extension to OAuth 2.0, was developed by Aaron Parecki and implemented by multiple people\u00a0 in the IndieWeb community, including myself.\nThe problem has been that people conflated it with the service Aaron created as a reference implementation, which implemented IndieAuth for people who didn\u2019t have it by using the OAuth services of sites like Twitter and Github to bootstrap the service.\nAaron succeeds here in finally conveying a point it took me a long time to understand, and partially only by reading and implementing one of these.\nWas pleased to see the founder of Home Assistant, a product I use, tweeting that he would adopt this in that product. Looking forward to seeing what people come up with.",
        "html": "IndieAuth, the extension to OAuth 2.0, was developed by Aaron Parecki and implemented by multiple people\u00a0 in the IndieWeb community, including myself.\n<p>The problem has been that people conflated it with the service Aaron created as a reference implementation, which implemented IndieAuth for people who didn\u2019t have it by using the OAuth services of sites like Twitter and Github to bootstrap the service.</p>\n<p>Aaron succeeds here in finally conveying a point it took me a long time to understand, and partially only by reading and implementing one of these.</p>\n<p>Was pleased to see the founder of Home Assistant, a product I use, <a href=\"https://twitter.com/balloob/status/1015740688695250946\">tweeting</a> that he would adopt this in that product. Looking forward to seeing what people come up with.</p>"
    },
    "author": {
        "type": "card",
        "name": "David Shanske",
        "url": "https://david.shanske.com/",
        "photo": "https://aperture-proxy.p3k.io/6f1f841c095626a5e52a3b86849e757329773a28/68747470733a2f2f64617669642e7368616e736b652e636f6d2f77702d636f6e74656e742f75706c6f6164732f6176617461722d707269766163792f63616368652f67726176617461722f322f632f326362316638616664396338643362363436623430373163356564383837633937306438316436323565656564383765343437373036393430653263343033642d3132352e706e67"
    },
    "refs": {
        "https://aaronparecki.com/2018/07/07/7/oauth-for-the-open-web": {
            "type": "entry",
            "url": "https://aaronparecki.com/2018/07/07/7/oauth-for-the-open-web",
            "name": "OAuth for the Open Web",
            "author": {
                "type": "card",
                "name": "Aaron Parecki",
                "url": "https://aaronparecki.com/",
                "photo": "https://aaronparecki.com/images/profile.jpg"
            }
        }
    },
    "_id": "570713",
    "_source": "5",
    "_is_read": true
}

{
    "type": "entry",
    "published": "2018-07-08T18:10:04-07:00",
    "url": "https://aaronparecki.com/2018/07/08/17/",
    "content": {
        "text": "I think that's all the brain power I've got for today. Feels good to have another IndieAuth server implementation in the wild now tho!"
    },
    "author": {
        "type": "card",
        "name": "Aaron Parecki",
        "url": "https://aaronparecki.com/",
        "photo": "https://aperture-media.p3k.io/aaronparecki.com/2b8e1668dcd9cfa6a170b3724df740695f73a15c2a825962fd0a0967ec11ecdc.jpg"
    },
    "_id": "569992",
    "_source": "16",
    "_is_read": true
}

{
    "type": "entry",
    "published": "2018-07-08T16:29:06-07:00",
    "url": "https://aaronparecki.com/2018/07/08/15/aperture-indieauth",
    "category": [
        "p3k",
        "indieauth"
    ],
    "photo": [
        "https://aperture-media.p3k.io/aaronparecki.com/11a0975c0afde82ff1fdbb303efe1e6b2b464096e8d9d297d33656b8c4d5b37b.png"
    ],
    "video": [
        "https://aperture-media.p3k.io/aaronparecki.com/24eadfbe365c654a9b9ff565b7284b0b2e01713ac22130a814e041c9daa72696.mp4"
    ],
    "content": {
        "text": "I just implemented an IndieAuth server for Aperture, which sounds crazy but it's actually pretty cool. Now you can log in to apps like https://indiepaper.io and they can post content directly into a private channel!  \n\nIf you have an Aperture account, try logging in to Quill using https://aperture.p3k.io as your URL. Here's a little demo of it in action!",
        "html": "I just implemented an IndieAuth server for Aperture, which sounds crazy but it's actually pretty cool. Now you can log in to apps like <a href=\"https://indiepaper.io\">https://indiepaper.io</a> and they can post content directly into a private channel!  <br /><br />If you have an Aperture account, try logging in to Quill using <a href=\"https://aperture.p3k.io\">https://aperture.p3k.io</a> as your URL. Here's a little demo of it in action!"
    },
    "author": {
        "type": "card",
        "name": "Aaron Parecki",
        "url": "https://aaronparecki.com/",
        "photo": "https://aperture-media.p3k.io/aaronparecki.com/2b8e1668dcd9cfa6a170b3724df740695f73a15c2a825962fd0a0967ec11ecdc.jpg"
    },
    "_id": "569737",
    "_source": "16",
    "_is_read": true
}

{
    "type": "entry",
    "published": "2018-07-07T23:20:51-04:00",
    "summary": "Yeah, I think it\u2019s an incredibly useful feature. I think @manton likes the name Favorite, but I do feel like your option #2, renaming it is the best option. I think renaming it to Bookmark explains more of the purpose, is clearer that it doesn\u2019t send information to others, and it already plays nice with the bookmark-of micropub vocabulary, so if there was gonna be a change I think that\u2019s the best one \ud83d\ude42",
    "url": "https://eddiehinkle.com/2018/07/07/28/reply/",
    "category": [
        "2"
    ],
    "in-reply-to": [
        "https://www.burk.io/2018/07/07/202918.html"
    ],
    "content": {
        "text": "Yeah, I think it\u2019s an incredibly useful feature. I think @manton likes the name Favorite, but I do feel like your option #2, renaming it is the best option. I think renaming it to Bookmark explains more of the purpose, is clearer that it doesn\u2019t send information to others, and it already plays nice with the bookmark-of micropub vocabulary, so if there was gonna be a change I think that\u2019s the best one \ud83d\ude42",
        "html": "<p>Yeah, I think it\u2019s an incredibly useful feature. I think <a href=\"https://eddiehinkle.com/timeline/undefined\">@manton</a> likes the name Favorite, but I do feel like your option <a href=\"https://eddiehinkle.com/tag/2/\">#2</a>, renaming it is the best option. I think renaming it to Bookmark explains more of the purpose, is clearer that it doesn\u2019t send information to others, and it already plays nice with the bookmark-of micropub vocabulary, so if there was gonna be a change I think that\u2019s the best one \ud83d\ude42</p>"
    },
    "author": {
        "type": "card",
        "name": "Eddie Hinkle",
        "url": "https://eddiehinkle.com/",
        "photo": "https://aperture-proxy.p3k.io/cc9591b69c2c835fa2c6e23745b224db4b4b431f/68747470733a2f2f656464696568696e6b6c652e636f6d2f696d616765732f70726f66696c652e6a7067"
    },
    "refs": {
        "https://www.burk.io/2018/07/07/202918.html": {
            "type": "entry",
            "url": "https://www.burk.io/2018/07/07/202918.html",
            "name": "https://www.burk.io/2018/07/07/202918.html"
        }
    },
    "_id": "564491",
    "_source": "226",
    "_is_read": true
}

{
    "type": "entry",
    "published": "2018-07-07T20:58:07+00:00",
    "url": "https://cleverdevil.io/2018/great-suggestion-i-am-debating-either-including-mf2py-as-a",
    "in-reply-to": [
        "https://github.com/cleverdevil/indiepaper/issues/2"
    ],
    "content": {
        "text": "Great suggestion. I am debating either including mf2py as a dependency, or just using\u00a0https://python.microformats.io as a web service like I do with Mercury, so I don't have to worry about keeping it up to date.I will likely want to take the output from mf2py and strip out everything but the basics. Any directional feedback is, of course, welcome!",
        "html": "<p>Great suggestion. I am debating either including mf2py as a dependency, or just using\u00a0<a href=\"https://python.microformats.io\">https://python.microformats.io</a> as a web service like I do with Mercury, so I don't have to worry about keeping it up to date.</p><p>I will likely want to take the output from mf2py and strip out everything but the basics. Any directional feedback is, of course, welcome!</p>\n<p><a href=\"https://brid.gy/publish/github\"></a></p>"
    },
    "author": {
        "type": "card",
        "name": "Jonathan LaCour",
        "url": "https://cleverdevil.io/profile/cleverdevil",
        "photo": "https://aperture-proxy.p3k.io/77e5d6e5871324c43aebf2e3e7a5553e14578f66/68747470733a2f2f636c65766572646576696c2e696f2f66696c652f66646263373639366135663733383634656131316138323863383631653133382f7468756d622e6a7067"
    },
    "_id": "562165",
    "_source": "71",
    "_is_read": true
}

{
    "type": "entry",
    "author": {
        "name": "manton",
        "url": "http://www.manton.org",
        "photo": null
    },
    "url": "http://www.manton.org/2018/07/7056.html",
    "content": {
        "html": "<p>If you\u2019re familiar with OAuth, <a href=\"https://aaronparecki.com/2018/07/07/7/oauth-for-the-open-web\">this introduction to IndieAuth</a> walks through the process of how auth for the open web works. Really happy that Micro.blog supports this now.</p>",
        "text": "If you\u2019re familiar with OAuth, this introduction to IndieAuth walks through the process of how auth for the open web works. Really happy that Micro.blog supports this now."
    },
    "published": "2018-07-07T20:41:12+00:00",
    "updated": "2018-07-07T20:41:12+00:00",
    "_id": "560818",
    "_source": "12",
    "_is_read": true
}

{
    "type": "entry",
    "published": "2018-07-07T20:11:16+00:00",
    "url": "https://cleverdevil.io/2018/i-added-experimental-support-for-indieauth-in",
    "syndication": [
        "https://twitter.com/cleverdevil/status/1015689745228279811"
    ],
    "content": {
        "text": "I added experimental support for IndieAuth in Indiepaper today. Test it out here \u2013 https://www.indiepaper.io/indieauth.html. Once authenticated, you get an automatically generated bookmarklet and a button to click for automatically configuring Indiepaper for macOS.",
        "html": "I added experimental support for IndieAuth in Indiepaper today. Test it out here \u2013 <a href=\"https://www.indiepaper.io/indieauth.html\">https://www.indiepaper.io/indieauth.html</a>. Once authenticated, you get an automatically generated bookmarklet and a button to click for automatically configuring Indiepaper for macOS."
    },
    "author": {
        "type": "card",
        "name": "Jonathan LaCour",
        "url": "https://cleverdevil.io/profile/cleverdevil",
        "photo": "https://aperture-proxy.p3k.io/77e5d6e5871324c43aebf2e3e7a5553e14578f66/68747470733a2f2f636c65766572646576696c2e696f2f66696c652f66646263373639366135663733383634656131316138323863383631653133382f7468756d622e6a7067"
    },
    "_id": "560797",
    "_source": "71",
    "_is_read": true
}

Du-dupe replies received via webmention

{
    "type": "entry",
    "published": "2018-07-07T14:11:11-04:00",
    "summary": "If I sent a reply into micro.blog via webmention. If I make a typo and send a second webmention, rather than using the permalink of the webmention to de-duplicate the post and just update the existing post, it creates a brand new second post with the new post content creating duplicate posts.",
    "url": "https://eddiehinkle.com/2018/07/07/13/reply/",
    "in-reply-to": [
        "https://github.com/microdotblog/issues"
    ],
    "name": "Du-dupe replies received via webmention",
    "author": {
        "type": "card",
        "name": "Eddie Hinkle",
        "url": "https://eddiehinkle.com/",
        "photo": "https://aperture-proxy.p3k.io/cc9591b69c2c835fa2c6e23745b224db4b4b431f/68747470733a2f2f656464696568696e6b6c652e636f6d2f696d616765732f70726f66696c652e6a7067"
    },
    "refs": {
        "https://github.com/microdotblog/issues": {
            "type": "entry",
            "url": "https://github.com/microdotblog/issues",
            "name": "https://github.com/microdotblog/issues"
        }
    },
    "_id": "559884",
    "_source": "226",
    "_is_read": true
}

OAuth for the Open Web

{
    "type": "entry",
    "published": "2018-07-07T09:30:27-07:00",
    "url": "https://aaronparecki.com/2018/07/07/7/oauth-for-the-open-web",
    "featured": "https://aaronparecki.com/2018/07/07/7/image-1.jpg",
    "category": [
        "indieauth",
        "oauth",
        "oauth2",
        "indieweb"
    ],
    "name": "OAuth for the Open Web",
    "content": {
        "text": "OAuth has become the de facto standard for authorization and authentication on the web. Nearly every company with an API used by third party developers has implemented OAuth to enable people to build apps on top of it.\nWhile OAuth is a great framework for this, the way it has ended up being used is much more centralized and closed than prior efforts like OpenID 1. Every service that spins up an OAuth-enabled API ends up being its own isolated system. For example, if I want to build an app that can read someone's step count from FitBit, I have to first go register as a developer on FitBit's website in order to get API keys to use with their OAuth API.\u00a0\nThis works okay for major services like Google, Twitter, Facebook, and even FitBit, but breaks down when you start to consider use cases like having someone's personal WordPress blog be its own OAuth server. If I want to build an app that lets you upload photos to your WordPress site, I'm obviously not going to be able to register for API keys on everyone's own WordPress installations. Enabling third party clients to be built against systems like WordPress or Mastodon opens up a huge possibility for some really interesting things. The trick is always how do these apps authenticate the user or obtain a token they can use to access those APIs.\nThis post details a few specific challenges with OAuth preventing it from being used by independent websites, as well as the solutions to each.\n\nClient Registration\nThe first major hurdle to overcome is the need for the developer to register to get API keys for the service. In a world where everyone's own website is its own OAuth server, it's obviously not practical to have an app developer register API keys at each.\nIn OAuth, client registration gives us a few specific things:\n\n    Provides a unique ID that is used to identify the app throughout the OAuth process, called the client ID\n    \n\n  Provides a place to enter the name and icon for the app which is displayed during login\n  Registers one or more redirect URLs for security\n  For \"confidential clients\" (web server apps), registration also provides the client with a client secret\nNote that in traditional OAuth, client secrets are not used by mobile apps or JavaScript apps, and OAuth servers will often not even issue secrets to those types of apps. Since we're trying to avoid registration entirely, we can also just avoid using client secrets at all, and leverage the same protections OAuth already has in place for clients that can't use a secret.\nIn order to avoid registration, we need a solution for the first three bullet points above.\nClient ID: Every application needs a unique identifier. If we're talking about turning every website into an OAuth provider, we need a way to have globally unique identifiers for every OAuth app. It turns out we already have a mechanism for this: URLs! In this Open Web version of OAuth, client IDs can be the application's URL. For web-based apps, this is straightforward, as it's simply the website the app is running on. For native apps, this can be the application's \"about\" page.\nApplication name and icon: Since the application's client ID is a URL, we can assume every application has a web page that talks about it, and treat that web page as the place the client defines its own metadata like name and icon. A simple way to accomplish this is with Microformats, so that the application's web page just needs to add a couple classes around the name and icon of the app. This is currently documented and implemented as the h-app microformat.\nRedirect URL registration: This one is a bit more subtle. The purpose of redirect URL registration is to prevent an attacker from tricking an authorization server into sending authorization codes to the attacker. This becomes especially important when we aren't using client secrets. The trick is that since client IDs are already URLs, we can shortcut the normal registration process by declaring a rule that redirect URLs have to be on the same domain as the client ID. This way, we can avoid a situation where an application claiming to be good.example.com sets a redirect URL to attacker.example.org and steals the authorization code. The only way to get the authorization code to attacker.example.org would be to set the client ID to that domain as well, which a user would hopefully notice.\n\nUser Accounts\nThere are two different situations to consider with regards to user accounts: authentication and authorization. Authentication is the process of proving the identity of the person signing in. Authorization is how an application obtains permission to do something to someone's account.\nWhen we talk about authentication, we are talking about wanting to allow an unknown user to identify themselves to the site they're logging in to. Common examples of this are using your email address as your identity to sign in to a website. You bring an existing identity (your email address) and then authenticate (usually by clicking a link that was sent to your email). The original version of OpenID was created to solve this problem on the web. People identified themselves with a URL, which they were able to prove they controlled using OpenID. This allows a new user to log in to a site without needing a prior relationship with the site.\nWhen we talk about authorization, the situation is subtly different. In this case, we're talking about a user of a website wanting to give permission to a third-party app to access some part of their account. We're very used to this pattern now, which is the typical OAuth use case of granting an application the ability to access your Google Calendar, or logging in to a third party Twitter app.\nAuthorization: There isn't really a challenge unique OAuth on the Open Web with regards to authorization. Once the client registration problem is solved, everything else falls into place nicely. It is assumed that users are authorizing an application to access an account they already have, so the application will just end up with an access token that works with their existing account.\nAuthentication: Where we need to define some new behavior is talking about authentication. In this case, we want users to be able to bring an existing identity and use it to log in to other places. This means we need a way to uniquely identify users across the entire web. We can again use URLs as the solution! Every user is identified by a URL. This can be a short URL like someone's domain name, e.g. https://aaronparecki.com/, or for a site with multiple users, can be a URL that contains a path specifying a particular user on the site, e.g. https://github.com/aaronpk.\u00a0\n\nDiscovery\nWith traditional OAuth services, discovery is not needed since the application author knows which OAuth server they're talking to before they start building the app. There is typically a \"Sign in with ____\" button in the application that begins the authorization process. In the case of using OAuth for authentication, the common pattern is to include buttons for several common \"social login\" providers such as Facebook, Google, Twitter and LinkedIn. Before the \"social login\" space essentially consolidated to these four, there were sometimes a dozen of these buttons on an application's login page, which eventually became known as the \"NASCAR problem\".\nIn a world where every WordPress or Gitlab site is its own OAuth provider, there obviously can't be a button for each on a login screen. Instead, we need to find out from the user which server to use to authenticate them.\u00a0\nSince we previously stated that every user identifier is a URL, we can ask the user to enter their URL in the sign-in screen, and then fetch that URL and discover their authorization server from there.\nOnce we've found the user's authorization endpoint, we can start a normal OAuth request and send them to their server to authenticate. When the server redirects back to the application, it will go and verify the authorization code with their authorization endpoint just like normally happens with OAuth.\n\nKnowing Who Logged In\nWhile knowing any user identity information is technically not part of OAuth, we do need the server to return a user identifier when using OAuth for authentication. In practice, most applications also want at least a unique user identifier in the authorization case as well.\nWe've previously said that user identifiers are URLs, which solves the global user identity problem, and gives us a mechanism to discover the user's OAuth server. So all we need is a way to return this information to the application after the user has authenticated.\u00a0\nOAuth gives us an easy opportunity to return this to the application: in the access token response when the application sends the authorization code to obtain an access token. The server can at that point return the full user identifier of the user that logged in. As long as the domain name matches the domain that the user entered at the start, the application can consider it successful. This also gives the authorization server the opportunity to canonicalize the user identifier, correcting \"http\" to \"https\", or adding a path component to the user's profile URL.\n\nLet's do this!\nBy now, hopefully you're thinking \"this sounds great, Aaron, someone should write this up as a OAuth extension!\" I'm glad you asked!\nThe IndieAuth spec, an OAuth 2.0 extensionEarlier this year, I wrote this all up as an extension to OAuth 2.0, called IndieAuth. IndieAuth encapsulates these small additions needed for OAuth 2.0 to work in the Open Web.\nDespite this spec being published in January, it has actually been implemented for several years before that. There are many implementations of this extension on the server side, everything from standalone authorization server projects, to a WordPress\u00a0plugin, and it's even implemented by a commercial service, Micro.blog. As far as consuming apps, nearly every Micropub app has implemented this for logging users in.\nFor further details on implementing this extension, there are several guides available depending on whether you're writing a client, a server, or just part of a server.\nAuthenticating users with IndieAuth\n  Obtaining an access token with IndieAuth\n  Creating an Authorization Endpoint\n  Creating a Token Endpoint\nThere are a few existing open source projects you can use to get started if you don't want to write your own!\n\nselfauth - a standalone authorization server using a simple password login\n  \nIndieAuth for WordPress - a plugin that turns your WordPress install into an OAuth 2.0 server\n  \nAcquiescence - an authorization endpoint written in Ruby that authenticates users via GitHub\nFor further reading, check out the IndieAuth spec.\u00a0Feel free to drop in to the IndieWeb chat if you'd like to talk about this, or you can reach me on Twitter\u00a0or from my website.",
        "html": "<img src=\"https://aperture-media.p3k.io/aaronparecki.com/063490713e5cecd672d9688e83f4edb016e4ef7e0d1b6cd1fa3efd1149d27047.jpg\" alt=\"\" class=\"u-featured\" /><p>OAuth has become the de facto standard for authorization and authentication on the web. Nearly every company with an API used by third party developers has implemented OAuth to enable people to build apps on top of it.</p>\n<p>While OAuth is a great framework for this, the way it has ended up being used is much more centralized and closed than prior efforts like OpenID 1. Every service that spins up an OAuth-enabled API ends up being its own isolated system. For example, if I want to build an app that can read someone's step count from FitBit, I have to first go register as a developer on FitBit's website in order to get API keys to use with their OAuth API.\u00a0</p>\n<p>This works okay for major services like Google, Twitter, Facebook, and even FitBit, but breaks down when you start to consider use cases like having someone's personal WordPress blog be its own OAuth server. If I want to build an app that lets you upload photos to your WordPress site, I'm obviously not going to be able to register for API keys on everyone's own WordPress installations. Enabling third party clients to be built against systems like WordPress or Mastodon opens up a huge possibility for some really interesting things. The trick is always how do these apps authenticate the user or obtain a token they can use to access those APIs.</p>\n<p>This post details a few specific challenges with OAuth preventing it from being used by independent websites, as well as the solutions to each.</p>\n\n<h2>Client Registration</h2>\n<p>The first major hurdle to overcome is the need for the developer to register to get API keys for the service. In a world where everyone's own website is its own OAuth server, it's obviously not practical to have an app developer register API keys at each.</p>\n<p>In OAuth, client registration gives us a few specific things:</p>\n<ul><li>\n    Provides a unique ID that is used to identify the app throughout the OAuth process, called the client ID\n    <br /></li>\n  <li>Provides a place to enter the name and icon for the app which is displayed during login</li>\n  <li>Registers one or more redirect URLs for security</li>\n  <li>For \"confidential clients\" (web server apps), registration also provides the client with a client secret</li>\n</ul><p>Note that in traditional OAuth, client secrets are not used by mobile apps or JavaScript apps, and OAuth servers will often not even issue secrets to those types of apps. Since we're trying to avoid registration entirely, we can also just avoid using client secrets at all, and leverage the same protections OAuth already has in place for clients that can't use a secret.</p>\n<img src=\"https://aperture-media.p3k.io/aaronparecki.com/b31e8bcf790aa2b853eee68cf80e8b0e61994aaf09c727a83c55466089a1b217.png\" alt=\"\" /><p>In order to avoid registration, we need a solution for the first three bullet points above.</p>\n<p><b>Client ID</b>: Every application needs a unique identifier. If we're talking about turning every website into an OAuth provider, we need a way to have globally unique identifiers for every OAuth app. It turns out we already have a mechanism for this: URLs! In this Open Web version of OAuth, client IDs can be the application's URL. For web-based apps, this is straightforward, as it's simply the website the app is running on. For native apps, this can be the application's \"about\" page.</p>\n<p><b>Application name and icon</b>: Since the application's client ID is a URL, we can assume every application has a web page that talks about it, and treat that web page as the place the client defines its own metadata like name and icon. A simple way to accomplish this is with Microformats, so that the application's web page just needs to add a couple classes around the name and icon of the app. This is currently documented and implemented as the <a href=\"https://indieweb.org/h-app\">h-app</a> microformat.</p>\n<p><b>Redirect URL registration</b>: This one is a bit more subtle. The purpose of redirect URL registration is to prevent an attacker from tricking an authorization server into sending authorization codes to the attacker. This becomes especially important when we aren't using client secrets. The trick is that since client IDs are already URLs, we can shortcut the normal registration process by declaring a rule that redirect URLs have to be on the same domain as the client ID. This way, we can avoid a situation where an application claiming to be good.example.com sets a redirect URL to attacker.example.org and steals the authorization code. The only way to get the authorization code to attacker.example.org would be to set the client ID to that domain as well, which a user would hopefully notice.</p>\n\n<h2>User Accounts</h2>\n<p>There are two different situations to consider with regards to user accounts: <i>authentication</i> and <i>authorization</i>. Authentication is the process of proving the identity of the person signing in. Authorization is how an application obtains permission to do something to someone's account.</p>\n<p>When we talk about <i>authentication</i>, we are talking about wanting to allow an unknown user to identify themselves to the site they're logging in to. Common examples of this are using your email address as your identity to sign in to a website. You bring an existing identity (your email address) and then authenticate (usually by clicking a link that was sent to your email). The original version of OpenID was created to solve this problem on the web. People identified themselves with a URL, which they were able to prove they controlled using OpenID. This allows a new user to log in to a site without needing a prior relationship with the site.</p>\n<p>When we talk about <i>authorization</i>, the situation is subtly different. In this case, we're talking about a user of a website wanting to give permission to a third-party app to access some part of their account. We're very used to this pattern now, which is the typical OAuth use case of granting an application the ability to access your Google Calendar, or logging in to a third party Twitter app.</p>\n<p><b>Authorization</b>: There isn't really a challenge unique OAuth on the Open Web with regards to authorization. Once the client registration problem is solved, everything else falls into place nicely. It is assumed that users are authorizing an application to access an account they already have, so the application will just end up with an access token that works with their existing account.</p>\n<p><b>Authentication</b>: Where we need to define some new behavior is talking about authentication. In this case, we want users to be able to bring an existing identity and use it to log in to other places. This means we need a way to uniquely identify users across the entire web. We can again use URLs as the solution! Every user is identified by a URL. This can be a short URL like someone's domain name, e.g. <b>https://aaronparecki.com/</b>, or for a site with multiple users, can be a URL that contains a path specifying a particular user on the site, e.g. <b>https://github.com/aaronpk</b>.\u00a0</p>\n\n<h2>Discovery</h2>\n<p>With traditional OAuth services, discovery is not needed since the application author knows which OAuth server they're talking to before they start building the app. There is typically a \"Sign in with ____\" button in the application that begins the authorization process. In the case of using OAuth for authentication, the common pattern is to include buttons for several common \"social login\" providers such as Facebook, Google, Twitter and LinkedIn. Before the \"social login\" space essentially consolidated to these four, there were sometimes a dozen of these buttons on an application's login page, which eventually became known as the \"NASCAR problem\".</p>\n<img src=\"https://aperture-media.p3k.io/aaronparecki.com/53b04744ebfaec38d6b6b4b65fb19b217a91f712d489f19ec85be8e2f2e201c5.png\" alt=\"\" /><p>In a world where every WordPress or Gitlab site is its own OAuth provider, there obviously can't be a button for each on a login screen. Instead, we need to find out from the user which server to use to authenticate them.\u00a0</p>\n<p>Since we previously stated that every user identifier is a URL, we can ask the user to enter their URL in the sign-in screen, and then fetch that URL and discover their authorization server from there.</p>\n<img src=\"https://aperture-media.p3k.io/aaronparecki.com/61b1c30b21fa6ac074564d906b4d490faf5523af6aa6a70d19076093e19c2c13.png\" alt=\"\" /><p>Once we've found the user's authorization endpoint, we can start a normal OAuth request and send them to their server to authenticate. When the server redirects back to the application, it will go and verify the authorization code with their authorization endpoint just like normally happens with OAuth.</p>\n\n<h2>Knowing Who Logged In</h2>\n<p>While knowing any user identity information is technically not part of OAuth, we do need the server to return a user identifier when using OAuth for authentication. In practice, most applications also want at least a unique user identifier in the authorization case as well.</p>\n<p>We've previously said that user identifiers are URLs, which solves the global user identity problem, and gives us a mechanism to discover the user's OAuth server. So all we need is a way to return this information to the application after the user has authenticated.\u00a0</p>\n<p>OAuth gives us an easy opportunity to return this to the application: in the access token response when the application sends the authorization code to obtain an access token. The server can at that point return the full user identifier of the user that logged in. As long as the domain name matches the domain that the user entered at the start, the application can consider it successful. This also gives the authorization server the opportunity to canonicalize the user identifier, correcting \"http\" to \"https\", or adding a path component to the user's profile URL.</p>\n\n<h2>Let's do this!</h2>\n<p>By now, hopefully you're thinking \"this sounds great, Aaron, someone should write this up as a OAuth extension!\" I'm glad you asked!</p>\n<img src=\"https://aperture-media.p3k.io/aaronparecki.com/861471899aba530cbd64a1330d163ca9e77d28c92b8bf86bc238a6c07dcc3c01.png\" alt=\"\" />The <a href=\"https://indieauth.spec.indieweb.org/\">IndieAuth</a> spec, an OAuth 2.0 extension<p>Earlier this year, I wrote this all up as an extension to OAuth 2.0, called IndieAuth. IndieAuth encapsulates these small additions needed for OAuth 2.0 to work in the Open Web.</p>\n<p>Despite this spec being published in January, it has actually been implemented for several years before that. There are <a href=\"https://indieweb.org/IndieAuth#Implementations\">many implementations</a> of this extension on the server side, everything from standalone authorization server projects, to a <a href=\"https://indieweb.org/Wordpress_IndieAuth_Plugin\">WordPress</a>\u00a0plugin, and it's even implemented by a commercial service, <a href=\"http://www.manton.org/2018/07/indieauth-for-micro-blog.html\">Micro.blog</a>. As far as consuming apps, nearly every <a href=\"https://indieweb.org/Micropub/Clients\">Micropub app</a> has implemented this for logging users in.</p>\n<p>For further details on implementing this extension, there are several guides available depending on whether you're writing a client, a server, or just part of a server.</p>\n<ul><li><a href=\"https://indieweb.org/indieauth-for-login\">Authenticating users with IndieAuth</a></li>\n  <li><a href=\"https://indieweb.org/obtaining-an-access-token\">Obtaining an access token with IndieAuth</a></li>\n  <li><a href=\"https://indieweb.org/authorization-endpoint\">Creating an Authorization Endpoint</a></li>\n  <li><a href=\"https://indieweb.org/token-endpoint\">Creating a Token Endpoint</a></li>\n</ul><p>There are a few existing open source projects you can use to get started if you don't want to write your own!</p>\n<ul><li>\n<a href=\"https://github.com/inklings-io/selfauth\">selfauth</a> - a standalone authorization server using a simple password login</li>\n  <li>\n<a href=\"https://wordpress.org/plugins/indieauth/\">IndieAuth for WordPress</a> - a plugin that turns your WordPress install into an OAuth 2.0 server</li>\n  <li>\n<a href=\"https://github.com/barryf/acquiescence\">Acquiescence</a> - an authorization endpoint written in Ruby that authenticates users via GitHub</li>\n</ul><p>For further reading, check out the <a href=\"https://indieauth.spec.indieweb.org/\">IndieAuth spec</a>.\u00a0Feel free to drop in to the <a href=\"https://indieweb.org/discuss\">IndieWeb chat</a> if you'd like to talk about this, or you can reach me on <a href=\"https://twitter.com/aaronpk\">Twitter</a>\u00a0or from <a href=\"https://aaronparecki.com/\">my website</a>.</p>"
    },
    "author": {
        "type": "card",
        "name": "Aaron Parecki",
        "url": "https://aaronparecki.com/",
        "photo": "https://aperture-media.p3k.io/aaronparecki.com/2b8e1668dcd9cfa6a170b3724df740695f73a15c2a825962fd0a0967ec11ecdc.jpg"
    },
    "_id": "558768",
    "_source": "16",
    "_is_read": true
}

Being the change isn’t enough

{
    "type": "entry",
    "published": "2018-07-07T16:50:49+01:00",
    "url": "https://ascraeus.org/being-the-change-isn-t-enough/",
    "name": "Being the change isn\u2019t enough",
    "content": {
        "text": "Was involved in a pretty dispiriting discourse on the indieweb irc channels earlier in the week. The specific issue of contention was the use of .io domains, and why you really shouldn\u2019t do that, but the terms and process of the debate (such as it was) followed the standard path for seemingly all such discourse in recent years.\n\n\nplease don\u2019t use .io domains\nbecause of the security breach a few years back?\nno, because by doing so you perpetrate the decades-long abuse of the Chagossian people\nah, politics. /me demurs\n\n\nI get and see this reaction all the time these days, on a multiplicity of topics and issues. It seems to be a particular mindset which has been widely adopted by well-meaning people in pursuit of some, I don\u2019t know, technical clarity?\n\nThe thing is, compelling as that mindset might be, it is completely wrong and damaging, on almost every level.\n\n\nPOLITICS (from \u03c0\u03bf\u03bb\u03b9\u03c4\u03b9\u03ba\u03ac, translit. Politik\u00e1, meaning \u201caffairs of the cities\u201d)\n\nthe complex or aggregate of relationships of people in society\n\n\nPut simply, politics is everywhere. Politics pervades our connected societies in ways that would have been unimaginable two or three generations ago. You can\u2019t just say that your actions are \u201cabove\u201d or \u201coutside\u201d politics. That, by itself, is a profoundly political position.\n\nSimilarly, the indieweb is a political movement, regardless of whether it ever intended to be one. Just look at the projects\u2019 web page\n\n\nWhat is the IndieWeb?\n\nThe IndieWeb is a people-focused alternative to the \u201ccorporate web\u201d.\nYour content is yours\n\nWhen you post something on the web, it should belong to you, not a corporation. [\u2026]\nYou are better connected\n\nYour articles and status messages can go to all services, not just one, allowing you to engage with everyone. [\u2026]\nYou are in control\n\nYou can post anything you want, in any format you want, with no one monitoring you.\n\n\n(Emphases and elisions are mine)\n\nNow, to my reading, that is a profoundly political document. It is based on personal self-realisation, written in terms of self-ownership and self-determination. It is precisely those principles which have propelled my own voyage of discovery, be that in terms of the indieweb and elsewhere. I cannot understand how or why anyone who holds to those principles would claim that they are not interested in politics.\n\nTo take this idea further, someone who is actively working to further the interests of the indieweb movement (by creating services or building blocks which allow those who are merely following the principles to do so more effectively) is engaged in a political action, based upon the principles of the movement, to further and advance those principles and goals in the pursuit of societal change.\n\nTo take it back to the origin of the discussion, I feel that, in that pursuit of change, it behoves us all to be cognisant of those principles when creating those building blocks. That\u2019s why, for example, I wrote my privacy policy, because I believe that my site needs to embody the principles I hold dear, otherwise, what\u2019s the point?\n\nThat is why it saddens me to see indieweb building blocks using the .io domain, largely because the (us-centric) tech culture views io as either cool or relevant, being the abbreviation for input-output. The .io domain, however, is a terrible one to use, as every subscription sees money flowing directly to the people who have carried out an effective genocide of an entire people, and who continue to perpetrate that oppression even today. It is as bad as the situation, just a few years ago, where using .ly domains, channelled funds to Muamar Ghadaffi\u2019s family and regime as they continued to oppress the benighted Libyan people.\n\nIf you haven\u2019t been aware of the issues, please, go and learn about the Chagossian people. The UK Chagos Support Asociation has a decent overview of the monstrous actions of the UK and US governments and military treatment of these people. You can see more in the Guardian\u2019s Chagos Archive.\n\nIf after reading even a little of that you feel that this is all just politics, nothing to do with you, then fine, I respect that decision. I can\u2019t pretend to understand your logic, however, nor can I see how you can claim to be building a \u201cpeople focussed alternative to the corporate web.\u201d1\n\nFinally, I just want to briefly address a coda to the above discussion, one that I see a lot these days, which is no surprise, given the awful timeline we\u2019re all now living in. I don\u2019t want to single out any particular person, but I am using a quote from someone which encapsulates this coda perfectly.\n\n\nI\u2019ve struggled mightily with caring too much about too many things, and\nit\u2019s emotionally exhausting! Especially for a person who struggles with\nanxiety/depression.\n\n\nBelieve me, I sympathise with this. Emotional exhaustion is a worry, anxiety and depression are no joke, I\u2019m a survivor myself. The thing is, however, you don\u2019t have to care too much about too many things to be a force for good in the world around you. You just have to know, even at a superficial level, what things in the world are contributing to making the world a better place, and what things are doing the opposite. To quote my old friend Marcus Aurelius:\n\n\n\u201cTo do harm is to do yourself harm. To do an injustice is to do yourself an\n injustice\u2014it degrades you. And you can also commit injustice by doing\n  nothing.\u201d\n\n [Meditations 9 4.&5.]\n\n\nThere\u2019s a huge difference between (a) not wanting to get involved in a struggle against injustice because of your mental health, and (b) abdicating personal responsibility to the level of perpetrating or facilitating an injustice. To put it another way, (as Gandhi said)\n\n\nIf we could change ourselves, the tendencies in the world would also change.\nAs a man changes his own nature, so does the attitude of the world change\ntowards him. \u2026 We need not wait to see what others do.\n\n\nPersonal and social transformation might go hand in hand, but mere personal transformation is not enough.\n\n\nUnless of course you\u2019re drawing arbitrary distinctions around different categories of people\n [return]",
        "html": "<p>Was involved in a pretty dispiriting discourse on the indieweb irc channels earlier in the week. The specific issue of contention was the use of .io domains, and why you really shouldn\u2019t do that, but the terms and process of the debate (such as it was) followed the standard path for seemingly all such discourse in recent years.</p>\n\n<blockquote>\n<p><strong>please don\u2019t use <code>.io</code> domains</strong><br /><em>because of the security breach a few years back?</em><br /><strong>no, because by doing so you perpetrate the decades-long abuse of the Chagossian people</strong><br /><em>ah, politics. /me demurs</em></p>\n</blockquote>\n\n<p>I get and see this reaction <em>all the time</em> these days, on a multiplicity of topics and issues. It seems to be a particular mindset which has been widely adopted by well-meaning people in pursuit of some, I don\u2019t know, technical clarity?</p>\n\n<p>The thing is, compelling as that mindset might be, it is completely wrong and damaging, on almost every level.</p>\n\n<blockquote>\n<p><strong>POLITICS</strong> (from \u03c0\u03bf\u03bb\u03b9\u03c4\u03b9\u03ba\u03ac, translit. Politik\u00e1, meaning \u201caffairs of the cities\u201d)<br />\nthe complex or aggregate of relationships of people in society</p>\n</blockquote>\n\n<p>Put simply, politics is everywhere. Politics pervades our connected societies in ways that would have been unimaginable two or three generations ago. You can\u2019t just say that your actions are \u201cabove\u201d or \u201coutside\u201d politics. That, by itself, is a <em>profoundly</em> political position.</p>\n\n<p>Similarly, the indieweb <em>is</em> a political movement, regardless of whether it ever intended to be one. Just look at the projects\u2019 <a href=\"https://indieweb.org\">web page</a></p>\n\n<blockquote>\n<p><strong>What is the IndieWeb?</strong><br />\nThe IndieWeb is a people-focused alternative to the \u201ccorporate web\u201d.<br /><strong>Your content is yours</strong><br />\nWhen you post something on the web, <em>it should belong to you</em>, not a corporation. [\u2026]<br /><strong>You are better connected</strong><br />\nYour articles and status messages can go to all services, not just one, <em>allowing you to engage with everyone.</em> [\u2026]<br /><strong>You are in control</strong><br />\nYou can post anything you want, in any format you want, <em>with no one monitoring you</em>.</p>\n</blockquote>\n\n<p><em>(Emphases and elisions are mine)</em></p>\n\n<p>Now, to my reading, that is a <em>profoundly</em> political document. It is based on personal self-realisation, written in terms of self-ownership and self-determination. It is precisely those principles which have propelled my own voyage of discovery, be that in terms of the indieweb and elsewhere. I cannot understand how or why anyone who holds to those principles would claim that they are <em>not</em> interested in politics.</p>\n\n<p>To take this idea further, someone who is actively <em>working</em> to further the interests of the indieweb movement (by creating services or building blocks which allow those who are merely <em>following</em> the principles to do so more effectively) is engaged in a political action, based upon the principles of the movement, to further and advance those principles and goals in the pursuit of societal change.</p>\n\n<p>To take it back to the origin of the discussion, I feel that, in that pursuit of change, it behoves us all to be cognisant of those principles when creating those building blocks. That\u2019s why, for example, I wrote my <a href=\"https://ascraeus.org/page/privacy/\">privacy policy</a>, because I believe that my site needs to embody the principles I hold dear, otherwise, what\u2019s the point?</p>\n\n<p>That is why it saddens me to see indieweb building blocks using the <code>.io</code> domain, largely because the (us-centric) tech culture views <code>io</code> as either cool or relevant, being the abbreviation for input-output. The <code>.io</code> domain, however, is a terrible one to use, as every subscription sees money flowing directly to the people who have carried out an effective genocide of an entire people, and who continue to perpetrate that oppression even today. It is as bad as the situation, just a few years ago, where using <code>.ly</code> domains, channelled funds to Muamar Ghadaffi\u2019s family and regime as they continued to oppress the benighted Libyan people.</p>\n\n<p>If you haven\u2019t been aware of the issues, please, go and learn about the Chagossian people. The <a href=\"https://www.chagossupport.org.uk\">UK Chagos Support Asociation</a> has a decent overview of the monstrous actions of the UK and US governments and military treatment of these people. You can see more in the Guardian\u2019s <a href=\"https://www.theguardian.com/world/chagos-islands\">Chagos Archive</a>.</p>\n\n<p>If after reading even a little of that you feel that this is all just politics, nothing to do with you, then fine, I respect that decision. I can\u2019t pretend to understand your logic, however, nor can I see how you can claim to be building a \u201cpeople focussed alternative to the corporate web.\u201d<a href=\"https://ascraeus.org/#fn:1\">1</a></p>\n\n<p>Finally, I just want to briefly address a coda to the above discussion, one that I see a lot these days, which is no surprise, given the awful timeline we\u2019re all now living in. I don\u2019t want to single out any particular person, but I am using a quote from someone which encapsulates this coda perfectly.</p>\n\n<blockquote>\n<p>I\u2019ve struggled mightily with caring too much about too many things, and\nit\u2019s emotionally exhausting! Especially for a person who struggles with\nanxiety/depression.</p>\n</blockquote>\n\n<p>Believe me, I sympathise with this. Emotional exhaustion is a worry, anxiety and depression are no joke, I\u2019m a survivor myself. The thing is, however, you don\u2019t have to care too much about too many things to be a force for good in the world around you. You just have to know, even at a superficial level, what things in the world are contributing to making the world a better place, and what things are doing the opposite. To quote my old friend Marcus Aurelius:</p>\n\n<blockquote>\n<p>\u201cTo do harm is to do yourself harm. To do an injustice is to do yourself an\n injustice\u2014it degrades you. And you can also commit injustice by doing\n  nothing.\u201d<br />\n [Meditations 9 4.&amp;5.]</p>\n</blockquote>\n\n<p>There\u2019s a huge difference between (a) not wanting to get involved in a struggle against injustice because of your mental health, and (b) abdicating personal responsibility to the level of perpetrating or facilitating an injustice. To put it another way, (as Gandhi said)</p>\n\n<blockquote>\n<p>If we could change ourselves, the tendencies in the world would also change.\nAs a man changes his own nature, so does the attitude of the world change\ntowards him. \u2026 We need not wait to see what others do.</p>\n</blockquote>\n\n<p>Personal and social transformation might go hand in hand, but mere personal transformation is not enough.</p>\n\n\n<ol><li>Unless of course you\u2019re drawing arbitrary distinctions around different categories of people\n <a href=\"https://ascraeus.org/#fnref:1\">[return]</a>\n</li>\n</ol>"
    },
    "author": {
        "type": "card",
        "name": "Daniel Goldsmith",
        "url": "https://ascraeus.org/",
        "photo": "https://aperture-proxy.p3k.io/9fde252f71ab2156be6041f7c744976dc51bfaed/68747470733a2f2f61736372616575732e6f72672f70696374757265732f6d617276696e2e706e67"
    },
    "_id": "558617",
    "_source": "195",
    "_is_read": true
}

{
    "type": "entry",
    "published": "2018-07-06T19:47:37-04:00",
    "url": "https://miklb.com/blog/2018/07/06/4041/",
    "syndication": [
        "https://twitter.com/miklb/status/1015381797994160129"
    ],
    "content": {
        "text": "Just found @agiletortoise\u2019s post to Micro.blog action for Drafts5 and realized it\u2019s using micropub so I can modify and post directly to my WordPress site. https://actions.getdrafts.com/a/1Dj",
        "html": "<p>Just found @agiletortoise\u2019s post to Micro.blog action for Drafts5 and realized it\u2019s using micropub so I can modify and post directly to my WordPress site. <a href=\"https://actions.getdrafts.com/a/1Dj\">https://actions.getdrafts.com/a/1Dj</a>\n</p>"
    },
    "author": {
        "type": "card",
        "name": "Michael Bishop",
        "url": "https://miklb.com",
        "photo": "https://aperture-proxy.p3k.io/d23fd4e96c85a909d2c1c121d7b72ebe2b369d8b/68747470733a2f2f7062732e7477696d672e636f6d2f70726f66696c655f696d616765732f3739393832313734393338363837343838302f585f7676374d6e4b2e6a7067"
    },
    "_id": "553154",
    "_source": "42",
    "_is_read": true
}

{
    "type": "entry",
    "published": "2018-07-06T15:39:21-07:00",
    "url": "https://aaronparecki.com/2018/07/06/21/",
    "category": [
        "indieweb"
    ],
    "syndication": [
        "https://twitter.com/aaronpk/status/1015364623095103488"
    ],
    "content": {
        "text": "I don't completely agree with this sentiment, but it was still a fun read: https://stackingthebricks.com/how-blogs-broke-the-web/ #indieweb",
        "html": "I don't completely agree with this sentiment, but it was still a fun read: <a href=\"https://stackingthebricks.com/how-blogs-broke-the-web/\">https://stackingthebricks.com/how-blogs-broke-the-web/</a> <a href=\"https://aaronparecki.com/tag/indieweb\">#indieweb</a>"
    },
    "author": {
        "type": "card",
        "name": "Aaron Parecki",
        "url": "https://aaronparecki.com/",
        "photo": "https://aperture-media.p3k.io/aaronparecki.com/2b8e1668dcd9cfa6a170b3724df740695f73a15c2a825962fd0a0967ec11ecdc.jpg"
    },
    "_id": "552981",
    "_source": "16",
    "_is_read": true
}

{
    "type": "entry",
    "published": "2018-07-06T14:26:14-04:00",
    "url": "https://martymcgui.re/2018/07/06/142614/",
    "in-reply-to": [
        "https://jaredwhite.com/podcast/5/"
    ],
    "content": {
        "text": "Fun episode! Thanks for the shout out about \ud83d\udd78\ud83d\udc8d!\nCurrently signing up requires a full on IndieAuth setup, which can be done with an extra template. I plan to add support for RelMeAuth soon, thanks to indielogin.com!",
        "html": "<p>Fun episode! Thanks for the shout out about \ud83d\udd78\ud83d\udc8d!</p>\n<p>Currently signing up requires a full on IndieAuth setup, which can be done with an extra template. I plan to add support for RelMeAuth soon, thanks to indielogin.com!</p>"
    },
    "author": {
        "type": "card",
        "name": "Marty McGuire",
        "url": "https://martymcgui.re/",
        "photo": "https://aperture-proxy.p3k.io/8275f85e3a389bd0ae69f209683436fc53d8bad9/68747470733a2f2f6d617274796d636775692e72652f696d616765732f6c6f676f2e6a7067"
    },
    "refs": {
        "https://jaredwhite.com/podcast/5/": {
            "type": "entry",
            "published": "2018-07-02T14:12:00-04:00",
            "summary": "Somehow on today\u2019s show we end up waxing nostalgic about the Sci-Fi of youth: namely, Babylon 5 and Star Trek: The Next Generation. But don\u2019t worry, there\u2019s also plenty to look forward to, such as throwing off the shackles of our corporate web overlords and embracing the scrappy technology of the IndieWeb. (Recent rebel activity was spotted on the surface...",
            "url": "https://jaredwhite.com/podcast/5/",
            "photo": [
                "https://martymcgui.re/imageproxy/960,fit,sLXA7V4aVWxbPJcf7zF8MyhskQttpwMC3v1DIZM_dsFE=/https://jaredwhite.com/assets/the-jared-white-show.jpg"
            ],
            "audio": [
                "http://media.blubrry.com/jaredwhiteshow/jaredwhiteshow.s3.us-west-1.amazonaws.com/Episode%205%20-%20Nostalgia%20Cafe.mp3"
            ],
            "name": "Nostalgia Caf\u00e9",
            "author": {
                "type": "card",
                "name": "The Jared White Show",
                "url": "https://martymcgui.re/posts/",
                "photo": null
            }
        }
    },
    "_id": "552805",
    "_source": "175",
    "_is_read": true
}

{
    "type": "entry",
    "author": {
        "name": "manton",
        "url": "http://www.manton.org",
        "photo": null
    },
    "url": "http://www.manton.org/2018/07/7051.html",
    "content": {
        "html": "<p>We posted <a href=\"https://coreint.org/2018/07/episode-335-kind-of-a-challenge-for-newcomers/\">a new episode of Core Intuition</a> this week with a summary of my time at IndieWeb Summit and more.</p>",
        "text": "We posted a new episode of Core Intuition this week with a summary of my time at IndieWeb Summit and more."
    },
    "published": "2018-07-06T21:22:32+00:00",
    "updated": "2018-07-06T21:22:32+00:00",
    "_id": "552630",
    "_source": "12",
    "_is_read": true
}

{
    "type": "entry",
    "published": "2018-07-06T12:24:50-07:00",
    "url": "https://aaronparecki.com/2018/07/06/11/",
    "category": [
        "indieweb"
    ],
    "syndication": [
        "https://twitter.com/aaronpk/status/1015315667740852224"
    ],
    "content": {
        "text": "My solution to avoid the pain of renewing domains every year: register them for 5 years at a time. \ud83d\ude02\ud83d\udcb8",
        "html": "My solution to avoid the pain of renewing domains every year: register them for 5 years at a time. <a href=\"https://aaronparecki.com/emoji/%F0%9F%98%82\">\ud83d\ude02</a><a href=\"https://aaronparecki.com/emoji/%F0%9F%92%B8\">\ud83d\udcb8</a>"
    },
    "author": {
        "type": "card",
        "name": "Aaron Parecki",
        "url": "https://aaronparecki.com/",
        "photo": "https://aperture-media.p3k.io/aaronparecki.com/2b8e1668dcd9cfa6a170b3724df740695f73a15c2a825962fd0a0967ec11ecdc.jpg"
    },
    "_id": "551596",
    "_source": "16",
    "_is_read": true
}

{
    "type": "entry",
    "published": "2018-07-06T16:47:11+00:00",
    "url": "https://cleverdevil.io/2018/it-would-also-be-nice-to-add-indieauth-to-the",
    "in-reply-to": [
        "https://github.com/cleverdevil/Indiepaper-macOS/issues/1"
    ],
    "content": {
        "text": "It would also be nice to add IndieAuth to the Indiepaper website, which could then generate bookmarklets and macOS configuration links automatically based upon the IndieAuth exchange.For the use case of Aperture, the user would log into www.indiepaper.io with https://aperture.p3k.io, and then would select a channel to publish to during the auth flow.",
        "html": "<p>It would also be nice to add IndieAuth to the Indiepaper website, which could then generate bookmarklets and macOS configuration links automatically based upon the IndieAuth exchange.</p><p>For the use case of Aperture, the user would log into www.indiepaper.io with <a href=\"https://aperture.p3k.io\">https://aperture.p3k.io</a>, and then would select a channel to publish to during the auth flow.</p>\n<p><a href=\"https://brid.gy/publish/github\"></a></p>"
    },
    "author": {
        "type": "card",
        "name": "Jonathan LaCour",
        "url": "https://cleverdevil.io/profile/cleverdevil",
        "photo": "https://aperture-proxy.p3k.io/77e5d6e5871324c43aebf2e3e7a5553e14578f66/68747470733a2f2f636c65766572646576696c2e696f2f66696c652f66646263373639366135663733383634656131316138323863383631653133382f7468756d622e6a7067"
    },
    "_id": "550559",
    "_source": "71",
    "_is_read": true
}

Automate configuration of mp-destination and token

{
    "type": "entry",
    "published": "2018-07-06T16:37:46+00:00",
    "url": "https://cleverdevil.io/2018/automate-configuration-of-mp-destination-and-token",
    "in-reply-to": [
        "https://github.com/cleverdevil/Indiepaper-macOS"
    ],
    "name": "Automate configuration of mp-destination and token",
    "content": {
        "text": "At present,\u00a0Indiepaper for macOS requires that the user manually configure their target micropub endpoint and a bearer token. This is nice and explicit, but it isn't a particularly good user experience. It would be better if configuration was automated.Currently, I am thinking that I should add auto-configuration via a URL handler for the macOS app. Something like this:`indiepaper:configure?micropubTargetURL=https://aperture.p3k.io/micropub&bearerToken=ASDF`Then, when clicked, the link would launch Indiepaper for macOS, store the configuration, and let the user know that they're all set.",
        "html": "<p>At present,\u00a0Indiepaper for macOS requires that the user manually configure their target micropub endpoint and a bearer token. This is nice and explicit, but it isn't a particularly good user experience. It would be better if configuration was automated.</p><p>Currently, I am thinking that I should add auto-configuration via a URL handler for the macOS app. Something like this:</p><p>`indiepaper:configure?micropubTargetURL=https://aperture.p3k.io/micropub&amp;bearerToken=ASDF`</p><p>Then, when clicked, the link would launch Indiepaper for macOS, store the configuration, and let the user know that they're all set.</p>\n<p><a href=\"https://brid.gy/publish/github\"></a></p>"
    },
    "author": {
        "type": "card",
        "name": "Jonathan LaCour",
        "url": "https://cleverdevil.io/profile/cleverdevil",
        "photo": "https://aperture-proxy.p3k.io/77e5d6e5871324c43aebf2e3e7a5553e14578f66/68747470733a2f2f636c65766572646576696c2e696f2f66696c652f66646263373639366135663733383634656131316138323863383631653133382f7468756d622e6a7067"
    },
    "_id": "550560",
    "_source": "71",
    "_is_read": true
}

Indiepaper for macOS

{
    "type": "entry",
    "published": "2018-07-05T20:11:38+00:00",
    "url": "https://cleverdevil.io/2018/indiepaper-for-macos",
    "syndication": [
        "https://twitter.com/cleverdevil/status/1014967340797177858"
    ],
    "name": "Indiepaper for macOS",
    "content": {
        "text": "IndieWeb Summit 2018\u00a0took place a few weeks ago in Portland, OR, and my project on day two was to create a service called Indiepaper, which is a \"read it later\" service for the IndieWeb. Indiepaper makes use of\u00a0Mercury by Postlight Labs\u00a0under the hood to extract article content and then publish it to a Micropub\u00a0destination for later reading. Indiepaper is open source\u00a0and is deployed on AWS Lambda\u00a0using the Zappa framework. The Indiepaper website\u00a0includes a tool to create a Bookmarklet for your web browser, and a Workflow for iOS that adds system-wide support for sending links to Indiepaper.In order to make Indiepaper even easier to use, I created Indiepaper for macOS, which adds system-wide sharing support for Indiepaper to macOS. Here is a quick video demo of Indiepaper for macOS in action. Indiepaper for macOS is also open source, so feel free to poke around in the source code, and submit pull requests if you have improvements!",
        "html": "<p><img src=\"https://aperture-proxy.p3k.io/62e5fbc233f798b1cbf007b40fc74f556918c816/68747470733a2f2f636c65766572646576696c2e696f2f66696c652f3631303030643138333630653833643430383934666432623532613664653965\" alt=\"Indiepaper Logo\" width=\"128\" height=\"128\" /><a href=\"http://2018.indieweb.org\">IndieWeb Summit 2018</a>\u00a0took place a few weeks ago in Portland, OR, and my project on day two was to create a service called <a href=\"https://indiepaper.cleverdevil.io\">Indiepaper</a>, which is a \"read it later\" service for the <a href=\"https://indieweb.org\">IndieWeb</a>. Indiepaper makes use of\u00a0<a href=\"https://mercury.postlight.com\">Mercury by Postlight Labs</a>\u00a0under the hood to extract article content and then publish it to a <a href=\"https://indieweb.org/Micropub\">Micropub</a>\u00a0destination for later reading. <a href=\"https://github.com/cleverdevil/indiepaper\">Indiepaper is open source</a>\u00a0and is deployed on <a href=\"https://aws.amazon.com/lambda/\">AWS Lambda</a>\u00a0using the <a href=\"https://www.zappa.io\">Zappa framework</a>. The <a href=\"https://indiepaper.cleverdevil.io\">Indiepaper website</a>\u00a0includes a tool to create a Bookmarklet for your web browser, and a Workflow for iOS that adds system-wide support for sending links to Indiepaper.</p><p>In order to make Indiepaper even easier to use, I created <a href=\"https://github.com/cleverdevil/Indiepaper-macOS/releases\">Indiepaper for macOS</a>, which adds system-wide sharing support for Indiepaper to macOS. <a href=\"https://cleverdevil.io/s/ZM4yR9ndtw.mp4\">Here is a quick video demo of Indiepaper for macOS in action</a>. <a href=\"https://github.com/cleverdevil/Indiepaper-macOS\">Indiepaper for macOS is also open source</a>, so feel free to poke around in the source code, and submit pull requests if you have improvements!</p>"
    },
    "author": {
        "type": "card",
        "name": "Jonathan LaCour",
        "url": "https://cleverdevil.io/profile/cleverdevil",
        "photo": "https://aperture-proxy.p3k.io/77e5d6e5871324c43aebf2e3e7a5553e14578f66/68747470733a2f2f636c65766572646576696c2e696f2f66696c652f66646263373639366135663733383634656131316138323863383631653133382f7468756d622e6a7067"
    },
    "_id": "544684",
    "_source": "71",
    "_is_read": true
}

{
    "type": "entry",
    "published": "2018-07-05T10:21:43-04:00",
    "url": "https://martymcgui.re/2018/07/05/102143/",
    "in-reply-to": [
        "https://ramblinggit.com/2018/07/the-indieweb-discovery-and-web-search/"
    ],
    "content": {
        "text": "A major missing feature from the Big search engines is that they don\u2019t bother understanding the richer microformats2 content on many IndieWeb enabled sites. Data like \u201cthis a like of that post\u201d and \u201cthis is a reply to some other post\u201d.\nRyan Barrett did some great exploratory work last year on a microformats2-enabled crawler and on the resulting data set: http://indiemap.org/",
        "html": "<p>A major missing feature from the Big search engines is that they don\u2019t bother understanding the richer microformats2 content on many IndieWeb enabled sites. Data like \u201cthis a like of that post\u201d and \u201cthis is a reply to some other post\u201d.</p>\n<p><a href=\"https://snarfed.org/\">Ryan Barrett</a> did some great exploratory work last year on a microformats2-enabled crawler and on the resulting data set: http://indiemap.org/</p>"
    },
    "author": {
        "type": "card",
        "name": "Marty McGuire",
        "url": "https://martymcgui.re/",
        "photo": "https://aperture-proxy.p3k.io/8275f85e3a389bd0ae69f209683436fc53d8bad9/68747470733a2f2f6d617274796d636775692e72652f696d616765732f6c6f676f2e6a7067"
    },
    "refs": {
        "https://ramblinggit.com/2018/07/the-indieweb-discovery-and-web-search/": {
            "type": "entry",
            "published": "2018-07-05T05:04:00-04:00",
            "summary": "First, let me say, I understand that the IndieWeb movement already has a lot on their plate and that they have already accomplished a lot. It seems to me, at some point, the problem of commercial silos of web search engines must be addressed since 1. a near monopoly is held by Google, 2. both spidering engines (Google and Bing)...",
            "url": "https://ramblinggit.com/2018/07/the-indieweb-discovery-and-web-search/",
            "name": "The IndieWeb, Discovery and Web Search",
            "author": {
                "type": "card",
                "name": "Brad",
                "url": "https://ramblinggit.com/",
                "photo": "https://martymcgui.re/imageproxy/60,s9LRKLJ_nB64ZVTU67UqwA3N9VaeD-p2Lc1qiGIzHOKw=/https://secure.gravatar.com/avatar/0ce8b2c406e423f114e39fd4d128c31d?s=40&d=https://ramblinggit.com/wp-content/plugins/semantic-linkbacks/img/mm.jpg&r=g"
            }
        }
    },
    "_id": "542761",
    "_source": "175",
    "_is_read": true
}