Jeremy Keith adactio.com

Opening up the AMP cache

{
    "type": "entry",
    "published": "2019-08-26T16:00:25Z",
    "url": "https://adactio.com/journal/15726",
    "category": [
        "google",
        "amp",
        "caching",
        "hosting",
        "prerendering",
        "proposal",
        "performance",
        "privacy",
        "speed",
        "search",
        "power",
        "injustice",
        "coercion",
        "frontend",
        "development"
    ],
    "syndication": [
        "https://medium.com/@adactio/63c1ca6318a8"
    ],
    "name": "Opening up the AMP cache",
    "content": {
        "text": "I have a proposal that I think might alleviate some of the animosity around Google AMP. You can jump straight to the proposal or get some of the back story first\u2026\n\nThe AMP format\n\nGoogle AMP is exactly the kind of framework I\u2019d like to get behind. Unlike most front-end frameworks, its components take a declarative approach\u2014no knowledge of JavaScript required. I think Lea\u2019s excellent Mavo is the only other major framework that takes this inclusive approach. All the configuration happens in markup, and all the styling happens in CSS. Excellent!\n\nBut I cannot get behind AMP.\n\nInstead of competing on its own merits, AMP is unfairly propped up by the search engine of its parent company, Google. That makes it very hard to evaluate whether AMP is being used on its own merits. Instead, the evidence suggests that most publishers of AMP pages are doing so because they feel they have to, rather than because they want to. That\u2019s a real shame, because as a library of web components, AMP seems pretty good. But there\u2019s just no way to evaluate AMP-the-format without taking into account AMP-the-ecosystem.\n\nThe AMP ecosystem\n\nGoogle AMP ostensibly exists to make the web faster. Initially the focus was specifically on mobile performance, but that distinction has since fallen by the wayside. The idea is that by using AMP\u2019s web components, your pages will be speedy. Though, as Andy Davies points out, this isn\u2019t always the case:\n\n\n  This is where I get confused\u2026 https://independent.co.uk only have an AMP site yet it\u2019s performance is awful from a user perspective - isn\u2019t AMP supposed to prevent this?\n\n\nSee also: Google AMP lowered our page speed, and there\u2019s no choice but to use it:\n\n\n  According to Google\u2019s own Page Speed Insights audit (which Google recommends to check your performance), the AMP version of articles got an average performance score of 87. The non-AMP versions? 95.\n\n\nPublishers who already have fast web pages\u2014like The Guardian\u2014are still compelled to make AMP versions of their stories because of the search benefits reserved for AMP. As Terence Eden reported from a meeting of the AMP advisory committee:\n\n\n  We heard, several times, that publishers don\u2019t like AMP. They feel forced to use it because otherwise they don\u2019t get into Google\u2019s news carousel \u2014 right at the top of the search results.\n  \n  Some people felt aggrieved that all the hard work they\u2019d done to speed up their sites was for nothing.\n\n\nThe Google AMP team are at pains to point out that AMP is not a ranking factor in search. That\u2019s true. But it is unfairly privileged in other ways. Only AMP pages can appear in the Top Stories carousel \u2026which appears above any other search results. As I\u2019ve said before:\n\n\n  Now, if you were to ask any right-thinking person whether they think having their page appear right at the top of a list of search results would be considered preferential treatment, I think they would say hell, yes! This is the only reason why The Guardian, for instance, even have AMP versions of their content\u2014it\u2019s not for the performance benefits (their non-AMP pages are faster); it\u2019s for that prime real estate in the carousel.\n\n\nFrom A letter about Google AMP:\n\n\n  Content that \u201copts in\u201d to AMP and the associated hosting within Google\u2019s domain is granted preferential search promotion, including (for news articles) a position above all other results.\n\n\nThat\u2019s not the only way that AMP pages get preferential treatment. It turns out that the secret to the speed of AMP pages isn\u2019t the web components. It\u2019s the prerendering.\n\nThe AMP cache\n\nIf you\u2019ve ever seen an AMP page in a list of search results, you\u2019ll have noticed the little lightning icon. If you\u2019ve ever tapped on that search result, you\u2019ll have noticed that the page loads blazingly fast!\n\nThat\u2019s not down to AMP-the-format, alas. That\u2019s down to the fact that the page has been prerendered by Google before you even went to it. If any page were prerendered that way, it would load blazingly fast. But currently, this privilege is reserved for AMP pages only.\n\nIf, after tapping through to that AMP page, you looked at the address bar of your browser, you might have noticed something odd. Even though you might have thought you were visiting The Washington Post, or The New York Times, the URL of the (blazingly fast) page you\u2019re looking at is still under Google\u2019s domain. That\u2019s because Google hosts any AMP pages that it prerenders.\n\nGoogle calls this \u201cthe AMP cache\u201d, but it would be better described as \u201cAMP hosting\u201d. The web page sent down the wire is hosted on Google\u2019s domain.\n\nHere\u2019s that AMP letter again:\n\n\n  When a user navigates from Google to a piece of content Google has recommended, they are, unwittingly, remaining within Google\u2019s ecosystem.\n\n\nThrough gritted teeth, I will refer to this as \u201cthe AMP cache\u201d, because that\u2019s what everyone else calls it. But make no mistake, Google is hosting\u2014not caching\u2014these pages.\n\nBut why host the pages on a Google domain? Why not prerender the original URLs?\n\nPrerendering and privacy\n\nScott summed up the situation with AMP nicely:\n\n\n  The pitch I think site owners are hearing is: let us host your pages on our domain and we\u2019ll promote them in search results AND preload them so they feel \u201cinstant.\u201d To opt-in, build pages using this component syntax.\n\n\nBut perhaps we could de-couple the AMP format from the AMP cache. \n\nThat\u2019s what Terence suggests:\n\n\n  My recommendation is that Google stop requiring that organisations use Google\u2019s proprietary mark-up in order to benefit from Google\u2019s promotion.\n\n\nThe AMP letter, too:\n\n\n  Instead of granting premium placement in search results only to AMP, provide the same perks to all pages that meet an objective, neutral performance criterion such as Speed Index.\n\n\nScott reiterates:\n\n\n  It\u2019s been said before but it would be so good for the web if pages with a Lighthouse score over say, 90 could get into that top search result area, even if they\u2019re not built using Google\u2019s AMP framework. Feels wrong to have to rebuild/reproduce an already-fast site just for SEO.\n\n\nThis was also what I was calling for. But then Malte pointed out something that stumped me. Privacy.\n\nHere\u2019s the problem\u2026\n\nLet\u2019s say Google do indeed prerender already-fast pages when they\u2019re listed in search results. You, a search user, type something into Google. A list of results come back. Google begins pre-rendering some of them. But you don\u2019t end up clicking through to those pages. Nonetheless, the servers those pages are hosted on have received a GET request coming from a Google search. Those publishers now know that a particular (cookied?) user could have clicked through to their site. That\u2019s very different from knowing when someone has actually arrived at a particular site.\n\nAnd that\u2019s why Google host all the AMP pages that they prerender. Given the privacy implications of prerendering non-Google URLs, I must admit that I see their point.\n\nStill, it\u2019s a real shame to miss out on the speed benefit of prerendering:\n\n\n  Prerendering AMP documents leads to substantial improvements in page load times. Page load time can be measured in different ways, but they consistently show that prerendering lets users see the content they want faster. For now, only AMP can provide the privacy preserving prerendering needed for this speed benefit.\n\n\nA modest proposal\n\nWhy is Google\u2019s AMP cache just for AMP pages? (Y\u2019know, apart from the obvious answer that it\u2019s in the name.)\n\nWhat if Google were allowed to host non-AMP pages? Google search could then prerender those pages just like it currently does for AMP pages. There would be no privacy leaks; everything would happen on the same domain\u2014google.com or ampproject.org or whatever\u2014just as currently happens with AMP pages.\n\nDon\u2019t get me wrong: I\u2019m not suggesting that Google should make a 1:1 model of the web just to prerender search results. I think that the implementation would need to have two important requirements:\n\nHosting needs to be opt-in.\nOnly fast pages should be prerendered.\nOpting in\n\nCurrently, by publishing a page using the AMP format, publishers give implicit approval to Google to host that page on Google\u2019s servers and serve up this Google-hosted version from search results. This has always struck me as being legally iffy. I\u2019ve looked in the AMP documentation to try to find any explicit granting of hosting permission (e.g. \u201cBy linking to this JavaScript file, you hereby give Google the right to serve up our copies of your content.\u201d), but no luck. So even with the current situation, I think a clear opt-in for hosting would be beneficial.\n\nThis could be a meta element. Maybe something like:\n\n<meta name=\"caches-allowed\" content=\"google\">\n\n\nThis would have the nice benefit of allowing comma-separated values:\n\n<meta name=\"caches-allowed\" content=\"google, yandex\">\n\n\n(The name is just a strawman, by the way\u2014I\u2019m not suggesting that this is what the final implementation would actually look like.)\n\nIf not a meta element, then perhaps this could be part of robots.txt? Although my feeling is that this needs to happen on a document-by-document basis rather than site-wide.\n\nMany people will, quite rightly, never want Google\u2014or anyone else\u2014to host and serve up their content. That\u2019s why it\u2019s so important that this behaviour needs to be opt-in. It\u2019s kind of appalling that the current hosting of AMP pages is opt-in-by-proxy-sort-of.\n\nCriteria for prerendering\n\nWhich pages should be blessed with hosting and prerendering? The fast ones. That\u2019s sorta the whole point of AMP. But right now, there\u2019s a lot of resentment by people with already-fast websites who quite rightly feel they shouldn\u2019t have to use the AMP format to benefit from the AMP ecosystem.\n\nPage speed is already a ranking factor. It doesn\u2019t seem like too much of a stretch to extend its benefits to hosting and prerendering. As mentioned above, there are already a few possible metrics to use:\n\nPage Speed Index\nLighthouse\nWeb Page Test\nAh, but what if a page has good score when it\u2019s indexed, but then gets worse afterwards? Not a problem! The version of the page that\u2019s measured is the same version of the page that gets hosted and prerendered. Google can confidently say \u201cThis page is fast!\u201d After all, they\u2019re the ones serving up the page.\n\nThat does raise the question of how often Google should check back with the original URL to see if it has changed/worsened/improved. The answer to that question is however long it currently takes to check back in on AMP pages:\n\n\n  Each time a user accesses AMP content from the cache, the content is automatically updated, and the updated version is served to the next user once the content has been cached.\n\n\nIssues\n\nThis proposal does not solve the problem with the address bar. You\u2019d still find yourself looking at a page from The Washington Post or The New York Times (or adactio.com) but seeing a completely different URL in your browser. That\u2019s not good, for all the reasons outlined in the AMP letter.\n\nIn fact, this proposal could potentially make the situation worse. It would allow even more sites to be impersonated by Google\u2019s URLs. Where currently only AMP pages are bad actors in terms of URL confusion, opening up the AMP cache would allow equal opportunity URL confusion.\n\nWhat I\u2019m suggesting is definitely not a long-term solution. The long-term solutions currently being investigated are technically tricky and will take quite a while to come to fruition\u2014web packages and signed exchanges. In the meantime, what I\u2019m proposing is a stopgap solution that\u2019s technically a lot simpler. But it won\u2019t solve all the problems with AMP.\n\nThis proposal solves one problem\u2014AMP pages being unfairly privileged in search results\u2014but does nothing to solve the other, perhaps more serious problem: the erosion of site identity.\n\nMeasuring\n\nCurrently, Google can assess whether a page should be hosted and prerendered by checking to see if it\u2019s a valid AMP page. That test would need to be widened to include a different measurement of performance, but those measurements already exist.\n\nI can see how this assessment might not be as quick as checking for AMP validity. That might affect whether non-AMP pages could be measured quickly enough to end up in the Top Stories carousel, which is, by its nature, time-sensitive. But search results are not necessarily as time-sensitive. Let\u2019s start there.\n\nAssets\n\nCurrently, AMP pages can be prerendered without fetching anything other than the markup of the AMP page itself. All the CSS is inline. There are no initial requests for other kinds of content like images. That\u2019s because there are no img elements on the page: authors must use amp-img instead. The image itself isn\u2019t loaded until the user is on the page.\n\nIf the AMP cache were to be opened up to non-AMP pages, then any content required for prerendering would also need to be hosted on that same domain. Otherwise, there\u2019s privacy leakage.\n\nThis definitely introduces an extra level of complexity. Paths to assets within the markup might need to be re-written to point to the Google-hosted equivalents. There would almost certainly need to be a limit on the number of assets allowed. Though, for performance, that\u2019s no bad thing.\n\nMake no mistake, figuring out what to do about assets\u2014style sheets, scripts, and images\u2014is very challenging indeed. Luckily, there are very smart people on the Google AMP team. If that brainpower were to focus on this problem, I am confident they could solve it.\n\nSummary\n\nPrerendering of non-Google URLs is problematic for privacy reasons, so Google needs to be able to host pages in order to prerender them.\nCurrently, that\u2019s only done for pages using the AMP format.\nThe AMP cache\u2014and with it, prerendering\u2014should be decoupled from the AMP format, and opened up to other fast web pages.\nThere will be technical challenges, but hopefully nothing insurmountable.\n\nI honestly can\u2019t see what Google have to lose here. If their goal is genuinely to reward fast pages, then opening up their AMP cache to fast non-AMP pages will actively encourage people to make fast web pages (without having to switch over to the AMP format).\n\nI\u2019ve deliberately kept the details vague\u2014what the opt-in should look like; what the speed measurement should be; how to handle assets\u2014I\u2019m sure smarter folks than me can figure that stuff out.\n\nI would really like to know what other people think about this proposal. Obviously, I\u2019d love to hear from members of the Google AMP team. But I\u2019d also love to hear from publishers. And I\u2019d very much like to know what people in the web performance community think about this. (Write a blog post and send me a webmention.)\n\nWhat am I missing here? What haven\u2019t I thought of? What are the potential pitfalls (and are they any worse than the current acrimonious situation with Google AMP)?\n\nI would really love it if someone with a fast website were in a position to say, \u201cHey Google, I\u2019m giving you permission to host this page so that it can be prerendered.\u201d\n\nI would really love it if someone with a slow website could say, \u201cOh, shit! We\u2019d better make our existing website faster or Google won\u2019t host our pages for prerendering.\u201d\n\nAnd I would dearly love to finally be able to embrace AMP-the-format with a clear conscience. But as long as prerendering is joined at the hip to the AMP format, the injustice of the situation only harms the AMP project.\n\nGoogle, open up the AMP cache.",
        "html": "<p>I have a proposal that I think might alleviate some of the animosity around Google AMP. You can <a href=\"https://adactio.com/#proposal\">jump straight to the proposal</a> or get some of the back story first\u2026</p>\n\n<h3>The AMP format</h3>\n\n<p><a href=\"https://amp.dev/\">Google AMP</a> is exactly the kind of framework I\u2019d like to get behind. Unlike most front-end frameworks, its components take a declarative approach\u2014no knowledge of JavaScript required. I think Lea\u2019s excellent <a href=\"https://mavo.io/\">Mavo</a> is the only other major framework that takes this <a href=\"https://adactio.com/journal/15050#barrier%20to%20entry\">inclusive</a> approach. All the configuration happens in markup, and all the styling happens in CSS. Excellent!</p>\n\n<p>But I cannot get behind AMP.</p>\n\n<p>Instead of competing on its own merits, AMP is unfairly propped up by the search engine of its parent company, Google. That makes it very hard to evaluate whether AMP is being used on its own merits. Instead, the evidence suggests that most publishers of AMP pages are doing so because they feel they have to, rather than because they want to. That\u2019s a real shame, because as a library of web components, AMP seems pretty good. But there\u2019s just no way to evaluate AMP-the-format without taking into account AMP-the-ecosystem.</p>\n\n<h3>The AMP ecosystem</h3>\n\n<p>Google AMP ostensibly exists to make the web faster. Initially the focus was specifically on mobile performance, but that distinction has since fallen by the wayside. The idea is that by using AMP\u2019s web components, your pages will be speedy. Though, <a href=\"https://twitter.com/AndyDavies/status/1165205231136673792\">as Andy Davies points out</a>, this isn\u2019t always the case:</p>\n\n<blockquote>\n  <p>This is where I get confused\u2026 <a href=\"https://independent.co.uk\">https://independent.co.uk</a> only have an AMP site yet it\u2019s performance is awful from a user perspective - isn\u2019t AMP supposed to prevent this?</p>\n</blockquote>\n\n<p>See also: <a href=\"https://unlikekinds.com/article/google-amp-page-speed\">Google AMP lowered our page speed, and there\u2019s no choice but to use it</a>:</p>\n\n<blockquote>\n  <p>According to Google\u2019s own Page Speed Insights audit (which Google recommends to check your performance), the AMP version of articles got an average performance score of 87. The non-AMP versions? 95.</p>\n</blockquote>\n\n<p>Publishers who already have fast web pages\u2014like The Guardian\u2014are still compelled to make AMP versions of their stories because of the search benefits reserved for AMP. As <a href=\"https://shkspr.mobi/blog/2019/05/a-report-from-the-amp-advisory-committee-meeting/\">Terence Eden reported from a meeting of the AMP advisory committee</a>:</p>\n\n<blockquote>\n  <p>We heard, several times, that publishers don\u2019t like AMP. They feel forced to use it because otherwise they don\u2019t get into Google\u2019s news carousel \u2014 right at the top of the search results.</p>\n  \n  <p>Some people felt aggrieved that all the hard work they\u2019d done to speed up their sites was for nothing.</p>\n</blockquote>\n\n<p>The Google AMP team are at pains to point out that AMP is not a ranking factor in search. That\u2019s true. But it is unfairly privileged in other ways. Only AMP pages can appear in the Top Stories carousel \u2026which appears <em>above</em> any other search results. <a href=\"https://adactio.com/journal/13035\">As I\u2019ve said before</a>:</p>\n\n<blockquote>\n  <p>Now, if you were to ask any right-thinking person whether they think having their page appear <em>right at the top</em> of a list of search results would be considered preferential treatment, I think they would say hell, yes! This is the only reason why The Guardian, for instance, even have AMP versions of their content\u2014it\u2019s not for the performance benefits (their non-AMP pages are faster); it\u2019s for that prime real estate in the carousel.</p>\n</blockquote>\n\n<p>From <a href=\"http://ampletter.org/\">A letter about Google AMP</a>:</p>\n\n<blockquote>\n  <p>Content that \u201copts in\u201d to AMP and the associated hosting within Google\u2019s domain is granted preferential search promotion, including (for news articles) a position above all other results.</p>\n</blockquote>\n\n<p>That\u2019s not the only way that AMP pages get preferential treatment. It turns out that the secret to the speed of AMP pages isn\u2019t the web components. It\u2019s the prerendering.</p>\n\n<h3>The AMP cache</h3>\n\n<p>If you\u2019ve ever seen an AMP page in a list of search results, you\u2019ll have noticed the little lightning icon. If you\u2019ve ever tapped on that search result, you\u2019ll have noticed that the page loads blazingly fast!</p>\n\n<p>That\u2019s not down to AMP-the-format, alas. That\u2019s down to the fact that the page has been prerendered by Google before you even went to it. If <em>any</em> page were prerendered that way, it would load blazingly fast. But currently, this privilege is reserved for AMP pages only.</p>\n\n<p>If, after tapping through to that AMP page, you looked at the address bar of your browser, you might have noticed something odd. Even though you might have thought you were visiting The Washington Post, or The New York Times, the URL of the (blazingly fast) page you\u2019re looking at is still under Google\u2019s domain. That\u2019s because Google hosts any AMP pages that it prerenders.</p>\n\n<p>Google calls this \u201cthe AMP cache\u201d, but it would be better described as \u201cAMP hosting\u201d. The web page sent down the wire is hosted on Google\u2019s domain.</p>\n\n<p>Here\u2019s that <a href=\"http://ampletter.org/\">AMP letter</a> again:</p>\n\n<blockquote>\n  <p>When a user navigates from Google to a piece of content Google has recommended, they are, unwittingly, remaining within Google\u2019s ecosystem.</p>\n</blockquote>\n\n<p>Through gritted teeth, I will refer to this as \u201cthe AMP cache\u201d, because that\u2019s what everyone else calls it. But make no mistake, Google is hosting\u2014not caching\u2014these pages.</p>\n\n<p>But <em>why</em> host the pages on a Google domain? Why not prerender the original URLs?</p>\n\n<h3>Prerendering and privacy</h3>\n\n<p><a href=\"https://twitter.com/scottjehl/status/1123995512867315712\">Scott summed up the situation with AMP nicely</a>:</p>\n\n<blockquote>\n  <p>The pitch I think site owners are hearing is: let us host your pages on our domain and we\u2019ll promote them in search results AND preload them so they feel \u201cinstant.\u201d To opt-in, build pages using this component syntax.</p>\n</blockquote>\n\n<p>But perhaps we could de-couple the AMP format from the AMP cache. </p>\n\n<p>That\u2019s <a href=\"https://shkspr.mobi/blog/2019/05/a-report-from-the-amp-advisory-committee-meeting/\">what Terence suggests</a>:</p>\n\n<blockquote>\n  <p>My recommendation is that Google stop <em>requiring</em> that organisations use Google\u2019s proprietary mark-up in order to benefit from Google\u2019s promotion.</p>\n</blockquote>\n\n<p><a href=\"http://ampletter.org/\">The AMP letter, too</a>:</p>\n\n<blockquote>\n  <p>Instead of granting premium placement in search results only to AMP, provide the same perks to all pages that meet an objective, neutral performance criterion such as <a href=\"https://sites.google.com/a/webpagetest.org/docs/using-webpagetest/metrics/speed-index\">Speed Index</a>.</p>\n</blockquote>\n\n<p><a href=\"https://twitter.com/scottjehl/status/1123960726803091456\">Scott reiterates</a>:</p>\n\n<blockquote>\n  <p>It\u2019s been said before but it would be so good for the web if pages with a Lighthouse score over say, 90 could get into that top search result area, even if they\u2019re not built using Google\u2019s AMP framework. Feels wrong to have to rebuild/reproduce an already-fast site just for SEO.</p>\n</blockquote>\n\n<p>This was also what I was calling for. But then <a href=\"https://twitter.com/cramforce\">Malte</a> pointed out something that stumped me. <a href=\"https://blog.amp.dev/2018/07/23/privacy-and-user-choice-in-amps-software-architecture/\">Privacy</a>.</p>\n\n<p>Here\u2019s the problem\u2026</p>\n\n<p>Let\u2019s say Google do indeed prerender already-fast pages when they\u2019re listed in search results. You, a search user, type something into Google. A list of results come back. Google begins pre-rendering some of them. But you don\u2019t end up clicking through to those pages. Nonetheless, the servers those pages are hosted on have received a GET request coming from a Google search. Those publishers now know that a particular (cookied?) user <em>could have</em> clicked through to their site. That\u2019s very different from knowing when someone has <em>actually</em> arrived at a particular site.</p>\n\n<p>And that\u2019s why Google host all the AMP pages that they prerender. Given the privacy implications of prerendering non-Google URLs, I must admit that I see their point.</p>\n\n<p>Still, it\u2019s a real shame to miss out on <a href=\"https://developers.googleblog.com/2019/08/the-speed-benefit-of-amp-prerendering.html\">the speed benefit of prerendering</a>:</p>\n\n<blockquote>\n  <p>Prerendering AMP documents leads to substantial improvements in page load times. Page load time can be measured in different ways, but they consistently show that prerendering lets users see the content they want faster. For now, only AMP can provide the privacy preserving prerendering needed for this speed benefit.</p>\n</blockquote>\n\n<h3>A modest proposal</h3>\n\n<p>Why is Google\u2019s AMP cache just for AMP pages? (Y\u2019know, apart from the obvious answer that it\u2019s in the name.)</p>\n\n<p><strong>What if Google were allowed to host non-AMP pages?</strong> Google search could then prerender those pages just like it currently does for AMP pages. There would be no privacy leaks; everything would happen on the same domain\u2014google.com or ampproject.org or whatever\u2014just as currently happens with AMP pages.</p>\n\n<p>Don\u2019t get me wrong: I\u2019m not suggesting that Google should make a 1:1 model of the web just to prerender search results. I think that the implementation would need to have two important requirements:</p>\n\n<ol><li>Hosting needs to be opt-in.</li>\n<li>Only fast pages should be prerendered.</li>\n</ol><h4>Opting in</h4>\n\n<p>Currently, by publishing a page using the AMP format, publishers give <em>implicit</em> approval to Google to host that page on Google\u2019s servers <em>and</em> serve up this Google-hosted version from search results. This has always struck me as being legally iffy. I\u2019ve looked in <a href=\"https://amp.dev/documentation/\">the AMP documentation</a> to try to find any <em>explicit</em> granting of hosting permission (e.g. \u201cBy linking to this JavaScript file, you hereby give Google the right to serve up our copies of your content.\u201d), but no luck. So even with the current situation, I think a clear opt-in for hosting would be beneficial.</p>\n\n<p>This could be a <code>meta</code> element. Maybe something like:</p>\n\n<pre><code>&lt;meta name=\"caches-allowed\" content=\"google\"&gt;\n</code></pre>\n\n<p>This would have the nice benefit of allowing comma-separated values:</p>\n\n<pre><code>&lt;meta name=\"caches-allowed\" content=\"google, yandex\"&gt;\n</code></pre>\n\n<p>(The name is just a strawman, by the way\u2014I\u2019m not suggesting that this is what the final implementation would actually look like.)</p>\n\n<p>If not a <code>meta</code> element, then perhaps this could be part of <code>robots.txt</code>? Although my feeling is that this needs to happen on a document-by-document basis rather than site-wide.</p>\n\n<p>Many people will, <a href=\"https://www.robinrendle.com/notes/taking-shortcuts.html\">quite rightly</a>, <em>never</em> want Google\u2014or anyone else\u2014to host and serve up their content. That\u2019s why it\u2019s so important that this behaviour needs to be opt-in. It\u2019s kind of appalling that the current hosting of AMP pages is opt-in-by-proxy-sort-of.</p>\n\n<h4>Criteria for prerendering</h4>\n\n<p><a href=\"https://blog.amp.dev/2017/01/13/why-amp-caches-exist/\">Which pages should be blessed with hosting and prerendering?</a> The fast ones. That\u2019s sorta the whole point of AMP. But right now, there\u2019s a lot of resentment by people with already-fast websites who quite rightly feel they shouldn\u2019t have to use the AMP <em>format</em> to benefit from the AMP ecosystem.</p>\n\n<p><a href=\"https://webmasters.googleblog.com/2018/01/using-page-speed-in-mobile-search.html\">Page speed is already a ranking factor</a>. It doesn\u2019t seem like too much of a stretch to extend its benefits to hosting and prerendering. As mentioned above, there are already a few possible metrics to use:</p>\n\n<ul><li>Page Speed Index</li>\n<li>Lighthouse</li>\n<li>Web Page Test</li>\n</ul><p>Ah, but what if a page has good score when it\u2019s indexed, but then gets worse afterwards? Not a problem! The version of the page that\u2019s <em>measured</em> is the same version of the page that gets hosted and prerendered. Google can confidently say \u201cThis page is fast!\u201d After all, they\u2019re the ones serving up the page.</p>\n\n<p>That does raise the question of how often Google should check back with the original URL to see if it has changed/worsened/improved. The answer to that question is <a href=\"https://developers.google.com/amp/cache/overview\">however long it currently takes to check back in on AMP pages</a>:</p>\n\n<blockquote>\n  <p>Each time a user accesses AMP content from the cache, the content is automatically updated, and the updated version is served to the next user once the content has been cached.</p>\n</blockquote>\n\n<h3>Issues</h3>\n\n<p>This proposal does <em>not</em> solve the problem with the address bar. You\u2019d still find yourself looking at a page from The Washington Post or The New York Times (or adactio.com) but seeing a completely different URL in your browser. That\u2019s not good, for all the reasons outlined in <a href=\"http://ampletter.org/\">the AMP letter</a>.</p>\n\n<p>In fact, this proposal could potentially make the situation <em>worse</em>. It would allow even more sites to be impersonated by Google\u2019s URLs. Where currently only AMP pages are bad actors in terms of URL confusion, opening up the AMP cache would allow equal opportunity URL confusion.</p>\n\n<p>What I\u2019m suggesting is definitely <em>not</em> a long-term solution. The long-term solutions currently being investigated are technically tricky and will take quite a while to come to fruition\u2014<a href=\"https://github.com/WICG/webpackage\">web packages</a> and <a href=\"https://developers.google.com/web/updates/2018/11/signed-exchanges\">signed exchanges</a>. In the meantime, what I\u2019m proposing is a stopgap solution that\u2019s technically a lot simpler. But it won\u2019t solve all the problems with AMP.</p>\n\n<p>This proposal solves <em>one</em> problem\u2014AMP pages being unfairly privileged in search results\u2014but does nothing to solve the other, perhaps more serious problem: the erosion of site identity.</p>\n\n<h4>Measuring</h4>\n\n<p>Currently, Google can assess whether a page should be hosted and prerendered by checking to see if it\u2019s a valid AMP page. That test would need to be widened to include a different measurement of performance, but those measurements already exist.</p>\n\n<p>I can see how this assessment might not be as quick as checking for AMP validity. That might affect whether non-AMP pages could be measured quickly enough to end up in the Top Stories carousel, which is, by its nature, time-sensitive. But search results are not necessarily as time-sensitive. Let\u2019s start there.</p>\n\n<h4>Assets</h4>\n\n<p>Currently, AMP pages can be prerendered without fetching anything other than the markup of the AMP page itself. All the CSS is inline. There are no initial requests for other kinds of content like images. That\u2019s because there are no <code>img</code> elements on the page: authors must use <code>amp-img</code> instead. The image itself isn\u2019t loaded until the user is on the page.</p>\n\n<p>If the AMP cache were to be opened up to non-AMP pages, then any content required for prerendering would also need to be hosted on that same domain. Otherwise, there\u2019s privacy leakage.</p>\n\n<p>This definitely introduces an extra level of complexity. Paths to assets within the markup might need to be re-written to point to the Google-hosted equivalents. There would almost certainly need to be a limit on the number of assets allowed. Though, for performance, that\u2019s no bad thing.</p>\n\n<p>Make no mistake, figuring out what to do about assets\u2014style sheets, scripts, and images\u2014is very challenging indeed. Luckily, there are very smart people on the Google AMP team. If that brainpower were to focus on this problem, I am confident they could solve it.</p>\n\n<h3>Summary</h3>\n\n<ol><li>Prerendering of non-Google URLs is problematic for privacy reasons, so Google needs to be able to host pages in order to prerender them.</li>\n<li>Currently, that\u2019s only done for pages using the AMP format.</li>\n<li>The AMP cache\u2014and with it, prerendering\u2014should be decoupled from the AMP format, and opened up to other fast web pages.</li>\n</ol><p>There will be technical challenges, but hopefully nothing insurmountable.</p>\n\n<p>I honestly can\u2019t see what Google have to lose here. If their goal is genuinely to reward fast pages, then opening up their AMP cache to fast non-AMP pages will actively encourage people to make fast web pages (without having to switch over to the AMP format).</p>\n\n<p>I\u2019ve deliberately kept the details vague\u2014what the opt-in should look like; what the speed measurement should be; how to handle assets\u2014I\u2019m sure smarter folks than me can figure that stuff out.</p>\n\n<p>I would really like to know what other people think about this proposal. Obviously, I\u2019d love to hear from members of the Google AMP team. But I\u2019d also love to hear from publishers. And I\u2019d very much like to know what people in the web performance community think about this. (Write a blog post and send me a webmention.)</p>\n\n<p>What am I missing here? What haven\u2019t I thought of? What are the potential pitfalls (and are they any worse than the current acrimonious situation with Google AMP)?</p>\n\n<p>I would really love it if <a href=\"https://twitter.com/rem/status/1164958772042895361\">someone with a fast website</a> were in a position to say, \u201cHey Google, I\u2019m giving you permission to host this page so that it can be prerendered.\u201d</p>\n\n<p>I would really love it if someone with a slow website could say, \u201cOh, shit! We\u2019d better make our <em>existing</em> website faster or Google won\u2019t host our pages for prerendering.\u201d</p>\n\n<p>And I would dearly love to finally be able to embrace AMP-the-format with a clear conscience. But as long as prerendering is joined at the hip to the AMP format, the injustice of the situation only harms the AMP project.</p>\n\n<p>Google, open up the AMP cache.</p>"
    },
    "author": {
        "type": "card",
        "name": "Jeremy Keith",
        "url": "https://adactio.com/",
        "photo": "https://aperture-proxy.p3k.io/bbbacdf0a064621004f2ce9026a1202a5f3433e0/68747470733a2f2f6164616374696f2e636f6d2f696d616765732f70686f746f2d3135302e6a7067"
    },
    "post-type": "article",
    "_id": "5025683",
    "_source": "2",
    "_is_read": true
}

Aaron Parecki aaronparecki.com

{
    "type": "entry",
    "published": "2019-08-25T21:46:36-07:00",
    "url": "https://aaronparecki.com/2019/08/25/14/travel",
    "category": [
        "homeautomation",
        "microformats",
        "epaper",
        "rpi",
        "raspberrypi",
        "travel"
    ],
    "photo": [
        "https://aperture-media.p3k.io/aaronparecki.com/5a54a45d15dc1b7f898745ecd3748ad1150ae57e02555c68cae57304baefac5c.jpg"
    ],
    "content": {
        "text": "Working on a little display that will sit in a picture frame and show my next upcoming flight! \n\nPowered by a raspberry pi which parses the flights from the microformats on my website, and shows either the next upcoming trip, or if I'm currently away, shows the details of the flight home. \n\nThis e-paper display is really nice looking too!",
        "html": "Working on a little display that will sit in a picture frame and show my next upcoming flight! <br /><br />Powered by a raspberry pi which parses the flights from the microformats on my website, and shows either the next upcoming trip, or if I'm currently away, shows the details of the flight home. <br /><br />This e-paper display is really nice looking too!"
    },
    "author": {
        "type": "card",
        "name": "Aaron Parecki",
        "url": "https://aaronparecki.com/",
        "photo": "https://aperture-media.p3k.io/aaronparecki.com/41061f9de825966faa22e9c42830e1d4a614a321213b4575b9488aa93f89817a.jpg"
    },
    "post-type": "photo",
    "_id": "5019722",
    "_source": "16",
    "_is_read": true
}

Tantek Çelik tantek.com

{
    "type": "entry",
    "published": "2019-08-25 10:29-0700",
    "url": "http://tantek.com/2019/237/t2/",
    "in-reply-to": [
        "https://twitter.com/dietrich/status/1165681487494008832"
    ],
    "content": {
        "text": "\ud83c\udf89 @dietrich!\n\nhttps://indieweb.org/events :)\n\nOff-cycle Homebrew Website Club SF this week: https://indieweb.org/events/2019-08-28-homebrew-website-club\nWeek after I\u2019m hosting a pop-up HWC @MozPDX during @XOXO conf week!\n\nStill coding, will follow-up when iCal/gCal links work!\n\nFirst, another run",
        "html": "\ud83c\udf89 <a class=\"h-cassis-username\" href=\"https://twitter.com/dietrich\">@dietrich</a>!<br /><br /><a href=\"https://indieweb.org/events\">https://indieweb.org/events</a> :)<br /><br />Off-cycle Homebrew Website Club SF this week: <a href=\"https://indieweb.org/events/2019-08-28-homebrew-website-club\">https://indieweb.org/events/2019-08-28-homebrew-website-club</a><br />Week after I\u2019m hosting a pop-up HWC <a class=\"h-cassis-username\" href=\"https://twitter.com/MozPDX\">@MozPDX</a> during <a class=\"h-cassis-username\" href=\"https://twitter.com/XOXO\">@XOXO</a> conf week!<br /><br />Still coding, will follow-up when iCal/gCal links work!<br /><br />First, another run"
    },
    "author": {
        "type": "card",
        "name": "Tantek \u00c7elik",
        "url": "http://tantek.com/",
        "photo": "https://aperture-media.p3k.io/tantek.com/acfddd7d8b2c8cf8aa163651432cc1ec7eb8ec2f881942dca963d305eeaaa6b8.jpg"
    },
    "post-type": "reply",
    "refs": {
        "https://twitter.com/dietrich/status/1165681487494008832": {
            "type": "entry",
            "url": "https://twitter.com/dietrich/status/1165681487494008832",
            "name": "@dietrich\u2019s tweet",
            "post-type": "article"
        }
    },
    "_id": "5016165",
    "_source": "1",
    "_is_read": true
}

Jeremy Keith adactio.com

{
    "type": "entry",
    "published": "2019-08-24T13:16:14Z",
    "url": "https://adactio.com/links/15716",
    "category": [
        "creating",
        "consuming",
        "writing",
        "editing",
        "publishing",
        "sharing",
        "indieweb"
    ],
    "bookmark-of": [
        "https://tjcx.me/posts/consumption-distraction/"
    ],
    "content": {
        "text": "Consume less, create more\n\n\n\n\n  Editing is hard because you realize how bad you are. But editing is easy because we\u2019re all better at criticizing than we are at creating.\n\n\nRelatable:\n\n\n  My essay was garbage. But it was my garbage.\n\n\nThis essay is most definitely not garbage. I like it very much.",
        "html": "<h3>\n<a class=\"p-name u-bookmark-of\" href=\"https://tjcx.me/posts/consumption-distraction/\">\nConsume less, create more\n</a>\n</h3>\n\n<blockquote>\n  <p>Editing is hard because you realize how bad you are. But editing is easy because we\u2019re all better at criticizing than we are at creating.</p>\n</blockquote>\n\n<p>Relatable:</p>\n\n<blockquote>\n  <p>My essay was garbage. But it was <em>my</em> garbage.</p>\n</blockquote>\n\n<p>This essay is most definitely not garbage. I like it very much.</p>"
    },
    "author": {
        "type": "card",
        "name": "Jeremy Keith",
        "url": "https://adactio.com/",
        "photo": "https://aperture-proxy.p3k.io/bbbacdf0a064621004f2ce9026a1202a5f3433e0/68747470733a2f2f6164616374696f2e636f6d2f696d616765732f70686f746f2d3135302e6a7067"
    },
    "post-type": "bookmark",
    "_id": "5002960",
    "_source": "2",
    "_is_read": true
}

Tantek Çelik tantek.com

{
    "type": "entry",
    "published": "2019-08-23 22:37-0700",
    "url": "http://tantek.com/2019/235/t4/next-add-to-calendar-interoperate",
    "category": [
        "indieweb",
        "interoperate",
        "openstandard",
        "RFC5545"
    ],
    "in-reply-to": [
        "https://tantek.com/2019/235/t3/federated-events-rsvps-webmention"
    ],
    "content": {
        "text": "The next step is to add a link or button on the #indieweb event like:\n\n\ud83d\udcc6 Add to Calendar\n\nto #interoperate with existing apps & services via .ics download (@IETF #openstandard #RFC5545). @schmarty & @gRegorLove do this. I\u2019ll add code for my events too",
        "html": "The next step is to add a link or button on the #<span class=\"p-category\">indieweb</span> event like:<br /><br />\ud83d\udcc6 Add to Calendar<br /><br />to #<span class=\"p-category\">interoperate</span> with existing apps &amp; services via .ics download (<a class=\"h-cassis-username\" href=\"https://twitter.com/IETF\">@IETF</a> #<span class=\"p-category\">openstandard</span> #<span class=\"p-category\">RFC5545</span>). <a class=\"h-cassis-username\" href=\"https://twitter.com/schmarty\">@schmarty</a> &amp; <a class=\"h-cassis-username\" href=\"https://twitter.com/gRegorLove\">@gRegorLove</a> do this. I\u2019ll add code for my events too"
    },
    "author": {
        "type": "card",
        "name": "Tantek \u00c7elik",
        "url": "http://tantek.com/",
        "photo": "https://aperture-media.p3k.io/tantek.com/acfddd7d8b2c8cf8aa163651432cc1ec7eb8ec2f881942dca963d305eeaaa6b8.jpg"
    },
    "post-type": "reply",
    "refs": {
        "https://tantek.com/2019/235/t3/federated-events-rsvps-webmention": {
            "type": "entry",
            "url": "https://tantek.com/2019/235/t3/federated-events-rsvps-webmention",
            "name": "Tantek\u2019s note",
            "post-type": "article"
        }
    },
    "_id": "5002291",
    "_source": "1",
    "_is_read": true
}

Tantek Çelik tantek.com

{
    "type": "entry",
    "published": "2019-08-23 22:25-0700",
    "url": "http://tantek.com/2019/235/t3/federated-events-rsvps-webmention",
    "category": [
        "indieweb",
        "federated",
        "Webmention",
        "microformats2"
    ],
    "in-reply-to": [
        "https://tantek.com/2019/235/t2/indieweb-strategy-federate-interoperate-bridges"
    ],
    "content": {
        "text": "The #indieweb has #federated events and RSVPs using #Webmention and #microformats2 h-event.\n\nThat Homebrew Website Club SF event was a demo thereof:\nhttps://tantek.com/2019/233/e1/homebrew-website-club-sf (note RSVPs)\n\nQuite good, yet as observed, insufficient for Google Calendar users",
        "html": "The #<span class=\"p-category\">indieweb</span> has #<span class=\"p-category\">federated</span> events and RSVPs using #<span class=\"p-category\">Webmention</span> and #<span class=\"p-category\">microformats2</span> h-event.<br /><br />That Homebrew Website Club SF event was a demo thereof:<br /><a href=\"https://tantek.com/2019/233/e1/homebrew-website-club-sf\">https://tantek.com/2019/233/e1/homebrew-website-club-sf</a> (note RSVPs)<br /><br />Quite good, yet as observed, insufficient for Google Calendar users"
    },
    "author": {
        "type": "card",
        "name": "Tantek \u00c7elik",
        "url": "http://tantek.com/",
        "photo": "https://aperture-media.p3k.io/tantek.com/acfddd7d8b2c8cf8aa163651432cc1ec7eb8ec2f881942dca963d305eeaaa6b8.jpg"
    },
    "post-type": "reply",
    "refs": {
        "https://tantek.com/2019/235/t2/indieweb-strategy-federate-interoperate-bridges": {
            "type": "entry",
            "url": "https://tantek.com/2019/235/t2/indieweb-strategy-federate-interoperate-bridges",
            "name": "Tantek\u2019s note",
            "post-type": "article"
        }
    },
    "_id": "5000667",
    "_source": "1",
    "_is_read": true
}

Tantek Çelik tantek.com

{
    "type": "entry",
    "published": "2019-08-23 21:51-0700",
    "url": "http://tantek.com/2019/235/t2/indieweb-strategy-federate-interoperate-bridges",
    "category": [
        "indieweb"
    ],
    "in-reply-to": [
        "https://twitter.com/dietrich/status/1164318286542016513"
    ],
    "content": {
        "text": "Replacement is a good goal @dietrich.\n\nThe #indieweb recognizes replacement may be impractical for a person or their friends in the short term.\n\nThe indieweb strategy is to federate, interoperate, and build bridges to transition in parallel.\n\nLet\u2019s begin",
        "html": "Replacement is a good goal <a class=\"h-cassis-username\" href=\"https://twitter.com/dietrich\">@dietrich</a>.<br /><br />The #<span class=\"p-category\">indieweb</span> recognizes replacement may be impractical for a person or their friends in the short term.<br /><br />The indieweb strategy is to federate, interoperate, and build bridges to transition in parallel.<br /><br />Let\u2019s begin"
    },
    "author": {
        "type": "card",
        "name": "Tantek \u00c7elik",
        "url": "http://tantek.com/",
        "photo": "https://aperture-media.p3k.io/tantek.com/acfddd7d8b2c8cf8aa163651432cc1ec7eb8ec2f881942dca963d305eeaaa6b8.jpg"
    },
    "post-type": "reply",
    "refs": {
        "https://twitter.com/dietrich/status/1164318286542016513": {
            "type": "entry",
            "url": "https://twitter.com/dietrich/status/1164318286542016513",
            "name": "@dietrich\u2019s tweet",
            "post-type": "article"
        }
    },
    "_id": "5000668",
    "_source": "1",
    "_is_read": true
}

{
    "type": "entry",
    "author": {
        "name": "Kh\u00fcrt Williams",
        "url": "https://islandinthenet.com/",
        "photo": null
    },
    "url": "https://islandinthenet.com/2019-08-23-00-40-20/",
    "published": "2019-08-23T00:40:20-04:00",
    "content": {
        "html": "Might be attending <a href=\"https://2019.indieweb.org/nyc\">IndieWebCamp NYC</a>\n<blockquote>IndieWebCamp NYC 2019 is a two-day maker event for creating and/or improving your personal website. All levels welcome! One of several 2019 IndieWebCamps and the seventh IndieWebCamp in NYC!</blockquote>",
        "text": "Might be attending IndieWebCamp NYC\nIndieWebCamp NYC 2019 is a two-day maker event for creating and/or improving your personal website. All levels welcome! One of several 2019 IndieWebCamps and the seventh IndieWebCamp in NYC!"
    },
    "post-type": "note",
    "_id": "4988405",
    "_source": "242",
    "_is_read": true
}

Jeremy Keith adactio.com

{
    "type": "entry",
    "published": "2019-08-22T03:17:15Z",
    "url": "https://adactio.com/links/15660",
    "category": [
        "indieweb",
        "personal",
        "publishing",
        "homepages",
        "websites",
        "independent",
        "inspiration",
        "ownership"
    ],
    "bookmark-of": [
        "https://99u.adobe.com/articles/64112/why-you-need-a-personal-website-and-tips-for-how-to-build-one"
    ],
    "content": {
        "text": "Why We All Need a Personal Website \u2013 Plus Practical Tips for How to Build One - Adobe 99U\n\n\n\n\n  The best time to make a personal website is 20 years ago. The second best time to make a personal website is now.\n\n\nChris offers some illustrated advice:\n\n\n  Define the purpose of your site\n  Organize your content\n  Look for inspiration\n  Own your own domain name\n  Build your website",
        "html": "<h3>\n<a class=\"p-name u-bookmark-of\" href=\"https://99u.adobe.com/articles/64112/why-you-need-a-personal-website-and-tips-for-how-to-build-one\">\nWhy We All Need a Personal Website \u2013 Plus Practical Tips for How to Build One - Adobe 99U\n</a>\n</h3>\n\n<blockquote>\n  <p>The best time to make a personal website is 20 years ago. The second best time to make a personal website is now.</p>\n</blockquote>\n\n<p><a href=\"http://shiflett.org/\">Chris</a> offers some illustrated advice:</p>\n\n<blockquote>\n  <ul><li>Define the purpose of your site</li>\n  <li>Organize your content</li>\n  <li>Look for inspiration</li>\n  <li>Own your own domain name</li>\n  <li>Build your website</li>\n  </ul></blockquote>"
    },
    "author": {
        "type": "card",
        "name": "Jeremy Keith",
        "url": "https://adactio.com/",
        "photo": "https://aperture-proxy.p3k.io/bbbacdf0a064621004f2ce9026a1202a5f3433e0/68747470733a2f2f6164616374696f2e636f6d2f696d616765732f70686f746f2d3135302e6a7067"
    },
    "post-type": "bookmark",
    "_id": "4975501",
    "_source": "2",
    "_is_read": true
}

Tantek Çelik tantek.com

{
    "type": "entry",
    "published": "2019-08-21 14:52-0700",
    "rsvp": "yes",
    "url": "http://tantek.com/2019/233/t1/hosting-homebrew-website-club-sf",
    "category": [
        "SF",
        "IndieWeb",
        "dweb",
        "openweb"
    ],
    "in-reply-to": [
        "https://tantek.com/2019/233/e1/homebrew-website-club-sf"
    ],
    "content": {
        "text": "hosting the Homebrew Website Club #SF #IndieWeb meetup tonight 17:30 @MozSF\nHope to see you there! Yes you @benwerd @dietrich @generativist @html5cat @NurtureGirl @feross @maira\ncc #dweb #openweb\n\nRSVP: https://tantek.com/2019/233/e1/homebrew-website-club-sf\nMore: https://indieweb.org/events/2019-08-21-homebrew-website-club#San_Francisco",
        "html": "hosting the Homebrew Website Club #<span class=\"p-category\">SF</span> #<span class=\"p-category\">IndieWeb</span> meetup tonight 17:30 <a class=\"h-cassis-username\" href=\"https://twitter.com/MozSF\">@MozSF</a><br />Hope to see you there! Yes you <a class=\"h-cassis-username\" href=\"https://twitter.com/benwerd\">@benwerd</a> <a class=\"h-cassis-username\" href=\"https://twitter.com/dietrich\">@dietrich</a> <a class=\"h-cassis-username\" href=\"https://twitter.com/generativist\">@generativist</a> <a class=\"h-cassis-username\" href=\"https://twitter.com/html5cat\">@html5cat</a> <a class=\"h-cassis-username\" href=\"https://twitter.com/NurtureGirl\">@NurtureGirl</a> <a class=\"h-cassis-username\" href=\"https://twitter.com/feross\">@feross</a> <a class=\"h-cassis-username\" href=\"https://twitter.com/maira\">@maira</a><br />cc #<span class=\"p-category\">dweb</span> #<span class=\"p-category\">openweb</span><br /><br />RSVP: <a href=\"https://tantek.com/2019/233/e1/homebrew-website-club-sf\">https://tantek.com/2019/233/e1/homebrew-website-club-sf</a><br />More: <a href=\"https://indieweb.org/events/2019-08-21-homebrew-website-club#San_Francisco\">https://indieweb.org/events/2019-08-21-homebrew-website-club#San_Francisco</a>"
    },
    "author": {
        "type": "card",
        "name": "Tantek \u00c7elik",
        "url": "http://tantek.com/",
        "photo": "https://aperture-media.p3k.io/tantek.com/acfddd7d8b2c8cf8aa163651432cc1ec7eb8ec2f881942dca963d305eeaaa6b8.jpg"
    },
    "post-type": "rsvp",
    "refs": {
        "https://tantek.com/2019/233/e1/homebrew-website-club-sf": {
            "type": "entry",
            "url": "https://tantek.com/2019/233/e1/homebrew-website-club-sf",
            "name": "Tantek\u2019s event",
            "post-type": "article"
        }
    },
    "_id": "4974517",
    "_source": "1",
    "_is_read": true
}

{
    "type": "entry",
    "author": {
        "name": "Neil Mather",
        "url": "https://doubleloop.net/",
        "photo": null
    },
    "url": "https://doubleloop.net/2019/08/21/showing-indieauth-and-micropub-at-hwclondon/",
    "published": "2019-08-21T18:37:56+00:00",
    "content": {
        "html": "Showing IndieAuth and Micropub at HWCLondon!",
        "text": "Showing IndieAuth and Micropub at HWCLondon!"
    },
    "post-type": "note",
    "_id": "4973134",
    "_source": "1895",
    "_is_read": true
}

{
    "type": "entry",
    "published": "2019-08-21T13:52:01.50788-07:00",
    "url": "https://v2.jacky.wtf/post/7c5536af-9925-4675-92af-d0b77393e3fc",
    "in-reply-to": [
        "https://beesbuzz.biz/blog/chatter/8726-Re-Intermediate-auth-service"
    ],
    "content": {
        "text": "Haha, yup! That said, I\u2019ll definitely ping you (and drop it in the IndieWeb chat) when I get this base-line system going. Going to tear down what I have with https://fortress.black.af to focus on this.",
        "html": "<p>Haha, yup! That said, I\u2019ll definitely ping you (and drop it in the IndieWeb chat) when I get this base-line system going. Going to tear down what I have with <a href=\"https://fortress.black.af\">https://fortress.black.af</a> to focus on this.</p>"
    },
    "post-type": "reply",
    "refs": {
        "https://beesbuzz.biz/blog/chatter/8726-Re-Intermediate-auth-service": {
            "type": "entry",
            "url": "https://beesbuzz.biz/blog/chatter/8726-Re-Intermediate-auth-service",
            "name": "Re: Intermediate auth service",
            "post-type": "article"
        }
    },
    "_id": "4972100",
    "_source": "1886",
    "_is_read": true
}

Tantek Çelik tantek.com

IndieWebCamps Timeline 2011-2019: Amsterdam to Utrecht

{
    "type": "entry",
    "published": "2019-08-16 14:21-0700",
    "url": "http://tantek.com/2019/228/b1/indiewebcamps-timeline-amsterdam-utrecht",
    "name": "IndieWebCamps Timeline 2011-2019: Amsterdam to Utrecht",
    "content": {
        "text": "While not a post directly about IndieWeb Summit 2019, this post provides a bit of background and is certainly related, so I\u2019m including it in my series of posts about the Summit. Previous post in this series: Reflecting On IndieWeb Summit: A Start\n\n\nAt the beginning of IndieWeb Summit 2019, I gave a brief talk on \nState of the IndieWeb and mentioned that:\n\nWe've scheduled lots of IndieWebCamps this year and are on track to schedule a record number of different cities as well.\n\nI had conceived of a graphical representation of the growth of IndieWebCamps over the past nine years, both in number and across the world, but with everything else involved with setting up and running the Summit, ran out of time. However, the idea persisted, and finally this past week, with a little help from Aaron Parecki re-implementing Dopplr\u2019s algorithm for turning city names into colors, was able to put togther something pretty close to what I\u2019d envisioned:\n\nIstanbul\n\n\u00a0\n\nAmsterdam\n\n\u00a0\nUtrecht\n\n\u00a0\nN\u00fcrnberg\n\n\u00a0\n\u00a0\n\u00a0\n\nD\u00fcsseldorf\n\n\u00a0\n\u00a0\n\u00a0\n\u00a0\n\u00a0\nBerlin\n\n\u00a0\n\n\u00a0\n\u00a0\n\u00a0\n\u00a0\nEdinburgh\n\n\u00a0\n\nOxford\n\n\u00a0\n\u00a0\nBrighton\n\n\u00a0\n\u00a0\n\u00a0\n\u00a0\n\u00a0\n\n\u00a0\nNew Haven\n\n\u00a0\nBaltimore\n\n\u00a0\n\nCambridge\n\n\u00a0\n\u00a0\n\u00a0\n\nNew York\n\n\u00a0\n\n\u00a0\n\u00a0\n\u00a0\n\u00a0\nAustin\n\n\u00a0\n\n\u00a0\nBellingham\n\n\u00a0\n\nLos Angeles\n\n\u00a0\n\n\u00a0\n\nSan Francisco\n\n\u00a0\n\u00a0\n\n\u00a0\n\nPortland\n\u00a0\n\u00a0\n\u00a0\n\u00a0\n\u00a0\n\u00a0\n\u00a0\n\u00a0\n\u00a0\n\n2011\n2012\n2013\n2014\n2015\n2016\n2017\n2018\n2019\n\nI don\u2019t know of any tools to take something like this kind of locations vs years data and graph it as such. So I built an HTML table with a cell for each IndieWebCamp, as well as cells for the colspans of empty space. Each colored cell is hyperlinked to the IndieWebCamp for that city for that year.\n\n\n2011-2018 and over half of 2019 are IndieWebCamps (and Summits) that have already happened. 2019 includes bars for four upcoming IndieWebCamps, which are fully scheduled and open for sign-ups. \n\nThe table markup is copy pasted from the \nIndieWebCamp wiki template where I built it, and you can see the template working live in the context of the IndieWebCamp Cities page. I\u2019m sure the markup could be improved, suggestions welcome!",
        "html": "<p>\nWhile not a post directly about <a href=\"https://indieweb.org/2019/\">IndieWeb Summit 2019</a>, this post provides a bit of background and is certainly related, so I\u2019m including it in my series of posts about the Summit. Previous post in this series: <a href=\"https://tantek.com/2019/217/b1/indieweb-summit-2019-start\">Reflecting On IndieWeb Summit: A Start</a>\n</p>\n<p>\nAt the beginning of <a href=\"https://indieweb.org/2019/\">IndieWeb Summit 2019</a>, I gave a brief talk on \n<a href=\"https://indieweb.org/2019/state-of-the-indieweb\">State of the IndieWeb</a> and mentioned that:\n</p>\n<blockquote>We've scheduled lots of IndieWebCamps this year and are on track to schedule a record number of different cities as well.</blockquote>\n<p>\nI had conceived of a graphical representation of the growth of IndieWebCamps over the past nine years, both in number and across the world, but with everything else involved with setting up and running the Summit, ran out of time. However, the idea persisted, and finally this past week, with a little help from <a class=\"h-card\" href=\"https://aaronparecki.com/\">Aaron Parecki</a> re-implementing Dopplr\u2019s algorithm for turning city names into colors, was able to put togther something pretty close to what I\u2019d envisioned:\n</p>\n<a href=\"https://indieweb.org/Istanbul\" title=\"Istanbul\">Istanbul</a>\n\n<a href=\"https://indieweb.org/2017/Istanbul\" title=\"2017/Istanbul\">\u00a0</a>\n\n<a href=\"https://indieweb.org/Amsterdam\" title=\"Amsterdam\">Amsterdam</a>\n\n<a href=\"https://indieweb.org/2019/Amsterdam\" title=\"2019/Amsterdam\">\u00a0</a>\n<a href=\"https://indieweb.org/Utrecht\" title=\"Utrecht\">Utrecht</a>\n\n<a href=\"https://indieweb.org/2019/Utrecht\" title=\"2019/Utrecht\">\u00a0</a>\n<a href=\"https://indieweb.org/N%C3%BCrnberg\" title=\"N\u00fcrnberg\">N\u00fcrnberg</a>\n\n<a href=\"https://indieweb.org/2016/Nuremberg\" title=\"2016/Nuremberg\">\u00a0</a>\n<a href=\"https://indieweb.org/2017/Nuremberg\" title=\"2017/Nuremberg\">\u00a0</a>\n<a href=\"https://indieweb.org/2018/Nuremberg\" title=\"2018/Nuremberg\">\u00a0</a>\n\n<a href=\"https://indieweb.org/D%C3%BCsseldorf\" title=\"D\u00fcsseldorf\">D\u00fcsseldorf</a>\n\n<a href=\"https://indieweb.org/2015/D%C3%BCsseldorf\" title=\"2015/D\u00fcsseldorf\">\u00a0</a>\n<a href=\"https://indieweb.org/2016/D%C3%BCsseldorf\" title=\"2016/D\u00fcsseldorf\">\u00a0</a>\n<a href=\"https://indieweb.org/2017/D%C3%BCsseldorf\" title=\"2017/D\u00fcsseldorf\">\u00a0</a>\n<a href=\"https://indieweb.org/2018/D%C3%BCsseldorf\" title=\"2018/D\u00fcsseldorf\">\u00a0</a>\n<a href=\"https://indieweb.org/2019/D%C3%BCsseldorf\" title=\"2019/D\u00fcsseldorf\">\u00a0</a>\n<a href=\"https://indieweb.org/Berlin\" title=\"Berlin\">Berlin</a>\n\n<a href=\"https://indieweb.org/2014/Berlin\" title=\"2014/Berlin\">\u00a0</a>\n\n<a href=\"https://indieweb.org/2016/Berlin\" title=\"2016/Berlin\">\u00a0</a>\n<a href=\"https://indieweb.org/2017/Berlin\" title=\"2017/Berlin\">\u00a0</a>\n<a href=\"https://indieweb.org/2018/Berlin\" title=\"2018/Berlin\">\u00a0</a>\n<a href=\"https://indieweb.org/2019/Berlin\" title=\"2019/Berlin\">\u00a0</a>\n<a href=\"https://indieweb.org/Edinburgh\" title=\"Edinburgh\">Edinburgh</a>\n\n<a href=\"https://indieweb.org/2015/Edinburgh\" title=\"2015/Edinburgh\">\u00a0</a>\n\n<a href=\"https://indieweb.org/Oxford\" title=\"Oxford\">Oxford</a>\n\n<a href=\"https://indieweb.org/2018/Oxford\" title=\"2018/Oxford\">\u00a0</a>\n<a href=\"https://indieweb.org/2019/Oxford\" title=\"2019/Oxford\">\u00a0</a>\n<a href=\"https://indieweb.org/Brighton\" title=\"Brighton\">Brighton</a>\n\n<a href=\"https://indieweb.org/2012/Brighton\" title=\"2012/Brighton\">\u00a0</a>\n<a href=\"https://indieweb.org/2013/Brighton\" title=\"2013/Brighton\">\u00a0</a>\n<a href=\"https://indieweb.org/2014/Brighton\" title=\"2014/Brighton\">\u00a0</a>\n<a href=\"https://indieweb.org/2015/Brighton\" title=\"2015/Brighton\">\u00a0</a>\n<a href=\"https://indieweb.org/2016/Brighton\" title=\"2016/Brighton\">\u00a0</a>\n\n<a href=\"https://indieweb.org/2019/Brighton\" title=\"2019/Brighton\">\u00a0</a>\n<a href=\"https://indieweb.org/New_Haven\" title=\"New Haven\">New Haven</a>\n\n<a href=\"https://indieweb.org/2019/New_Haven\" title=\"2019/New Haven\">\u00a0</a>\n<a href=\"https://indieweb.org/Baltimore\" title=\"Baltimore\">Baltimore</a>\n\n<a href=\"https://indieweb.org/2018/Baltimore\" title=\"2018/Baltimore\">\u00a0</a>\n\n<a href=\"https://indieweb.org/Cambridge\" title=\"Cambridge\">Cambridge</a>\n\n<a href=\"https://indieweb.org/2014/Cambridge\" title=\"2014/Cambridge\">\u00a0</a>\n<a href=\"https://indieweb.org/2015/Cambridge\" title=\"2015/Cambridge\">\u00a0</a>\n<a href=\"https://indieweb.org/wiki/index.php?title=2016/Cambridge&amp;action=edit&amp;redlink=1\" title=\"2016/Cambridge (page does not exist)\">\u00a0</a>\n\n<a href=\"https://indieweb.org/New_York\" title=\"New York\">New York</a>\n\n<a href=\"https://indieweb.org/2014/NYC\" title=\"2014/NYC\">\u00a0</a>\n\n<a href=\"https://indieweb.org/2016/NYC\" title=\"2016/NYC\">\u00a0</a>\n<a href=\"https://indieweb.org/2017/NYC\" title=\"2017/NYC\">\u00a0</a>\n<a href=\"https://indieweb.org/2018/NYC\" title=\"2018/NYC\">\u00a0</a>\n<a href=\"https://indieweb.org/2019/NYC\" title=\"2019/NYC\">\u00a0</a>\n<a href=\"https://indieweb.org/Austin\" title=\"Austin\">Austin</a>\n\n<a href=\"https://indieweb.org/2017/Austin\" title=\"2017/Austin\">\u00a0</a>\n\n<a href=\"https://indieweb.org/2019/Austin\" title=\"2019/Austin\">\u00a0</a>\n<a href=\"https://indieweb.org/Bellingham\" title=\"Bellingham\">Bellingham</a>\n\n<a href=\"https://indieweb.org/2017/Bellingham\" title=\"2017/Bellingham\">\u00a0</a>\n\n<a href=\"https://indieweb.org/Los_Angeles\" title=\"Los Angeles\">Los Angeles</a>\n\n<a href=\"https://indieweb.org/wiki/index.php?title=2013/Los_Angeles&amp;action=edit&amp;redlink=1\" title=\"2013/Los Angeles (page does not exist)\">\u00a0</a>\n\n<a href=\"https://indieweb.org/2016/Santa_Monica\" title=\"2016/Santa Monica\">\u00a0</a>\n\n<a href=\"https://indieweb.org/San_Francisco\" title=\"San Francisco\">San Francisco</a>\n\n<a href=\"https://indieweb.org/2014/SF\" title=\"2014/SF\">\u00a0</a>\n<a href=\"https://indieweb.org/2015/SF\" title=\"2015/SF\">\u00a0</a>\n\n<a href=\"https://indieweb.org/2018/SF\" title=\"2018/SF\">\u00a0</a>\n\n<a href=\"https://indieweb.org/Portland\" title=\"Portland\">Portland</a>\n<a href=\"https://indieweb.org/2011\" title=\"2011\">\u00a0</a>\n<a href=\"https://indieweb.org/2012\" title=\"2012\">\u00a0</a>\n<a href=\"https://indieweb.org/2013\" title=\"2013\">\u00a0</a>\n<a href=\"https://indieweb.org/2014\" title=\"2014\">\u00a0</a>\n<a href=\"https://indieweb.org/2015\" title=\"2015\">\u00a0</a>\n<a href=\"https://indieweb.org/2016\" title=\"2016\">\u00a0</a>\n<a href=\"https://indieweb.org/2017\" title=\"2017\">\u00a0</a>\n<a href=\"https://indieweb.org/2018\" title=\"2018\">\u00a0</a>\n<a href=\"https://indieweb.org/2019\" title=\"2019\">\u00a0</a>\n\n<a href=\"https://indieweb.org/2011\" title=\"2011\">2011</a>\n<a href=\"https://indieweb.org/2012\" title=\"2012\">2012</a>\n<a href=\"https://indieweb.org/2013\" title=\"2013\">2013</a>\n<a href=\"https://indieweb.org/2014\" title=\"2014\">2014</a>\n<a href=\"https://indieweb.org/2015\" title=\"2015\">2015</a>\n<a href=\"https://indieweb.org/2016\" title=\"2016\">2016</a>\n<a href=\"https://indieweb.org/2017\" title=\"2017\">2017</a>\n<a href=\"https://indieweb.org/2018\" title=\"2018\">2018</a>\n<a href=\"https://indieweb.org/2019\" title=\"2019\">2019</a>\n<p>\nI don\u2019t know of any tools to take something like this kind of locations vs years data and graph it as such. So I built an HTML table with a cell for each IndieWebCamp, as well as cells for the colspans of empty space. Each colored cell is hyperlinked to the IndieWebCamp for that city for that year.\n</p>\n<p>\n2011-2018 and over half of 2019 are IndieWebCamps (and Summits) that have already happened. 2019 includes bars for <a href=\"https://tantek.com/2019/221/t1/four-indiewebcamps-open-sign-ups\">four upcoming IndieWebCamps, which are fully scheduled and open for sign-ups</a>. \n</p>\n<p>The table markup is copy pasted from the \n<a href=\"https://indieweb.org/Template:indiewebcamps-timeline\">IndieWebCamp wiki template</a> where I built it, and you can see the template working live in the context of the <a href=\"https://indieweb.org/cities\">IndieWebCamp Cities</a> page. I\u2019m sure the markup could be improved, suggestions welcome!\n</p>"
    },
    "author": {
        "type": "card",
        "name": "Tantek \u00c7elik",
        "url": "http://tantek.com/",
        "photo": "https://aperture-media.p3k.io/tantek.com/acfddd7d8b2c8cf8aa163651432cc1ec7eb8ec2f881942dca963d305eeaaa6b8.jpg"
    },
    "post-type": "article",
    "_id": "4920629",
    "_source": "1",
    "_is_read": true
}

Matthias Pfefferle notiz.blog/author/matthias-pfefferle/

{
    "type": "entry",
    "published": "2019-08-16T14:54:56+02:00",
    "summary": "SemPress war das erste WordPress Theme (September 2002), das Microformats 2 unterst\u00fctzte und somit voll IndieWeb-kompatibel war. Seit ein paar Monaten/Jahren gibt es zwar weitere Themes die MF2 unterst\u00fctzen, aber SemPress ist seit fast 7 Jahren (Dezember 2002) immer noch das einzige, das \u00fcber WordPress.org installierbar (ist das ein Wort?) ist.\nPrateek Saxena arbeitet gerade daran, das zu \u00e4ndern! Sein Theme ist seit diesem Jahr auf WordPress.org und er arbeitet flei\u00dfig am MF2 Support.\n`war ne lange Zeit \ud83d\ude42",
    "url": "https://notiz.blog/2019/08/16/the-first-microformats2-wp-theme/",
    "content": {
        "text": "SemPress war das erste WordPress Theme (September 2002), das Microformats 2 unterst\u00fctzte und somit voll IndieWeb-kompatibel war. Seit ein paar Monaten/Jahren gibt es zwar weitere Themes die MF2 unterst\u00fctzen, aber SemPress ist seit fast 7 Jahren (Dezember 2002) immer noch das einzige, das \u00fcber WordPress.org installierbar (ist das ein Wort?) ist.\n\n\n\nPrateek Saxena arbeitet gerade daran, das zu \u00e4ndern! Sein Theme ist seit diesem Jahr auf WordPress.org und er arbeitet flei\u00dfig am MF2 Support.\n\n\n\n`war ne lange Zeit \ud83d\ude42",
        "html": "<p><a href=\"https://notiz.blog/projects/sempress/\">SemPress</a> war das erste WordPress Theme (<a href=\"https://notiz.blog/2012/09/06/ive-made-a-wordpress-theme-kind-of/\">September 2002</a>), das <a href=\"https://indieweb.org/microformats2\">Microformats 2</a> unterst\u00fctzte und somit voll IndieWeb-kompatibel war. Seit ein paar Monaten/Jahren gibt es zwar <a href=\"https://indieweb.org/WordPress/Themes#Themes_Supporting_Microformats\">weitere Themes die MF2 unterst\u00fctzen</a>, aber SemPress ist seit fast 7 Jahren (<a href=\"https://notiz.blog/2012/12/07/sempress-auf-wordpress-org/\">Dezember 2002</a>) immer noch das einzige, das \u00fcber <a href=\"https://wordpress.org/themes/sempress/\">WordPress.org</a> installierbar (ist das ein Wort?) ist.</p>\n\n\n\n<p><a href=\"https://prtksxna.com/\">Prateek Saxena</a> arbeitet gerade daran, das zu \u00e4ndern! Sein Theme ist seit diesem Jahr auf <a href=\"https://wordpress.org/themes/zuari/\">WordPress.org</a> und er arbeitet flei\u00dfig am <a href=\"https://github.com/prtksxna/zuari/commit/ff5374b062620635ce31e4e368980ed23d85b0c3\">MF2 Support</a>.</p>\n\n\n\n<p>`war ne lange Zeit \ud83d\ude42</p>"
    },
    "author": {
        "type": "card",
        "name": "Matthias Pfefferle",
        "url": "https://notiz.blog/author/matthias-pfefferle/",
        "photo": "https://secure.gravatar.com/avatar/75512bb584bbceae57dfc503692b16b2?s=40&d=https://notiz.blog/wp-content/plugins/semantic-linkbacks/img/mm.jpg&r=g"
    },
    "post-type": "note",
    "_id": "4915105",
    "_source": "206",
    "_is_read": true
}

Homebrew Website Club SF!

{
    "type": "event",
    "name": "Homebrew Website Club SF!",
    "summary": "Homebrew Website Club retro 1980s-style logo.\nTopics for this week: IndieWeb Summit Notes & Videos! Sign-up for Upcoming IndieWebCamps! \u274c IndieWebCamp Amsterdam \ud83c\udfeb IndieWebCamp Oxford \ud83d\uddfd IndieWebCamp New York City \ud83c\udfaa IndieWebCamp Brighton 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": "2019-08-15 18:51-0700",
    "start": "2019-08-21 17:30-0700",
    "end": "2019-08-21 18:30-0700",
    "url": "http://tantek.com/2019/233/e1/homebrew-website-club-sf",
    "location": [
        "https://wiki.mozilla.org/SF"
    ],
    "content": {
        "text": "When: 2019-08-21 17:30\u202618:30\nWhere: Mozilla San Francisco\n\nHost: Tantek \u00c7elik\n\n\n \nTopics for this week:\nIndieWeb Summit Notes & Videos!\nSign-up for Upcoming IndieWebCamps!\n\u274c  IndieWebCamp Amsterdam\n\ud83c\udfeb IndieWebCamp Oxford\n\ud83d\uddfd IndieWebCamp New York City\n\ud83c\udfaa IndieWebCamp Brighton\n\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\">2019-08-21 17:30</time>\u2026<time class=\"dt-end\">18: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><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>IndieWeb Summit <a href=\"https://indieweb.org/2019/Schedule\">Notes &amp; Videos</a>!</li>\n<li>Sign-up for Upcoming IndieWebCamps!\n<ul><li><a href=\"https://indieweb.org/2019/Amsterdam\">\u274c  IndieWebCamp Amsterdam</a></li>\n<li><a href=\"https://indieweb.org/2019/Oxford\">\ud83c\udfeb IndieWebCamp Oxford</a></li>\n<li><a href=\"https://indieweb.org/2019/NYC\">\ud83d\uddfd IndieWebCamp New York City</a></li>\n<li><a href=\"https://indieweb.org/2019/Brighton\">\ud83c\udfaa IndieWebCamp Brighton</a></li>\n</ul></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/2019-08-21-homebrew-website-club\">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": "4909533",
    "_source": "1",
    "_is_read": true
}

A journey to the underworld that is RDF

{
    "type": "entry",
    "author": {
        "name": "Peter Molnar",
        "url": "https://petermolnar.net/feed/",
        "photo": null
    },
    "url": "https://petermolnar.net/web-of-the-machines/",
    "published": "2019-02-10T20:10:00+00:00",
    "content": {
        "html": "<img src=\"https://aperture-proxy.p3k.io/47c1a335655f3ed264b3b656498183412096113c/68747470733a2f2f70657465726d6f6c6e61722e6e65742f7765622d6f662d7468652d6d616368696e65732f7264662d69742d646f65732d6e6f742d737061726b2d6a6f792e6a7067\" title=\"rdf-it-does-not-spark-joy\" alt=\"rdf-it-does-not-spark-joy\" />\nworking with RDF - this one does not spark joy\n<p>I want to say it all started with a rather offensive tweet<a href=\"https://petermolnar.net/feed/#fn1\">1</a>, but it wouldn't be true. No, it all started with my curiosity to please the Google Structured Data testing tool<a href=\"https://petermolnar.net/feed/#fn2\">2</a>. Last year, in August, I added microdata<a href=\"https://petermolnar.net/feed/#fn3\">3</a> to my website - it was more or less straightforward to do so.</p>\n<p>Except it was ugly, and, after half a year, I'm certain to say, quite useless. I got no pretty Google cards - maybe because I refuse to do AMP<a href=\"https://petermolnar.net/feed/#fn4\">4</a>, maybe because I'm not important enough, who knows. But by the time I was reaching this conclusion, that aforementioned tweet happened, and I got caught up in Semantic Hell, also known as arguing about RDF.</p>\n<p>The first time I heard about the Semantic Web collided with the dawn of the web 2.0 hype, so it wasn't hard to dismiss it when so much was happening. I was rather new to the whole web thing, and most of the academic discussions were not even available in Hungarian.</p>\n<p>In that thread, it pointed was out to me that what I have on my site is microdata, not RDFa - I genuinely thought they are more or less interchangeable: both can use the same vocabulary, so it shouldn't really matter which HTML properties I use, should it? Well, it does, but I believe the basis for my confusion can be found in the microdata description: it was an initiative to make RDF simple enough for people making websites.</p>\n<p>If you're just as confused as I was, in my own words:</p>\n<ul><li><strong>RDF</strong> is a ruleset framework, which is <strong>only used to describe sets of rules</strong></li>\n<li>these rules are named <strong>vocabularies</strong>: Schema.org, Dublin Core, Open Graph (<em>the not-invented-here is strong in Facebook</em>), FOAF (<em>for the sake of your own sanity, don't read the FOAF doc, unless you already know how to greet Shub-Niggurath or what geekcode is/was</em>), etc</li>\n<li>if you try to use multiple vocabularies at once - which you can -, it will be incredibly hard to remember when to use what</li>\n<li>a vocabulary is what you can actually add to your data - machines then go to the RDF definition of the vocabulary make databases out of the data</li>\n<li><strong>microdata</strong> is <code>itemprop</code>, <code>itemscope</code>, <code>itemtype</code> and <code>itemref</code> HTML5 attributes</li>\n<li>whereas <strong>RDFa</strong> is <code>vocab</code>, <code>typeof</code>, <code>property</code> HTML5 attributes</li>\n<li>if you want to please academics or some sort of internal tool that is built to utilize RDF, use RDFa - I keep asking if RDFa vocabularies, such as Dublin Core, are consumed by anything on the public internet, but I keep getting answers<a href=\"https://petermolnar.net/feed/#fn5\">5</a> with no actual answers</li>\n<li>if you're doing this for a search engine, stick to microdata, it's less prone to errors</li>\n<li>... or instead of both, just do <strong>JSON-LD</strong>, which is JSON with special keys: <code>@context</code>, which points to a vocabulary, and <code>@type</code>, which points you to a vocabulary element, and these two define what your data keys should be named and what kind of data they might contain</li>\n</ul><p>With all this now known, I tried to turn mark up my content as microformats v1, microformats v2, and RDFa.</p>\n<p>I already had errors with microdata...</p>\n<a href=\"https://petermolnar.net/web-of-the-machines/gsdtt_microdata_error_01_b.png\"> <img src=\"https://aperture-proxy.p3k.io/ac2aee208cce936e718df92f11e04a4e38a3c059/68747470733a2f2f70657465726d6f6c6e61722e6e65742f7765622d6f662d7468652d6d616368696e65732f67736474745f6d6963726f646174615f6572726f725f30312e706e67\" title=\"gsdtt_microdata_error_01\" alt=\"gsdtt_microdata_error_01\" /></a>\n\nInteresting, it has some problems...\n<a href=\"https://petermolnar.net/web-of-the-machines/gsdtt_microdata_error_02_b.png\"> <img src=\"https://aperture-proxy.p3k.io/370f10a7e762e6ccaf4328b04e30a76b1225a8cb/68747470733a2f2f70657465726d6f6c6e61722e6e65742f7765622d6f662d7468652d6d616368696e65732f67736474745f6d6963726f646174615f6572726f725f30322e706e67\" title=\"gsdtt_microdata_error_02\" alt=\"gsdtt_microdata_error_02\" /></a>\n\nit says URL for org is missing... it's there. Line 13.\n<p>...but those errors then became ever more peculiar problems with RDFa...</p>\n<a href=\"https://petermolnar.net/web-of-the-machines/gsdtt_rdfa_error_01_b.png\"> <img src=\"https://aperture-proxy.p3k.io/2607fbcfb0443d64c6e219c30c26bc397bf8276c/68747470733a2f2f70657465726d6f6c6e61722e6e65742f7765622d6f662d7468652d6d616368696e65732f67736474745f726466615f6572726f725f30312e706e67\" title=\"gsdtt_rdfa_error_01\" alt=\"gsdtt_rdfa_error_01\" /></a>\n\nUndefined type, eh?\n<a href=\"https://petermolnar.net/web-of-the-machines/gsdtt_rdfa_error_02_b.png\"> <img src=\"https://aperture-proxy.p3k.io/c8a01ebee0bdc161376d425b7fe921e926836a27/68747470733a2f2f70657465726d6f6c6e61722e6e65742f7765622d6f662d7468652d6d616368696e65732f67736474745f726466615f6572726f725f30322e706e67\" title=\"gsdtt_rdfa_error_02\" alt=\"gsdtt_rdfa_error_02\" /></a>\n\nwat\n<p>... while microformats v1 was parsed without any glitches. <em>Sidenote: <strong>microformats</strong> (v1 and v2), unlike the previous things, are extra HTML <code>class</code> data, and v1 is still parsed by most search engines.</em></p>\n<p><strong>At this point I gave up on RDFa and moved over to test JSON-LD.</strong></p>\n<p>It's surprisingly easy to represent data in JSON-LD with schema.org context (<em>vocabulary, why on earth was vocabulary renamed to context?! Oh. Because we're in hell.</em>). There's a long entry about why JSON-LD happened<a href=\"https://petermolnar.net/feed/#fn6\">6</a> and it has a lot of reasonable points.</p>\n<p>What it forgets to talk about is that JSON-LD is an invisible duplication of what is either already or what should be in HTML. It's a decent way to store data, to exchange data, but not to present it to someone on the other end of the cable.</p>\n<p>The most common JSON-LD vocabulary, Schema.org has it's own interesting world of problems. It wants to be a single point of entry, one gigantic vocabulary, for anything web, a humongous task and noble goal. However, it's still lacking a lot of definitions (<em>ever tried to represent a resume with it?</em>), it has weird quirks (<em>'follows' on a Person can only be another Person, it can't be a Brand, a WebSite, or a simple URL</em>) and it's driven heavily by Google (<em>most people working on it are working at Google</em>).</p>\n<p>I ended up with compromises.</p>\n<pre><code>&lt;html lang=\"en\"  prefix=\"og: http://ogp.me/ns# article: http://ogp.me/ns/article#\"&gt;\n&lt;head&gt;\n    &lt;title&gt;A piece of Powerscourt Waterfall - petermolnar.net&lt;/title&gt;\n&lt;!-- JSON-LD as alternative --&gt;\n    &lt;link rel=\"alternate\" type=\"application/json\" title=\"a-piece-of-powerscourt-waterfall JSON-LD\" href=\"https://petermolnar.net/a-piece-of-powerscourt-waterfall/index.json\" /&gt;\n&lt;!-- Open Graph vocabulary RDFa --&gt;\n    &lt;meta property=\"og:title\" content=\"A piece of Powerscourt Waterfall\" /&gt;\n    &lt;meta property=\"og:type\" content=\"article\" /&gt;\n    &lt;meta property=\"og:url\" content=\"https://petermolnar.net/a-piece-of-powerscourt-waterfall/\" /&gt;\n    &lt;meta property=\"og:description\" content=\"\" /&gt;\n    &lt;meta property=\"article:published_time\" content=\"2017-11-09T18:00:00+00:00\" /&gt;\n    &lt;meta property=\"article:modified_time\" content=\"2019-01-05T11:52:47.543053+00:00\" /&gt;\n    &lt;meta property=\"article:author\" content=\"Peter Molnar (mail@petermolnar.net)\" /&gt;\n    &lt;meta property=\"og:image\" content=\"https://petermolnar.net/a-piece-of-powerscourt-waterfall/a-piece-of-powerscourt-waterfall_b.jpg\" /&gt;\n    &lt;meta property=\"og:image:type\" content=\"image/jpeg\" /&gt;\n    &lt;meta property=\"og:image:width\" content=\"1280\" /&gt;\n    &lt;meta property=\"og:image:height\" content=\"847\" /&gt;\n&lt;!-- the rest of meta and header elements --&gt;\n&lt;!-- followed by the content, with microformats v1 and v2 markup --&gt;</code></pre>\n<p>HTML provides an interesting functionality, the <code>rel=alternate</code>. This is meant to be the representation of the same data, but in another format. The most common use is links to RSS and Atom feeds.</p>\n<p>I don't know if Google will consume the JSON-LD alternate format, but it's there, and anyone can easily use it.</p>\n<p>As for RDFa, I turned to <code>meta</code> elements. Unlike with JSON-LD, I decided to use the extremely simple vocabulary of Open Graph - at least Facebook is known to consume that.</p>\n<p><strong>The tragedy of this whole story: HTML5 has so many tags that is should be possible to do structured data without any need for any of the things above.</strong></p>\n<p>My content is now:</p>\n<ul><li>microformats v1 and v2 within the visible content</li>\n<li>a minimal RDFa in <code>meta</code> tags</li>\n<li>a sidecar JSON-LD version</li>\n</ul><p>This way it's simple, but compatible enough for most cases.</p>\n\n\n<ol><li><p><a href=\"http://web.archive.org/web/20190211232147/https:/twitter.com/csarven/status/1091314310465421312\">http://web.archive.org/web/20190211232147/https:/twitter.com/csarven/status/1091314310465421312</a><a href=\"https://petermolnar.net/feed/#fnref1\">\u21a9</a></p></li>\n<li><p><a href=\"https://search.google.com/structured-data/testing-tool\">https://search.google.com/structured-data/testing-tool</a><a href=\"https://petermolnar.net/feed/#fnref2\">\u21a9</a></p></li>\n<li><p><a href=\"https://github.com/petermolnar/nasg/commit/9c749f4591333744588bdf183b22ba638babcb20\">https://github.com/petermolnar/nasg/commit/9c749f4591333744588bdf183b22ba638babcb20</a><a href=\"https://petermolnar.net/feed/#fnref3\">\u21a9</a></p></li>\n<li><p><a href=\"https://www.ampproject.org/\">https://www.ampproject.org/</a><a href=\"https://petermolnar.net/feed/#fnref4\">\u21a9</a></p></li>\n<li><p><a href=\"https://web.archive.org/web/20190203123749/https://twitter.com/RubenVerborgh/status/1092029740364587008\">https://web.archive.org/web/20190203123749/https://twitter.com/RubenVerborgh/status/1092029740364587008</a><a href=\"https://petermolnar.net/feed/#fnref5\">\u21a9</a></p></li>\n<li><p><a href=\"http://manu.sporny.org/2014/json-ld-origins-2/\">http://manu.sporny.org/2014/json-ld-origins-2/</a><a href=\"https://petermolnar.net/feed/#fnref6\">\u21a9</a></p></li>\n</ol>",
        "text": "working with RDF - this one does not spark joy\nI want to say it all started with a rather offensive tweet1, but it wouldn't be true. No, it all started with my curiosity to please the Google Structured Data testing tool2. Last year, in August, I added microdata3 to my website - it was more or less straightforward to do so.\nExcept it was ugly, and, after half a year, I'm certain to say, quite useless. I got no pretty Google cards - maybe because I refuse to do AMP4, maybe because I'm not important enough, who knows. But by the time I was reaching this conclusion, that aforementioned tweet happened, and I got caught up in Semantic Hell, also known as arguing about RDF.\nThe first time I heard about the Semantic Web collided with the dawn of the web 2.0 hype, so it wasn't hard to dismiss it when so much was happening. I was rather new to the whole web thing, and most of the academic discussions were not even available in Hungarian.\nIn that thread, it pointed was out to me that what I have on my site is microdata, not RDFa - I genuinely thought they are more or less interchangeable: both can use the same vocabulary, so it shouldn't really matter which HTML properties I use, should it? Well, it does, but I believe the basis for my confusion can be found in the microdata description: it was an initiative to make RDF simple enough for people making websites.\nIf you're just as confused as I was, in my own words:\nRDF is a ruleset framework, which is only used to describe sets of rules\nthese rules are named vocabularies: Schema.org, Dublin Core, Open Graph (the not-invented-here is strong in Facebook), FOAF (for the sake of your own sanity, don't read the FOAF doc, unless you already know how to greet Shub-Niggurath or what geekcode is/was), etc\nif you try to use multiple vocabularies at once - which you can -, it will be incredibly hard to remember when to use what\na vocabulary is what you can actually add to your data - machines then go to the RDF definition of the vocabulary make databases out of the data\nmicrodata is itemprop, itemscope, itemtype and itemref HTML5 attributes\nwhereas RDFa is vocab, typeof, property HTML5 attributes\nif you want to please academics or some sort of internal tool that is built to utilize RDF, use RDFa - I keep asking if RDFa vocabularies, such as Dublin Core, are consumed by anything on the public internet, but I keep getting answers5 with no actual answers\nif you're doing this for a search engine, stick to microdata, it's less prone to errors\n... or instead of both, just do JSON-LD, which is JSON with special keys: @context, which points to a vocabulary, and @type, which points you to a vocabulary element, and these two define what your data keys should be named and what kind of data they might contain\nWith all this now known, I tried to turn mark up my content as microformats v1, microformats v2, and RDFa.\nI already had errors with microdata...\n \n\nInteresting, it has some problems...\n \n\nit says URL for org is missing... it's there. Line 13.\n...but those errors then became ever more peculiar problems with RDFa...\n \n\nUndefined type, eh?\n \n\nwat\n... while microformats v1 was parsed without any glitches. Sidenote: microformats (v1 and v2), unlike the previous things, are extra HTML class data, and v1 is still parsed by most search engines.\nAt this point I gave up on RDFa and moved over to test JSON-LD.\nIt's surprisingly easy to represent data in JSON-LD with schema.org context (vocabulary, why on earth was vocabulary renamed to context?! Oh. Because we're in hell.). There's a long entry about why JSON-LD happened6 and it has a lot of reasonable points.\nWhat it forgets to talk about is that JSON-LD is an invisible duplication of what is either already or what should be in HTML. It's a decent way to store data, to exchange data, but not to present it to someone on the other end of the cable.\nThe most common JSON-LD vocabulary, Schema.org has it's own interesting world of problems. It wants to be a single point of entry, one gigantic vocabulary, for anything web, a humongous task and noble goal. However, it's still lacking a lot of definitions (ever tried to represent a resume with it?), it has weird quirks ('follows' on a Person can only be another Person, it can't be a Brand, a WebSite, or a simple URL) and it's driven heavily by Google (most people working on it are working at Google).\nI ended up with compromises.\n<html lang=\"en\"  prefix=\"og: http://ogp.me/ns# article: http://ogp.me/ns/article#\">\n<head>\n    <title>A piece of Powerscourt Waterfall - petermolnar.net</title>\n<!-- JSON-LD as alternative -->\n    <link rel=\"alternate\" type=\"application/json\" title=\"a-piece-of-powerscourt-waterfall JSON-LD\" href=\"https://petermolnar.net/a-piece-of-powerscourt-waterfall/index.json\" />\n<!-- Open Graph vocabulary RDFa -->\n    <meta property=\"og:title\" content=\"A piece of Powerscourt Waterfall\" />\n    <meta property=\"og:type\" content=\"article\" />\n    <meta property=\"og:url\" content=\"https://petermolnar.net/a-piece-of-powerscourt-waterfall/\" />\n    <meta property=\"og:description\" content=\"\" />\n    <meta property=\"article:published_time\" content=\"2017-11-09T18:00:00+00:00\" />\n    <meta property=\"article:modified_time\" content=\"2019-01-05T11:52:47.543053+00:00\" />\n    <meta property=\"article:author\" content=\"Peter Molnar (mail@petermolnar.net)\" />\n    <meta property=\"og:image\" content=\"https://petermolnar.net/a-piece-of-powerscourt-waterfall/a-piece-of-powerscourt-waterfall_b.jpg\" />\n    <meta property=\"og:image:type\" content=\"image/jpeg\" />\n    <meta property=\"og:image:width\" content=\"1280\" />\n    <meta property=\"og:image:height\" content=\"847\" />\n<!-- the rest of meta and header elements -->\n<!-- followed by the content, with microformats v1 and v2 markup -->\nHTML provides an interesting functionality, the rel=alternate. This is meant to be the representation of the same data, but in another format. The most common use is links to RSS and Atom feeds.\nI don't know if Google will consume the JSON-LD alternate format, but it's there, and anyone can easily use it.\nAs for RDFa, I turned to meta elements. Unlike with JSON-LD, I decided to use the extremely simple vocabulary of Open Graph - at least Facebook is known to consume that.\nThe tragedy of this whole story: HTML5 has so many tags that is should be possible to do structured data without any need for any of the things above.\nMy content is now:\nmicroformats v1 and v2 within the visible content\na minimal RDFa in meta tags\na sidecar JSON-LD version\nThis way it's simple, but compatible enough for most cases.\n\n\nhttp://web.archive.org/web/20190211232147/https:/twitter.com/csarven/status/1091314310465421312\u21a9\nhttps://search.google.com/structured-data/testing-tool\u21a9\nhttps://github.com/petermolnar/nasg/commit/9c749f4591333744588bdf183b22ba638babcb20\u21a9\nhttps://www.ampproject.org/\u21a9\nhttps://web.archive.org/web/20190203123749/https://twitter.com/RubenVerborgh/status/1092029740364587008\u21a9\nhttp://manu.sporny.org/2014/json-ld-origins-2/\u21a9"
    },
    "name": "A journey to the underworld that is RDF",
    "post-type": "article",
    "_id": "4902212",
    "_source": "268",
    "_is_read": true
}

{
    "type": "entry",
    "author": {
        "name": "Kh\u00fcrt Williams",
        "url": "https://islandinthenet.com/",
        "photo": null
    },
    "url": "https://islandinthenet.com/automattic-to-acquire-tumblr/",
    "published": "2019-08-14T06:23:48-04:00",
    "content": {
        "html": "<a href=\"https://diaryofdennis.com/2019/08/13/tumblr-sold-to-automattic/\">Tumblr Sold to Automattic</a> <em>(Diary of Dennis)</em>\n<blockquote>What it means for WordPress.com users is not clear either. But if we start to speculate based on the term \u201cstandardize\u201d he used in his statement, it\u2019s likely that the company will enable sharing or reblogging across both services. It could also be that they bring registered users of both services closer together, which could also mean that it becomes easier for users of both services to comment and interact with each other. If we speculate further, it could become a reality that both services are integrated into the same feed or reader, which is how both communities could meet and interact with each other.</blockquote>\n\n<p>This was a surprise for me. I\u2019m not sure what any of this means for Tumblr or WordPress.com customers but I think it\u2019s an exciting development. Perhaps we\u2019ll get more Indieweb features such as Webmentions.</p>",
        "text": "Tumblr Sold to Automattic (Diary of Dennis)\nWhat it means for WordPress.com users is not clear either. But if we start to speculate based on the term \u201cstandardize\u201d he used in his statement, it\u2019s likely that the company will enable sharing or reblogging across both services. It could also be that they bring registered users of both services closer together, which could also mean that it becomes easier for users of both services to comment and interact with each other. If we speculate further, it could become a reality that both services are integrated into the same feed or reader, which is how both communities could meet and interact with each other.\n\nThis was a surprise for me. I\u2019m not sure what any of this means for Tumblr or WordPress.com customers but I think it\u2019s an exciting development. Perhaps we\u2019ll get more Indieweb features such as Webmentions."
    },
    "post-type": "note",
    "_id": "4888022",
    "_source": "242",
    "_is_read": true
}

Manton Reece www.manton.org

Tumblr and… App.net

{
    "type": "entry",
    "author": {
        "name": "Manton Reece",
        "url": "https://www.manton.org/",
        "photo": "https://aperture-proxy.p3k.io/907926e361383204bd1bc913c143c23e70ae69bb/68747470733a2f2f6d6963726f2e626c6f672f6d616e746f6e2f6176617461722e6a7067"
    },
    "url": "https://www.manton.org/2019/08/13/tumblr-and-appnet.html",
    "name": "Tumblr and\u2026 App.net",
    "content": {
        "html": "<p>Thanks to the \u201con this day\u201d feature <a href=\"https://github.com/cleverdevil/micromemories\">that Jonathan LaCour built</a> for Micro.blog-hosted blogs, I noticed that 7 years ago yesterday <a href=\"https://www.manton.org/2012/08/12/appnets-great-start.html\">I blogged about App.net reaching their funding goal</a>. I still get asked about App.net sometimes. It is easy to look back on something that didn\u2019t last and pick it apart. I\u2019d rather look at the good things that came out of App.net.</p>\n\n<p>When it was shutting down, I blogged <a href=\"https://www.manton.org/2017/01/06/thank-you-to.html\">my thanks to the App.net community</a>:</p>\n\n<blockquote>\n<p><a href=\"http://www.manton.org/2013/08/waiting_for_appnets.html\">I wrote in 2013</a> that it was not just a Twitter clone but an <em>amplifier</em> for applications that couldn\u2019t be built before. It came along at the right time, took off, and then faded. The App.net founders deserve significant credit and thanks for trying something risky and succeeding to grow a community that lasted so long.</p>\n</blockquote>\n\n<p>There is a guiding principle in Micro.blog that differentiates it from nearly every other platform. It\u2019s not only about creating an alternative social network. The foundation is around blogs and IndieWeb standards because that\u2019s <a href=\"https://manton.org/2018/09/07/the-way-out.html\">part of unrolling the damage caused by massive silos</a>.</p>\n\n<p>Micro.blog is also designed around blogs because it gives immediate value to the platform, insulating it against the network effect that drives the success or failure of most other social networks: not all your friends are there yet. Unlike ad-supported platforms, Micro.blog aligns its business model with customer needs. Subscriptions for blog hosting let us deliver the best features we can, and also help support the rest of the platform.</p>\n\n<p>Brent Simmons really <a href=\"https://inessential.com/2018/02/01/why_micro_blog_is_not_another_app_net\">said it best</a>:</p>\n\n<blockquote>\n<p>Micro.blog is not an alternative silo: instead, it\u2019s what you build when you believe that <em>the web itself</em> is the great social network.</p>\n</blockquote>\n\n<p>I often look back at this quote to help guide me as I evaluate the direction of Micro.blog. I believe that Micro.blog is the first platform of its kind. The closest competition might be Tumblr, <a href=\"https://photomatt.tumblr.com/post/186964618222/automattic-tumblr\">acquired yesterday by Automattic</a>.</p>\n\n<p>Of course it was coincidence that Automattic acquired Tumblr pretty much exactly 7 years after App.net was funded. No one is paying attention to those dates. And yet, now that I\u2019ve noticed it, there\u2019s a kind of symbolism to it. Tumblr is effectively being re-funded.</p>\n\n<p>Like Micro.blog, Tumblr is about making blogging easier. Like Micro.blog, Tumblr allows custom domain names for your blog, something no other major social network allows. Unlike Micro.blog, however, Tumblr\u2019s community is only Tumblr blogs. Micro.blog\u2019s community brings together not just Micro.blog-hosted blogs, but people using WordPress, Mastodon, or home-grown IndieWeb solutions.</p>\n\n<p>Matt Mullenweg and the Automattic team have a bunch of work ahead of them to integrate Tumblr into the WordPress ecosystem. I don\u2019t know how that\u2019s going to play out, but I know that preserving all the Tumblr blogs and giving them new life <em>is a good thing</em>.</p>\n\n<p>I wonder if Micro.blog and Automattic are on parallel tracks. Two companies wildly different in size and scope, but we can all learn from platforms that have come and gone, finding our own path to a shared vision of the future that embraces content ownership, supports healthy communities, and deemphasizes massive social networks. I\u2019m wishing the team at Automattic the best.</p>",
        "text": "Thanks to the \u201con this day\u201d feature that Jonathan LaCour built for Micro.blog-hosted blogs, I noticed that 7 years ago yesterday I blogged about App.net reaching their funding goal. I still get asked about App.net sometimes. It is easy to look back on something that didn\u2019t last and pick it apart. I\u2019d rather look at the good things that came out of App.net.\n\nWhen it was shutting down, I blogged my thanks to the App.net community:\n\n\nI wrote in 2013 that it was not just a Twitter clone but an amplifier for applications that couldn\u2019t be built before. It came along at the right time, took off, and then faded. The App.net founders deserve significant credit and thanks for trying something risky and succeeding to grow a community that lasted so long.\n\n\nThere is a guiding principle in Micro.blog that differentiates it from nearly every other platform. It\u2019s not only about creating an alternative social network. The foundation is around blogs and IndieWeb standards because that\u2019s part of unrolling the damage caused by massive silos.\n\nMicro.blog is also designed around blogs because it gives immediate value to the platform, insulating it against the network effect that drives the success or failure of most other social networks: not all your friends are there yet. Unlike ad-supported platforms, Micro.blog aligns its business model with customer needs. Subscriptions for blog hosting let us deliver the best features we can, and also help support the rest of the platform.\n\nBrent Simmons really said it best:\n\n\nMicro.blog is not an alternative silo: instead, it\u2019s what you build when you believe that the web itself is the great social network.\n\n\nI often look back at this quote to help guide me as I evaluate the direction of Micro.blog. I believe that Micro.blog is the first platform of its kind. The closest competition might be Tumblr, acquired yesterday by Automattic.\n\nOf course it was coincidence that Automattic acquired Tumblr pretty much exactly 7 years after App.net was funded. No one is paying attention to those dates. And yet, now that I\u2019ve noticed it, there\u2019s a kind of symbolism to it. Tumblr is effectively being re-funded.\n\nLike Micro.blog, Tumblr is about making blogging easier. Like Micro.blog, Tumblr allows custom domain names for your blog, something no other major social network allows. Unlike Micro.blog, however, Tumblr\u2019s community is only Tumblr blogs. Micro.blog\u2019s community brings together not just Micro.blog-hosted blogs, but people using WordPress, Mastodon, or home-grown IndieWeb solutions.\n\nMatt Mullenweg and the Automattic team have a bunch of work ahead of them to integrate Tumblr into the WordPress ecosystem. I don\u2019t know how that\u2019s going to play out, but I know that preserving all the Tumblr blogs and giving them new life is a good thing.\n\nI wonder if Micro.blog and Automattic are on parallel tracks. Two companies wildly different in size and scope, but we can all learn from platforms that have come and gone, finding our own path to a shared vision of the future that embraces content ownership, supports healthy communities, and deemphasizes massive social networks. I\u2019m wishing the team at Automattic the best."
    },
    "published": "2019-08-13T10:16:06-05:00",
    "post-type": "article",
    "_id": "4879676",
    "_source": "12",
    "_is_read": true
}

{
    "type": "entry",
    "published": "2019-08-12T16:37:55-04:00",
    "url": "https://miklb.com/blog/2019/08/12/5203/",
    "syndication": [
        "https://twitter.com/miklb/status/1161013983907852289"
    ],
    "content": {
        "text": "MySpace with web standards and a personalized domain name that you can export anytime as html. Using webmentions & some form of oAuth. That\u2019s what is going to win.",
        "html": "<p>MySpace with web standards and a personalized domain name that you can export anytime as html. Using webmentions &amp; some form of oAuth. That\u2019s what is going to win.\n</p>"
    },
    "post-type": "note",
    "_id": "4867504",
    "_source": "42",
    "_is_read": true
}

Marty McGuire martymcgui.re

{
    "type": "entry",
    "published": "2019-08-12T11:25:20-0400",
    "rsvp": "yes",
    "url": "https://martymcgui.re/2019/08/12/112520/",
    "in-reply-to": [
        "https://2019.indieweb.org/nyc"
    ],
    "content": {
        "text": "I'm going!So excited to be co-organizing an IndieWebCamp in NYC!\n\nLooking to start your personal website? Want to take control of your social media content?\n\nJoin us at Pace University in downtown Manhattan on October 5th and 6th!",
        "html": "I'm going!<p>So excited to be co-organizing an IndieWebCamp in NYC!</p>\n\n<p>Looking to start your personal website? Want to take control of your social media content?</p>\n\n<p>Join us at Pace University in downtown Manhattan on October 5th and 6th!</p>"
    },
    "author": {
        "type": "card",
        "name": "Marty McGuire",
        "url": "https://martymcgui.re/",
        "photo": "https://aperture-proxy.p3k.io/8275f85e3a389bd0ae69f209683436fc53d8bad9/68747470733a2f2f6d617274796d636775692e72652f696d616765732f6c6f676f2e6a7067"
    },
    "post-type": "rsvp",
    "refs": {
        "https://2019.indieweb.org/nyc": {
            "type": "entry",
            "summary": "IndieWebCamp NYC 2019 is a two-day maker event for creating and/or improving your personal website. All levels welcome! One of several 2019 IndieWebCamps and the seventh IndieWebCamp in NYC!",
            "url": "https://2019.indieweb.org/nyc",
            "name": "IndieWebCamp NYC",
            "author": {
                "type": "card",
                "name": "2019.indieweb.org",
                "url": "http://2019.indieweb.org",
                "photo": null
            },
            "post-type": "note"
        }
    },
    "_id": "4864036",
    "_source": "175",
    "_is_read": true
}