{
    "type": "entry",
    "published": "2020-06-12T01:42:00.00000-07:00",
    "url": "https://v2.jacky.wtf/post/f964ac50-d9bf-4352-9b47-76663efb026b",
    "category": [
        "lighthouse"
    ],
    "content": {
        "text": "Added the back end code to handle the act of sending relayed Webmentions. It\u2019ll be handy for me when/if my site goes down and other sites are smart enough to cache endpoints used. I should add some of the endpoint caching stuff.But most importantly, I have to implement the API that can list out Webmentions for things to use. From there, I want to build a set of custom components that can implement a comments section that\u2019ll be connected to Lighthouse via the subscription system Phoenix has.",
        "html": "<p>Added the back end code to handle the act of sending relayed Webmentions. It\u2019ll be handy for me when/if my site goes down and other sites are smart enough to cache endpoints used. I should add some of the endpoint caching stuff.</p><p>But most importantly, I have to implement the API that can list out Webmentions for things to use. From there, I want to build a set of custom components that can implement a comments section that\u2019ll be connected to Lighthouse via the subscription system Phoenix has.</p>"
    },
    "author": {
        "type": "card",
        "name": "",
        "url": "https://v2.jacky.wtf",
        "photo": null
    },
    "post-type": "note",
    "_id": "12367620",
    "_source": "1886",
    "_is_read": true
}

{
    "type": "entry",
    "published": "2020-06-10T04:35:00.00000-07:00",
    "url": "https://v2.jacky.wtf/post/4b4b888a-7e92-4af6-ad4b-ec20e2c8a164",
    "content": {
        "text": "Definitely going to refactor how I handle Webmention feed rendering so I can use it as the basis in my other feeds. It\u2019s so much easier to do it in HTML oddly enough.",
        "html": "<p>Definitely going to refactor how I handle Webmention feed rendering so I can use it as the basis in my other feeds. It\u2019s so much easier to do it in HTML oddly enough.</p>"
    },
    "author": {
        "type": "card",
        "name": "",
        "url": "https://v2.jacky.wtf",
        "photo": null
    },
    "post-type": "note",
    "_id": "12314068",
    "_source": "1886",
    "_is_read": true
}

{
    "type": "entry",
    "published": "2020-06-09T19:35:00.00000-07:00",
    "url": "https://v2.jacky.wtf/post/954383dc-11ce-49f1-b03e-76d0f751f46a",
    "bookmark-of": [
        "https://marinintim.com/2020/your-data/"
    ],
    "content": {
        "text": "Interesting points on some stuff we\u2019re looking into the IndieWeb, when it comes to handling meta-data.",
        "html": "<p>Interesting points on some stuff we\u2019re looking into the IndieWeb, when it comes to handling meta-data.</p>"
    },
    "author": {
        "type": "card",
        "name": "",
        "url": "https://v2.jacky.wtf",
        "photo": null
    },
    "post-type": "bookmark",
    "refs": {
        "https://marinintim.com/2020/your-data/": {
            "type": "entry",
            "url": "https://marinintim.com/2020/your-data/",
            "content": {
                "text": "On the weekend, publisher Pragmatic Programmers migrated to a new system, which is noticeably faster than the previous one. That's good. But the new version lacks the wish list.\nNow, I don't know if it's an artifact of migration and wish list is to be reinstated, or if it was a deliberate decision to drop the feature that probably isn't used by the majority of buyers. But it made me aware, that my \"data\" is way broader then I thought before.\nI've blogged about Indieweb movement at length the last year (in Russian), but even then I mostly thought about my data as data that I consciously create: photos, essays, lame jokes, et cetera. Turns out, my wish list was also useful to me, and I miss it. The same is true, say, about my YouTube watch history and Watch Later list, I regularly refer to it to find some weird video I watched a few days ago.\nI don't think that any decision in the chain of events that led to me missing my wish list was malicious, but such is the nature of complex systems, especially web services, that they produce unintended outcomes. That's okay, losing wish list is not a big deal.\nThis incident made me even more aware that the only data I'm guaranteed to be able to access is the data hosted under my control, either on my own disks, or on the disks of my hosting provider.\nWhat other data I'm not thinking of? That's hard to tell, because this data is produced reactively, as a side effect of using web services normally. Message archives in proprietary services (Telegram, FB, VK, and others), upvoted links to research later on Lobsters and others websites, the set of subscriptions.\nI also store my \"books to buy\" lists at Amazon.com as Wish Lists, which could also disappear at any moment, and in the Cart, which may get emptied. These lists act as my own bibliography of things I'm interested to learn more about, so they do have value on their own.\nI'm planning to migrate these lists to my web server as a simple HTML file. HTML files do not require maintenance and also have zero marginal costs.\nAs to PragProg wish list, I guess I'd have to buy every book they have, 'cause every book published by them that I've read was great.",
                "html": "<p>On the weekend, publisher <a href=\"https://pragprog.com\">Pragmatic Programmers</a> migrated to a new system, which is noticeably faster than the previous one. That's good. But the new version lacks the wish list.</p>\n<p>Now, I don't know if it's an artifact of migration and wish list is to be reinstated, or if it was a deliberate decision to drop the feature that probably isn't used by the majority of buyers. But it made me aware, that my \"data\" is way broader then I thought before.</p>\n<p>I've blogged about <a href=\"https://indieweb.org\">Indieweb</a> movement at length <a href=\"https://marinintim.com/2019/indieweb\">the last year (in Russian)</a>, but even then I mostly thought about my data as data that I consciously create: photos, essays, lame jokes, et cetera. Turns out, my wish list was also useful to me, and I miss it. The same is true, say, about my YouTube watch history and Watch Later list, I regularly refer to it to find some weird video I watched a few days ago.</p>\n<p>I don't think that any decision in the chain of events that led to me missing my wish list was malicious, but such is the nature of complex systems, especially web services, that they produce unintended outcomes. That's okay, losing wish list is not a big deal.</p>\n<p>This incident made me even more aware that the only data I'm guaranteed to be able to access is the data hosted under my control, either on my own disks, or on the disks of my hosting provider.</p>\n<p>What other data I'm not thinking of? That's hard to tell, because this data is produced reactively, as a side effect of using web services normally. Message archives in proprietary services (Telegram, FB, VK, and others), upvoted links to research later on Lobsters and others websites, the set of subscriptions.</p>\n<p>I also store my \"books to buy\" lists at Amazon.com as Wish Lists, which could also disappear at any moment, and in the Cart, which may get emptied. These lists act as my own bibliography of things I'm interested to learn more about, so they do have value on their own.</p>\n<p>I'm planning to migrate these lists to my web server as a simple HTML file. HTML files do not require maintenance and also have zero marginal costs.</p>\n<p>As to PragProg wish list, I guess I'd have to buy every book they have, 'cause every book published by them that I've read was great.</p>"
            },
            "author": {
                "type": "card",
                "name": "",
                "url": "https://v2.jacky.wtf/false",
                "photo": null
            },
            "post-type": "note"
        }
    },
    "_id": "12306126",
    "_source": "1886",
    "_is_read": true
}

{
    "type": "entry",
    "published": "2020-06-09T15:03:00.00000-07:00",
    "url": "https://v2.jacky.wtf/post/8b7f3ca5-fe9b-4436-8d19-b79daafbc732",
    "content": {
        "text": "Okay, fixed up my Webmentions (only the JSON feed). I need to fix the hfeed of Webmentions and see if I can use that to provide richer representation of it because JSON feed is a little janky.",
        "html": "<p>Okay, fixed up my Webmentions (only the JSON feed). I need to fix the hfeed of Webmentions and see if I can use that to provide richer representation of it because JSON feed is a little janky.</p>"
    },
    "author": {
        "type": "card",
        "name": "",
        "url": "https://v2.jacky.wtf",
        "photo": null
    },
    "post-type": "note",
    "_id": "12301017",
    "_source": "1886",
    "_is_read": true
}

An Idea on Following People (or Organizations or Whomever) in the IndieWeb for Lwa

{
    "type": "entry",
    "published": "2020-06-09T13:05:30.97684-07:00",
    "url": "https://v2.jacky.wtf/post/1149bdd8-a3ac-43b8-b15e-94387bc136d7",
    "category": [
        "lwa"
    ],
    "name": "An Idea on Following People (or Organizations or Whomever) in the IndieWeb for Lwa",
    "content": {
        "text": "After a bit of discussion in the IndieWeb channels (start here and end about here), I think I have an idea on how I want Lwa to handle \"people\". Tantek made a good point about optimizing the experience to follow people (or any sort of \"entity\" that isn't specifically a site) - that's a behavior people are familiar with and it's natural. This got me thinking about how I want this to look in my social reader.Setting up the EnvironmentThis requires a bit of contextual setup - where would someone find someone to \"follow\"? I'll optimize this to be in the case of someone who's already logged into Lwa (which assumes that they have a IndieWeb site) and are already following some people.A preview of a post in Lwa.From the screenshot above, I can think of the following ways to follow someone from this screenshot of a post in the feed for Lwa:Adding a button next to the post-type icon to follow the person.\nAdding a pop-over modal that'd provide a \"best-effort\" representation of the entity that made that post.\nProviding an intent to follow page that'll provide information on that user\nThe first two can be collapsed into a on-page experience that'll present some information about the content's author via a modal of some sorts. Ideally, that'll have information about them (name, photo and whatever else is semantically relevant). There, we can have a page that'll heads to the \"intent to follow\" page mentioned in the last step. This is where things get a bit interesting.An Intent to FollowThe intent to follow page will be vital. I haven't built one yet but it'll be something that'll combine the following sources of data:a \"best effort\" representation of the author\nconditionally presenting the post that brought us here\na way to view the multiple feeds presented by the author\nI'm thinking about making this page accessible by either providing the author URL itself or the contextual post to show. The latter will be something that helps people just finding content. The method of composing the author representation will be something of a collection of the following with (unspecified) weights:fetching rel=me information from the provided URL\nfetching the representative h-card of the URL\nopting to use Microformats over anything else when it's available (specifically, Microformats, Activity Streams and then whatever is left over)\nBuilding a list of the feeds for this user would be done the same way. One thing that'll help with optimization of these feeds is, in the event that they have a Microformats2 site, we can collapse syndicated posts into the site's post so the feed doesn't look too noisy. With these feeds collected, we can do some light metrics crunching about post frequency, the average interaction rate (if any) for posts in a feed. With that, we can give the user in question a choice of what feed that they'd like to follow (and into which channel). I don't have an immediate mock-up of that page but I can see it being a mix of Twitter's user profile pages and the now-defunct Twitter intent-to-follow pages. There's a case to be made to allow for a \"catch-all\" channel for people to use but I think I'll make that an opt-in function of Lwa; having such a thing tends to enable more lock-in.I'll make another post once I get around to the demo of this feature in Lwa. For now, I'm down to get feedback about such a flow!",
        "html": "<p>After a bit of discussion in the IndieWeb channels (start <a href=\"https://chat.indieweb.org/meta/2020-06-09#t1591724374780000\">here</a> and end about <a href=\"https://chat.indieweb.org/meta/2020-06-09#t1591727624999000\">here</a>), I think I have an idea on how I want <a href=\"https://lwa.black.af\">Lwa</a> to handle \"people\". <a href=\"http://tantek.com\">Tantek</a> made a good point about optimizing the experience to follow people (or any sort of \"entity\" that isn't specifically a site) - that's a behavior people are familiar with and it's natural. This got me thinking about how I want this to look in my social reader.</p><h3>Setting up the Environment</h3><p>This requires a bit of contextual setup - where would someone find someone to \"follow\"? I'll optimize this to be in the case of someone who's already logged into Lwa (which assumes that they have a IndieWeb site) and are already following some people.</p><img src=\"https://v2.jacky.wtf/media/image/floating/Screenshot_20200609_120621.png?v=original\" alt=\"Screenshot_20200609_120621.png?v=original\" />A preview of a post in Lwa.<p>From the screenshot above, I can think of the following ways to follow someone from this screenshot of a post in the feed for Lwa:</p><ul><li>Adding a button next to the post-type icon to follow the person.</li>\n<li>Adding a pop-over modal that'd provide a \"best-effort\" representation of the entity that made that post.</li>\n<li>Providing an intent to follow page that'll provide information on that user</li>\n</ul><p>The first two can be collapsed into a on-page experience that'll present some information about the content's author via a modal of some sorts. Ideally, that'll have information about them (name, photo and whatever else is semantically relevant). There, we can have a page that'll heads to the \"intent to follow\" page mentioned in the last step. This is where things get a bit interesting.</p><h3>An Intent to Follow</h3><p>The intent to follow page will be vital. I haven't built one yet but it'll be something that'll combine the following sources of data:</p><ul><li>a \"best effort\" representation of the author</li>\n<li>conditionally presenting the post that brought us here</li>\n<li>a way to view the multiple feeds presented by the author</li>\n</ul><p>I'm thinking about making this page accessible by either providing the author URL itself or the contextual post to show. The latter will be something that helps people just finding content. The method of composing the author representation will be something of a collection of the following with (unspecified) weights:</p><ul><li>fetching rel=me information from the provided URL</li>\n<li>fetching the representative h-card of the URL</li>\n<li>opting to use Microformats over anything else when it's available (specifically, Microformats, Activity Streams and then whatever is left over)</li>\n</ul><p>Building a list of the feeds for this user would be done the same way. One thing that'll help with optimization of these feeds is, in the event that they have a Microformats2 site, we can collapse syndicated posts into the site's post so the feed doesn't look too noisy. With these feeds collected, we can do some light metrics crunching about post frequency, the average interaction rate (if any) for posts in a feed. With that, we can give the user in question a choice of what feed that they'd like to follow (and into which channel). I don't have an immediate mock-up of that page but I can see it being a mix of Twitter's user profile pages and the now-defunct Twitter intent-to-follow pages. There's a case to be made to allow for a \"catch-all\" channel for people to use but I think I'll make that an opt-in function of Lwa; having such a thing tends to enable more lock-in.</p><p>I'll make another post once I get around to the demo of this feature in Lwa. For now, I'm down to get feedback about such a flow!</p>"
    },
    "author": {
        "type": "card",
        "name": "",
        "url": "https://v2.jacky.wtf",
        "photo": null
    },
    "post-type": "article",
    "_id": "12298628",
    "_source": "1886",
    "_is_read": true
}

{
    "type": "entry",
    "published": "2020-06-09T11:27:00.00000-07:00",
    "url": "https://v2.jacky.wtf/post/3340084e-6531-42ad-b40d-58b1c4ec7546",
    "content": {
        "text": "I\u2019m also losing Webmentions left and right due to this hard failure.",
        "html": "<p>I\u2019m also losing Webmentions left and right due to this hard failure.</p>"
    },
    "author": {
        "type": "card",
        "name": "",
        "url": "https://v2.jacky.wtf",
        "photo": null
    },
    "post-type": "note",
    "_id": "12297326",
    "_source": "1886",
    "_is_read": true
}

Manton Reece www.manton.org

{
    "type": "entry",
    "author": {
        "name": "Manton Reece",
        "url": "https://www.manton.org/",
        "photo": "https://micro.blog/manton/avatar.jpg"
    },
    "url": "https://www.manton.org/2020/06/08/ill-be-attending.html",
    "content": {
        "html": "<p>I\u2019ll be attending <a href=\"https://events.indieweb.org/2020/06/indiewebcamp-west-2020-ZB8zoAAu6sdN\">IndieWebCamp West</a> later this month. It\u2019s online-only, centered in the west coast timezone, but anyone around the world is welcome. Need to think about IndieWeb-related goals for Micro.blog that week.</p>",
        "text": "I\u2019ll be attending IndieWebCamp West later this month. It\u2019s online-only, centered in the west coast timezone, but anyone around the world is welcome. Need to think about IndieWeb-related goals for Micro.blog that week."
    },
    "published": "2020-06-08T11:36:44-05:00",
    "post-type": "note",
    "_id": "12266050",
    "_source": "12",
    "_is_read": true
}

{
    "type": "entry",
    "published": "2020-06-07T21:12:05.91246-07:00",
    "url": "https://v2.jacky.wtf/post/ecb0ee9d-c6f4-40a0-92a1-3adea2c9c383",
    "content": {
        "text": "Ugh, finally fixed my Webmentions and from my recordings, it\u2019s even faster than before. This is so exciting.",
        "html": "<p>Ugh, finally fixed my Webmentions and from my recordings, it\u2019s even faster than before. This is so exciting.</p>"
    },
    "author": {
        "type": "card",
        "name": "",
        "url": "https://v2.jacky.wtf",
        "photo": null
    },
    "post-type": "note",
    "_id": "12253753",
    "_source": "1886",
    "_is_read": true
}

Jeremy Keith adactio.com

{
    "type": "entry",
    "published": "2020-06-03T17:05:54Z",
    "url": "https://adactio.com/links/16974",
    "category": [
        "rss",
        "feeds",
        "indieweb",
        "blogging",
        "publishing",
        "syndication",
        "writing",
        "updates",
        "urls",
        "discovery"
    ],
    "bookmark-of": [
        "https://marcus.io/blog/making-rss-more-visible-again-with-slash-feeds"
    ],
    "content": {
        "text": "marcus.io \u00b7 Making RSS more visible again with a /feeds page\n\n\n\n\n  Personal website owners \u2013 what do you think about collecting all of the feeds you are producing in one way or the other on a /feeds page?\n\n\nSounds like a good idea! I\u2019ll get on that.",
        "html": "<h3>\n<a class=\"p-name u-bookmark-of\" href=\"https://marcus.io/blog/making-rss-more-visible-again-with-slash-feeds\">\nmarcus.io \u00b7 Making RSS more visible again with a /feeds page\n</a>\n</h3>\n\n<blockquote>\n  <p>Personal website owners \u2013 what do you think about collecting all of the feeds you are producing in one way or the other on a <code>/feeds</code> page?</p>\n</blockquote>\n\n<p>Sounds like a good idea! I\u2019ll get on that.</p>"
    },
    "author": {
        "type": "card",
        "name": "Jeremy Keith",
        "url": "https://adactio.com/",
        "photo": "https://adactio.com/images/photo-150.jpg"
    },
    "post-type": "bookmark",
    "_id": "12129814",
    "_source": "2",
    "_is_read": true
}

Jamie Tanna www.jvt.me

{
    "type": "entry",
    "published": "2020-06-01T20:42:00+01:00",
    "url": "https://www.jvt.me/mf2/2020/06/fa1ve/",
    "category": [
        "web",
        "indieweb",
        "webmention",
        "personal-website"
    ],
    "bookmark-of": [
        "https://petermolnar.net/article/less-features-cleaner-site/"
    ],
    "author": {
        "type": "card",
        "name": "Jamie Tanna",
        "url": "https://www.jvt.me",
        "photo": "https://www.jvt.me/img/profile.png"
    },
    "post-type": "bookmark",
    "_id": "12070097",
    "_source": "2169",
    "_is_read": true
}

Refactoring my static generator

{
    "type": "entry",
    "author": {
        "name": null,
        "url": "https://petermolnar.net/",
        "photo": null
    },
    "url": "https://petermolnar.net/article/less-features-cleaner-site/",
    "published": "2020-06-01T08:30:00+01:00",
    "content": {
        "html": "<p>A few weeks ago I sat down in front of my site and realized: it's doing too many things, the code is over 3500 lines of Python, and I feel lost when I look at it. It was an organic growth, and happened somewhat like this:</p>\n<p><em>Let's start simple: collect images, extract EXIF using exiftool<a href=\"https://petermolnar.net/#fn1\">1</a>, watermark them, if needed, resize them, if needed. Collect markdown files, convert them to HTML with pandoc<a href=\"https://petermolnar.net/#fn2\">2</a> using microformat friendly templates. Ah, wait I need categories. I also need pages. And feeds. Multiple feeds, because I'm not going to choose sides, RSS, Atom, JSON, hfeed. Let's make all of them! I'll even invent YAMLFeed<a href=\"https://petermolnar.net/#fn3\">3</a> for the lulz. I need webmentions. Receive them, create comments before rendering anything, then render, then sync, then send outgoing webmentions. Oh. Don't send them every single time, just on change. I need to publish to flickr, but I need to be able to backfill from brid.gy. Let's handle gone content properly, also redirects nicely. Let's try JavaScript based search. Or let's not, it's needs people to download the full index every time, let's do PHP from Python templates instead. Google zombies are doing JSON-LD, academics are doing Linked Data, let's do all that. Hell, let's make an intermediate representation of all my content in JSON-LD that is made from the Markdown files before it hit's the HTML templates! In the meanwhile, why not auto-save my posts to archive.org? But what if I already did it? Let's find the earliest version automagically! OK, this is a bit slow now, let's start using async stuff. Let's syndicate to fediverse via fed.brid.gy. I don't like my pagination logic, let's do some categories flat: all on one page; others paginated by year. I want to add something funky for IWC this year, I'll add a worldmap for photos with location data. I see federated things are pinging <code>.well-known</code> locations, let's generate data for them.</em></p>\n<p>I'm not certain if this is the whole list of features, but it's quite clear it has overgrown it's original purpose. In my defense, some of these functionalities were only meant to be learning experiences.</p>\n<h2>DRY - don't repeat yourself</h2>\n<p>I started with the most painful point. The previous iteration had a <code>source</code> directory for the content, with the unprocessed, original files, a <code>nasg</code> for the code, and a <code>www</code> for the generated output. What I should have done from the start it to have 1 and only 1 directory for everything.</p>\n<p>The main reasons for the original layout were to keep my original - quite large - images safe on my own computer, copy only the resized and potentially watermarked ones online. The other was to keep the code in it's own repository, so it can be \"Open Sourced\". <em>Why the quotes: because I've started to question what Open Source means to me and what it is right now in the world, but this is for another day.</em></p>\n<p>The more I complicated this the more I realized all these disconnected pieces are making the originally simple process more and more convoluted. So I made certain decisions.</p>\n<p><strong>My generator code is not going to live on Github any more. Instead, it'll be in the root folder of my site content, which will also be the root folder for the website. I'll generate everything in place.</strong> I'll move the original images to be hidden files and protect them via webserver rules, like I did in the WordPress times. I'll place the Python virtualenv in this directory as well.</p>\n<p>With the move to a single directory structure I also moved away from the weird path system I ended up with: direct uris for entries and /category/ prefixes for categories. Now everything always is /folder/subfolder/ etc, as it should have been from the start.</p>\n<p>It needed some rewrite magic to have it done properly, but it should all be fine now.</p>\n<h2>Parsing should be stiff and intolerant</h2>\n<p>When I saved markdown files by hand, I wasn't paying too much attention to, for example, dates. The Python library I used - arrow - parsed nearly everything. This also applied to the comments, but the comments were saved by my own code: missing or <code>null</code> authors, bad date formats, etc.</p>\n<p>With the refactoring I decided to ditch as many libraries as possible in favour of Python's built in ones, and <code>datetime</code> suddenly wasn't happy.</p>\n<p>I fixed all of them; some with scripts, others by hand. Than swapped to a very strict parsing: if stuff is malformed, fail hard. Make me have to fix it.</p>\n<p><strong>No workarounds in the code, no clever hundreds of lines of fallbacks; the source should be cleaned if there is an issue.</strong></p>\n<h2>Not everything needs templating</h2>\n<p>In order to have a nice search, I had templated PHP files. Truth is: it's not essential. Search is happy with a few lines of CSS and a \"back to petermolnar.net\" button.</p>\n<p>My fallback 404.php can now rely on looking up files itself. Previously I had <code>removeduri.del</code> and <code>some-old-uri.url</code> files. The first were empty files, with the deleted URIs in their names; the second contained the URL to redirect to. Because of the <code>content</code> and <code>www</code> directory setup, I had to parse these, collect them, and then insert in the PHP. But now I had the files accessible from the PHP itself, meaning it can look it up itself.</p>\n<p><strong>This way both my <code>404.php</code> and my <code>search.php</code> became self-sufficient - no more Python Jinja2 templates for PHP files.</strong></p>\n<h2>Semantic HTML5 is a joke, JSON-LD is a monster, and I have no need for either</h2>\n<p>Some elements in HTML5 are good, and were much needed. Personally I'm very happy with <code>figure</code> and <code>figcaption</code>, <code>details</code> and <code>summary</code>, and <code>time</code>.</p>\n<p>I find<code>header</code>, <code>footer</code> , and <code>nav</code> a bit useless, but nothing tops the <code>main</code>, <code>section</code>, <code>article</code> (and probably some other) mess. There's no definitive way of using one or the other, so everyone is doing which make sense to them<a href=\"https://petermolnar.net/#fn4\">4</a> - which is the opposite of a standard. Try to figure out which definition goes for which (official definitions from the \"living\" HTML standard):</p>\n<blockquote>\n<p>The X element represents a generic section of a document or application. The X , in this context, is a thematic grouping of content, typically with a heading.</p>\n</blockquote>\n<blockquote>\n<p>The Y element represents a complete, or self-contained, composition in a document, page, application, or site and that is, in principle, independently distributable or reusable, e.g. in syndication.</p>\n</blockquote>\n<blockquote>\n<p>The Z element represents the dominant contents of the document.</p>\n</blockquote>\n<p>So I dropped most of it; especially because I have microformats<a href=\"https://petermolnar.net/#fn5\">5</a> v1 and v2 markup already, and that is an actual standard with obvious guidelines.</p>\n<p>Next ripe for reaping was JSON-LD. I got into the semantic web possibilities because I was curios. I learnt a lot, including the fact that I have no need for it.</p>\n<p>The enforced vocabulary for JSON-LD, schema.org, is terrible to use. Whenever you have a need for something that's not present already, you're done for, and it'll probably pollute the structured data results, because all the search engines, especially Google, are picky: they limit the options plus they require properties. Examples everything MUST have a photo! And and address! And a publisher! If you don't believe me, try to make a resume with schema.org then see how opinion of the Google Structured Data Testing Tool about it.</p>\n<p>No, Google. Not everything has an image - see <a href=\"http://textfiles.com/\">http://textfiles.com</a> Like it or not, a website doesn't need and address. The list goes on forever.</p>\n<p><strong>I'm going to stop feeding it, stop feeding all of them, stop playing by their weird rules. HTML has <code>link</code> and <code>meta</code> elements, plus <code>rel=</code> property, so it can already represent the minimum, which is enough. Plus, again, there's microformats, and Google is still very happy with them<a href=\"https://petermolnar.net/#fn6\">6</a>.</strong></p>\n<p>Note: with structured data, in theory, one could pull in other vocabularies to overcome problems like nonexistent properties in one, but search engines are not real RDF parsers. Unless you're writing for academic publishing tools that will do so, don't bother.</p>\n<h2>Pick your format, and pick just one</h2>\n<p>Between 2003 and 2007 some tragic mud-throwing (<em>mirror translated Hungarian phrase, just because it's pretty visual</em>) was going on on the web, over something ridiculously small: my XML is better, than your XML! <a href=\"https://petermolnar.net/#fn7\">7</a>.</p>\n<p>When I first encountered with the whole \"feed\" idea itself, there was only RSS, and for a very long time, I was happy with it. Then I read opinions of people I listen to on how Atom is better. <a href=\"https://fed.brid.gy/\">https://fed.brid.gy</a> is Atom only. Much later someone on the internet popped the JSONFeed thought.</p>\n<p><em>When I first saw JSONFeed, I thought it's a joke. Turned out it's not, because there are simpletons who honestly believe the world will be better if things are JSON and not XML. It won't, it'll only result in things like JSON-LD</em></p>\n<p><em>In the heat of the moment, I coined the thought of YAMLFeed<a href=\"https://petermolnar.net/#fn8\">8</a>, strictly as a satire, but for a brief time I actually maintained a YAMLFeed file as well Do not follow my example.</em></p>\n<p>And then I found myself serving them all. I had a <code>Category</code> class in Python, that had <code>JSONFeed</code> and <code>XMLFeed</code>subclasses, which latter had <code>AtomFeed</code> and <code>RSSFeed</code> subclasses, it used <code>FeedParser</code> to deal with it, and so on... in short, I made a monster.</p>\n<p><strong>I went back an RSS 2.0 feed and a h-feed.</strong> The first can be made with the <code>lxml</code> library directly, and I always liked the RSS acronym.</p>\n<h2>Closure</h2>\n<p>If you have a website in 2020, it's probably a hobby for you as well; don't let anything change that.</p>\n<p>It should never become a burden, any part of it. It did for me, and I seriously considered firing up something like Microsoft FrontPage 98 to start from the proverbial scratch, but managed to salvage it before resulting to drastic measures.</p>\n<p>Don't follow trends. Once a solution grows deep enough roots - microformats, RSS, etc - it'll be around for a very long time.</p>\n<p>Screw SEO. If you're like me, and you write for yourself, and, maybe, for the small web<a href=\"https://petermolnar.net/#fn9\">9</a>, don't bother trying to please an ever-changing power play.</p>\n<p>If you want to learn something new, be careful not to embed it too deep - it may be a fast fading idea.</p>\n\n\n<ol><li><p><a href=\"https://exiftool.org/\">https://exiftool.org/</a><a href=\"https://petermolnar.net/#fnref1\">\u21a9</a></p></li>\n<li><p><a href=\"https://pandoc.org/\">https://pandoc.org/</a><a href=\"https://petermolnar.net/#fnref2\">\u21a9</a></p></li>\n<li><p><a href=\"https://indieweb.org/YAMLFeed\">https://indieweb.org/YAMLFeed</a><a href=\"https://petermolnar.net/#fnref3\">\u21a9</a></p></li>\n<li><p><a href=\"https://www.w3schools.com/html/html5_semantic_elements.asp\">https://www.w3schools.com/html/html5_semantic_elements.asp</a><a href=\"https://petermolnar.net/#fnref4\">\u21a9</a></p></li>\n<li><p><a href=\"http://microformats.org/\">http://microformats.org/</a><a href=\"https://petermolnar.net/#fnref5\">\u21a9</a></p></li>\n<li><p><a href=\"https://aaronparecki.com/2016/12/17/8/owning-my-reviews#historical-recommendations\">https://aaronparecki.com/2016/12/17/8/owning-my-reviews#historical-recommendations</a><a href=\"https://petermolnar.net/#fnref6\">\u21a9</a></p></li>\n<li><p><a href=\"https://indieweb.org/RSS_Atom_wars\">https://indieweb.org/RSS_Atom_wars</a><a href=\"https://petermolnar.net/#fnref7\">\u21a9</a></p></li>\n<li><p><a href=\"https://indieweb.org/YAMLFeed\">https://indieweb.org/YAMLFeed</a><a href=\"https://petermolnar.net/#fnref8\">\u21a9</a></p></li>\n<li><p><a href=\"https://neustadt.fr/essays/the-small-web/\">https://neustadt.fr/essays/the-small-web/</a><a href=\"https://petermolnar.net/#fnref9\">\u21a9</a></p></li>\n</ol>",
        "text": "A few weeks ago I sat down in front of my site and realized: it's doing too many things, the code is over 3500 lines of Python, and I feel lost when I look at it. It was an organic growth, and happened somewhat like this:\nLet's start simple: collect images, extract EXIF using exiftool1, watermark them, if needed, resize them, if needed. Collect markdown files, convert them to HTML with pandoc2 using microformat friendly templates. Ah, wait I need categories. I also need pages. And feeds. Multiple feeds, because I'm not going to choose sides, RSS, Atom, JSON, hfeed. Let's make all of them! I'll even invent YAMLFeed3 for the lulz. I need webmentions. Receive them, create comments before rendering anything, then render, then sync, then send outgoing webmentions. Oh. Don't send them every single time, just on change. I need to publish to flickr, but I need to be able to backfill from brid.gy. Let's handle gone content properly, also redirects nicely. Let's try JavaScript based search. Or let's not, it's needs people to download the full index every time, let's do PHP from Python templates instead. Google zombies are doing JSON-LD, academics are doing Linked Data, let's do all that. Hell, let's make an intermediate representation of all my content in JSON-LD that is made from the Markdown files before it hit's the HTML templates! In the meanwhile, why not auto-save my posts to archive.org? But what if I already did it? Let's find the earliest version automagically! OK, this is a bit slow now, let's start using async stuff. Let's syndicate to fediverse via fed.brid.gy. I don't like my pagination logic, let's do some categories flat: all on one page; others paginated by year. I want to add something funky for IWC this year, I'll add a worldmap for photos with location data. I see federated things are pinging .well-known locations, let's generate data for them.\nI'm not certain if this is the whole list of features, but it's quite clear it has overgrown it's original purpose. In my defense, some of these functionalities were only meant to be learning experiences.\nDRY - don't repeat yourself\nI started with the most painful point. The previous iteration had a source directory for the content, with the unprocessed, original files, a nasg for the code, and a www for the generated output. What I should have done from the start it to have 1 and only 1 directory for everything.\nThe main reasons for the original layout were to keep my original - quite large - images safe on my own computer, copy only the resized and potentially watermarked ones online. The other was to keep the code in it's own repository, so it can be \"Open Sourced\". Why the quotes: because I've started to question what Open Source means to me and what it is right now in the world, but this is for another day.\nThe more I complicated this the more I realized all these disconnected pieces are making the originally simple process more and more convoluted. So I made certain decisions.\nMy generator code is not going to live on Github any more. Instead, it'll be in the root folder of my site content, which will also be the root folder for the website. I'll generate everything in place. I'll move the original images to be hidden files and protect them via webserver rules, like I did in the WordPress times. I'll place the Python virtualenv in this directory as well.\nWith the move to a single directory structure I also moved away from the weird path system I ended up with: direct uris for entries and /category/ prefixes for categories. Now everything always is /folder/subfolder/ etc, as it should have been from the start.\nIt needed some rewrite magic to have it done properly, but it should all be fine now.\nParsing should be stiff and intolerant\nWhen I saved markdown files by hand, I wasn't paying too much attention to, for example, dates. The Python library I used - arrow - parsed nearly everything. This also applied to the comments, but the comments were saved by my own code: missing or null authors, bad date formats, etc.\nWith the refactoring I decided to ditch as many libraries as possible in favour of Python's built in ones, and datetime suddenly wasn't happy.\nI fixed all of them; some with scripts, others by hand. Than swapped to a very strict parsing: if stuff is malformed, fail hard. Make me have to fix it.\nNo workarounds in the code, no clever hundreds of lines of fallbacks; the source should be cleaned if there is an issue.\nNot everything needs templating\nIn order to have a nice search, I had templated PHP files. Truth is: it's not essential. Search is happy with a few lines of CSS and a \"back to petermolnar.net\" button.\nMy fallback 404.php can now rely on looking up files itself. Previously I had removeduri.del and some-old-uri.url files. The first were empty files, with the deleted URIs in their names; the second contained the URL to redirect to. Because of the content and www directory setup, I had to parse these, collect them, and then insert in the PHP. But now I had the files accessible from the PHP itself, meaning it can look it up itself.\nThis way both my 404.php and my search.php became self-sufficient - no more Python Jinja2 templates for PHP files.\nSemantic HTML5 is a joke, JSON-LD is a monster, and I have no need for either\nSome elements in HTML5 are good, and were much needed. Personally I'm very happy with figure and figcaption, details and summary, and time.\nI findheader, footer , and nav a bit useless, but nothing tops the main, section, article (and probably some other) mess. There's no definitive way of using one or the other, so everyone is doing which make sense to them4 - which is the opposite of a standard. Try to figure out which definition goes for which (official definitions from the \"living\" HTML standard):\n\nThe X element represents a generic section of a document or application. The X , in this context, is a thematic grouping of content, typically with a heading.\n\n\nThe Y element represents a complete, or self-contained, composition in a document, page, application, or site and that is, in principle, independently distributable or reusable, e.g. in syndication.\n\n\nThe Z element represents the dominant contents of the document.\n\nSo I dropped most of it; especially because I have microformats5 v1 and v2 markup already, and that is an actual standard with obvious guidelines.\nNext ripe for reaping was JSON-LD. I got into the semantic web possibilities because I was curios. I learnt a lot, including the fact that I have no need for it.\nThe enforced vocabulary for JSON-LD, schema.org, is terrible to use. Whenever you have a need for something that's not present already, you're done for, and it'll probably pollute the structured data results, because all the search engines, especially Google, are picky: they limit the options plus they require properties. Examples everything MUST have a photo! And and address! And a publisher! If you don't believe me, try to make a resume with schema.org then see how opinion of the Google Structured Data Testing Tool about it.\nNo, Google. Not everything has an image - see http://textfiles.com Like it or not, a website doesn't need and address. The list goes on forever.\nI'm going to stop feeding it, stop feeding all of them, stop playing by their weird rules. HTML has link and meta elements, plus rel= property, so it can already represent the minimum, which is enough. Plus, again, there's microformats, and Google is still very happy with them6.\nNote: with structured data, in theory, one could pull in other vocabularies to overcome problems like nonexistent properties in one, but search engines are not real RDF parsers. Unless you're writing for academic publishing tools that will do so, don't bother.\nPick your format, and pick just one\nBetween 2003 and 2007 some tragic mud-throwing (mirror translated Hungarian phrase, just because it's pretty visual) was going on on the web, over something ridiculously small: my XML is better, than your XML! 7.\nWhen I first encountered with the whole \"feed\" idea itself, there was only RSS, and for a very long time, I was happy with it. Then I read opinions of people I listen to on how Atom is better. https://fed.brid.gy is Atom only. Much later someone on the internet popped the JSONFeed thought.\nWhen I first saw JSONFeed, I thought it's a joke. Turned out it's not, because there are simpletons who honestly believe the world will be better if things are JSON and not XML. It won't, it'll only result in things like JSON-LD\nIn the heat of the moment, I coined the thought of YAMLFeed8, strictly as a satire, but for a brief time I actually maintained a YAMLFeed file as well Do not follow my example.\nAnd then I found myself serving them all. I had a Category class in Python, that had JSONFeed and XMLFeedsubclasses, which latter had AtomFeed and RSSFeed subclasses, it used FeedParser to deal with it, and so on... in short, I made a monster.\nI went back an RSS 2.0 feed and a h-feed. The first can be made with the lxml library directly, and I always liked the RSS acronym.\nClosure\nIf you have a website in 2020, it's probably a hobby for you as well; don't let anything change that.\nIt should never become a burden, any part of it. It did for me, and I seriously considered firing up something like Microsoft FrontPage 98 to start from the proverbial scratch, but managed to salvage it before resulting to drastic measures.\nDon't follow trends. Once a solution grows deep enough roots - microformats, RSS, etc - it'll be around for a very long time.\nScrew SEO. If you're like me, and you write for yourself, and, maybe, for the small web9, don't bother trying to please an ever-changing power play.\nIf you want to learn something new, be careful not to embed it too deep - it may be a fast fading idea.\n\n\nhttps://exiftool.org/\u21a9\nhttps://pandoc.org/\u21a9\nhttps://indieweb.org/YAMLFeed\u21a9\nhttps://www.w3schools.com/html/html5_semantic_elements.asp\u21a9\nhttp://microformats.org/\u21a9\nhttps://aaronparecki.com/2016/12/17/8/owning-my-reviews#historical-recommendations\u21a9\nhttps://indieweb.org/RSS_Atom_wars\u21a9\nhttps://indieweb.org/YAMLFeed\u21a9\nhttps://neustadt.fr/essays/the-small-web/\u21a9"
    },
    "name": "Refactoring my static generator",
    "post-type": "article",
    "_id": "12055234",
    "_source": "268",
    "_is_read": true
}

A journey to the underworld that is RDF

{
    "type": "entry",
    "author": {
        "name": null,
        "url": "https://petermolnar.net/",
        "photo": null
    },
    "url": "https://petermolnar.net/article/web-of-the-machines/",
    "published": "2019-02-10T20:10:00+00:00",
    "content": {
        "html": "<img src=\"https://petermolnar.net/article/web-of-the-machines/rdf-it-does-not-spark-joy.jpg\" title=\"rdf-it-does-not-spark-joy.jpg\" alt=\"working with RDF - this one does not spark joy\" />\n    working 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/#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/#fn2\">2</a>. Last year, in August, I added microdata<a href=\"https://petermolnar.net/#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/#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/#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<img src=\"https://petermolnar.net/article/web-of-the-machines/gsdtt_microdata_error_01.png\" title=\"gsdtt_microdata_error_01.png\" alt=\"Interesting, it has some problems...\" />\n    Interesting, it has some problems...\n<img src=\"https://petermolnar.net/article/web-of-the-machines/gsdtt_microdata_error_02.png\" title=\"gsdtt_microdata_error_02.png\" alt=\"it says URL for org is missing... it's there. Line 13.\" />\n    it 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<img src=\"https://petermolnar.net/article/web-of-the-machines/gsdtt_rdfa_error_01.png\" title=\"gsdtt_rdfa_error_01.png\" alt=\"Undefined type, eh?\" />\n    Undefined type, eh?\n<img src=\"https://petermolnar.net/article/web-of-the-machines/gsdtt_rdfa_error_02.png\" title=\"gsdtt_rdfa_error_02.png\" alt=\"wat\" />\n    wat\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/#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<h2>Footnotes</h2>\n<p>Out of the blue, Maria from 3WhiteHats pinged me with an article of their on how to do structured data on your site<a href=\"https://petermolnar.net/#fn7\">7</a> - it's useful, and it's good, especially the troubleshooting at the bottom of the entry.</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/#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/#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/#fnref3\">\u21a9</a></p></li>\n<li><p><a href=\"https://www.ampproject.org/\">https://www.ampproject.org/</a><a href=\"https://petermolnar.net/#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/#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/#fnref6\">\u21a9</a></p></li>\n<li><p><a href=\"https://www.3whitehats.co.nz/knowledge/guide-to-structured-data-seo/\">https://www.3whitehats.co.nz/knowledge/guide-to-structured-data-seo/</a><a href=\"https://petermolnar.net/#fnref7\">\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    Interesting, it has some problems...\n\n    it 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    Undefined type, eh?\n\n    wat\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.\nFootnotes\nOut of the blue, Maria from 3WhiteHats pinged me with an article of their on how to do structured data on your site7 - it's useful, and it's good, especially the troubleshooting at the bottom of the entry.\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\nhttps://www.3whitehats.co.nz/knowledge/guide-to-structured-data-seo/\u21a9"
    },
    "name": "A journey to the underworld that is RDF",
    "post-type": "article",
    "_id": "12055272",
    "_source": "268",
    "_is_read": true
}

{
    "type": "entry",
    "published": "2020-05-30T20:51:53.51990-07:00",
    "url": "https://v2.jacky.wtf/post/b17e4a23-44d9-4c8f-9f6a-4e4cf9d2e5b5",
    "in-reply-to": [
        "https://twitter.com/Cambridgeport90/status/1266939257618403329"
    ],
    "content": {
        "text": "Well, the IndieWeb doesn\u2019t necessarily have like a devrel team to help build out things for each language / stack - it\u2019s been mostly on what people are coming in with. Like I was lucky to find a microformats2 parsing library in Elixir but I\u2019ve had to write everything else if I wanted it to be in Elixir as well.",
        "html": "<p>Well, the IndieWeb doesn\u2019t necessarily have like a devrel team to help build out things for each language / stack - it\u2019s been mostly on what people are coming in with. Like I was lucky to find a microformats2 parsing library in Elixir but I\u2019ve had to write everything else if I wanted it to be in Elixir as well.</p>"
    },
    "author": {
        "type": "card",
        "name": "",
        "url": "https://v2.jacky.wtf",
        "photo": null
    },
    "post-type": "reply",
    "refs": {
        "https://twitter.com/Cambridgeport90/status/1266939257618403329": {
            "type": "entry",
            "url": "https://twitter.com/Cambridgeport90/status/1266939257618403329",
            "content": {
                "text": "I find it odd ... just the fact that through it's history, the #IndieWeb has pretty much ignored #dotnet. I understand why at the beginning, but not now."
            },
            "author": {
                "type": "card",
                "name": "",
                "url": "https://v2.jacky.wtf/stream",
                "photo": null
            },
            "post-type": "note"
        }
    },
    "_id": "12021126",
    "_source": "1886",
    "_is_read": true
}

{
    "type": "entry",
    "published": "2020-05-30T20:44:55.46330-07:00",
    "url": "https://v2.jacky.wtf/post/084c1c15-76f4-4384-850b-ceaf81a22c54",
    "category": [
        "",
        "-adjacent"
    ],
    "in-reply-to": [
        "https://twitter.com/Cambridgeport90/status/1266905514027474949"
    ],
    "content": {
        "text": "If that does end up happening, let me know. I\u2019m comfortable with C# and would love to help see a C#-adjacent library for IndieWeb stuff come to light.",
        "html": "<p>If that does end up happening, let me know. I\u2019m comfortable with C<strong class=\"p-category\">#</strong> and would love to help see a C<strong class=\"p-category\">#-adjacent</strong> library for IndieWeb stuff come to light.</p>"
    },
    "author": {
        "type": "card",
        "name": "",
        "url": "https://v2.jacky.wtf",
        "photo": null
    },
    "post-type": "reply",
    "refs": {
        "https://twitter.com/Cambridgeport90/status/1266905514027474949": {
            "type": "entry",
            "url": "https://twitter.com/Cambridgeport90/status/1266905514027474949",
            "content": {
                "text": "I have a funny feeling that in order for whatever I end up using to have all required #IndieWeb features, it's going to end up being something custom. And hopefully #dotnet, as well."
            },
            "author": {
                "type": "card",
                "name": "",
                "url": "https://v2.jacky.wtf/stream",
                "photo": null
            },
            "post-type": "note"
        }
    },
    "_id": "12021127",
    "_source": "1886",
    "_is_read": true
}

Aaron Parecki aaronparecki.com

{
    "type": "entry",
    "published": "2020-05-30T14:08:47-07:00",
    "url": "https://aaronparecki.com/2020/05/30/22/pineblog",
    "category": [
        "webmention",
        "indieweb"
    ],
    "content": {
        "text": "This is fantastic! Pine.blog can now receive webmentions for you, and it'll show them to you in the timeline! This is probably the best option for static sites now! https://blog.pine.blog/2020/05/bring-us-your-static-sites-yearning-to-breathe-free/",
        "html": "This is fantastic! Pine.blog can now receive webmentions for you, and it'll show them to you in the timeline! This is probably the best option for static sites now! <a href=\"https://blog.pine.blog/2020/05/bring-us-your-static-sites-yearning-to-breathe-free/\"><span>https://</span>blog.pine.blog/2020/05/bring-us-your-static-sites-yearning-to-breathe-free/</a>"
    },
    "author": {
        "type": "card",
        "name": "Aaron Parecki",
        "url": "https://aaronparecki.com/",
        "photo": "https://aperture-media.p3k.io/aaronparecki.com/41061f9de825966faa22e9c42830e1d4a614a321213b4575b9488aa93f89817a.jpg"
    },
    "post-type": "note",
    "_id": "12013156",
    "_source": "16",
    "_is_read": true
}

ThreadReader app via Micropub to blog

{
    "type": "entry",
    "author": {
        "name": "<span class='p-author h-card'>allaboutgeorge</span>",
        "url": "https://www.allaboutgeorge.com/",
        "photo": null
    },
    "url": "https://www.allaboutgeorge.com/2020/05/29/threadreader-app-via-micropub-to-blog/",
    "published": "2020-05-29T19:08:41-08:00",
    "content": {
        "html": "<a href=\"https://boffosocko.com/2020/05/28/threadreaderapp-micropub-to-blog/\">ThreadReaderApp now has beta support for the Micropub Spec so you can publish Twitter threads directly to your blog</a> by <a href=\"https://boffosocko.com/\"><img src=\"https://secure.gravatar.com/avatar/d5fb4e498fe609cc29b04e5b7ad688c4?s=96&amp;d=identicon&amp;r=pg\" alt=\"Chris Aldrich\" />Chris Aldrich</a>\n<blockquote>So\u2026 a while back I tweeted about a bit of functionality I\u2019ve long thought would be a cool one to have for Twitter:\nhttps://twitter.com/ChrisAldrich/status/1236046889054654465\nI would often see people post tweetstorms, long threads of related tweets, to tell an extended story.\nInvariably people s...</blockquote>\n\nThis is cool, and an important reminder (of all weeks) that ways to share on Twitter needn\u2019t stay there",
        "text": "ThreadReaderApp now has beta support for the Micropub Spec so you can publish Twitter threads directly to your blog by Chris Aldrich\nSo\u2026 a while back I tweeted about a bit of functionality I\u2019ve long thought would be a cool one to have for Twitter:\nhttps://twitter.com/ChrisAldrich/status/1236046889054654465\nI would often see people post tweetstorms, long threads of related tweets, to tell an extended story.\nInvariably people s...\n\nThis is cool, and an important reminder (of all weeks) that ways to share on Twitter needn\u2019t stay there"
    },
    "name": "ThreadReader app via Micropub to blog",
    "post-type": "article",
    "_id": "11994389",
    "_source": "4592",
    "_is_read": true
}

{
    "type": "entry",
    "published": "2020-05-28T17:53:54.16049-07:00",
    "url": "https://v2.jacky.wtf/post/29362930-b34b-44de-8dd4-e0834fbbf2e8",
    "content": {
        "text": "Going to go live in about 10 minutes at https://jacky.wtf/twitch. Focusing on working on code coverage for my IndieWeb library for Elixir so definitely going to be either looking to splunk on good Elixir practices and what the IndieWeb suggests for behavior! Pull up in 10!",
        "html": "<p>Going to go live in about 10 minutes at <a href=\"https://jacky.wtf/twitch\">https://jacky.wtf/twitch</a>. Focusing on working on code coverage for my IndieWeb library for Elixir so definitely going to be either looking to splunk on good Elixir practices and what the IndieWeb suggests for behavior! Pull up in 10!</p>"
    },
    "author": {
        "type": "card",
        "name": "",
        "url": "https://v2.jacky.wtf",
        "photo": null
    },
    "post-type": "note",
    "_id": "11985920",
    "_source": "1886",
    "_is_read": true
}

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

Es ging nie um Matrix

{
    "type": "entry",
    "published": "2020-05-29T20:54:13+02:00",
    "url": "https://notiz.blog/2020/05/29/es-ging-nie-um-matrix/",
    "name": "Es ging nie um Matrix",
    "content": {
        "text": "Meine letzten beiden Blogposts wurden glaube ich etwas falsch verstanden, deshalb hier eine kleine Richtigstellung.\n\n\n\nIch hatte mich sehr gefreut (als ich f\u00e4lschlicherweise dachte hoffte), dass WordPress vielleicht Matrix kompatibel wird und ich hatte mich etwas ge\u00e4rgert, als sich dann herausstellte, dass es nie darum ging WordPress in die Matrix zu bringen.\n\n\n\nFrank hat mir dann auf Twitter geschrieben, dass es ja auch andere Wege gibt um ans gleiche Ziel zu kommen.\n\n\n\nIch ne, vielleicht per Trac in den core bringen.\n\n\n\n\u2026und Stefan hat es dann in den Kommentaren noch etwas konkretisiert.\n\n\n\nGenau! WordPress ist OpenSource. Was hindert uns dem Wunsch zur Vaterschaft zu verhelfen?!\n\n\n\nMacht Sinn! WordPress ist OpenSource Software und hat eine ziemlich umfassende Plugin API\u2026\n\n\n\nWarum also nicht einfach selber machen?\n\n\n\n\u2026und genau das ist die entscheidende Frage!\n\n\n\nMir ging es nie darum, dass speziell Matrix in WordPress integriert wird und ich war auch nie wirklich traurig, dass es nur ein Missverst\u00e4ndnis war. Ich bin nicht mal ein gro\u00dfer Fan von Matrix und es gibt eine ganze Reihe an Protokollen die ich viel liebe integriert sehen w\u00fcrde.\n\n\n\nIch hatte statt dessen gehofft, dass sich eine Firma wie Automattic f\u00fcr das Thema dezentrale Netze, Fediverse, IndieWeb, oder wie auch immer man es nennen will, interessieren k\u00f6nnte und sogar Geld in die Hand nehmen w\u00fcrde um WordPress zu einem Teil dieser Bewegung zu machen.\n\n\n\n\u201eSelber machen\u201c probiere ich jetzt seit DataPortability.org (also seit ungef\u00e4hr 2007/2008) mit nur m\u00e4\u00dfigem Erfolg. F\u00fcr ein Side-Project ist das Thema einfach zu gro\u00df und investieren will leider auch niemand so wirklich.\n\n\n\nNaja\u2026 vielleicht zieht ja irgendwann mein geheimer Masterplan \ud83d\ude09",
        "html": "<p>Meine letzten beiden Blogposts wurden glaube ich etwas falsch verstanden, deshalb hier eine kleine Richtigstellung.</p>\n\n\n\n<p><a href=\"https://notiz.blog/2020/05/24/wordpress-in-der-matrix/\">Ich hatte mich sehr gefreut</a> (als ich f\u00e4lschlicherweise dachte hoffte), dass WordPress vielleicht Matrix kompatibel wird und <a href=\"https://notiz.blog/2020/05/26/egal-matrix-is-eh-doof/\">ich hatte mich etwas ge\u00e4rgert</a>, als sich dann herausstellte, dass es nie darum ging WordPress in die Matrix zu bringen.</p>\n\n\n\n<p><a href=\"https://twitter.com/bueltge/status/1265355452927348737\">Frank</a> hat mir dann auf Twitter geschrieben, dass es ja auch andere Wege gibt um ans gleiche Ziel zu kommen.</p>\n\n\n\n<blockquote><p>Ich ne, vielleicht per Trac in den core bringen.</p></blockquote>\n\n\n\n<p>\u2026und <a href=\"https://notiz.blog/2020/05/26/egal-matrix-is-eh-doof/#comment-1168849\">Stefan</a> hat es dann in den Kommentaren noch etwas konkretisiert.</p>\n\n\n\n<blockquote><p>Genau! WordPress ist OpenSource. Was hindert uns dem Wunsch zur Vaterschaft zu verhelfen?!</p></blockquote>\n\n\n\n<p>Macht Sinn! WordPress ist OpenSource Software und hat eine ziemlich umfassende Plugin API\u2026</p>\n\n\n\n<p>Warum also nicht einfach selber machen?</p>\n\n\n\n<p><strong>\u2026und genau das ist die entscheidende Frage!</strong></p>\n\n\n\n<img src=\"https://notiz.blog/wp-content/uploads/2019/09/FediverseDiagram-700x709.png\" alt=\"\" width=\"350\" height=\"355\" />\n\n\n\n<p>Mir ging es nie darum, dass speziell <strong>Matrix</strong> in WordPress integriert wird und ich war auch nie wirklich traurig, dass es nur ein Missverst\u00e4ndnis war. Ich bin nicht mal ein gro\u00dfer Fan von Matrix und es gibt eine ganze Reihe an Protokollen die ich viel liebe integriert sehen w\u00fcrde.</p>\n\n\n\n<p>Ich hatte statt dessen gehofft, dass sich eine Firma wie Automattic f\u00fcr das Thema <em>dezentrale Netze</em>, <em>Fediverse</em>, <em>IndieWeb</em>, <em>oder wie auch immer man es nennen will</em>, interessieren k\u00f6nnte und sogar Geld in die Hand nehmen w\u00fcrde um WordPress zu einem Teil dieser Bewegung zu machen.</p>\n\n\n\n<p>\u201eSelber machen\u201c probiere ich jetzt seit <a href=\"https://notiz.blog/2007/11/19/dataportabilityorg/\">DataPortability.org</a> (also seit ungef\u00e4hr 2007/2008) mit nur m\u00e4\u00dfigem Erfolg. F\u00fcr ein Side-Project ist das Thema einfach zu gro\u00df und investieren will leider auch niemand so wirklich.</p>\n\n\n\n<p>Naja\u2026 vielleicht zieht ja irgendwann mein geheimer Masterplan \ud83d\ude09</p>"
    },
    "author": {
        "type": "card",
        "name": "Matthias Pfefferle",
        "url": "https://notiz.blog/author/matthias-pfefferle/",
        "photo": "https://secure.gravatar.com/avatar/75512bb584bbceae57dfc503692b16b2?s=40&d=mm&r=g"
    },
    "post-type": "article",
    "_id": "11983099",
    "_source": "206",
    "_is_read": true
}

Manton Reece www.manton.org

Closing the microblogging Slack

{
    "type": "entry",
    "author": {
        "name": "Manton Reece",
        "url": "https://www.manton.org/",
        "photo": "https://micro.blog/manton/avatar.jpg"
    },
    "url": "https://www.manton.org/2020/05/28/closing-the-microblogging.html",
    "name": "Closing the microblogging Slack",
    "content": {
        "html": "<p>Three years ago I created microblogging.slack.com to chat about indie microblogging and Micro.blog. There have been many great discussions in that time, and I appreciate everyone who has contributed or helped other members of the Micro.blog community. But to continue to improve Micro.blog regularly, I need to focus on fewer support channels.</p>\n\n<p>Daniel Jalkut and I talked about this <a href=\"https://coreint.org/2020/05/episode-421-replacing-it-with-nothing/\">on Core Intuition 421</a>. It is not sustainable for me to work on new Micro.blog features at the current pace as well as be responsive in Slack. If someone has a question about Micro.blog, I want to point them to the best place to get a thorough answer, and that\u2019s email.</p>\n\n<p>Slack also has a couple problems:</p>\n\n<ul><li>It\u2019s a proprietary platform that doesn\u2019t fit well with our goals for Micro.blog. For example, you can\u2019t have your own domain name for Slack, which makes migrating away very difficult.</li>\n<li>Because the search is limited to only recent messages, it is less useful as a resource to new members.</li>\n</ul><p>Last year, Jean MacDonald and I considered replacing Slack with Discourse. We may still do that, or it may be that forums around microblogging should best be run by the community rather than an official channel of Micro.blog. There is also a great <a href=\"https://chat.indieweb.org/\">IndieWeb chat</a> accessible via Slack.</p>\n\n<p>This weekend, I\u2019ll be closing the current Slack. I will export all the data for backup \u2014 just in case we want to rebuild it in the future, or make the messages searchable \u2014 and then I\u2019ll completely delete the Slack account, unless I can find a more elegant way to handle shutting it down or pausing it.</p>\n\n<p>Thanks again to everyone who has participated in the Slack community, sending feature requests, helping others with Hugo theme questions, and just being supportive of the mission of Micro.blog. See you on Micro.blog!</p>",
        "text": "Three years ago I created microblogging.slack.com to chat about indie microblogging and Micro.blog. There have been many great discussions in that time, and I appreciate everyone who has contributed or helped other members of the Micro.blog community. But to continue to improve Micro.blog regularly, I need to focus on fewer support channels.\n\nDaniel Jalkut and I talked about this on Core Intuition 421. It is not sustainable for me to work on new Micro.blog features at the current pace as well as be responsive in Slack. If someone has a question about Micro.blog, I want to point them to the best place to get a thorough answer, and that\u2019s email.\n\nSlack also has a couple problems:\n\nIt\u2019s a proprietary platform that doesn\u2019t fit well with our goals for Micro.blog. For example, you can\u2019t have your own domain name for Slack, which makes migrating away very difficult.\nBecause the search is limited to only recent messages, it is less useful as a resource to new members.\nLast year, Jean MacDonald and I considered replacing Slack with Discourse. We may still do that, or it may be that forums around microblogging should best be run by the community rather than an official channel of Micro.blog. There is also a great IndieWeb chat accessible via Slack.\n\nThis weekend, I\u2019ll be closing the current Slack. I will export all the data for backup \u2014 just in case we want to rebuild it in the future, or make the messages searchable \u2014 and then I\u2019ll completely delete the Slack account, unless I can find a more elegant way to handle shutting it down or pausing it.\n\nThanks again to everyone who has participated in the Slack community, sending feature requests, helping others with Hugo theme questions, and just being supportive of the mission of Micro.blog. See you on Micro.blog!"
    },
    "published": "2020-05-28T13:56:13-05:00",
    "category": [
        "Essays",
        "Podcasts"
    ],
    "post-type": "article",
    "_id": "11954306",
    "_source": "12",
    "_is_read": true
}

{
    "type": "entry",
    "published": "2020-05-27T23:23:03.68477-07:00",
    "url": "https://v2.jacky.wtf/post/979f783b-9aa7-49f7-b21d-0d4999f95744",
    "content": {
        "text": "I\u2019m getting an odd joy by working more on indieweb stuff because I feel that I can help people divest from environments that extract from us (our pain, our joy, anything) with little given back. Like I can see how this can help.",
        "html": "<p>I\u2019m getting an odd joy by working more on indieweb stuff because I feel that I can help people divest from environments that extract from us (our pain, our joy, anything) with little given back. Like I can see how this can help.</p>"
    },
    "author": {
        "type": "card",
        "name": "",
        "url": "https://v2.jacky.wtf",
        "photo": null
    },
    "post-type": "note",
    "_id": "11935683",
    "_source": "1886",
    "_is_read": true
}