Shifting focus

{
    "type": "entry",
    "author": {
        "name": "Duncan Stephen",
        "url": "https://duncanstephen.co.uk/",
        "photo": null
    },
    "url": "https://duncanstephen.co.uk/shifting-focus/",
    "published": "2018-11-12T20:05:33+00:00",
    "content": {
        "html": "<img src=\"https://aperture-proxy.p3k.io/82083408d23bf3edfa0bd7aa3bb921f4d5340a12/68747470733a2f2f64756e63616e7374657068656e2e636f2e756b2f77702d636f6e74656e742f75706c6f6164732f323031382f31312f74696c742d73686966742d333630783138392e6a7067\" alt=\"Tilt shift photo of a wall\" /><p><a href=\"https://duncanstephen.co.uk/why-its-time-to-reclaim-our-digital-lives/\">Just over a year ago, I started blogging again</a>. Shortly afterwards, I committed myself to publishing a blog post a day. Most of these would be \u201c<a href=\"https://duncanstephen.co.uk/type/link/\">links that made me think</a>\u201d. I saw this as quite an easy way of publishing something daily.</p>\n<p>This seemed to work pretty well at first. But gradually, I began to realise something disturbing. It was taking me far too long to push these link posts out.</p>\n<p>Here is my blogging workflow. Whenever I read an interesting article I think is worth linking to, I add it to a backlog. When I have some spare time for blogging, I go through this backlog, re-read those articles, consider if I still find them interesting, then figure out if I have something interesting to say about them.</p>\n<p>I would often schedule these posts way in advance. This worked really well if I was going on holiday. I could have two weeks\u2019 worth of posts lined up and ready to go. But that brought other challenges. I had to avoid really timely topics. Although since it took me so long to get through my backlog, timely topics usually fell by the wayside anyway.</p>\n<p>Sometimes people would say to me in person, \u201cyou posted an interesting article today\u201d. But I couldn\u2019t even remember what I had written and scheduled for that day.</p>\n<p>If I was feeling really lazy, I would simply post a link, just with a quote from the link, without adding anything of my own. After a while, I stopped myself from doing that.</p>\n<p>I ought to add value, by adding my own commentary, or some kind of response to the article. Otherwise there is no real point in my posting a link.</p>\n<p>Also, most of the links I published didn\u2019t actually attract much traffic. People seem to be more interested in my longer articles, when I write about myself, or what I think about something.</p>\n<p>In a way, that makes sense. Why would anyone go to the Duncan Stephen blog to follow external links? As much as I might like to be, I\u2019m not a curator or an aggregator. The point of a personal blog is that it\u2019s <em>personal</em> \u2014 about me.</p>\n<p>Most absurdly of all, I have a large backlog of links that I have <em>loads</em> to say about, but I <em>haven\u2019t</em>. Because I perceive that I don\u2019t have the time to. Because I thought I needed to write about less interesting articles once a day.</p>\n<p>I expected August to be the toughest time of year to keep up the daily blogging routine, because it\u2019s such a busy time of year for me and I was going on holiday. But things actually ground to a halt in October.</p>\n<p>I found myself staring at a backlog of articles that were either slightly dull, or I didn\u2019t have anything to say about. Meanwhile, further down the list, there were a set of articles and topics I\u2019ve put off for another day when I\u2019ve got more time.</p>\n<p>The tail was wagging the dog. This was completely the opposite of the situation I wanted to be in when I started blogging again. I had wanted to be in control of what I published. But I let a self-imposed routine take control of me.</p>\n<p>So about a month ago I loosened up my rules. Gone are the daily link posts. Gone, possibly, is the commitment to post daily at all.</p>\n<p>Then the floodgates opened. Suddenly, I was writing more freely. I found myself tapping out more longer articles every week \u2014 sometimes a handful of them a one day.</p>\n<p>I had gone from agonising over what to say about a link, to genuinely writing about my own thoughts and feelings. It feels much better.</p>\n<h3>A technical note</h3>\n<p>I have changed the way different post types are organised. I had tried two previous out-of-the-box options \u2014 <a href=\"https://indieweb.org/Post_Kinds_Plugin\">IndieWeb Post Kinds</a> and <a href=\"https://codex.wordpress.org/Post_Formats\">WordPress\u2019s own Post Formats</a>. Neither of them worked quite right for me.</p>\n<p>So now I have implemented my own custom taxonomy. Quite why I hadn\u2019t done that in the first place is a mystery to me now, since custom taxonomies aren\u2019t actually that difficult to set up in WordPress.</p>\n<p>This does mean that I have to go through and add all of my archive posts to the new custom taxonomy. I\u2019m about a quarter of the way through. So some archives posts will look a bit odd for the time being.</p>",
        "text": "Just over a year ago, I started blogging again. Shortly afterwards, I committed myself to publishing a blog post a day. Most of these would be \u201clinks that made me think\u201d. I saw this as quite an easy way of publishing something daily.\nThis seemed to work pretty well at first. But gradually, I began to realise something disturbing. It was taking me far too long to push these link posts out.\nHere is my blogging workflow. Whenever I read an interesting article I think is worth linking to, I add it to a backlog. When I have some spare time for blogging, I go through this backlog, re-read those articles, consider if I still find them interesting, then figure out if I have something interesting to say about them.\nI would often schedule these posts way in advance. This worked really well if I was going on holiday. I could have two weeks\u2019 worth of posts lined up and ready to go. But that brought other challenges. I had to avoid really timely topics. Although since it took me so long to get through my backlog, timely topics usually fell by the wayside anyway.\nSometimes people would say to me in person, \u201cyou posted an interesting article today\u201d. But I couldn\u2019t even remember what I had written and scheduled for that day.\nIf I was feeling really lazy, I would simply post a link, just with a quote from the link, without adding anything of my own. After a while, I stopped myself from doing that.\nI ought to add value, by adding my own commentary, or some kind of response to the article. Otherwise there is no real point in my posting a link.\nAlso, most of the links I published didn\u2019t actually attract much traffic. People seem to be more interested in my longer articles, when I write about myself, or what I think about something.\nIn a way, that makes sense. Why would anyone go to the Duncan Stephen blog to follow external links? As much as I might like to be, I\u2019m not a curator or an aggregator. The point of a personal blog is that it\u2019s personal \u2014 about me.\nMost absurdly of all, I have a large backlog of links that I have loads to say about, but I haven\u2019t. Because I perceive that I don\u2019t have the time to. Because I thought I needed to write about less interesting articles once a day.\nI expected August to be the toughest time of year to keep up the daily blogging routine, because it\u2019s such a busy time of year for me and I was going on holiday. But things actually ground to a halt in October.\nI found myself staring at a backlog of articles that were either slightly dull, or I didn\u2019t have anything to say about. Meanwhile, further down the list, there were a set of articles and topics I\u2019ve put off for another day when I\u2019ve got more time.\nThe tail was wagging the dog. This was completely the opposite of the situation I wanted to be in when I started blogging again. I had wanted to be in control of what I published. But I let a self-imposed routine take control of me.\nSo about a month ago I loosened up my rules. Gone are the daily link posts. Gone, possibly, is the commitment to post daily at all.\nThen the floodgates opened. Suddenly, I was writing more freely. I found myself tapping out more longer articles every week \u2014 sometimes a handful of them a one day.\nI had gone from agonising over what to say about a link, to genuinely writing about my own thoughts and feelings. It feels much better.\nA technical note\nI have changed the way different post types are organised. I had tried two previous out-of-the-box options \u2014 IndieWeb Post Kinds and WordPress\u2019s own Post Formats. Neither of them worked quite right for me.\nSo now I have implemented my own custom taxonomy. Quite why I hadn\u2019t done that in the first place is a mystery to me now, since custom taxonomies aren\u2019t actually that difficult to set up in WordPress.\nThis does mean that I have to go through and add all of my archive posts to the new custom taxonomy. I\u2019m about a quarter of the way through. So some archives posts will look a bit odd for the time being."
    },
    "name": "Shifting focus",
    "post-type": "article",
    "_id": "1404806",
    "_source": "239",
    "_is_read": true
}

Homebrew Website Club SF!

{
    "type": "event",
    "name": "Homebrew Website Club SF!",
    "summary": "17:30: Optional writing hour and quiet socializing\n18:30: IndieWeb demos and hack night!\n\nHomebrew Website Club retro 1980s-style logo\nTopics for this week: Recently: IndieWebCamp Berlin! Year-end hack projects Demos of personal website breakthroughs Create or update your personal web site!\nJoin a community with like-minded interests. Bring friends that want a personal site, or are interested in a healthy, independent web!\nAny questions? Ask in #indieweb Slack or IRC\nMore information: IndieWeb Wiki Event Page\nRSVP: post an indie RSVP on your own site!",
    "published": "2018-11-12 10:15-0800",
    "start": "2018-11-14 17:30-0800",
    "end": "2018-11-14 19:30-0800",
    "url": "http://tantek.com/2018/318/e1/homebrew-website-club-sf",
    "location": [
        "https://wiki.mozilla.org/SF"
    ],
    "content": {
        "text": "When: 2018-11-14 17:30\u202619:30\nWhere: Mozilla San Francisco\n\nHost: Tantek \u00c7elik\n\n\n\n17:30: Optional writing hour and quiet socializing\n\n18:30: IndieWeb demos and hack night!\n\n\nTopics for this week:\nRecently: IndieWebCamp Berlin!\nYear-end hack projects\nDemos of personal website breakthroughs\nCreate or update your personal web site!\n\nJoin a community with like-minded interests. Bring friends that want a personal site, or are interested in a healthy, independent web!\n\n\nAny questions? Ask in \n#indieweb Slack or IRC\n\n\nMore information: \nIndieWeb Wiki Event Page\n\n\nRSVP:  post an indie RSVP on your own site!",
        "html": "<p>\nWhen: <time class=\"dt-start\">2018-11-14 17:30</time>\u2026<time class=\"dt-end\">19:30</time><span>\nWhere: <a class=\"u-location h-card\" href=\"https://wiki.mozilla.org/SF\">Mozilla San Francisco</a>\n</span>\nHost: <a class=\"u-organizer h-card\" href=\"http://tantek.com/\">Tantek \u00c7elik</a>\n</p>\n\n<p>\n17:30: Optional writing hour and quiet socializing<br />\n18:30: IndieWeb demos and hack night!<br /></p>\n<p><img class=\"u-featured\" style=\"height:300px;\" src=\"https://aperture-media.p3k.io/indieweb.org/c24f7b1e711955ef818bde12e2a3e79708ecc9b106d95b460a9fefe93b0be723.jpg\" alt=\"Homebrew Website Club retro 1980s-style logo\" /></p>\n<p>Topics for this week:</p>\n<ul><li>Recently: <a href=\"https://indieweb.org/2018/Berlin\">IndieWebCamp Berlin</a>!</li>\n<li><a href=\"https://indieweb.org/2019-01-01-commitments\">Year-end hack projects</a></li>\n<li>Demos of personal website breakthroughs</li>\n<li>Create or update your personal web site!</li>\n</ul><p>\nJoin a community with like-minded interests. Bring friends that want a personal site, or are interested in a healthy, independent web!\n</p>\n<p>\nAny questions? Ask in \n<a href=\"https://indieweb.org/discuss\">#indieweb Slack or IRC</a>\n</p>\n<p>\nMore information: \n<a class=\"u-url\" href=\"https://indieweb.org/events/2018-11-14-homebrew-website-club-sf\">IndieWeb Wiki Event Page</a>\n</p>\n<p>\nRSVP:  post an <a href=\"https://indieweb.org/rsvp\">indie RSVP</a> on your own site!\n</p>"
    },
    "post-type": "event",
    "refs": {
        "https://wiki.mozilla.org/SF": {
            "type": "card",
            "name": "Mozilla San Francisco",
            "url": "https://wiki.mozilla.org/SF",
            "photo": null
        }
    },
    "_id": "1404766",
    "_source": "1",
    "_is_read": true
}

{
    "type": "entry",
    "url": "https://davidjohnmead.com/blog/2018/11/11/am-i-secure-now/",
    "syndication": [
        "https://twitter.com/davidmead/status/1061737385216610304"
    ],
    "content": {
        "text": "I think I\u2019ve just successfully set up an SSL Certificate for my domain. Now lets see if any of my #indieweb stuff breaks.",
        "html": "I <em>think</em> I\u2019ve just successfully set up an <abbr title=\"Secure Sockets Layer\">SSL</abbr> Certificate for my domain. Now lets see if any of my #indieweb stuff breaks."
    },
    "post-type": "note",
    "_id": "1403105",
    "_source": "194",
    "_is_read": true
}

Manton Reece www.manton.org

Timetable migrated to Micro.blog

{
    "type": "entry",
    "author": {
        "name": "Manton Reece",
        "url": "https://www.manton.org/",
        "photo": "https://aperture-proxy.p3k.io/907926e361383204bd1bc913c143c23e70ae69bb/68747470733a2f2f6d6963726f2e626c6f672f6d616e746f6e2f6176617461722e6a7067"
    },
    "url": "https://www.manton.org/2018/11/12/timetable-migrated-to.html",
    "name": "Timetable migrated to Micro.blog",
    "content": {
        "html": "<p>Earlier this year I migrated 15 years of posts on manton.org to Micro.blog blog hosting. Today I finished moving over 100 episodes of <a href=\"https://timetable.manton.org/\">my podcast Timetable</a> to Micro.blog podcast hosting. I had gotten out of the routine of recording Timetable, and I think moving it to Micro.blog will simplify the setup and make me publish the podcast more often.</p>\n\n<p>Timetable had been hosted on WordPress using the Seriously Simple Podcasting plugin. There were at least a few ways I could\u2019ve moved the episodes, but ultimately I decided on the following:</p>\n\n<ol><li>Downloaded all the MP3s to my Mac.</li>\n  <li>Adjusted the WordPress settings to show 120 recent posts in the feeds, then saved the resulting JSON Feed of all episodes. This let me parse the JSON much more easily than working with the WordPress API or XML.</li>\n  <li>Wrote <a href=\"https://gist.github.com/manton/d840af1ea9048215de40985b22668cca\">a Ruby script</a> that uses the Micropub API to upload each MP3, then create a new post with an <code>audio</code> tag, preserving the original post content and date.</li>\n  <li>Pointed timetable.manton.org to use Micro.blog.</li>\n</ol><p>Even if you don\u2019t know Ruby, hopefully you can see in the script how easy is it to work with Micropub, which Micro.blog uses as its native interface to create posts and upload files. I just call out to the <code>curl</code> command-line tool to do the work.</p>\n\n<p>If you\u2019re new to Timetable, each episode is only about 5 minutes. Some of my recent favorites include <a href=\"http://timetable.manton.org/2017/12/21/episode-lose-yourself.html\">episode 91</a> (Lose yourself), <a href=\"http://timetable.manton.org/2018/01/12/episode-good-better.html\">episode 92</a> (Good, better, best), and <a href=\"http://timetable.manton.org/2018/05/04/episode-one-year.html\">episode 100</a> (One year).</p>",
        "text": "Earlier this year I migrated 15 years of posts on manton.org to Micro.blog blog hosting. Today I finished moving over 100 episodes of my podcast Timetable to Micro.blog podcast hosting. I had gotten out of the routine of recording Timetable, and I think moving it to Micro.blog will simplify the setup and make me publish the podcast more often.\n\nTimetable had been hosted on WordPress using the Seriously Simple Podcasting plugin. There were at least a few ways I could\u2019ve moved the episodes, but ultimately I decided on the following:\n\nDownloaded all the MP3s to my Mac.\n  Adjusted the WordPress settings to show 120 recent posts in the feeds, then saved the resulting JSON Feed of all episodes. This let me parse the JSON much more easily than working with the WordPress API or XML.\n  Wrote a Ruby script that uses the Micropub API to upload each MP3, then create a new post with an audio tag, preserving the original post content and date.\n  Pointed timetable.manton.org to use Micro.blog.\nEven if you don\u2019t know Ruby, hopefully you can see in the script how easy is it to work with Micropub, which Micro.blog uses as its native interface to create posts and upload files. I just call out to the curl command-line tool to do the work.\n\nIf you\u2019re new to Timetable, each episode is only about 5 minutes. Some of my recent favorites include episode 91 (Lose yourself), episode 92 (Good, better, best), and episode 100 (One year)."
    },
    "published": "2018-11-12T09:40:44-06:00",
    "post-type": "article",
    "_id": "1402463",
    "_source": "12",
    "_is_read": true
}

Jeremy Keith adactio.com

Push without notifications

{
    "type": "entry",
    "published": "2018-11-11T23:41:41Z",
    "url": "https://adactio.com/journal/14511",
    "category": [
        "push",
        "notifications",
        "serviceworkers",
        "offline",
        "caching",
        "caches",
        "background",
        "sync",
        "frontend",
        "development",
        "permissions",
        "dialogue",
        "security",
        "indiewebcamp",
        "berlin",
        "browsers",
        "standards"
    ],
    "syndication": [
        "https://medium.com/@adactio/e5dfb24f7189"
    ],
    "name": "Push without notifications",
    "content": {
        "text": "On the first day of Indie Web Camp Berlin, I led a session on going offline with service workers. This covered all the usual use-cases: pre-caching; custom offline pages; saving pages for offline reading.\n\nBut on the second day, Sebastiaan spent a fair bit of time investigating a more complex use of service workers with the Push API.\n\nThe Push API is what makes push notifications possible on the web. There are a lot of moving parts\u2014browser, server, service worker\u2014and, frankly, it\u2019s way over my head. But I\u2019m familiar with the general gist of how it works. Here\u2019s a typical flow:\n\nA website prompts the user for permission to send push notifications.\nThe user grants permission.\nA whole lot of complicated stuff happens behinds the scenes.\nNext time the website publishes something relevant, it fires a push message containing the details of the new URL.\nThe user\u2019s service worker receives the push message (even if the site isn\u2019t open).\nThe service worker creates a notification linking to the URL, interrupting the user, and generally adding to the weight of information overload.\nHere\u2019s what Sebastiaan wanted to investigate: what if that last step weren\u2019t so intrusive? Here\u2019s the alternate flow he wanted to test:\n\nA website prompts the user for permission to send push notifications.\nThe user grants permission.\nA whole lot of complicated stuff happens behinds the scenes.\nNext time the website publishes something relevant, it fires a push message containing the details of the new URL.\nThe user\u2019s service worker receives the push message (even if the site isn\u2019t open).\nThe service worker fetches the contents of the URL provided in the push message and caches the page. Silently.\nIt worked.\n\nI think this could be a real game-changer. I don\u2019t know about you, but I\u2019m very, very wary of granting websites the ability to send me push notifications. In fact, I don\u2019t think I\u2019ve ever given a website permission to interrupt me with push notifications. \n\nYou\u2019ve seen the annoying permission dialogues, right?\n\nIn Firefox, it looks like this:\n\n\n  Will you allow name-of-website to send notifications?\n  \n  [Not Now] [Allow Notifications]\n\n\nIn Chrome, it\u2019s:\n\n\n  name-of-website wants to\n  \n  Show notifications\n  \n  [Block] [Allow]\n\n\nBut in actual fact, these dialogues are asking for permission to do two things:\n\nReceive messages pushed from the server.\nDisplay notifications based on those messages.\nThere\u2019s no way to ask for permission just to do the first part. That\u2019s a shame. While I\u2019m very unwilling to grant permission to be interrupted by intrusive notifications, I\u2019d be more than willing to grant permission to allow a website to silently cache timely content in the background. It would be a more calm technology.\n\nThink of the use cases:\n\nI grant push permission to a magazine. When the magazine publishes a new article, it\u2019s cached on my device.\nI grant push permission to a podcast. Whenever a new episode is published, it\u2019s cached on my device.\nI grant push permission to a blog. When there\u2019s a new blog post, it\u2019s cached on my device.\nThen when I\u2019m on a plane, or in the subway, or in any other situation without a network connection, I could still visit these websites and get content that\u2019s fresh to me. It\u2019s kind of like background sync in reverse.\n\nThere\u2019s plenty of opportunity for abuse\u2014the cache could get filled with content. But websites can already do that, and they don\u2019t need to be granted any permissions to do so; just by visiting a website, it can add multiple files to a cache.\n\nSo it seems that the reason for the permissions dialogue is all about displaying notifications \u2026not so much about receiving push messages from the server.\n\nI wish there were a way to implement this background-caching pattern without requiring the user to grant permission to a dialogue that contains the word \u201cnotification.\u201d\n\nI wonder if the act of adding a site to the home screen could implicitly grant permission to allow use of the Push API without notifications?\n\nIn the meantime, the proposal for periodic synchronisation (using background sync) could achieve similar results, but in a less elegant way; periodically polling for new content instead of receiving a push message when new content is published. Also, it requires permission. But at least in this case, the permission dialogue should be more specific, and wouldn\u2019t include the word \u201cnotification\u201d anywhere.",
        "html": "<p>On the first day of <a href=\"https://indieweb.org/2018/Berlin\">Indie Web Camp Berlin</a>, I led a session on <a href=\"https://abookapart.com/products/going-offline\">going offline with service workers</a>. This covered all the usual use-cases: pre-caching; custom offline pages; saving pages for offline reading.</p>\n\n<p>But on the second day, <a href=\"https://seblog.nl/\">Sebastiaan</a> spent a fair bit of time investigating a more complex use of service workers with <a href=\"https://www.w3.org/TR/push-api/\">the Push API</a>.</p>\n\n<p>The Push API is what makes push notifications possible on the web. There are a <em>lot</em> of moving parts\u2014browser, server, service worker\u2014and, frankly, it\u2019s way over my head. But I\u2019m familiar with the general gist of how it works. Here\u2019s a typical flow:</p>\n\n<ol><li>A website prompts the user for permission to send push notifications.</li>\n<li>The user grants permission.</li>\n<li>A whole lot of complicated stuff happens behinds the scenes.</li>\n<li>Next time the website publishes something relevant, it fires a push message containing the details of the new URL.</li>\n<li>The user\u2019s service worker receives the push message (even if the site isn\u2019t open).</li>\n<li>The service worker creates a notification linking to the URL, interrupting the user, and generally adding to the weight of information overload.</li>\n</ol><p>Here\u2019s what Sebastiaan wanted to investigate: what if that last step weren\u2019t so intrusive? Here\u2019s the alternate flow he wanted to test:</p>\n\n<ol><li>A website prompts the user for permission to send push notifications.</li>\n<li>The user grants permission.</li>\n<li>A whole lot of complicated stuff happens behinds the scenes.</li>\n<li>Next time the website publishes something relevant, it fires a push message containing the details of the new URL.</li>\n<li>The user\u2019s service worker receives the push message (even if the site isn\u2019t open).</li>\n<li>The service worker fetches the contents of the URL provided in the push message and caches the page. Silently.</li>\n</ol><p>It worked.</p>\n\n<p>I think this could be a real game-changer. I don\u2019t know about you, but I\u2019m very, <em>very</em> wary of granting websites the ability to send me push notifications. In fact, I don\u2019t think I\u2019ve ever given a website permission to interrupt me with push notifications. </p>\n\n<p>You\u2019ve seen the annoying permission dialogues, right?</p>\n\n<p>In Firefox, it looks like this:</p>\n\n<blockquote>\n  <p>Will you allow name-of-website to send notifications?</p>\n  \n  <p>[Not Now] [Allow Notifications]</p>\n</blockquote>\n\n<p>In Chrome, it\u2019s:</p>\n\n<blockquote>\n  <p>name-of-website wants to</p>\n  \n  <p>Show notifications</p>\n  \n  <p>[Block] [Allow]</p>\n</blockquote>\n\n<p>But in actual fact, these dialogues are asking for permission to do <strong>two</strong> things:</p>\n\n<ol><li>Receive messages pushed from the server.</li>\n<li>Display notifications based on those messages.</li>\n</ol><p>There\u2019s no way to ask for permission just to do the first part. That\u2019s a shame. While I\u2019m very unwilling to grant permission to be interrupted by intrusive notifications, I\u2019d be more than willing to grant permission to allow a website to silently cache timely content in the background. It would be a more <a href=\"https://calmtech.com/\">calm technology</a>.</p>\n\n<p>Think of the use cases:</p>\n\n<ul><li>I grant push permission to <a href=\"https://www.1843magazine.com/\">a magazine</a>. When the magazine publishes a new article, it\u2019s cached on my device.</li>\n<li>I grant push permission to <a href=\"http://revisionisthistory.com/\">a podcast</a>. Whenever a new episode is published, it\u2019s cached on my device.</li>\n<li>I grant push permission to <a href=\"https://www.centauri-dreams.org/\">a blog</a>. When there\u2019s a new blog post, it\u2019s cached on my device.</li>\n</ul><p>Then when I\u2019m on a plane, or in the subway, or in any other situation without a network connection, I could still visit these websites and get content that\u2019s fresh to me. It\u2019s kind of like <a href=\"https://developers.google.com/web/updates/2015/12/background-sync\">background sync</a> in reverse.</p>\n\n<p>There\u2019s plenty of opportunity for abuse\u2014the cache could get filled with content. But websites can already do that, and they don\u2019t need to be granted any permissions to do so; <a href=\"https://adactio.com/journal/11730\">just by visiting a website</a>, it can add multiple files to a cache.</p>\n\n<p>So it seems that the reason for the permissions dialogue is all about <em>displaying notifications</em> \u2026not so much about receiving push messages from the server.</p>\n\n<p>I wish there were a way to implement this background-caching pattern without requiring the user to grant permission to a dialogue that contains the word \u201cnotification.\u201d</p>\n\n<p>I wonder if the act of <a href=\"https://adactio.com/journal/13061\">adding a site to the home screen</a> could implicitly grant permission to allow use of the Push API <em>without</em> notifications?</p>\n\n<p>In the meantime, the proposal for <a href=\"https://github.com/WICG/BackgroundSync/blob/master/explainer.md#periodic-synchronization-in-design\">periodic synchronisation</a> (using background sync) could achieve similar results, but in a less elegant way; periodically polling for new content instead of receiving a push message when new content is published. Also, it requires permission. But at least in this case, the permission dialogue should be more specific, and wouldn\u2019t include the word \u201cnotification\u201d anywhere.</p>"
    },
    "author": {
        "type": "card",
        "name": "Jeremy Keith",
        "url": "https://adactio.com/",
        "photo": "https://aperture-proxy.p3k.io/bbbacdf0a064621004f2ce9026a1202a5f3433e0/68747470733a2f2f6164616374696f2e636f6d2f696d616765732f70686f746f2d3135302e6a7067"
    },
    "post-type": "article",
    "_id": "1399637",
    "_source": "2",
    "_is_read": true
}

{
    "type": "entry",
    "url": "http://davidjohnmead.com/blog/2018/11/11/am-i-secure-now/",
    "content": {
        "text": "I think I\u2019ve just successfully set up an SSL Certificate for my domain. Now lets see if any of my #indieweb stuff breaks.",
        "html": "I <em>think</em> I\u2019ve just successfully set up an <abbr title=\"Secure Sockets Layer\">SSL</abbr> Certificate for my domain. Now lets see if any of my #indieweb stuff breaks."
    },
    "post-type": "note",
    "_id": "1398818",
    "_source": "194",
    "_is_read": true
}

Jeremy Keith adactio.com

Webmentions at Indie Web Camp Berlin

{
    "type": "entry",
    "published": "2018-11-10T12:53:17Z",
    "url": "https://adactio.com/journal/14509",
    "category": [
        "indieweb",
        "webmentions",
        "publishing",
        "privacy",
        "ethics",
        "indiewebcamp",
        "berlin",
        "h-entry",
        "microformats",
        "location",
        "mapping",
        "demos"
    ],
    "syndication": [
        "https://medium.com/@adactio/38a5680bea11"
    ],
    "name": "Webmentions at Indie Web Camp Berlin",
    "content": {
        "text": "I was in Berlin for most of last week, and every day was packed with activity:\n\n\nIndie Web Camp on Saturday and Sunday,\n\nAccessibility Club on Monday,\n\nBeyond Tellerrand on Tuesday and Wednesday.\nBy the time I got back to Brighton, my brain was full \u2026just in time for FF Conf.\n\nAll of the events were very different, but equally enjoyable. It was also quite nice to just attend events without speaking at them.\n\nIndie Web Camp Berlin was terrific. There was an excellent turnout, and once again, I found that the format was just right: a day of discussions (BarCamp style) followed by a day of doing (coding, designing, hacking). I got very inspired on the first day, so I was raring to go on the second.\n\nWhat I like to do on the second day is try to complete two tasks; one that\u2019s fairly straightforward, and one that\u2019s a bit tougher. That way, when it comes time to demo at the end of the day, even if I haven\u2019t managed to complete the tougher one, I\u2019ll still be able to demo the simpler one.\n\nIn this case, the tougher one was also tricky to demo. It involved a lot of invisible behind-the-scenes plumbing. I was tweaking my webmention endpoint (stop sniggering\u2014tweaking your endpoint is no laughing matter).\n\nUp until now, I could handle straightforward webmentions, and I could handle updates (if I receive more than one webmention from the same link, I check it each time). But I needed to also handle deletions.\n\nThe spec is quite clear on this. A 404 isn\u2019t enough to trigger a deletion\u2014that might be a temporary state. But a status of 410 Gone indicates that a resource was once here but has since been deliberately removed. In that situation, any stored webmentions for that link should also be removed.\n\nAnyway, I think I got it working, but it\u2019s tricky to test and even trickier to demo. \u201cNot to worry\u201d, I thought, \u201cI\u2019ve always got my simpler task.\u201d\n\nFor that, I chose to add a little map to my homepage showing the last location I published something from. I\u2019ve been geotagging all my content for years (journal entries, notes, links, articles), but not really doing anything with that data. This is a first step to doing something interesting with many years of location data.\n\nI\u2019ve got it working now, but the demo gods really weren\u2019t with me at Indie Web Camp. Both of my demos failed. The webmention demo failed quite embarrassingly.\n\nAs well as handling deletions, I also wanted to handle updates where a URL that once linked to a post of mine no longer does. Just to be clear, the URL still exists\u2014it\u2019s not 404 or 410\u2014but it has been updated to remove the original link back to one of my posts. I know this sounds like another very theoretical situation, but I\u2019ve actually got an example of it on my very first webmention test post from five years ago. Believe it or not, there\u2019s an escort agency in Nottingham that\u2019s using webmention as a vector for spam. They post something that does link to my test post, send a webmention, and then remove the link to my test post. I almost admire their dedication.\n\nStill, I wanted to foil this particular situation so I thought I had updated my code to handle it. Alas, when it came time to demo this, I was using someone else\u2019s computer, and in my attempt to right-click and copy the URL of the spam link \u2026I accidentally triggered it. In front of a room full of people. It was midly NSFW, but more worryingly, a potential Code Of Conduct violation. I\u2019m very sorry about that.\n\nApart from the humiliating demo, I thoroughly enjoyed Indie Web Camp, and I\u2019m going to keep adjusting my webmention endpoint. There was a terrific discussion around the ethical implications of storing webmentions, led by Sebastian, based on his epic post from earlier this year.\n\nWe established early in the discussion that we weren\u2019t going to try to solve legal questions\u2014like GDPR \u201ccompliance\u201d, which varies depending on which lawyer you talk to\u2014but rather try to figure out what the right thing to do is.\n\nEarlier that day, during the introductions, I quite happily showed webmentions in action on my site. I pointed out that my last blog post had received a response from another site, and because that response was marked up as an h-entry, I displayed it in full on my site. I thought this was all hunky-dory, but now this discussion around privacy made me question some inferences I was making:\n\nBy receiving a webention in the first place, I was inferring a willingness for the link to be made public. That\u2019s not necessarily true, as someone pointed out: a CMS could be automatically sending webmentions, which the author might be unaware of.\nIf the linking post is marked up in h-entry, I was inferring a willingness for the content to be republished. Again, not necessarily true.\nThat second inferrence of mine\u2014that publishing in a particular format somehow grants permissions\u2014actually has an interesting precedent: Google AMP. Simply by including the Google AMP script on a web page, you are implicitly giving Google permission to store a complete copy of that page and serve it from their servers instead of sending people to your site. No terms and conditions. No checkbox ticked. No \u201cI agree\u201d button pressed.\n\nJust sayin\u2019.\n\nAnyway, when it comes to my own processing of webmentions, I\u2019m going to take some of the suggestions from the discussion on board. There are certain signals I could be looking for in the linking post:\n\nDoes it include a link to a licence?\nIs there a restrictive robots.txt file?\nAre there meta declarations that say noindex?\nEach one of these could help to infer whether or not I should be publishing a webmention or not. I quickly realised that what we\u2019re talking about here is an algorithm.\n\nDespite its current usage to mean \u201cmagic\u201d, an algorithm is a recipe. It\u2019s a series of steps that contribute to a decision point. The problem is that, in the case of silos like Facebook or Instagram, the algorithms are secret (which probably contributes to their aura of magical thinking). If I\u2019m going to write an algorithm that handles other people\u2019s information, I don\u2019t want to make that mistake. Whatever steps I end up codifying in my webmention endpoint, I\u2019ll be sure to document them publicly.",
        "html": "<p>I was in Berlin for most of last week, and every day was packed with activity:</p>\n\n<ul><li>\n<a href=\"https://indieweb.org/2018/Berlin\">Indie Web Camp</a> on Saturday and Sunday,</li>\n<li>\n<a href=\"https://accessibility-club.org/\">Accessibility Club</a> on Monday,</li>\n<li>\n<a href=\"https://beyondtellerrand.com/events/berlin-2018/speakers\">Beyond Tellerrand</a> on Tuesday and Wednesday.</li>\n</ul><p>By the time I got back to Brighton, my brain was full \u2026just in time for <a href=\"https://2018.ffconf.org/\">FF Conf</a>.</p>\n\n<p>All of the events were very different, but equally enjoyable. It was also quite nice to just <em>attend</em> events without speaking at them.</p>\n\n<p><a href=\"https://indieweb.org/2018/Berlin\">Indie Web Camp Berlin</a> was terrific. There was an excellent turnout, and once again, I found that the format was just right: a day of discussions (BarCamp style) followed by a day of doing (coding, designing, hacking). I got very inspired on the first day, so I was raring to go on the second.</p>\n\n<p>What I like to do on the second day is try to complete two tasks; one that\u2019s fairly straightforward, and one that\u2019s a bit tougher. That way, when it comes time to demo at the end of the day, even if I haven\u2019t managed to complete the tougher one, I\u2019ll still be able to demo the simpler one.</p>\n\n<p>In this case, the tougher one was also tricky to demo. It involved a lot of invisible behind-the-scenes plumbing. I was tweaking my <a href=\"https://webmention.net/\">webmention</a> endpoint (stop sniggering\u2014tweaking your endpoint is no laughing matter).</p>\n\n<p>Up until now, I could handle straightforward webmentions, and I could handle updates (if I receive more than one webmention from the same link, I check it each time). But I needed to also handle deletions.</p>\n\n<p><a href=\"https://www.w3.org/TR/webmention/#sending-webmentions-for-deleted-posts\">The spec is quite clear on this</a>. A 404 isn\u2019t enough to trigger a deletion\u2014that might be a temporary state. But a status of <a href=\"https://tools.ietf.org/html/rfc7231#section-6.5.9\">410 Gone</a> indicates that a resource was once here but has since been deliberately removed. In that situation, any stored webmentions for that link should also be removed.</p>\n\n<p>Anyway, I <em>think</em> I got it working, but it\u2019s tricky to test and even trickier to demo. \u201cNot to worry\u201d, I thought, \u201cI\u2019ve always got my simpler task.\u201d</p>\n\n<p>For that, I chose to add a little map to my homepage showing the last location I published something from. I\u2019ve been geotagging all my content for years (journal entries, notes, links, articles), but not really doing anything with that data. This is a first step to doing something interesting with many years of location data.</p>\n\n<p>I\u2019ve got it working <em>now</em>, but the demo gods really weren\u2019t with me at Indie Web Camp. Both of my demos failed. The webmention demo failed quite embarrassingly.</p>\n\n<p>As well as handling deletions, I also wanted to handle updates where a URL that once linked to a post of mine no longer does. Just to be clear, the URL still exists\u2014it\u2019s not 404 or 410\u2014but it has been updated to remove the original link back to one of my posts. I know this sounds like another very theoretical situation, but I\u2019ve actually got an example of it on <a href=\"https://adactio.com/journal/6469\">my very first webmention test post</a> from five years ago. Believe it or not, there\u2019s an escort agency in Nottingham that\u2019s using webmention as a vector for spam. They post something that <em>does</em> link to my test post, send a webmention, and then remove the link to my test post. I almost admire their dedication.</p>\n\n<p>Still, I wanted to foil this particular situation so I thought I had updated my code to handle it. Alas, when it came time to demo this, I was using someone else\u2019s computer, and in my attempt to right-click and copy the URL of the spam link \u2026I accidentally triggered it. In front of a room full of people. It was midly <abbr title=\"Not Safe For Work\">NSFW</abbr>, but more worryingly, a potential <a href=\"https://indieweb.org/code-of-conduct\">Code Of Conduct</a> violation. I\u2019m very sorry about that.</p>\n\n<p>Apart from the humiliating demo, I thoroughly enjoyed Indie Web Camp, and I\u2019m going to keep adjusting my webmention endpoint. There was a terrific <a href=\"https://etherpad.indieweb.org/ethics\">discussion</a> around the ethical implications of storing webmentions, led by <a href=\"https://sebastiangreger.net/\">Sebastian</a>, based on <a href=\"https://sebastiangreger.net/2018/05/indieweb-privacy-challenge-webmentions-backfeeds-gdpr/\">his epic post from earlier this year</a>.</p>\n\n<p>We established early in the discussion that we weren\u2019t going to try to solve legal questions\u2014like GDPR \u201ccompliance\u201d, which varies depending on which lawyer you talk to\u2014but rather try to figure out what the right thing to do is.</p>\n\n<p>Earlier that day, during the introductions, I quite happily showed webmentions in action on my site. I pointed out that <a href=\"https://adactio.com/journal/14452\">my last blog post</a> had received <a href=\"https://ruk.ca/content/phil-nash-and-jeremy-keith-save-safari-video-playback-day\">a response from another site</a>, and because that response was marked up as an <a href=\"http://microformats.org/wiki/h-entry\">h-entry</a>, I <a href=\"https://adactio.com/journal/14452#comment64243\">displayed it in full on my site</a>. I thought this was all hunky-dory, but now this discussion around privacy made me question some inferences I was making:</p>\n\n<ol><li>By receiving a webention in the first place, I was inferring a willingness for the link to be made public. That\u2019s not necessarily true, as someone pointed out: a CMS could be automatically sending webmentions, which the author might be unaware of.</li>\n<li>If the linking post is marked up in h-entry, I was inferring a willingness for the content to be republished. Again, not necessarily true.</li>\n</ol><p>That second inferrence of mine\u2014that publishing in a particular format somehow grants permissions\u2014actually has an interesting precedent: <a href=\"https://www.ampproject.org/\">Google AMP</a>. Simply by including the Google AMP script on a web page, <a href=\"https://www.ampproject.org/support/faqs/overview#42_AMP_content_5\">you are implicitly giving Google permission</a> to store a complete copy of that page <strong>and</strong> serve it from their servers instead of sending people to your site. No terms and conditions. No checkbox ticked. No \u201cI agree\u201d button pressed.</p>\n\n<p>Just sayin\u2019.</p>\n\n<p>Anyway, when it comes to my own processing of webmentions, I\u2019m going to take some of the suggestions from the discussion on board. There are certain signals I could be looking for in the linking post:</p>\n\n<ul><li>Does it include a link to a licence?</li>\n<li>Is there a restrictive <code>robots.txt</code> file?</li>\n<li>Are there <code>meta</code> declarations that say <code>noindex</code>?</li>\n</ul><p>Each one of these could help to infer whether or not I should be publishing a webmention or not. I quickly realised that what we\u2019re talking about here is an algorithm.</p>\n\n<p>Despite its current usage to mean \u201cmagic\u201d, an algorithm is a recipe. It\u2019s a series of steps that contribute to a decision point. The problem is that, in the case of silos like Facebook or Instagram, the algorithms are secret (which probably contributes to their aura of magical thinking). If I\u2019m going to write an algorithm that handles other people\u2019s information, I don\u2019t want to make that mistake. Whatever steps I end up codifying in my webmention endpoint, I\u2019ll be sure to document them publicly.</p>"
    },
    "author": {
        "type": "card",
        "name": "Jeremy Keith",
        "url": "https://adactio.com/",
        "photo": "https://aperture-proxy.p3k.io/bbbacdf0a064621004f2ce9026a1202a5f3433e0/68747470733a2f2f6164616374696f2e636f6d2f696d616765732f70686f746f2d3135302e6a7067"
    },
    "post-type": "article",
    "_id": "1391009",
    "_source": "2",
    "_is_read": true
}

Dates set for IndieWebCamp Austin

{
    "type": "entry",
    "author": {
        "name": null,
        "url": "https://www.manton.org/",
        "photo": null
    },
    "url": "https://www.manton.org/2018/11/09/dates-set-for.html",
    "name": "Dates set for IndieWebCamp Austin",
    "content": {
        "html": "<p>Last year we held the first IndieWebCamp in Austin. <a href=\"https://www.manton.org/2017/12/12/indiewebcamp-austin-wrapup.html\">I blogged about</a> how the event went, including sessions and topics covered, and what I learned from it:</p>\n\n<blockquote>\n  <p>I\u2019m really happy with the way the event came together. I learned a lot in helping plan it, made a few mistakes that we can improve next time, but overall came away as inspired as ever to keep improving Micro.blog so that it\u2019s a standout platform of the IndieWeb movement.</p>\n</blockquote>\n\n<p>We\u2019re going to do it again early next year: February 23-24 at Capital Factory. If you\u2019ll be in Austin, mark that weekend on your calendar. I\u2019ll make another announcement when registration is open.</p>\n\n<p>Last year there was a lot of work and last-minute stress deciding on a venue, so this year we\u2019re going to keep a bunch of things the same that seemed to work pretty well. By nailing down the details early, we\u2019ll have much more time for promotion. I\u2019d love to see us double attendance from last year. Hope to see you there!</p>",
        "text": "Last year we held the first IndieWebCamp in Austin. I blogged about how the event went, including sessions and topics covered, and what I learned from it:\n\n\n  I\u2019m really happy with the way the event came together. I learned a lot in helping plan it, made a few mistakes that we can improve next time, but overall came away as inspired as ever to keep improving Micro.blog so that it\u2019s a standout platform of the IndieWeb movement.\n\n\nWe\u2019re going to do it again early next year: February 23-24 at Capital Factory. If you\u2019ll be in Austin, mark that weekend on your calendar. I\u2019ll make another announcement when registration is open.\n\nLast year there was a lot of work and last-minute stress deciding on a venue, so this year we\u2019re going to keep a bunch of things the same that seemed to work pretty well. By nailing down the details early, we\u2019ll have much more time for promotion. I\u2019d love to see us double attendance from last year. Hope to see you there!"
    },
    "published": "2018-11-09T10:30:24-06:00",
    "post-type": "article",
    "_id": "1385747",
    "_source": "12",
    "_is_read": true
}

Recap of An Introduction to Microformats

{
    "type": "entry",
    "published": "2018-11-08 23:13-0800",
    "url": "https://gregorlove.com/2018/11/recap-of-an-introduction-to-microformats/",
    "name": "Recap of An Introduction to Microformats",
    "content": {
        "text": "I gave a talk on microformats last night at the San Diego PHP Meetup group. This was my first time giving a formal talk on the topic. I appreciate SDPHP giving me the opportunity!\n\nResources\n\n\nAn Introduction to Microformats slides. I added microformats to them because, of course. :]\n\t\nmicroformats.io: A brief introduction to microformats and links to several parsers. Includes web versions so you can try parsing microformats by direct HTML input or by entering a URL.\n\t\nmicroformats.org wiki: the microformats specifications and the parsing algorithm. I touched on some specific pages: principles, h-card, h-event, microformats2\n\n\t\nmf2-to-iCalendar: a small PHP library that converts h-event microformats to iCalendar. This is what I use on my own calendar page.\n\t\nWebmention: a specification I mentioned that enables cross-site commenting. Many receivers of webmention will parse h-card and h-entry microformats to display responses.\n\t\nMicropub: a specification for publishing using third-party clients. It uses the microformats vocabulary.\n\t\nphp-mf2: PHP parser library for microformats2\n\t\nGranary: a library and web service to convert between multiple formats, including microformats2\n\t\nXRay: a library and web service to parse structured content, including microformats2\nSome people were really interested in webmention and we ended up talking about it more after the event. I recommended Aaron's tutorial: Sending your First Webmention from Scratch. Schema.org also came up in that conversation and I mentioned Aaron's other post that documents the history of Google's recommended formats. They've changed a lot over the years, but they still parse microformats1 hReview.\n\nNotes\n\nThese are mostly notes to myself, or other potential presenters.\n\nI forgot to demo one of my favorite uses for microformats. I use the Granary web service to parse the h-feed on my notes page and generate an Atom feed: https://gregorlove.com/notes.atom\n\nI think it would help to discuss use-cases earlier in the talk. Through the questions and some discussion after the talk, I realized that wasn't fully clicking for people earlier in the talk.\n\nThe live demo of the parser went okay, though I should have planned out some more examples for the direct HTML input instead of trying to come up with it off the top of my head. It would also be good to have some examples that emphasize the flexibility of microformats placement. We discussed that point, but a visual example would be better.\n\nBe prepared to discuss schema.org, alternatives, pros and cons. I think I did okay with this. I chose to focus on the interesting consuming use-cases for microformats.",
        "html": "<p>I gave a talk on microformats last night at the <a href=\"http://sdphp.org\">San Diego PHP Meetup group</a>. This was my first time giving a formal talk on the topic. I appreciate SDPHP giving me the opportunity!</p>\n\n<h2>Resources</h2>\n\n<ul><li>\n<i><a href=\"https://gregorlove.com/presentations/an-introduction-to-microformats/\">An Introduction to Microformats</a></i> slides. I added microformats to them because, of course. :]</li>\n\t<li>\n<a href=\"https://microformats.io\">microformats.io</a>: A brief introduction to microformats and links to several parsers. Includes web versions so you can try parsing microformats by direct HTML input or by entering a URL.</li>\n\t<li>\n<a href=\"http://microformats.org/wiki/\">microformats.org wiki</a>: the microformats specifications and the parsing algorithm. I touched on some specific pages: <a href=\"http://microformats.org/wiki/principles\">principles</a>, <a href=\"http://microformats.org/wiki/h-card\">h-card</a>, <a href=\"http://microformats.org/wiki/h-event\">h-event</a>, <a href=\"http://microformats.org/wiki/microformats2\">microformats2</a>\n</li>\n\t<li>\n<a href=\"https://github.com/gRegorLove/mf2-to-iCalendar\">mf2-to-iCalendar</a>: a small PHP library that converts h-event microformats to iCalendar. This is what I use on my own <a href=\"https://gregorlove.com/calendar/\">calendar</a> page.</li>\n\t<li>\n<a href=\"https://webmention.net\">Webmention</a>: a specification I mentioned that enables cross-site commenting. Many receivers of webmention will parse h-card and h-entry microformats to display responses.</li>\n\t<li>\n<a href=\"https://micropub.net\">Micropub</a>: a specification for publishing using third-party clients. It uses the microformats vocabulary.</li>\n\t<li>\n<a href=\"https://github.com/microformats/php-mf2\">php-mf2</a>: PHP parser library for microformats2</li>\n\t<li>\n<a href=\"https://granary.io\">Granary</a>: a library and web service to convert between multiple formats, including microformats2</li>\n\t<li>\n<a href=\"https://xray.p3k.app\">XRay</a>: a library and web service to parse structured content, including microformats2</li>\n</ul><p>Some people were really interested in webmention and we ended up talking about it more after the event. I recommended Aaron's tutorial: <i><a href=\"https://aaronparecki.com/2018/06/30/11/your-first-webmention\">Sending your First Webmention from Scratch</a></i>. <a href=\"https://schema.org\">Schema.org</a> also came up in that conversation and I mentioned Aaron's <a href=\"https://aaronparecki.com/2016/12/17/8/owning-my-reviews\">other post</a> that documents the history of Google's recommended formats. They've changed a lot over the years, but they still parse microformats1 <a href=\"http://microformats.org/wiki/hreview\">hReview</a>.</p>\n\n<h2>Notes</h2>\n\n<p>These are mostly notes to myself, or other potential presenters.</p>\n\n<p>I forgot to demo one of my favorite uses for microformats. I use the Granary web service to parse the h-feed on my <a href=\"https://gregorlove.com/notes/\">notes</a> page and generate an Atom feed: <a href=\"https://gregorlove.com/notes.atom\">https://gregorlove.com/notes.atom</a></p>\n\n<p>I think it would help to discuss use-cases earlier in the talk. Through the questions and some discussion after the talk, I realized that wasn't fully clicking for people earlier in the talk.</p>\n\n<p>The live demo of the parser went okay, though I should have planned out some more examples for the direct HTML input instead of trying to come up with it off the top of my head. It would also be good to have some examples that emphasize the flexibility of microformats placement. We discussed that point, but a visual example would be better.</p>\n\n<p>Be prepared to discuss schema.org, alternatives, pros and cons. I think I did okay with this. I chose to focus on the interesting consuming use-cases for microformats.</p>"
    },
    "post-type": "article",
    "_id": "1382681",
    "_source": "179",
    "_is_read": true
}

Aaron Parecki aaronparecki.com

{
    "type": "entry",
    "published": "2018-11-08T14:38:50-08:00",
    "url": "https://aaronparecki.com/2018/11/08/11/",
    "category": [
        "https://indiewebcat.com/"
    ],
    "photo": [
        "https://aperture-media.p3k.io/aaronparecki.com/ecef22a0a4f7891c4445813f307d0937d31b4661bfbc30c4496887d6e0309bdd.jpg"
    ],
    "video": [
        "https://aperture-media.p3k.io/aaronparecki.com/da5aa6fcbe8c973178f77fc187827c8c6d6d4305361759eafdf018d20207c4c3.mp4"
    ],
    "syndication": [
        "https://www.instagram.com/p/Bp77Zo-gm6h/"
    ],
    "content": {
        "text": "Look at @indiewebcat mostly enjoying the ride to the vet \ud83d\ude3b\ud83d\udc89",
        "html": "Look at <a href=\"https://twitter.com/indiewebcat\">@indiewebcat</a> mostly enjoying the ride to the vet <a href=\"https://aaronparecki.com/emoji/%F0%9F%98%BB\">\ud83d\ude3b</a><a href=\"https://aaronparecki.com/emoji/%F0%9F%92%89\">\ud83d\udc89</a>"
    },
    "author": {
        "type": "card",
        "name": "Aaron Parecki",
        "url": "https://aaronparecki.com/",
        "photo": "https://aperture-media.p3k.io/aaronparecki.com/2b8e1668dcd9cfa6a170b3724df740695f73a15c2a825962fd0a0967ec11ecdc.jpg"
    },
    "post-type": "video",
    "_id": "1380320",
    "_source": "16",
    "_is_read": true
}

Grant Richmond grant.codes

{
    "type": "entry",
    "published": "2018-06-26T00:10:02.185Z",
    "url": "https://grant.codes/2018/06/26/5b31845ac1f2f0162199a45d-1",
    "photo": [
        "https://aperture-proxy.p3k.io/fa46e496d59866a2dc5253737ebe411d94008c86/68747470733a2f2f6772616e742e636f6465732f"
    ],
    "syndication": [
        "https://twitter.com/grantcodes/status/1011401165551087616",
        "https://www.instagram.com/p/Bkd53a7l0Lf/",
        "https://www.facebook.com/2307321132619023"
    ],
    "content": {
        "text": "#IndieWebSummit party time",
        "html": "<p>#IndieWebSummit party time</p>"
    },
    "author": {
        "type": "card",
        "name": "Grant Richmond",
        "url": "https://grant.codes",
        "photo": "https://aperture-proxy.p3k.io/be31049af9884a65289b2d14300adafc0e4030c6/68747470733a2f2f6772616e742e636f6465732f696d672f6d652e6a7067"
    },
    "post-type": "photo",
    "_id": "1380142",
    "_source": "11",
    "_is_read": true
}

Usernames on Micro.blog

{
    "type": "entry",
    "author": {
        "name": null,
        "url": "https://www.manton.org/",
        "photo": null
    },
    "url": "https://www.manton.org/2018/11/08/usernames-on-microblog.html",
    "name": "Usernames on Micro.blog",
    "content": {
        "html": "<p><a href=\"https://micro.blog/\">Micro.blog</a> now has 3 distinct styles of usernames to make the platform more compatible with other services:</p>\n\n<ul><li>Micro.blog usernames, e.g. <strong>@you</strong>. These are simple usernames for @-mentioning someone else in the Micro.blog community.</li>\n  <li>Mastodon usernames, e.g. <strong>@you@yourdomain.com</strong>. When you search Micro.blog for these usernames, Micro.blog will look for the user in another federated Mastodon instance so that you can follow them.</li>\n  <li>IndieWeb-friendly domain names, e.g. <strong>@yourdomain.com</strong>. This is where I always thought we\u2019d go for more distributed \u201cthe web is the social network\u201d interactions. Replying to one of these usernames will send a Webmention to that user\u2019s external web site.</li>\n</ul><p>I\u2019m <a href=\"https://micro.blog/manton\">@manton</a> on Micro.blog, my blog is <a href=\"https://manton.org/\">manton.org</a>, and because <a href=\"https://manton.org/2018/11/07/microblog-mastodon.html\">Micro.blog-hosted blogs support the ActivityPub API</a>, you can follow me from Mastodon by using @manton@manton.org.</p>\n\n<p>I just rolled out some ActivityPub-related reply improvements. I\u2019ll continue to improve the Micro.blog timeline so that these usernames can all coexist nicely. We\u2019ll also be updating the native apps to better support these usernames, for highlighting and auto-completion.</p>",
        "text": "Micro.blog now has 3 distinct styles of usernames to make the platform more compatible with other services:\n\nMicro.blog usernames, e.g. @you. These are simple usernames for @-mentioning someone else in the Micro.blog community.\n  Mastodon usernames, e.g. @you@yourdomain.com. When you search Micro.blog for these usernames, Micro.blog will look for the user in another federated Mastodon instance so that you can follow them.\n  IndieWeb-friendly domain names, e.g. @yourdomain.com. This is where I always thought we\u2019d go for more distributed \u201cthe web is the social network\u201d interactions. Replying to one of these usernames will send a Webmention to that user\u2019s external web site.\nI\u2019m @manton on Micro.blog, my blog is manton.org, and because Micro.blog-hosted blogs support the ActivityPub API, you can follow me from Mastodon by using @manton@manton.org.\n\nI just rolled out some ActivityPub-related reply improvements. I\u2019ll continue to improve the Micro.blog timeline so that these usernames can all coexist nicely. We\u2019ll also be updating the native apps to better support these usernames, for highlighting and auto-completion."
    },
    "published": "2018-11-08T15:32:39-06:00",
    "post-type": "article",
    "_id": "1379552",
    "_source": "12",
    "_is_read": true
}

{
    "type": "entry",
    "published": "2018-11-08T08:26:07Z",
    "url": "https://adactio.com/links/14498",
    "category": [
        "writing",
        "sharing",
        "publishing",
        "indieweb",
        "communication",
        "connection",
        "text"
    ],
    "bookmark-of": [
        "https://robinrendle.com/notes/what-do-you-want-to-do-when-you-grow-up-kid/"
    ],
    "content": {
        "text": "What do you want to do when you grow up, kid? \u2022 Robin Rendle\n\n\n\nPublishing on the web really is quite marvellous:\n\n\n  \u2026an endless thrill, a sort of everlasting, punk-rock feeling and I hope it will never really go away.",
        "html": "<h3>\n<a class=\"p-name u-bookmark-of\" href=\"https://robinrendle.com/notes/what-do-you-want-to-do-when-you-grow-up-kid/\">\nWhat do you want to do when you grow up, kid? \u2022 Robin Rendle\n</a>\n</h3>\n\n<p>Publishing on the web really is quite marvellous:</p>\n\n<blockquote>\n  <p>\u2026an endless thrill, a sort of everlasting, punk-rock feeling and I hope it will never really go away.</p>\n</blockquote>"
    },
    "post-type": "bookmark",
    "_id": "1373429",
    "_source": "2",
    "_is_read": true
}

Micro.blog + Mastodon

{
    "type": "entry",
    "author": {
        "name": null,
        "url": "https://www.manton.org/",
        "photo": null
    },
    "url": "https://www.manton.org/2018/11/07/microblog-mastodon.html",
    "name": "Micro.blog + Mastodon",
    "content": {
        "html": "<p>For some time, we have been considering how we could open up compatibility between <a href=\"https://micro.blog/\">Micro.blog</a> and <a href=\"https://joinmastodon.org/\">Mastodon</a>. Any feature that could be disruptive needs to be approached carefully. In this post I want to talk about how Micro.blog supports Mastodon, why I think it\u2019s useful, and anticipate some questions that we\u2019ll get about this feature.</p>\n\n<p>We\u2019re launching 2 major features today:</p>\n\n<ul><li>Micro.blog can now cross-post to a Mastodon user account, in the same way we cross-post to Twitter, Facebook, Medium, and LinkedIn. This takes a copy of your blog posts and sends them to a specified Mastodon account.</li>\n  <li>Your custom domain on Micro.blog can now be ActivityPub-compatible, so that you can follow and reply to Mastodon users directly on Micro.blog. This also means someone can follow your blog posts by adding @you@yourdomain.com on Mastodon. (This username is configurable. Mine is @manton@manton.org.)</li>\n</ul><p>These 2 features are separate and either can be enabled if you want. I have tried to be very deliberate in how ActivityPub is implemented. It is off by default, and to keep the focus on blogging and content ownership, it only works with custom domain names.</p>\n\n<p>One of the most important goals for Micro.blog is to encourage more people to blog. I wrote last year that <a href=\"https://www.manton.org/2017/01/14/key-for-microblog.html\">it\u2019s a success if more people blog</a>. Based on the feedback we\u2019ve received from the Micro.blog community, we are making great progress toward that goal.</p>\n\n<p>We have a lot of things we want to help solve with Micro.blog, but blogging is a core part of the foundation. It\u2019s not about being the most popular social network. It\u2019s not about competing with every platform that launches. It\u2019s much better for the mission of Micro.blog for us to embrace other platforms (as we\u2019ve always done with the <a href=\"https://indieweb.org/\">IndieWeb</a>) rather than put up walls between APIs.</p>\n\n<p><a href=\"https://manton.org/2018/09/07/the-way-out.html\">I recently published a post with 4 parts</a> to how we get out of the current mess with today\u2019s big social networks. I mentioned Mastodon in that post because while I don\u2019t think Mastodon tackles all 4 parts of fixing this, I do think it has a role to play.</p>\n\n<p>More compatibility with Mastodon lets us support the good things that Mastodon has accomplished, while still carrying forward what I think are the unique strengths of Micro.blog. It also opens up the Micro.blog community to interact with a much larger user base.</p>\n\n<p>Sometimes in the Mastodon world your identity can get fragmented across multiple instances. You might start on mastodon.social but then move to another instance, effectively breaking the link between your readers and your posts each time you move, with no way to migrate posts between instances. By supporting Mastodon and ActivityPub in Micro.blog, you can consolidate your identity and posts back to your own blog at your own domain name.</p>\n\n<p><a href=\"https://manton.org/2018/03/23/indieweb-generation-and.html\">As I wrote earlier this year</a>, content ownership on the web is about domain names:</p>\n\n<blockquote>\n  <p>When you write and post photos at your own domain name, your content can outlive any one blogging platform. This month marked the 16th anniversary of blogging at manton.org, and in that time I\u2019ve switched blogging platforms and hosting providers a few times. The posts and URLs can all be preserved through those changes because it\u2019s my own domain name.</p>\n</blockquote>\n\n<p>If you already have your blog on Micro.blog at yourdomain.com, we can build on that to allow @you@yourdomain.com or @whatever@micro.domain.com. This focus on domain names will continue to guide new features in Micro.blog.</p>\n\n<p>Let me answer some questions:</p>\n\n<ul><li><strong>How is Mastodon support enabled on my account?</strong> In Micro.blog on the web, click Account \u2192 ActivityPub. You will be prompted to select a username. A paid hosted microblog is required so that Micro.blog can use your custom domain name.</li>\n  <li><strong>How can I find Mastodon users to follow on Micro.blog?</strong> As more Micro.blog users interact with Mastodon users, some of those users will naturally show up in conversations or even be featured in our Discover timeline. You can also add a specific Mastodon user by searching for their full username.</li>\n  <li><strong>Will Micro.blog now start showing follower counts?</strong> No, it\u2019s important to me that we don\u2019t change the Micro.blog user experience to resemble every other social network. When you follow a Micro.blog user from Mastodon, an individual Mastodon instance will have its own follower count just for that instance. Any follower count shown in Mastodon for a Micro.blog user will be wrong. This isn\u2019t ideal, but it\u2019s the best we can currently do with how Mastodon works.</li>\n  <li><strong>What about Content Warnings?</strong> Micro.blog does not support them. I\u2019ve heard from Mastodon fans who like Content Warnings, but I\u2019m concerned about introducing extra friction in both the posting and reading experience. We\u2019ll reevaluate this feature later.</li>\n  <li><strong>What happens to direct messages sent from Mastodon to Micro.blog?</strong> Micro.blog does not have any private posts by design. Direct messages sent from Mastodon are converted into a private email.</li>\n  <li><strong>Is this going to make Micro.blog just like Mastodon?</strong> No, this is not a clone of Mastodon merged into Micro.blog or running alongside it. It\u2019s a from-scratch implementation of a few common APIs that Mastodon uses so that both systems can talk to each other.</li>\n  <li><strong>Will third-party Mastodon clients work with Micro.blog?</strong> Not currently. We might consider this later, but because of the UI differences, I think it\u2019s a better fit to have third-party apps designed for either Micro.blog or IndieWeb standards.</li>\n  <li><strong>What will happen to the Micro.blog community?</strong> I hope that this will help grow the community, without taking away from what has worked well on Micro.blog. While you might see some Mastodon posts, and those Mastodon users can interact with Micro.blog users, users from other Mastodon instances won\u2019t know about our community guidelines or expectations for Micro.blog. The community will remain predominantly Micro.blog users who share our goals for the platform.</li>\n  <li><strong>How does Micro.blog\u2019s mute feature work with Mastodon?</strong> Muting in Micro.blog has been expanded to support muting individual Mastodon users, or entire Mastodon instances based on their domain name. We have also preloaded a common <a href=\"https://github.com/tootcafe/blocked-instances\">list of Mastodon instances that are muted automatically</a> because of code of conduct violations.</li>\n</ul><p>This is a really big feature. I hope you enjoy it! This is just the baseline. I\u2019ll be working on bug fixes and improvements to make this integration work as smoothly as possible. If you have any feedback, let me know at <a href=\"mailto:help@micro.blog\">help@micro.blog</a>.</p>",
        "text": "For some time, we have been considering how we could open up compatibility between Micro.blog and Mastodon. Any feature that could be disruptive needs to be approached carefully. In this post I want to talk about how Micro.blog supports Mastodon, why I think it\u2019s useful, and anticipate some questions that we\u2019ll get about this feature.\n\nWe\u2019re launching 2 major features today:\n\nMicro.blog can now cross-post to a Mastodon user account, in the same way we cross-post to Twitter, Facebook, Medium, and LinkedIn. This takes a copy of your blog posts and sends them to a specified Mastodon account.\n  Your custom domain on Micro.blog can now be ActivityPub-compatible, so that you can follow and reply to Mastodon users directly on Micro.blog. This also means someone can follow your blog posts by adding @you@yourdomain.com on Mastodon. (This username is configurable. Mine is @manton@manton.org.)\nThese 2 features are separate and either can be enabled if you want. I have tried to be very deliberate in how ActivityPub is implemented. It is off by default, and to keep the focus on blogging and content ownership, it only works with custom domain names.\n\nOne of the most important goals for Micro.blog is to encourage more people to blog. I wrote last year that it\u2019s a success if more people blog. Based on the feedback we\u2019ve received from the Micro.blog community, we are making great progress toward that goal.\n\nWe have a lot of things we want to help solve with Micro.blog, but blogging is a core part of the foundation. It\u2019s not about being the most popular social network. It\u2019s not about competing with every platform that launches. It\u2019s much better for the mission of Micro.blog for us to embrace other platforms (as we\u2019ve always done with the IndieWeb) rather than put up walls between APIs.\n\nI recently published a post with 4 parts to how we get out of the current mess with today\u2019s big social networks. I mentioned Mastodon in that post because while I don\u2019t think Mastodon tackles all 4 parts of fixing this, I do think it has a role to play.\n\nMore compatibility with Mastodon lets us support the good things that Mastodon has accomplished, while still carrying forward what I think are the unique strengths of Micro.blog. It also opens up the Micro.blog community to interact with a much larger user base.\n\nSometimes in the Mastodon world your identity can get fragmented across multiple instances. You might start on mastodon.social but then move to another instance, effectively breaking the link between your readers and your posts each time you move, with no way to migrate posts between instances. By supporting Mastodon and ActivityPub in Micro.blog, you can consolidate your identity and posts back to your own blog at your own domain name.\n\nAs I wrote earlier this year, content ownership on the web is about domain names:\n\n\n  When you write and post photos at your own domain name, your content can outlive any one blogging platform. This month marked the 16th anniversary of blogging at manton.org, and in that time I\u2019ve switched blogging platforms and hosting providers a few times. The posts and URLs can all be preserved through those changes because it\u2019s my own domain name.\n\n\nIf you already have your blog on Micro.blog at yourdomain.com, we can build on that to allow @you@yourdomain.com or @whatever@micro.domain.com. This focus on domain names will continue to guide new features in Micro.blog.\n\nLet me answer some questions:\n\nHow is Mastodon support enabled on my account? In Micro.blog on the web, click Account \u2192 ActivityPub. You will be prompted to select a username. A paid hosted microblog is required so that Micro.blog can use your custom domain name.\n  How can I find Mastodon users to follow on Micro.blog? As more Micro.blog users interact with Mastodon users, some of those users will naturally show up in conversations or even be featured in our Discover timeline. You can also add a specific Mastodon user by searching for their full username.\n  Will Micro.blog now start showing follower counts? No, it\u2019s important to me that we don\u2019t change the Micro.blog user experience to resemble every other social network. When you follow a Micro.blog user from Mastodon, an individual Mastodon instance will have its own follower count just for that instance. Any follower count shown in Mastodon for a Micro.blog user will be wrong. This isn\u2019t ideal, but it\u2019s the best we can currently do with how Mastodon works.\n  What about Content Warnings? Micro.blog does not support them. I\u2019ve heard from Mastodon fans who like Content Warnings, but I\u2019m concerned about introducing extra friction in both the posting and reading experience. We\u2019ll reevaluate this feature later.\n  What happens to direct messages sent from Mastodon to Micro.blog? Micro.blog does not have any private posts by design. Direct messages sent from Mastodon are converted into a private email.\n  Is this going to make Micro.blog just like Mastodon? No, this is not a clone of Mastodon merged into Micro.blog or running alongside it. It\u2019s a from-scratch implementation of a few common APIs that Mastodon uses so that both systems can talk to each other.\n  Will third-party Mastodon clients work with Micro.blog? Not currently. We might consider this later, but because of the UI differences, I think it\u2019s a better fit to have third-party apps designed for either Micro.blog or IndieWeb standards.\n  What will happen to the Micro.blog community? I hope that this will help grow the community, without taking away from what has worked well on Micro.blog. While you might see some Mastodon posts, and those Mastodon users can interact with Micro.blog users, users from other Mastodon instances won\u2019t know about our community guidelines or expectations for Micro.blog. The community will remain predominantly Micro.blog users who share our goals for the platform.\n  How does Micro.blog\u2019s mute feature work with Mastodon? Muting in Micro.blog has been expanded to support muting individual Mastodon users, or entire Mastodon instances based on their domain name. We have also preloaded a common list of Mastodon instances that are muted automatically because of code of conduct violations.\nThis is a really big feature. I hope you enjoy it! This is just the baseline. I\u2019ll be working on bug fixes and improvements to make this integration work as smoothly as possible. If you have any feedback, let me know at help@micro.blog."
    },
    "published": "2018-11-07T14:24:01-06:00",
    "post-type": "article",
    "_id": "1369047",
    "_source": "12",
    "_is_read": true
}

IndieWebRing

{
    "type": "entry",
    "author": {
        "name": "<span class='p-author h-card'>Kh\u00fcrt Williams</span>",
        "url": "https://islandinthenet.com/",
        "photo": null
    },
    "url": "https://islandinthenet.com/indiewebring/",
    "published": "2018-11-07T14:50:32+00:00",
    "content": {
        "html": "<p>Added IndieWebring code to the title header for blog posts.</p>",
        "text": "Added IndieWebring code to the title header for blog posts."
    },
    "name": "IndieWebRing",
    "post-type": "article",
    "_id": "1365437",
    "_source": "242",
    "_is_read": true
}

Exploring queries for private feeds

{
    "type": "entry",
    "published": "2018-11-06T23:18:52+0000",
    "url": "https://seblog.nl/2018/11/06/3/exploring-queries-for-private-feeds",
    "category": [
        "indieweb",
        "private posts"
    ],
    "syndication": [
        "https://news.indieweb.org/en/seblog.nl/2018/11/06/3/exploring-queries-for-private-feeds"
    ],
    "name": "Exploring queries for private feeds",
    "content": {
        "text": "One of the discussions this weekend in Berlin was on the topic of private feeds. Martijn and Sven made great progress by implemeting a flow to fetch private pages using various endpoints for tokens and authentication.\nApart from the question how to fetch private feeds, there is also the question how to present private feeds. The easiest way is probably to give every user their own feed, containing only the private posts for them. They can separately follow your public feed, and your queries are easier.\nBut in line with Silo\u2019s like Twitter and Facebook, I think I would prefer presenting one feed, with both public and private posts, scoped for the authenticated user. When I described this to Aaron he said that he liked it, but that he didn\u2019t know where to begin with writing code that does that. I didn\u2019t either, but it made me want to explore the possibilities.\nOn a sidenote: this feed design also raises another problem, of how to signal to the user that they can see this post but no-one else. I leave that one for another time.\nDrawing rough lines around boxes\nBorrowing from Facebook, there are roughly four categories you can share content in:\n\npublic \u2013\u00a0These posts can be seen by anyone. This is the default on nearly all IndieWeb sites today.\n\nauthenticated \u2013 These posts can only been seen if you sign in, but, anyone can sign in. Facebook has this category and we can mimic that with IndieAuth, but it might not add that much value.\n\nfriends only \u2013 This is a big category on Facebook, and made possible by the friendslist, which is also a big feature on Facebook.\n\nselected audience \u2013\u00a0Facebook also allows you to pick your audience on a per-post basis. This can be done by either selecting individual users, or selecting lists, which can contain users.\nThere is also the possibility of excluding specific people or lists from posts, but that one is even more advanced, so I put it out of scope for this exploration.\nThe first category is easy, for we already have it. The second category is harder, but once you got past the authentication it\u2019s easy again. One could query a database for visibility = 'authenticated' OR visibility = 'public', that would work.\nThe third category would require us to keep a list of friends. The fourth category could also require us to keep lists of people, so it might be better to merge them.\nThrow in some tables\nThis brings us to a simple database schema. I see three main tables: entries, people and groups, with a pivot table between all of them: entry_group, entry_person and group_person. I have chosen \u2018people\u2019 over \u2018users\u2019, because I might not want to give these people write access to anything, but they could be users as well.\nIt should work like this:\nEntries have a field for visibility, which can me marked public, authenticated or private.\nPeople can belong to groups, which have names. Think \u2018Friends\u2019, \u2018Family\u2019 and \u2018Coworkers\u2019.\nEntries can be opened up to individual people, or for a whole group.\nThere might be better ways of naming these, but I like the simplicity of this model. With private posts and audiences, I will always have to manage some form of lists, and this is the most simple way of doing it.\nEnter the monster query\nSo, with some trial and error, PHPUnit tests, and a lot of Laravel magic I came to the following monster query for these tables:\n(\n  select `entries`.* \n  from `groups` \n  inner join `group_person` \n    on `groups`.`id` = `group_person`.`group_id` \n  inner join `entry_group` \n    on `groups`.`id` = `entry_group`.`group_id` \n  inner join `entries` \n    on `entries`.`id` = `entry_group`.`entry_id` \n  where `group_person`.`person_id` = ?\n) \nunion \n(\n  select `entries`.* \n  from `entries` \n  inner join `entry_person` \n    on `entries`.`id` = `entry_person`.`entry_id` \n  where `entry_person`.`person_id` = ?\n) \nunion \n(\n  select * \n  from `entries` \n  where `visibility` = 'public'\n) \norder by `published_at` desc\n... which is way shorter when expressed in with Laravel\u2019s Eloquent:\nclass Person extends Model\n{\n    public function timeline()\n    {\n        return $this->groups()\n            ->join('entry_group', 'groups.id', '=', 'entry_group.group_id')\n            ->join('entries', 'entries.id', '=', 'entry_group.entry_id')\n            ->select('entries.*')\n            ->union($this->entries()->select('entries.*'))\n            ->union(Entry::whereVisibility('public'))\n            ->orderBy('published_at', 'desc');\n    }\n\n    public function groups()\n    {\n        return $this->belongsToMany(Group::class);\n    }\n\n    public function entries()\n    {\n        return $this->belongsToMany(Entry::class);\n    }\n}\nSince the method timeline() returns the Query object, other where-clauses can be appended when needed.\nI am in a bit of a fight with Laravel still, for it adds\n\n'`group_person`.`person_id` as `pivot_person_id`, `group_person`.`group_id` as `pivot_group_id`' to the first query, which makes it blow up, but the raw query works!\nThere is possibly a better way of doing it, but this is a start! Feel free to steal or improve, but if you improve, let me know.",
        "html": "<p>One of the discussions this weekend in <a href=\"https://indieweb.org/2018/Berlin\">Berlin</a> was on the topic of private feeds. <a href=\"https://vanderven.se/martijn/\">Martijn</a> and <a href=\"https://svenknebel.de\">Sven</a> made great progress by implemeting a flow to fetch private pages using <a href=\"https://indieweb.org/2018/Nuremberg/autoauth\">various endpoints for tokens and authentication</a>.</p>\n<p>Apart from the question how to fetch private feeds, there is also the question how to present private feeds. The easiest way is probably to give every user their own feed, containing only the private posts for them. They can separately follow your public feed, and your queries are easier.</p>\n<p>But in line with Silo\u2019s like Twitter and Facebook, I think I would prefer presenting one feed, with both public and private posts, scoped for the authenticated user. When I described this to <a href=\"https://aaronparecki.com\">Aaron</a> he said that he liked it, but that he didn\u2019t know where to begin with writing code that does that. I didn\u2019t either, but it made me want to explore the possibilities.</p>\n<p>On a sidenote: this feed design also raises another problem, of how to signal to the user that they can see this post but no-one else. I leave that one for another time.</p>\n<h2>Drawing rough lines around boxes</h2>\n<p>Borrowing from Facebook, there are roughly four categories you can share content in:</p>\n<ol><li>\n<em>public</em> \u2013\u00a0These posts can be seen by anyone. This is the default on nearly all IndieWeb sites today.</li>\n<li>\n<em>authenticated</em> \u2013 These posts can only been seen if you sign in, but, anyone can sign in. Facebook has this category and we can mimic that with IndieAuth, but it might not add that much value.</li>\n<li>\n<em>friends only</em> \u2013 This is a big category on Facebook, and made possible by the friendslist, which is also a big feature on Facebook.</li>\n<li>\n<em>selected audience</em> \u2013\u00a0Facebook also allows you to pick your audience on a per-post basis. This can be done by either selecting individual users, or selecting lists, which can contain users.</li>\n</ol><p>There is also the possibility of excluding specific people or lists from posts, but that one is even more advanced, so I put it out of scope for this exploration.</p>\n<p>The first category is easy, for we already have it. The second category is harder, but once you got past the authentication it\u2019s easy again. One could query a database for <code>visibility = 'authenticated' OR visibility = 'public'</code>, that would work.</p>\n<p>The third category would require us to keep a list of friends. The fourth category could also require us to keep lists of people, so it might be better to merge them.</p>\n<h2>Throw in some tables</h2>\n<p>This brings us to a simple database schema. I see three main tables: <code>entries</code>, <code>people</code> and <code>groups</code>, with a pivot table between all of them: <code>entry_group</code>, <code>entry_person</code> and <code>group_person</code>. I have chosen \u2018people\u2019 over \u2018users\u2019, because I might not want to give these people write access to anything, but they could be users as well.</p>\n<p>It should work like this:</p>\n<ul><li>Entries have a field for <code>visibility</code>, which can me marked <code>public</code>, <code>authenticated</code> or <code>private</code>.</li>\n<li>People can belong to groups, which have names. Think \u2018Friends\u2019, \u2018Family\u2019 and \u2018Coworkers\u2019.</li>\n<li>Entries can be opened up to individual people, or for a whole group.</li>\n</ul><p>There might be better ways of naming these, but I like the simplicity of this model. With private posts and audiences, I will always have to manage some form of lists, and this is the most simple way of doing it.</p>\n<h2>Enter the monster query</h2>\n<p>So, with some trial and error, PHPUnit tests, and a lot of Laravel magic I came to the following monster query for these tables:</p>\n<pre><code>(\n  select `entries`.* \n  from `groups` \n  inner join `group_person` \n    on `groups`.`id` = `group_person`.`group_id` \n  inner join `entry_group` \n    on `groups`.`id` = `entry_group`.`group_id` \n  inner join `entries` \n    on `entries`.`id` = `entry_group`.`entry_id` \n  where `group_person`.`person_id` = ?\n) \nunion \n(\n  select `entries`.* \n  from `entries` \n  inner join `entry_person` \n    on `entries`.`id` = `entry_person`.`entry_id` \n  where `entry_person`.`person_id` = ?\n) \nunion \n(\n  select * \n  from `entries` \n  where `visibility` = 'public'\n) \norder by `published_at` desc</code></pre>\n<p>... which is way shorter when expressed in with Laravel\u2019s Eloquent:</p>\n<pre><code>class Person extends Model\n{\n    public function timeline()\n    {\n        return $this-&gt;groups()\n            -&gt;join('entry_group', 'groups.id', '=', 'entry_group.group_id')\n            -&gt;join('entries', 'entries.id', '=', 'entry_group.entry_id')\n            -&gt;select('entries.*')\n            -&gt;union($this-&gt;entries()-&gt;select('entries.*'))\n            -&gt;union(Entry::whereVisibility('public'))\n            -&gt;orderBy('published_at', 'desc');\n    }\n\n    public function groups()\n    {\n        return $this-&gt;belongsToMany(Group::class);\n    }\n\n    public function entries()\n    {\n        return $this-&gt;belongsToMany(Entry::class);\n    }\n}</code></pre>\n<p>Since the method <code>timeline()</code> returns the Query object, other where-clauses can be appended when needed.</p>\n<p>I am in a bit of a fight with Laravel still, for it adds<br />\n'`group_person`.`person_id` as `pivot_person_id`, `group_person`.`group_id` as `pivot_group_id`' to the first query, which makes it blow up, but the raw query works!</p>\n<p>There is possibly a better way of doing it, but this is a start! Feel free to steal or improve, but if you improve, let me know.</p>"
    },
    "post-type": "article",
    "_id": "1367147",
    "_source": "1366",
    "_is_read": true
}

Tantek Çelik tantek.com

{
    "type": "entry",
    "published": "2018-11-06 09:05-0800",
    "url": "http://tantek.com/2018/310/t2/great-speakers-a11yclub-talks",
    "category": [
        "indieweb",
        "a11yclub",
        "HTMLfirst",
        "a11y",
        "2018_309"
    ],
    "content": {
        "text": "Yesterday: Great speakers @a11yclub (8/9 with blog, 7/9 on own #indieweb site)\nInformative & thought provoking #a11yclub talks.\nThanks @LeonieWatson @hdv for posting slides, especially Leonie with HTML slides: http://decks.tink.uk/2018/a11yclub/\n#HTMLfirst #a11y #2018_309",
        "html": "Yesterday: Great speakers <a class=\"h-cassis-username\" href=\"https://twitter.com/a11yclub\">@a11yclub</a> (8/9 with blog, 7/9 on own #<span class=\"p-category\">indieweb</span> site)<br />Informative &amp; thought provoking #<span class=\"p-category\">a11yclub</span> talks.<br />Thanks <a class=\"h-cassis-username\" href=\"https://twitter.com/LeonieWatson\">@LeonieWatson</a> <a class=\"h-cassis-username\" href=\"https://twitter.com/hdv\">@hdv</a> for posting slides, especially Leonie with HTML slides: <a href=\"http://decks.tink.uk/2018/a11yclub/\">http://decks.tink.uk/2018/a11yclub/</a><br />#<span class=\"p-category\">HTMLfirst</span> #<span class=\"p-category\">a11y</span> #<span class=\"p-category\">2018_309</span>"
    },
    "author": {
        "type": "card",
        "name": "Tantek \u00c7elik",
        "url": "http://tantek.com/",
        "photo": "https://aperture-media.p3k.io/tantek.com/acfddd7d8b2c8cf8aa163651432cc1ec7eb8ec2f881942dca963d305eeaaa6b8.jpg"
    },
    "post-type": "note",
    "_id": "1357027",
    "_source": "1",
    "_is_read": true
}

{
    "type": "entry",
    "published": "2018-11-06T17:45:41Z",
    "url": "https://adactio.com/links/14492",
    "category": [
        "indieweb",
        "comic",
        "primer",
        "explanation",
        "drawing",
        "illustration",
        "webmention",
        "microsub",
        "relme"
    ],
    "bookmark-of": [
        "http://hag.codes/social/2018/11/05/indieweb-comic.html"
    ],
    "content": {
        "text": "How to get on the #indieweb!\n\n\n\nAs well as graciously hosting Indie Web Camp Berlin on the weekend at Mozilla\u2019s offices, Yulia has also drawn this super-cute comic.",
        "html": "<h3>\n<a class=\"p-name u-bookmark-of\" href=\"http://hag.codes/social/2018/11/05/indieweb-comic.html\">\nHow to get on the #indieweb!\n</a>\n</h3>\n\n<p>As well as graciously hosting Indie Web Camp Berlin on the weekend at Mozilla\u2019s offices, Yulia has also drawn this super-cute comic.</p>"
    },
    "post-type": "bookmark",
    "_id": "1355867",
    "_source": "2",
    "_is_read": true
}

Tantek Çelik tantek.com

{
    "type": "entry",
    "published": "2018-11-06 03:29-0800",
    "url": "http://tantek.com/2018/310/t1/beautiful-comic-indieweb",
    "category": [
        "indieweb"
    ],
    "in-reply-to": [
        "http://hag.codes/social/2018/11/05/indieweb-comic.html"
    ],
    "content": {
        "text": "Beautiful comic by @ioctaptceb!\n\u201cHow to get on the #indieweb\u201d\nhttp://hag.codes/social/2018/11/05/indieweb-comic.html",
        "html": "Beautiful comic by <a class=\"h-cassis-username\" href=\"https://twitter.com/ioctaptceb\">@ioctaptceb</a>!<br />\u201cHow to get on the #<span class=\"p-category\">indieweb</span>\u201d<br />http://hag.codes/social/2018/11/05/indieweb-comic.html"
    },
    "author": {
        "type": "card",
        "name": "Tantek \u00c7elik",
        "url": "http://tantek.com/",
        "photo": "https://aperture-media.p3k.io/tantek.com/acfddd7d8b2c8cf8aa163651432cc1ec7eb8ec2f881942dca963d305eeaaa6b8.jpg"
    },
    "post-type": "reply",
    "refs": {
        "http://hag.codes/social/2018/11/05/indieweb-comic.html": {
            "type": "entry",
            "url": "http://hag.codes/social/2018/11/05/indieweb-comic.html",
            "name": "hag.codes\u2019s post",
            "post-type": "article"
        }
    },
    "_id": "1352525",
    "_source": "1",
    "_is_read": true
}

Marty McGuire

{
    "type": "entry",
    "published": "2018-11-06T04:02:28-05:00",
    "url": "https://martymcgui.re/2018/11/06/040228/",
    "category": [
        "IndieWeb",
        "comic"
    ],
    "content": {
        "text": "Oh gosh this IndieWeb comic by yulia is simply delightful:\nhttp://hag.codes/social/2018/11/05/indieweb-comic.html",
        "html": "<p>Oh gosh this IndieWeb comic by <a href=\"http://hag.codes/\">yulia</a> is simply delightful:</p>\n<p><a href=\"http://hag.codes/social/2018/11/05/indieweb-comic.html\">http://hag.codes/social/2018/11/05/indieweb-comic.html</a></p>"
    },
    "author": {
        "type": "card",
        "name": "Marty McGuire",
        "url": false,
        "photo": "https://aperture-proxy.p3k.io/8275f85e3a389bd0ae69f209683436fc53d8bad9/68747470733a2f2f6d617274796d636775692e72652f696d616765732f6c6f676f2e6a7067"
    },
    "post-type": "note",
    "_id": "1352003",
    "_source": "175",
    "_is_read": true
}