The web is the social network

{
    "type": "entry",
    "author": {
        "name": null,
        "url": "https://www.manton.org/",
        "photo": null
    },
    "url": "https://www.manton.org/2018/07/02/193738.html",
    "name": "The web is the social network",
    "content": {
        "html": "<p>In my talk at Peers Conference earlier this year I closed with this quote from Brent Simmons:</p>\n\n<blockquote>\n  Micro.blog is not an alternative silo: instead, it\u2019s what you build when you believe that <em>the web itself</em> is the great social network.\n</blockquote>\n\n<p>I\u2019ve been thinking more about Brent\u2019s post since then, and so for the keynote that Jean and I gave at <a href=\"http://www.manton.org/2018/06/indieweb-summit-2018-wrap-up.html\">IndieWeb Summit last week</a> I wanted to start with that quote. Many people have written nice testimonials about Micro.blog, but this one really seems to capture the goal.</p>\n\n<p>It should come as no surprise that I liked <a href=\"http://inessential.com/2018/02/01/why_micro_blog_is_not_another_app_net\">Brent\u2019s full post from February about why Micro.blog isn\u2019t like App.net</a>. He made the case even better than I usually do, about how the web is more important than any one platform:</p>\n\n<blockquote>\n  But if you think of the years 1995-2005, you remember when the web was our social network: blogs, comments on blogs, feed readers, and services such as Flickr, Technorati, and BlogBridge to glue things together. Those were great years \u2014 but then a few tragedies happened: Google Reader came out, and then, almost <em>worse</em>, it went away. Worse still was the rise of Twitter and Facebook, when we decided it would be okay to give up ownership and let just a couple companies own our communication.\n</blockquote>\n\n<p>Micro.blog is one of the first platforms to focus on domain names that decouple the timeline from post storage. Anyone can post a Micro.blog-hosted site at their own domain name today and move it all somewhere else tomorrow. It\u2019s a simple, IndieWeb-friendly architecture that we think is essential to the next phase of the web.</p>",
        "text": "In my talk at Peers Conference earlier this year I closed with this quote from Brent Simmons:\n\n\n  Micro.blog is not an alternative silo: instead, it\u2019s what you build when you believe that the web itself is the great social network.\n\n\nI\u2019ve been thinking more about Brent\u2019s post since then, and so for the keynote that Jean and I gave at IndieWeb Summit last week I wanted to start with that quote. Many people have written nice testimonials about Micro.blog, but this one really seems to capture the goal.\n\nIt should come as no surprise that I liked Brent\u2019s full post from February about why Micro.blog isn\u2019t like App.net. He made the case even better than I usually do, about how the web is more important than any one platform:\n\n\n  But if you think of the years 1995-2005, you remember when the web was our social network: blogs, comments on blogs, feed readers, and services such as Flickr, Technorati, and BlogBridge to glue things together. Those were great years \u2014 but then a few tragedies happened: Google Reader came out, and then, almost worse, it went away. Worse still was the rise of Twitter and Facebook, when we decided it would be okay to give up ownership and let just a couple companies own our communication.\n\n\nMicro.blog is one of the first platforms to focus on domain names that decouple the timeline from post storage. Anyone can post a Micro.blog-hosted site at their own domain name today and move it all somewhere else tomorrow. It\u2019s a simple, IndieWeb-friendly architecture that we think is essential to the next phase of the web."
    },
    "published": "2018-07-02T14:37:38-05:00",
    "_id": "570883",
    "_source": "12",
    "_is_read": true
}

IndieAuth for Micro.blog

{
    "type": "entry",
    "author": {
        "name": null,
        "url": "https://www.manton.org/",
        "photo": null
    },
    "url": "https://www.manton.org/2018/07/02/indieauth-for-microblog.html",
    "name": "IndieAuth for Micro.blog",
    "content": {
        "html": "<p>After posting about <a href=\"http://www.manton.org/2018/06/indieweb-summit-2018-wrap-up.html\">my time at IndieWeb Summit</a> and <a href=\"http://www.manton.org/2018/06/indiebookclub.html\">the new IndieBookClub support</a>, let me give some more details on what IndieAuth means for Micro.blog. I spent the second day of IndieWeb Summit working on this, and it has now been rolled out to all Micro.blog users. (If you haven\u2019t posted in the last few days, after your next post your microblog will be updated with the new authorization endpoints.)</p>\n\n<p>IndieAuth lets you sign in to other apps using your own domain name. If Micro.blog is hosting a blog for you, you can use that custom domain or your subdomain like yourname.micro.blog to sign in.</p>\n\n<p>While this was possible before with extra configuration to delegate auth to another service, Micro.blog can now be an IndieAuth provider on its own. It\u2019s much easier for IndieWeb apps to work with Micro.blog.</p>\n\n<p>Here are some apps that work great with Micro.blog:</p>\n\n<ul><li><a href=\"https://quill.p3k.io/\">Quill</a>: web-based interface for posting to your microblog.</li>\n<li><a href=\"https://ownyourgram.com/\">OwnYourGram</a>: automatically post your Instagram photos to your microblog.</li>\n<li><a href=\"https://ownyourswarm.p3k.io/\">OwnYourSwarm</a>: automatically post your Swarm check-ins to your microblog.</li>\n<li><a href=\"https://indiebookclub.biz/\">IndieBookClub</a>: post what books you're reading or want to read.</li>\n<li><a href=\"https://omnibear.com/\">Omnibear</a>: Chrome or Firefox extension for quick posting.</li>\n<li><a>IndieWeb Ring</a>: wait\u2026 <a href=\"http://help.micro.blog/2018/web-rings/\">what?</a></li>\n</ul><p>I\u2019m really happy with the progress over the last week because it makes Micro.blog-hosted sites more useful. As I mentioned in my IndieWeb Summit keynote, the business model for Micro.blog is aligned with what users need. If you pay for Micro.blog hosting, we\u2019ll keep making it better without worrying about ads or other user-hostile distractions.</p>",
        "text": "After posting about my time at IndieWeb Summit and the new IndieBookClub support, let me give some more details on what IndieAuth means for Micro.blog. I spent the second day of IndieWeb Summit working on this, and it has now been rolled out to all Micro.blog users. (If you haven\u2019t posted in the last few days, after your next post your microblog will be updated with the new authorization endpoints.)\n\nIndieAuth lets you sign in to other apps using your own domain name. If Micro.blog is hosting a blog for you, you can use that custom domain or your subdomain like yourname.micro.blog to sign in.\n\nWhile this was possible before with extra configuration to delegate auth to another service, Micro.blog can now be an IndieAuth provider on its own. It\u2019s much easier for IndieWeb apps to work with Micro.blog.\n\nHere are some apps that work great with Micro.blog:\n\nQuill: web-based interface for posting to your microblog.\nOwnYourGram: automatically post your Instagram photos to your microblog.\nOwnYourSwarm: automatically post your Swarm check-ins to your microblog.\nIndieBookClub: post what books you're reading or want to read.\nOmnibear: Chrome or Firefox extension for quick posting.\nIndieWeb Ring: wait\u2026 what?\nI\u2019m really happy with the progress over the last week because it makes Micro.blog-hosted sites more useful. As I mentioned in my IndieWeb Summit keynote, the business model for Micro.blog is aligned with what users need. If you pay for Micro.blog hosting, we\u2019ll keep making it better without worrying about ads or other user-hostile distractions."
    },
    "published": "2018-07-02T08:24:37-05:00",
    "_id": "570886",
    "_source": "12",
    "_is_read": true
}

IndieBookClub

{
    "type": "entry",
    "author": {
        "name": null,
        "url": "https://www.manton.org/",
        "photo": null
    },
    "url": "https://www.manton.org/2018/06/30/indiebookclub.html",
    "name": "IndieBookClub",
    "content": {
        "html": "<p>As I mentioned in <a href=\"http://www.manton.org/2018/06/indieweb-summit-2018-wrap-up.html\">my IndieWeb Summit wrap-up</a>, I added support for <a href=\"https://indiebookclub.biz/\">IndieBookClub</a> while in Portland. IndieBookClub is a little like Goodreads, but built on standards like Microformats and Micropub so that you can post what you\u2019re reading to your own blog.</p>\n\n<p>Now that I\u2019m back in Austin, I\u2019ve tweaked the behavior to be smarter about recognizing the ISBN that IndieBookClub sends to Micro.blog. Posts from IndieBookClub also get the \ud83d\udcda emoji added automatically so that they show up in the <a href=\"https://micro.blog/discover/books\">books Discover section</a> on Micro.blog. Here\u2019s a screenshot of what posts look like on your Micro.blog-hosted site:</p>\n\n<p><img src=\"http://manton.micro.blog/uploads/2018/b6a848e9c9.jpg\" width=\"593\" height=\"321\" alt=\"Screenshot of IndieBookClub post\" /></p>\n\n<p>If the ISBN is specified, Micro.blog will redirect the link to Amazon, although we may change that in the future. And it\u2019s just a regular blog post, so you can always edit it using Markdown in Micro.blog.</p>",
        "text": "As I mentioned in my IndieWeb Summit wrap-up, I added support for IndieBookClub while in Portland. IndieBookClub is a little like Goodreads, but built on standards like Microformats and Micropub so that you can post what you\u2019re reading to your own blog.\n\nNow that I\u2019m back in Austin, I\u2019ve tweaked the behavior to be smarter about recognizing the ISBN that IndieBookClub sends to Micro.blog. Posts from IndieBookClub also get the \ud83d\udcda emoji added automatically so that they show up in the books Discover section on Micro.blog. Here\u2019s a screenshot of what posts look like on your Micro.blog-hosted site:\n\n\n\nIf the ISBN is specified, Micro.blog will redirect the link to Amazon, although we may change that in the future. And it\u2019s just a regular blog post, so you can always edit it using Markdown in Micro.blog."
    },
    "published": "2018-06-30T14:06:44-05:00",
    "_id": "570889",
    "_source": "12",
    "_is_read": true
}

IndieWeb Summit 2018 wrap-up

{
    "type": "entry",
    "author": {
        "name": null,
        "url": "https://www.manton.org/",
        "photo": null
    },
    "url": "https://www.manton.org/2018/06/30/indieweb-summit-wrapup.html",
    "name": "IndieWeb Summit 2018 wrap-up",
    "content": {
        "html": "<p>Last week I was in Portland for <a href=\"https://2018.indieweb.org/\">IndieWeb Summit</a>. This was only my second IndieWeb conference (the first was IndieWebCamp in Austin). I had a great time in Portland and got even more than I expected out of IndieWeb Summit.</p>\n\n<p>The first day was short keynotes and sessions led by attendees on a range of topics. Jean and I talked about our experience and goals with Micro.blog in reaching even more mainstream users. I went to sessions on Microformats, timeline algorithms, code libraries for common IndieWeb building blocks, and Microsub. Some of this carried over to the beginning of the next day, including Aaron Parecki leading a discussion about IndieAuth.</p>\n\n<p>We held <a href=\"http://macgenie.micro.blog/2018/06/26/micro-meetup-a.html\">a Micro.blog meetup at Von Ebert Brewing</a> after the first day wrapped up. Thanks everyone for joining us!</p>\n\n<p>Most of the second day was a hack day to work on our own projects, and at the end of the day everyone could present what they had worked on. I was so impressed with what people had come up with, whether that was improvements to their own site or prototypes for new tools.</p>\n\n<p>It turned out that having this dedicated time was exactly what I needed to turn Micro.blog into an IndieAuth provider. This means that Micro.blog no longer needs to delegate to Twitter or GitHub for authorization when someone is using an IndieWeb posting tool like OwnYourGram or Quill. Users can instead authorize directly with their Micro.blog account. I also added support for the <code>summary</code> fallback parameter in Micropub, which makes Micro.blog compatible with <a href=\"https://indiebookclub.biz/\">IndieBookClub</a>.</p>\n\n<p>In the morning before I left Portland, I interviewed Tantek and Aaron for my upcoming book Indie Microblogging. We had a great conversation on the founding of IndieWebCamp, the accomplishments and changes in the community, and where everything is going from here.</p>\n\n<p><img src=\"http://manton.micro.blog/uploads/2018/6f65264901.jpg\" width=\"300\" height=\"300\" alt=\"Coava Coffee\" /><img src=\"http://manton.micro.blog/uploads/2018/03bc2cf6d4.jpg\" width=\"300\" height=\"300\" alt=\"Portland bridge\" /></p>\n\n<p>Portland was great. For this trip I opted for an Airbnb close to the IndieWeb Summit venue. It was also just a block from <a href=\"https://www.coavacoffee.com/\">Coava Coffee</a>, where I spent a couple mornings catching up on work. I hope to be back in Portland for IndieWeb Summit next year.</p>",
        "text": "Last week I was in Portland for IndieWeb Summit. This was only my second IndieWeb conference (the first was IndieWebCamp in Austin). I had a great time in Portland and got even more than I expected out of IndieWeb Summit.\n\nThe first day was short keynotes and sessions led by attendees on a range of topics. Jean and I talked about our experience and goals with Micro.blog in reaching even more mainstream users. I went to sessions on Microformats, timeline algorithms, code libraries for common IndieWeb building blocks, and Microsub. Some of this carried over to the beginning of the next day, including Aaron Parecki leading a discussion about IndieAuth.\n\nWe held a Micro.blog meetup at Von Ebert Brewing after the first day wrapped up. Thanks everyone for joining us!\n\nMost of the second day was a hack day to work on our own projects, and at the end of the day everyone could present what they had worked on. I was so impressed with what people had come up with, whether that was improvements to their own site or prototypes for new tools.\n\nIt turned out that having this dedicated time was exactly what I needed to turn Micro.blog into an IndieAuth provider. This means that Micro.blog no longer needs to delegate to Twitter or GitHub for authorization when someone is using an IndieWeb posting tool like OwnYourGram or Quill. Users can instead authorize directly with their Micro.blog account. I also added support for the summary fallback parameter in Micropub, which makes Micro.blog compatible with IndieBookClub.\n\nIn the morning before I left Portland, I interviewed Tantek and Aaron for my upcoming book Indie Microblogging. We had a great conversation on the founding of IndieWebCamp, the accomplishments and changes in the community, and where everything is going from here.\n\n\n\nPortland was great. For this trip I opted for an Airbnb close to the IndieWeb Summit venue. It was also just a block from Coava Coffee, where I spent a couple mornings catching up on work. I hope to be back in Portland for IndieWeb Summit next year."
    },
    "published": "2018-06-30T13:34:01-05:00",
    "_id": "570890",
    "_source": "12",
    "_is_read": true
}

{
    "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
}