This is my new favourite indie web site (super performant and responsive too).
{
"type": "entry",
"published": "2021-07-01T17:39:53Z",
"url": "https://adactio.com/links/18260",
"category": [
"indieweb",
"homepage",
"website",
"responsive",
"html",
"css",
"frontend",
"development"
],
"bookmark-of": [
"https://www.dianash.dev/"
],
"content": {
"text": "Diana Ashktorab\n\n\n\nThis is my new favourite indie web site (super performant and responsive too).",
"html": "<h3>\n<a class=\"p-name u-bookmark-of\" href=\"https://www.dianash.dev/\">\nDiana Ashktorab\n</a>\n</h3>\n\n<p>This is my new favourite indie web site (super performant and <a href=\"https://twitter.com/diana_ashktorab/status/1410646905789599758\">responsive</a> too).</p>"
},
"author": {
"type": "card",
"name": "Jeremy Keith",
"url": "https://adactio.com/",
"photo": "https://adactio.com/images/photo-150.jpg"
},
"post-type": "bookmark",
"_id": "21725702",
"_source": "2",
"_is_read": true
}
{
"type": "entry",
"published": "2021-06-28T10:41:22Z",
"url": "https://adactio.com/journal/18248",
"category": [
"coil",
"monetisation",
"micropayments",
"crypto",
"scams",
"scamming",
"ponzi",
"grifters",
"blockchain"
],
"syndication": [
"https://adactio.medium.com/c39831a4db9e"
],
"name": "ReCoil",
"content": {
"text": "On the Coil developers site there\u2019s a page proudly answering the question who is web monetized?\n\nYou\u2019ll some familiar sites in there: CSS Tricks, A List Apart, and even this humble website, adactio.com.\n\nBut lest you think that this social proof is in any way an endorsement, I should probably clarify what my experience with Coil has been like.\n\nCoil itself is grand. You get an identifier and you add it to your website in a meta element, much like you would do with indie web endpoints for webmentions or micropub.\n\nThe problem is with how you then actually get hold of any money that is owed to you from micropayments. Coil doesn\u2019t handle this directly. You have to set up a \u201cwallet\u201d with a third-party service and therein lies the problem.\n\nThey are all terrible.\n\nI\u2019m not talking about the hoops you have to jump through to set up an account. I get it. This is scary financial stuff so of course I\u2019ll need to scan my passport and hand over loads of information (more than is needed to open an actual bank account with, say, Monzo).\n\nNo, the problem is the stench of crypto. \n\nI tried Stronghold for a while. They really, really don\u2019t want you to use boring old-fashioned currencies like the euro or the pound. There\u2019s also Gatehub. Same. And there\u2019s Uphold. Also a shell game.\n\nI\u2019ve been using Coil and Uphold for a while now, and I\u2019ve amassed a grand total of \u00a36.06 \u2014 woo-hoo! So I log into my account and attempt to transfer that sweet, sweet monetisation and \u2026I can\u2019t.\n\n\n The amount needs to be greater than or equal to \u00a311.53 GBP\n\n\nBut I can still exchange that \u00a36.06 for magic beans like Bitcoin, XRP, and Ether.\n\nThe whole thing smells of grift and it feels icky to be in any way associated with it. I understand why Coil needs to partner with existing payment providers, but it would be nice if just one of them weren\u2019t propping up ponzi schemes. If anyone has found a way to get web monetisation to work without needing like you need to take a shower afterwards, I\u2019d love to hear about it.",
"html": "<p>On <a href=\"https://developers.coil.com/\">the Coil developers site</a> there\u2019s a page proudly answering the question <a href=\"https://developers.coil.com/community/who-is-web-monetized\">who is web monetized?</a></p>\n\n<p>You\u2019ll some familiar sites in there: CSS Tricks, A List Apart, and even this humble website, adactio.com.</p>\n\n<p>But lest you think that this social proof is in any way an endorsement, I should probably clarify what my experience with <a href=\"https://coil.com/\">Coil</a> has been like.</p>\n\n<p>Coil itself is grand. You get an identifier and you add it to your website in a <code>meta</code> element, much like you would do with indie web endpoints for webmentions or micropub.</p>\n\n<p>The problem is with how you then actually get hold of any money that is owed to you from micropayments. Coil doesn\u2019t handle this directly. You have to set up a \u201cwallet\u201d with a third-party service and therein lies the problem.</p>\n\n<p>They are all terrible.</p>\n\n<p>I\u2019m not talking about the hoops you have to jump through to set up an account. I get it. This is scary financial stuff so of course I\u2019ll need to scan my passport and hand over loads of information (more than is needed to open an <em>actual</em> bank account with, say, Monzo).</p>\n\n<p>No, the problem is the stench of crypto. </p>\n\n<p>I tried <a href=\"https://stronghold.co/\">Stronghold</a> for a while. They really, really don\u2019t want you to use boring old-fashioned currencies like the euro or the pound. There\u2019s also <a href=\"https://gatehub.net/\">Gatehub</a>. Same. And there\u2019s <a href=\"https://uphold.com/\">Uphold</a>. Also a shell game.</p>\n\n<p>I\u2019ve been using Coil and Uphold for a while now, and I\u2019ve amassed a grand total of \u00a36.06 \u2014 woo-hoo! So I log into my account and attempt to transfer that sweet, sweet monetisation and \u2026I can\u2019t.</p>\n\n<blockquote>\n <p>The amount needs to be greater than or equal to \u00a311.53 GBP</p>\n</blockquote>\n\n<p>But I can still exchange that \u00a36.06 for magic beans like Bitcoin, XRP, and Ether.</p>\n\n<p>The whole thing smells of grift and it feels icky to be in any way associated with it. I understand why Coil needs to partner with existing payment providers, but it would be nice if just one of them weren\u2019t <a href=\"https://davidgerard.co.uk/blockchain/2021/06/27/bitcoin-myths-immutability-decentralisation-and-the-cult-of-21-million/\">propping up ponzi schemes</a>. If anyone has found a way to get web monetisation to work without needing like you need to take a shower afterwards, I\u2019d love to hear about it.</p>"
},
"author": {
"type": "card",
"name": "Jeremy Keith",
"url": "https://adactio.com/",
"photo": "https://adactio.com/images/photo-150.jpg"
},
"post-type": "article",
"_id": "21634747",
"_source": "2",
"_is_read": true
}
{
"type": "entry",
"author": {
"name": "fluffy",
"url": "http://beesbuzz.biz/",
"photo": null
},
"url": "http://beesbuzz.biz/blog/12341-Private-friends-only-IndieWeb-stuff",
"published": "2021-06-27T10:32:40-07:00",
"content": {
"html": "<p>Yesterday I participated in the <a href=\"https://indieweb.org/2021/Pop-ups/Very_Sensitive_Data_on_Your_Personal_Website\">IndieWeb sensitive data pop-up</a>, or at least the first half of it (I had to disappear for my <a href=\"http://beesbuzz.biz/blog/7690-High-temperature-alert\">refrigerator delivery</a>). It was really great to have some further discussion about what people want out of this stuff and how we\u2019re all going to agree to get it.</p><h3><a href=\"http://beesbuzz.biz/blog/12341-Private-friends-only-IndieWeb-stuff#12341_h3_1_Authentication-stuff\"></a>Authentication stuff</h3><p>One of the biggest pain points that keeps on coming up is there being no support for people to be able to get private posts without having to log in or be notified about them in side channels. Lots of people are doing things like making pages with unguessable URLs and then doing side-channel notification, but that\u2019s unwieldy; fewer folks are doing things with actual login mechanisms.</p>\n\n\n<p>In Publ I support both approaches, and also templates are allowed to get <em>limited</em> data about unauthorized posts so that they can provide some sort of generic notification about unauthorized content. For example, in my Atom template I have the following:</p><pre><a href=\"http://beesbuzz.biz/blog/12341-Private-friends-only-IndieWeb-stuff#e12341cb1L1\"></a>{% for entry in view.entries(unauthorized=1 if not user else 0) %}\n<a href=\"http://beesbuzz.biz/blog/12341-Private-friends-only-IndieWeb-stuff#e12341cb1L2\"></a> <entry>\n<a href=\"http://beesbuzz.biz/blog/12341-Private-friends-only-IndieWeb-stuff#e12341cb1L3\"></a> {% if entry.authorized %}\n<a href=\"http://beesbuzz.biz/blog/12341-Private-friends-only-IndieWeb-stuff#e12341cb1L4\"></a> <title>{{'\ud83d\udd0f ' if entry.private else ''}}{{entry.category.name ~ \": \" if entry.category.name != category.name}}{{entry.title(markup=False, smartquotes=False)}}</title>\n<a href=\"http://beesbuzz.biz/blog/12341-Private-friends-only-IndieWeb-stuff#e12341cb1L5\"></a> <!-- the rest of the authorized entry metadata goes here -->\n<a href=\"http://beesbuzz.biz/blog/12341-Private-friends-only-IndieWeb-stuff#e12341cb1L6\"></a> <content type=\"html\"><![CDATA[\n<a href=\"http://beesbuzz.biz/blog/12341-Private-friends-only-IndieWeb-stuff#e12341cb1L7\"></a> {% if entry.private %}\n<a href=\"http://beesbuzz.biz/blog/12341-Private-friends-only-IndieWeb-stuff#e12341cb1L8\"></a> <aside><i><mark>Note:</mark> This is a private entry, so please use discretion in linking to it or mentioning it publicly. Thanks!</i></aside>\n<a href=\"http://beesbuzz.biz/blog/12341-Private-friends-only-IndieWeb-stuff#e12341cb1L9\"></a> {% endif %}\n<a href=\"http://beesbuzz.biz/blog/12341-Private-friends-only-IndieWeb-stuff#e12341cb1L10\"></a> <!-- The rest of the entry content goes here -->\n<a href=\"http://beesbuzz.biz/blog/12341-Private-friends-only-IndieWeb-stuff#e12341cb1L11\"></a> ]]></content>\n<a href=\"http://beesbuzz.biz/blog/12341-Private-friends-only-IndieWeb-stuff#e12341cb1L12\"></a> {% else %}\n<a href=\"http://beesbuzz.biz/blog/12341-Private-friends-only-IndieWeb-stuff#e12341cb1L13\"></a> <title>\ud83d\udd0f Private entry [{{entry.title(always_show=True).split()|join(attribute=0)}}]</title>\n<a href=\"http://beesbuzz.biz/blog/12341-Private-friends-only-IndieWeb-stuff#e12341cb1L14\"></a> <link href=\"{{ entry.permalink(absolute=True) }}\" rel=\"alternate\" type=\"text/html\" />\n<a href=\"http://beesbuzz.biz/blog/12341-Private-friends-only-IndieWeb-stuff#e12341cb1L15\"></a> <published>{{entry.date.isoformat()}}</published>\n<a href=\"http://beesbuzz.biz/blog/12341-Private-friends-only-IndieWeb-stuff#e12341cb1L16\"></a> <updated>{{entry.last_modified.isoformat()}}</updated>\n<a href=\"http://beesbuzz.biz/blog/12341-Private-friends-only-IndieWeb-stuff#e12341cb1L17\"></a> <id>urn:uuid:{{entry.uuid}}</id>\n<a href=\"http://beesbuzz.biz/blog/12341-Private-friends-only-IndieWeb-stuff#e12341cb1L18\"></a> <author><name>{{ entry.author if entry.author else \"fluffy\" }}</name></author>\n<a href=\"http://beesbuzz.biz/blog/12341-Private-friends-only-IndieWeb-stuff#e12341cb1L19\"></a> <content type=\"html\">This entry has a restricted audience.</content>\n<a href=\"http://beesbuzz.biz/blog/12341-Private-friends-only-IndieWeb-stuff#e12341cb1L20\"></a> {% endif %}\n<a href=\"http://beesbuzz.biz/blog/12341-Private-friends-only-IndieWeb-stuff#e12341cb1L21\"></a> </entry>\n<a href=\"http://beesbuzz.biz/blog/12341-Private-friends-only-IndieWeb-stuff#e12341cb1L22\"></a>{% endfor %}\n</pre><p>What this does is:</p>\n<ul><li><p>If the user (or their feed reader) is authorized to view the entry, show it directly</p><p>Further, if the entry has a privacy restriction, indicate that clearly in both the title and the <code><aside></code> blurb.</p></li>\n<li><p>If they are not authorized, show a stub entry that indicates that there is a private entry available</p><p>In this context, Publ limits the kind of data that\u2019s available for an entry, and takes a secure-by-default approach; <code>entry.permalink</code> can only generate slugless, categoryless short-links (e.g. <code>https://example.com/12345</code>), and <a href=\"https://github.com/PlaidWeb/Publ/blob/ee40cfcd388ee31b3e5c977b5ca326ce0af1e013/publ/entry.py#L620\">very few other metadata items</a> are available at all (basically just the bare minimum that\u2019s necessary for Atom feeds, really). <code>entry.title</code> will normally not be generated, but the <code>always_show=True</code> parameter overrides that, and in this case the feed template uses that to generate an initialism of the post title, just for the convenience of readers (for example, a post with a title of <code>This thing that keeps on PISSING ME OFF</code> will appear as <code>[TttkoPMO]</code> in the unauthorized feed).</p></li>\n</ul><p>Also, for an extra layer of leak-avoidance, Publ has to be told how many unauthorized entries to even allow in the view to begin with; <code>view.entries(unauthorized=1)</code> means only the most recent unauthorized entry will even get a stub. This way, random people can\u2019t see how many private posts I\u2019ve been making recently without a lot of work. (The <code>if not user</code> check is so that if someone is logged in, no stubs get generated at all \u2014 if someone\u2019s signed in there\u2019s no sense in telling them there\u2019s entries they still can\u2019t see!)</p><p>Granted, there are ways that they could figure out which days have private entries, or they could infer it by looking at the Twitter autoposts, or they could subscribe to my feed and log all the private posts that occur going forward, but I find this an acceptable tradeoff.</p><p>But! My hope is that this tradeoff won\u2019t be necessary forever. I\u2019ve long been very interested in supporting a protocol like <a href=\"https://indieweb.org/AutoAuth\">AutoAuth</a> or <a href=\"https://indieweb.org/IndieAuth_Ticket_Auth\">TicketAuth</a>. Neither has gotten a lot of traction, unfortunately; AutoAuth has one experimental implementation that I know of, and adding support to it requires a <em>significant</em> amount of agreement between a <em>lot</em> of moving parts (for example, it needs to be supported by the IndieAuth endpoint, its associated token endpoint, the feed reader, and the publisher), whereas TicketAuth seems a lot more feasible (as it only requires support from a purpose-specific TicketAuth endpoint and the publisher, and then the reader needs to be able to consume the ticket in some way, and also the publisher\u2019s side of things is much, much simpler). TicketAuth also only tries to answer the question about how a ticket gets sent in the first place, and doesn\u2019t make any specific interaction requirements on how a publisher opts to grant a ticket to a reader.</p><p>I already have most of the functionality in Publ for supporting TicketAuth; for example, there is full support for bearer tokens (want one? get it from your <a href=\"http://beesbuzz.biz/profile\">user profile</a>!) and if you already have a means of associating a bearer token with your feed fetcher, you can get fully-authenticated feeds already; for example, <code>curl https://beesbuzz.biz/feed -H 'Authorization: Bearer [TOKEN GOES HERE]'</code> \u2014 and this will work on any page request). What\u2019s missing is the actual token grant flow.</p><p>My <em>intention</em> has been that when someone logs in to my site, the profile parser (which lives in Authl) will see if there\u2019s a ticketauth endpoint and provide that to Publ, and if Publ sees that, it\u2019ll enqueue a ticket granting transaction. I was debating whether Publ should do the profile parsing itself with the hope that non-IndieAuth things support this (after all, that should be possible), but the possibility of that ever happening seems pretty remote, so it\u2019d be better to just have it live in the identity providers. Anyway, if hell freezes over and Twitter does support arbitrary federated social media endpoints, it\u2019d probably be in their user-specific JSON blob and not on the user profile page anyway, right?</p><p>Mastodon support seems less-remote, but Mastodon already has a different means of getting private posts (via ActivityPub delivery filtering), and supporting that would involve natively supporting ActivityPub, which is a <em>lot</em> of work, but something I do want to do\u2026 someday\u2026 eventually\u2026</p><p>I\u2019ve also been wanting to hack a TicketAuth endpoint into <a href=\"https://github.com/fluffy-critter/Feed-on-Feeds\">Feed-on-Feeds</a>, but its security model makes that a really bad idea. Improving the security model is one of my many goals for <a href=\"https://github.com/PlaidWeb/Subl/\">Subl</a>, which I swear I\u2019ll get around to working on someday. I suppose that adding bearer token support to FoF is possible, but it\u2019d have the caveat that FoF doesn\u2019t have any means of doing per-user data on a feed or any way of doing a per-user subscription, and it seems really risky to allow this on a multi-user installation. I suppose I could hack it in for my own personal uses but it just seems like a <em>gigantic</em> privacy risk right now. So I\u2019d rather not.</p><p>Anyway. The lack of TicketAuth support has been a big chicken-egg situation; I\u2019ve been really wanting to implement the publisher side of TicketAuth, but with no receivers out there it just didn\u2019t feel like a worthwhile time investment. But! As a result of yesterday\u2019s popup, several folks (including <a href=\"https://david.shanske.com/2021/06/27/thinking-about-ticket-auth/\">David Shansky</a>) have voiced support towards implementing a TicketAuth endpoint, which at least provides an initial test case for this.</p><p>To reiterate what David said:</p>\n<blockquote>\n<p>But first things first. Let\u2019s build something.</p></blockquote>\n<p>I absolutely promise that I will build TicketAuth publishing into Publ, and when someone has built a TicketAuth endpoint I will work with them to make sure it actually works.</p><p>Heck, I should build a standalone TicketAuth endpoint just as a proof-of-concept. And for testing. And so on.</p><p>Yeah. Let\u2019s build something.</p><h3><a href=\"http://beesbuzz.biz/blog/12341-Private-friends-only-IndieWeb-stuff#12341_h3_2_Other-content-limiting-stuff\"></a>Other content limiting stuff</h3><p>Another topic which came up is the desire to have an entry have different content visible to different viewers; for example, friends can see \u201cI went out to lunch with Barack Obama\u201d while others can only see \u201cI went out to lunch with a well-known politician.\u201d Back in the day when I was running Movable Type and had all sorts of unwieldy hacks for friends-only access, I was able to do this, as an additional layer of hacks.</p><p>Since my MT templates were still statically-generating files which happened to be PHP, I could put something like this into my entries:</p><pre><a href=\"http://beesbuzz.biz/blog/12341-Private-friends-only-IndieWeb-stuff#e12341cb2L1\"></a>Today I had lunch with <?= $user_friend ? \"Barack Obama\" : \"a well-known politician\" ?>\n</pre><p>and it would work. Or at least it did until DreamHost beefed up their <code>mod_security</code> settings and detected this as a PHP injection attack (which, to be fair, <em>it was</em>).</p><p>Publ doesn\u2019t have any current support for inline conditional content, although I\u2019d be tempted to try adding it. I sort of want to hold off on markup-related extensions until I get around to <a href=\"https://github.com/PlaidWeb/Publ/issues/261\">switching to a more flexible Markdown processor</a>, although I suppose this sort of thing would be better served in the entry body parser anyway. Like maybe adding a custom XMLish tag that runs blocks through Jinja before handing it off to the actual renderer. That would be tricky to do right though, and I\u2019m not sure how much benefit there\u2019d be.</p><p>That said, Publ <em>does</em> have an incredibly unwieldy mechanism that could be used for this sort of thing, in the form of entry attachments. Right now I only use attachments for comic transcripts, but one of the intended use cases would be to provide \u201ccut\u201d sections, and since attachments get the same per-entry security model (since attachments are just entries) it\u2019d be possible to have my content block be something like:</p><pre>{{entry.body}}\n\n{% for attach in entry.attachments(order='title') %}\n{{attach.body}}\n{% endfor %}\n</pre><p>and then have different versions of attachments for different permission types. I don\u2019t really know of a good way to do the fallback, though, and managing this from the UX standpoint would be ridiculous. (There\u2019s also a few other things I want to rework with attachments anyway, like it should be possible for something to attach itself to something else, rather than requiring an entry to declare its attachments.)</p>\n\n<p><a href=\"http://beesbuzz.biz/blog/12341-Private-friends-only-IndieWeb-stuff#comments\">comments</a></p>",
"text": "Yesterday I participated in the IndieWeb sensitive data pop-up, or at least the first half of it (I had to disappear for my refrigerator delivery). It was really great to have some further discussion about what people want out of this stuff and how we\u2019re all going to agree to get it.Authentication stuffOne of the biggest pain points that keeps on coming up is there being no support for people to be able to get private posts without having to log in or be notified about them in side channels. Lots of people are doing things like making pages with unguessable URLs and then doing side-channel notification, but that\u2019s unwieldy; fewer folks are doing things with actual login mechanisms.\n\n\nIn Publ I support both approaches, and also templates are allowed to get limited data about unauthorized posts so that they can provide some sort of generic notification about unauthorized content. For example, in my Atom template I have the following:{% for entry in view.entries(unauthorized=1 if not user else 0) %}\n <entry>\n {% if entry.authorized %}\n <title>{{'\ud83d\udd0f ' if entry.private else ''}}{{entry.category.name ~ \": \" if entry.category.name != category.name}}{{entry.title(markup=False, smartquotes=False)}}</title>\n <!-- the rest of the authorized entry metadata goes here -->\n <content type=\"html\"><![CDATA[\n {% if entry.private %}\n <aside><i><mark>Note:</mark> This is a private entry, so please use discretion in linking to it or mentioning it publicly. Thanks!</i></aside>\n {% endif %}\n <!-- The rest of the entry content goes here -->\n ]]></content>\n {% else %}\n <title>\ud83d\udd0f Private entry [{{entry.title(always_show=True).split()|join(attribute=0)}}]</title>\n <link href=\"{{ entry.permalink(absolute=True) }}\" rel=\"alternate\" type=\"text/html\" />\n <published>{{entry.date.isoformat()}}</published>\n <updated>{{entry.last_modified.isoformat()}}</updated>\n <id>urn:uuid:{{entry.uuid}}</id>\n <author><name>{{ entry.author if entry.author else \"fluffy\" }}</name></author>\n <content type=\"html\">This entry has a restricted audience.</content>\n {% endif %}\n </entry>\n{% endfor %}\nWhat this does is:\nIf the user (or their feed reader) is authorized to view the entry, show it directlyFurther, if the entry has a privacy restriction, indicate that clearly in both the title and the <aside> blurb.\nIf they are not authorized, show a stub entry that indicates that there is a private entry availableIn this context, Publ limits the kind of data that\u2019s available for an entry, and takes a secure-by-default approach; entry.permalink can only generate slugless, categoryless short-links (e.g. https://example.com/12345), and very few other metadata items are available at all (basically just the bare minimum that\u2019s necessary for Atom feeds, really). entry.title will normally not be generated, but the always_show=True parameter overrides that, and in this case the feed template uses that to generate an initialism of the post title, just for the convenience of readers (for example, a post with a title of This thing that keeps on PISSING ME OFF will appear as [TttkoPMO] in the unauthorized feed).\nAlso, for an extra layer of leak-avoidance, Publ has to be told how many unauthorized entries to even allow in the view to begin with; view.entries(unauthorized=1) means only the most recent unauthorized entry will even get a stub. This way, random people can\u2019t see how many private posts I\u2019ve been making recently without a lot of work. (The if not user check is so that if someone is logged in, no stubs get generated at all \u2014 if someone\u2019s signed in there\u2019s no sense in telling them there\u2019s entries they still can\u2019t see!)Granted, there are ways that they could figure out which days have private entries, or they could infer it by looking at the Twitter autoposts, or they could subscribe to my feed and log all the private posts that occur going forward, but I find this an acceptable tradeoff.But! My hope is that this tradeoff won\u2019t be necessary forever. I\u2019ve long been very interested in supporting a protocol like AutoAuth or TicketAuth. Neither has gotten a lot of traction, unfortunately; AutoAuth has one experimental implementation that I know of, and adding support to it requires a significant amount of agreement between a lot of moving parts (for example, it needs to be supported by the IndieAuth endpoint, its associated token endpoint, the feed reader, and the publisher), whereas TicketAuth seems a lot more feasible (as it only requires support from a purpose-specific TicketAuth endpoint and the publisher, and then the reader needs to be able to consume the ticket in some way, and also the publisher\u2019s side of things is much, much simpler). TicketAuth also only tries to answer the question about how a ticket gets sent in the first place, and doesn\u2019t make any specific interaction requirements on how a publisher opts to grant a ticket to a reader.I already have most of the functionality in Publ for supporting TicketAuth; for example, there is full support for bearer tokens (want one? get it from your user profile!) and if you already have a means of associating a bearer token with your feed fetcher, you can get fully-authenticated feeds already; for example, curl https://beesbuzz.biz/feed -H 'Authorization: Bearer [TOKEN GOES HERE]' \u2014 and this will work on any page request). What\u2019s missing is the actual token grant flow.My intention has been that when someone logs in to my site, the profile parser (which lives in Authl) will see if there\u2019s a ticketauth endpoint and provide that to Publ, and if Publ sees that, it\u2019ll enqueue a ticket granting transaction. I was debating whether Publ should do the profile parsing itself with the hope that non-IndieAuth things support this (after all, that should be possible), but the possibility of that ever happening seems pretty remote, so it\u2019d be better to just have it live in the identity providers. Anyway, if hell freezes over and Twitter does support arbitrary federated social media endpoints, it\u2019d probably be in their user-specific JSON blob and not on the user profile page anyway, right?Mastodon support seems less-remote, but Mastodon already has a different means of getting private posts (via ActivityPub delivery filtering), and supporting that would involve natively supporting ActivityPub, which is a lot of work, but something I do want to do\u2026 someday\u2026 eventually\u2026I\u2019ve also been wanting to hack a TicketAuth endpoint into Feed-on-Feeds, but its security model makes that a really bad idea. Improving the security model is one of my many goals for Subl, which I swear I\u2019ll get around to working on someday. I suppose that adding bearer token support to FoF is possible, but it\u2019d have the caveat that FoF doesn\u2019t have any means of doing per-user data on a feed or any way of doing a per-user subscription, and it seems really risky to allow this on a multi-user installation. I suppose I could hack it in for my own personal uses but it just seems like a gigantic privacy risk right now. So I\u2019d rather not.Anyway. The lack of TicketAuth support has been a big chicken-egg situation; I\u2019ve been really wanting to implement the publisher side of TicketAuth, but with no receivers out there it just didn\u2019t feel like a worthwhile time investment. But! As a result of yesterday\u2019s popup, several folks (including David Shansky) have voiced support towards implementing a TicketAuth endpoint, which at least provides an initial test case for this.To reiterate what David said:\n\nBut first things first. Let\u2019s build something.\nI absolutely promise that I will build TicketAuth publishing into Publ, and when someone has built a TicketAuth endpoint I will work with them to make sure it actually works.Heck, I should build a standalone TicketAuth endpoint just as a proof-of-concept. And for testing. And so on.Yeah. Let\u2019s build something.Other content limiting stuffAnother topic which came up is the desire to have an entry have different content visible to different viewers; for example, friends can see \u201cI went out to lunch with Barack Obama\u201d while others can only see \u201cI went out to lunch with a well-known politician.\u201d Back in the day when I was running Movable Type and had all sorts of unwieldy hacks for friends-only access, I was able to do this, as an additional layer of hacks.Since my MT templates were still statically-generating files which happened to be PHP, I could put something like this into my entries:Today I had lunch with <?= $user_friend ? \"Barack Obama\" : \"a well-known politician\" ?>\nand it would work. Or at least it did until DreamHost beefed up their mod_security settings and detected this as a PHP injection attack (which, to be fair, it was).Publ doesn\u2019t have any current support for inline conditional content, although I\u2019d be tempted to try adding it. I sort of want to hold off on markup-related extensions until I get around to switching to a more flexible Markdown processor, although I suppose this sort of thing would be better served in the entry body parser anyway. Like maybe adding a custom XMLish tag that runs blocks through Jinja before handing it off to the actual renderer. That would be tricky to do right though, and I\u2019m not sure how much benefit there\u2019d be.That said, Publ does have an incredibly unwieldy mechanism that could be used for this sort of thing, in the form of entry attachments. Right now I only use attachments for comic transcripts, but one of the intended use cases would be to provide \u201ccut\u201d sections, and since attachments get the same per-entry security model (since attachments are just entries) it\u2019d be possible to have my content block be something like:{{entry.body}}\n\n{% for attach in entry.attachments(order='title') %}\n{{attach.body}}\n{% endfor %}\nand then have different versions of attachments for different permission types. I don\u2019t really know of a good way to do the fallback, though, and managing this from the UX standpoint would be ridiculous. (There\u2019s also a few other things I want to rework with attachments anyway, like it should be possible for something to attach itself to something else, rather than requiring an entry to declare its attachments.)\n\ncomments"
},
"name": "fluffy rambles: Private, friends-only, IndieWeb stuff",
"post-type": "article",
"_id": "21620448",
"_source": "3782",
"_is_read": true
}
After today's IndieWebCamp popup session, I built a way to create unlisted posts on my site that require a secret key in the URL in order to view.
Since all my URLs are more or less sequential, I needed a way to be able to add something to the URL that is unguessable. It was a relatively easy thing to add!
Try viewing this post without the secret string at the end to see the feature in action: https://aaronparecki.com/2021/06/26/9/MXJEJKW
{
"type": "entry",
"published": "2021-06-26T13:45:18-07:00",
"url": "https://aaronparecki.com/2021/06/26/10/secret-posts",
"category": [
"indieweb",
"secret"
],
"content": {
"text": "After today's IndieWebCamp popup session, I built a way to create unlisted posts on my site that require a secret key in the URL in order to view.\n\nSince all my URLs are more or less sequential, I needed a way to be able to add something to the URL that is unguessable. It was a relatively easy thing to add!\n\nTry viewing this post without the secret string at the end to see the feature in action: https://aaronparecki.com/2021/06/26/9/MXJEJKW",
"html": "<p>After <a href=\"https://events.indieweb.org/2021/06/indiewebcamp-popup-sensitive-data-on-your-personal-website-DNjCEi05jHfH\">today's IndieWebCamp popup session</a>, I built a way to create unlisted posts on my site that require a secret key in the URL in order to view.</p>\n\n<p>Since all my URLs are more or less sequential, I needed a way to be able to add something to the URL that is unguessable. It was a relatively easy thing to add!</p>\n\n<p>Try viewing this post without the secret string at the end to see the feature in action: <a href=\"https://aaronparecki.com/2021/06/26/9/MXJEJKW\">https://aaronparecki.com/2021/06/26/9/MXJEJKW</a></p>"
},
"author": {
"type": "card",
"name": "Aaron Parecki",
"url": "https://aaronparecki.com/",
"photo": "https://aperture-media.p3k.io/aaronparecki.com/41061f9de825966faa22e9c42830e1d4a614a321213b4575b9488aa93f89817a.jpg"
},
"post-type": "note",
"_id": "21602693",
"_source": "16",
"_is_read": true
}
New #indieweb libraries: taproot/micropub-adapter and taproot/indieauth!
Finally put the finishing touches on these two closely-related libraries, which make it very easy to add Micropub and IndieAuth support to any PHP app which uses PSR-7.
Feedback appreciated, either as replies, GH issues, or at indieweb.org/discuss
{
"type": "entry",
"published": "2021-06-24T15:01:20+03:00",
"summary": "New #indieweb libraries: taproot/micropub-adapter and taproot/indieauth!\nFinally put the finishing touches on these two closely-related libraries, which make it very easy to add Micropub and IndieAuth support to any PHP app which uses PSR-7.\nFeedback appreciated, either as replies, GH issues, or at indieweb.org/discuss",
"url": "https://waterpigs.co.uk/notes/5DNF1L/",
"content": {
"text": "New #indieweb libraries: taproot/micropub-adapter and taproot/indieauth!\n\nFinally put the finishing touches on these two closely-related libraries, which make it very easy to add Micropub and IndieAuth support to any PHP app which uses PSR-7.\n\nFeedback appreciated, either as replies, GH issues, or at indieweb.org/discuss",
"html": "<p>New <a href=\"https://waterpigs.co.uk/tags/indieweb\">#indieweb</a> libraries: <a href=\"https://github.com/Taproot/micropub-adapter\">taproot/micropub-adapter</a> and <a href=\"https://github.com/Taproot/indieauth\">taproot/indieauth</a>!</p>\n\n<p>Finally put the finishing touches on these two closely-related libraries, which make it very easy to add <a href=\"https://indieweb.org/Micropub\">Micropub</a> and <a href=\"https://indieweb.org/IndieAuth\">IndieAuth</a> support to any PHP app which uses PSR-7.</p>\n\n<p>Feedback appreciated, either as replies, GH issues, or at <a href=\"http://indieweb.org/discuss\">indieweb.org/discuss</a></p>"
},
"author": {
"type": "card",
"name": "Barnaby Walters",
"url": "https://waterpigs.co.uk",
"photo": "https://waterpigs.co.uk/photo-2021-04-22.jpg"
},
"post-type": "note",
"_id": "21546400",
"_source": "188",
"_is_read": true
}
It’s like an IndieWeb thing probably!
{
"type": "entry",
"published": "2021-06-23T15:27:24-0400",
"url": "https://martymcgui.re/2021/06/23/152724/",
"photo": [
"https://res.cloudinary.com/schmarty/image/fetch/w_960,c_fill/https://media.martymcgui.re/9d/d3/01/3b/1e0afc1cedfa18a2226aa834c3bb8dab2ef5be604d60cc5560e503af.jpg"
],
"content": {
"text": "It\u2019s like an IndieWeb thing probably!",
"html": "<a href=\"https://media.martymcgui.re/9d/d3/01/3b/1e0afc1cedfa18a2226aa834c3bb8dab2ef5be604d60cc5560e503af.jpg\"></a>\n\n <p>It\u2019s like an IndieWeb thing probably!</p>"
},
"author": {
"type": "card",
"name": "Marty McGuire",
"url": "https://martymcgui.re/",
"photo": "https://martymcgui.re/images/logo.jpg"
},
"post-type": "photo",
"_id": "21523459",
"_source": "175",
"_is_read": true
}
{
"type": "entry",
"author": {
"name": "Manton Reece",
"url": "https://www.manton.org/",
"photo": "https://micro.blog/manton/avatar.jpg"
},
"url": "https://www.manton.org/2021/06/17/building-on-the.html",
"name": "Building on the Micro.blog books API",
"content": {
"html": "<p>Since <a href=\"https://www.manton.org/2021/05/11/bookshelves-beta-for.html\">launching the bookshelves feature</a> in Micro.blog on the web, I\u2019ve been wondering whether we should build a native interface for this in the Micro.blog app. My answer: no. Books are so unique that it feels like they need a dedicated app, just like there is a native app for Goodreads on iOS and Android. Native apps could make it easy to quickly mark a book as \u201cfinished reading\u201d, or provide fun features like barcode scanning from the phone camera.</p>\n\n<p>You can make a pretty strong case that we already have <em>too many</em> official iOS apps: Micro.blog, Sunlit, and Wavelength. Books seems like a great third-party opportunity instead.</p>\n\n<p>I\u2019ve documented the <a href=\"https://help.micro.blog/t/json-api-books/545/2\">bookshelves API in the Help Center</a>. It can do most of what Micro.blog on the web does, with the notable exception of book search. If you are building a books app, you\u2019ll need to \u201cbring your own\u201d book search from Open Library, ISBNdb, Google Books, Amazon, or wherever.</p>\n\n<p>A theoretical app built on Micro.blog could let the user sign in with their Micro.blog account <a href=\"https://help.micro.blog/t/indieauth/99\">using IndieAuth</a>. Then the app could get the user\u2019s bookshelves, add new books, or post to their blog with a link to the book.</p>\n\n<p>Like most of Micro.blog, the API is based on JSON Feed. Lists of bookshelves and books are just JSON Feed with a little bit of extra data like <code>isbn</code> in a namespace field. When Micro.blog has the book cover, it\u2019s included in <code>image</code>.</p>\n\n<p>There have been some <a href=\"https://tomcritchlow.com/2020/04/15/library-json/\">interesting experiments with custom JSON formats</a> or even <a href=\"https://www.zylstra.org/blog/2021/05/federated-bookshelf-proof-of-concept/\">based on OPML</a>, but as I was reviewing these it seemed like an unusual departure for Micro.blog to not use JSON Feed. We can consider adding additional formats later.</p>\n\n<p>I\u2019m happy to support whoever wants to tackle this. <a href=\"https://jonhays.me/\">Jon Hays</a> suggested a hackathon for people to get together and tinker with the API, or build an app together. What do y\u2019all think?</p>\n\n<p>In addition to the Micro.blog API, another area where we could experiment is an app that connects bookshelf data from independent web sites. For Micro.blog-hosted blogs, the bookshelves are <a href=\"https://help.micro.blog/t/bookshelves/515\">available via Hugo templates</a>, so it\u2019s possible to generate HTML pages that include Microformats. <a href=\"https://indieweb.org/read\">See the IndieWeb wiki</a> for some prior art about this.</p>",
"text": "Since launching the bookshelves feature in Micro.blog on the web, I\u2019ve been wondering whether we should build a native interface for this in the Micro.blog app. My answer: no. Books are so unique that it feels like they need a dedicated app, just like there is a native app for Goodreads on iOS and Android. Native apps could make it easy to quickly mark a book as \u201cfinished reading\u201d, or provide fun features like barcode scanning from the phone camera.\n\nYou can make a pretty strong case that we already have too many official iOS apps: Micro.blog, Sunlit, and Wavelength. Books seems like a great third-party opportunity instead.\n\nI\u2019ve documented the bookshelves API in the Help Center. It can do most of what Micro.blog on the web does, with the notable exception of book search. If you are building a books app, you\u2019ll need to \u201cbring your own\u201d book search from Open Library, ISBNdb, Google Books, Amazon, or wherever.\n\nA theoretical app built on Micro.blog could let the user sign in with their Micro.blog account using IndieAuth. Then the app could get the user\u2019s bookshelves, add new books, or post to their blog with a link to the book.\n\nLike most of Micro.blog, the API is based on JSON Feed. Lists of bookshelves and books are just JSON Feed with a little bit of extra data like isbn in a namespace field. When Micro.blog has the book cover, it\u2019s included in image.\n\nThere have been some interesting experiments with custom JSON formats or even based on OPML, but as I was reviewing these it seemed like an unusual departure for Micro.blog to not use JSON Feed. We can consider adding additional formats later.\n\nI\u2019m happy to support whoever wants to tackle this. Jon Hays suggested a hackathon for people to get together and tinker with the API, or build an app together. What do y\u2019all think?\n\nIn addition to the Micro.blog API, another area where we could experiment is an app that connects bookshelf data from independent web sites. For Micro.blog-hosted blogs, the bookshelves are available via Hugo templates, so it\u2019s possible to generate HTML pages that include Microformats. See the IndieWeb wiki for some prior art about this."
},
"published": "2021-06-17T08:29:27-05:00",
"category": [
"Essays"
],
"post-type": "article",
"_id": "21369249",
"_source": "12",
"_is_read": true
}
I hooked up my bookmarks from Notion to automatically post to my site via micropub. The micropub standard makes this really easy. And Known lets you subscribe to just the content of your choice - so if you want just my posts, or just my links, you can get that.
{
"type": "entry",
"published": "2021-06-15T16:24:35+00:00",
"url": "https://werd.io/2021/i-hooked-up-my-bookmarks-from-notion",
"content": {
"text": "I hooked up my bookmarks from Notion to automatically post to my site via micropub. The micropub standard makes this really easy. And Known lets you subscribe to just the content of your choice - so if you want just my posts, or just my links, you can get that."
},
"author": {
"type": "card",
"name": "Ben Werdm\u00fcller",
"url": "https://werd.io/profile/benwerd",
"photo": "https://werd.io/file/5d388c5fb16ea14aac640912/thumb.jpg"
},
"post-type": "note",
"_id": "21316965",
"_source": "191",
"_is_read": true
}
PHPUnit’s HTML code coverage reports don’t play nicely with GitHub pages “main branch /docs folder” by default, as they store CSS, JS and icon assets in folders prefixed with underscores.
Here’s a little bash script to run tests with code coverage enabled, then move the assets around:
rm -rf docs/coverage/
XDEBUG_MODE=coverage ./vendor/bin/phpunit tests --coverage-filter src --coverage-html docs/coverage
mv docs/coverage/_css docs/coverage/phpunit_css
mv docs/coverage/_icons docs/coverage/phpunit_icons
mv docs/coverage/_js docs/coverage/phpunit_js
grep -rl _css docs/coverage | xargs sed -i "" -e 's/_css/phpunit_css/g'
grep -rl _icons docs/coverage | xargs sed -i "" -e 's/_icons/phpunit_icons/g'
grep -rl _js docs/coverage | xargs sed -i "" -e 's/_js/phpunit_js/g'
That allows you to use GitHub pages to show code coverage reports as well as docs, as I’m doing for taproot/indieauth.
{
"type": "entry",
"published": "2021-06-13T16:59:09+03:00",
"summary": "PHPUnit\u2019s HTML code coverage reports don\u2019t play nicely with GitHub pages \u201cmain branch /docs folder\u201d by default, as they store CSS, JS and icon assets in folders prefixed with underscores.\nHere\u2019s a little bash script to run tests with code coverage enabled, then move the assets around: rm -rf docs/coverage/ XDEBUG_MODE=coverage ./vendor/bin/phpunit tests --coverage-filter src --coverage-html docs/coverage mv docs/coverage/_css docs/coverage/phpunit_css mv docs/coverage/_icons docs/coverage/phpunit_icons mv docs/coverage/_js docs/coverage/phpunit_js grep -rl _css docs/coverage | xargs sed -i \"\" -e 's/_css/phpunit_css/g' grep -rl _icons docs/coverage | xargs sed -i \"\" -e 's/_icons/phpunit_icons/g' grep -rl _js docs/coverage | xargs sed -i \"\" -e 's/_js/phpunit_js/g'\nThat allows you to use GitHub pages to show code coverage reports as well as docs, as I\u2019m doing for taproot/indieauth.",
"url": "https://waterpigs.co.uk/notes/5DBGz9/",
"content": {
"text": "PHPUnit\u2019s HTML code coverage reports don\u2019t play nicely with GitHub pages \u201cmain branch /docs folder\u201d by default, as they store CSS, JS and icon assets in folders prefixed with underscores.\n\nHere\u2019s a little bash script to run tests with code coverage enabled, then move the assets around:\n\nrm -rf docs/coverage/\nXDEBUG_MODE=coverage ./vendor/bin/phpunit tests --coverage-filter src --coverage-html docs/coverage\nmv docs/coverage/_css docs/coverage/phpunit_css\nmv docs/coverage/_icons docs/coverage/phpunit_icons\nmv docs/coverage/_js docs/coverage/phpunit_js\ngrep -rl _css docs/coverage | xargs sed -i \"\" -e 's/_css/phpunit_css/g'\ngrep -rl _icons docs/coverage | xargs sed -i \"\" -e 's/_icons/phpunit_icons/g'\ngrep -rl _js docs/coverage | xargs sed -i \"\" -e 's/_js/phpunit_js/g'\n\n\nThat allows you to use GitHub pages to show code coverage reports as well as docs, as I\u2019m doing for taproot/indieauth.",
"html": "<p>PHPUnit\u2019s HTML code coverage reports don\u2019t play nicely with GitHub pages \u201cmain branch /docs folder\u201d by default, as they store CSS, JS and icon assets in folders prefixed with underscores.</p>\n\n<p>Here\u2019s a little bash script to run tests with code coverage enabled, then move the assets around:</p>\n\n<pre><code>rm -rf docs/coverage/\nXDEBUG_MODE=coverage ./vendor/bin/phpunit tests --coverage-filter src --coverage-html docs/coverage\nmv docs/coverage/_css docs/coverage/phpunit_css\nmv docs/coverage/_icons docs/coverage/phpunit_icons\nmv docs/coverage/_js docs/coverage/phpunit_js\ngrep -rl _css docs/coverage | xargs sed -i \"\" -e 's/_css/phpunit_css/g'\ngrep -rl _icons docs/coverage | xargs sed -i \"\" -e 's/_icons/phpunit_icons/g'\ngrep -rl _js docs/coverage | xargs sed -i \"\" -e 's/_js/phpunit_js/g'\n</code></pre>\n\n<p>That allows you to use GitHub pages to show code coverage reports as well as docs, as I\u2019m doing <a href=\"https://taproot.github.io/indieauth/coverage/\">for taproot/indieauth</a>.</p>"
},
"author": {
"type": "card",
"name": "Barnaby Walters",
"url": "https://waterpigs.co.uk",
"photo": "https://waterpigs.co.uk/photo-2021-04-22.jpg"
},
"post-type": "note",
"_id": "21261568",
"_source": "188",
"_is_read": true
}
{
"type": "entry",
"published": "2021-06-08T10:06:07.061Z",
"url": "https://www.jvt.me/mf2/2021/06/fyejk/",
"category": [
"homebrew-website-club"
],
"content": {
"text": "Reminder that it's #HomebrewWebsiteClub Nottingham tomorrow! I hope to see you there at 1730 for some website stuff! https://events.indieweb.org/2021/06/homebrew-website-club-nottingham-pqX9qzmGWbHp",
"html": "<p>Reminder that it's <a href=\"https://www.jvt.me/tags/homebrew-website-club/\">#HomebrewWebsiteClub</a> Nottingham tomorrow! I hope to see you there at 1730 for some website stuff! <a href=\"https://events.indieweb.org/2021/06/homebrew-website-club-nottingham-pqX9qzmGWbHp\">https://events.indieweb.org/2021/06/homebrew-website-club-nottingham-pqX9qzmGWbHp</a></p>"
},
"author": {
"type": "card",
"name": "Jamie Tanna",
"url": "https://www.jvt.me",
"photo": "https://www.jvt.me/img/profile.png"
},
"post-type": "note",
"_id": "21122591",
"_source": "2169",
"_is_read": true
}
I think IndieWeb is an example of Nested-I and Ubuntu Rationality as per Free, Fair and Alive.
Not unrelatedly, Jack Jamieson’s dissertation on the IndieWeb is called Independent Together: Building and Maintaining Values in a Distributed Web Infrastructure.
Also on: social.coop
{
"type": "entry",
"author": {
"name": "Neil Mather",
"url": "https://doubleloop.net/",
"photo": null
},
"url": "https://doubleloop.net/2021/06/06/i-think-indieweb-is-an-example/",
"published": "2021-06-06T12:38:09+00:00",
"content": {
"html": "I think IndieWeb is an example of Nested-I and Ubuntu Rationality as per Free, Fair and Alive.\n<p>Not unrelatedly, Jack Jamieson\u2019s dissertation on the IndieWeb is called Independent Together: Building and Maintaining Values in a Distributed Web Infrastructure.</p>\nAlso on:<p><a href=\"https://social.coop/@neil/106363819973748731\"> social.coop</a></p>",
"text": "I think IndieWeb is an example of Nested-I and Ubuntu Rationality as per Free, Fair and Alive.\nNot unrelatedly, Jack Jamieson\u2019s dissertation on the IndieWeb is called Independent Together: Building and Maintaining Values in a Distributed Web Infrastructure.\nAlso on: social.coop"
},
"post-type": "note",
"_id": "21068944",
"_source": "1895",
"_is_read": true
}
Replied to https://adhoc.systems/replies/indieforum (adhoc.systems)
Yea that looks like a cool site! I hope it catches on, but we also have IndieNews and Indieweb.xyz and those have never really had huge usage.
Yea I think showing the replies inline makes it more interesting than just an aggregator to me. I hope it might stimulate some blogchains (https://doubleloop.net/2020/04/05/blogchains-and-hyperconversations/)
I kicked one off, if you’re interested! – https://www.indieforums.net/threads/c1c36e81a755848c.html
{
"type": "entry",
"author": {
"name": "Neil Mather",
"url": "https://doubleloop.net/",
"photo": null
},
"url": "https://doubleloop.net/2021/05/31/yea-i-think-showing-the-replies/",
"published": "2021-05-31T10:31:21+00:00",
"content": {
"html": "Replied to <a href=\"https://adhoc.systems/replies/indieforum\">https://adhoc.systems/replies/indieforum</a><em> (adhoc.systems)</em>\n<blockquote>Yea that looks like a cool site! I hope it catches on, but we also have IndieNews and Indieweb.xyz and those have never really had huge usage.</blockquote>\n\nYea I think showing the replies inline makes it more interesting than just an aggregator to me. I hope it might stimulate some blogchains (<a href=\"https://doubleloop.net/2020/04/05/blogchains-and-hyperconversations/\">https://doubleloop.net/2020/04/05/blogchains-and-hyperconversations/</a>)\n<p>I kicked one off, if you\u2019re interested! \u2013 <a href=\"https://www.indieforums.net/threads/c1c36e81a755848c.html\">https://www.indieforums.net/threads/c1c36e81a755848c.html</a></p>",
"text": "Replied to https://adhoc.systems/replies/indieforum (adhoc.systems)\nYea that looks like a cool site! I hope it catches on, but we also have IndieNews and Indieweb.xyz and those have never really had huge usage.\n\nYea I think showing the replies inline makes it more interesting than just an aggregator to me. I hope it might stimulate some blogchains (https://doubleloop.net/2020/04/05/blogchains-and-hyperconversations/)\nI kicked one off, if you\u2019re interested! \u2013 https://www.indieforums.net/threads/c1c36e81a755848c.html"
},
"post-type": "note",
"_id": "20903813",
"_source": "1895",
"_is_read": true
}
Hometown says on its wiki: "Also, if Hometown is going to be a universal reader, you’re going to need better control over organizing your feeds." That’s really interesting – same as the social reader idea in IndieWeb presumably. (I’ve imagined before a social reader in the Mastodon/TweetDeck style.)
https://github.com/hometown-fork/hometown/wiki/Exclusive-lists
Also on: social.coop
{
"type": "entry",
"author": {
"name": "Neil Mather",
"url": "https://doubleloop.net/",
"photo": null
},
"url": "https://doubleloop.net/2021/05/31/hometown-says-on-its-wiki-also/",
"published": "2021-05-31T10:11:40+00:00",
"content": {
"html": "Hometown says on its wiki: \"Also, if Hometown is going to be a universal reader, you\u2019re going to need better control over organizing your feeds.\" That\u2019s really interesting \u2013 same as the social reader idea in IndieWeb presumably. (I\u2019ve imagined before a social reader in the Mastodon/TweetDeck style.)\n<p><a href=\"https://github.com/hometown-fork/hometown/wiki/Exclusive-lists\">https://github.com/hometown-fork/hometown/wiki/Exclusive-lists</a></p>\nAlso on:<p><a href=\"https://social.coop/@neil/106329270063684683\"> social.coop</a></p>",
"text": "Hometown says on its wiki: \"Also, if Hometown is going to be a universal reader, you\u2019re going to need better control over organizing your feeds.\" That\u2019s really interesting \u2013 same as the social reader idea in IndieWeb presumably. (I\u2019ve imagined before a social reader in the Mastodon/TweetDeck style.)\nhttps://github.com/hometown-fork/hometown/wiki/Exclusive-lists\nAlso on: social.coop"
},
"post-type": "note",
"_id": "20903814",
"_source": "1895",
"_is_read": true
}
{
"type": "entry",
"author": {
"name": "Neil Mather",
"url": "https://doubleloop.net/",
"photo": null
},
"url": "https://doubleloop.net/2021/05/29/when-did-you-join-the-indieweb/",
"published": "2021-05-29T18:18:55+00:00",
"content": {
"html": "(Hopefully this appears at <a href=\"https://www.indieforums.net/\">https://www.indieforums.net</a>)\n<p>I think I first <strong>heard</strong> of the <a href=\"https://indieweb.org/\">IndieWeb</a> movement in 2016 sometime. It\u2019s a bit hazy now, but I\u2019ve a memory that I stumbled on it through a trail of links starting on <a href=\"https://anagora.org/node/wikity\">Wikity</a>.</p>\n<p>I\u2019ve tinkered with web sites in some form or another for a long time, and I have happy memories of various weird Geocities experiments, sadly lost to the sands of time it seems.</p>\n<p>As far as independently hosting goes, I appear to have had a self-hosted blog since 2006 at my old domain <a href=\"http://noodlemaps.net/\">noodlemaps.net</a> \u2013 thanks Wayback Machine for that! My first self-hosted post is seemingly on the topic of <a href=\"https://web.archive.org/web/20060822085346/http://blog.noodlemaps.net/index.php?/archives/1-Art-in-Linux.html\">data sonification and playing non-audio files through /dev/dsp on Linux</a>. Excellent.</p>\n<p>I\u2019ve had a self-hosted blog up at <a href=\"http://doubleloop.net/\">doubleloop.net</a> since around <a href=\"https://web.archive.org/web/20160823223823/http://doubleloop.net/blog/archives\">2013</a> (thanks again Internet Archive). I went through a through static site generators. I actually really like how my old Hexo-based site looked. Better than my current site\u2026</p>\n<p>My first documented attendance of HWC London looks to be <a href=\"https://indieweb.org/events/2016-12-14-homebrew-website-club\">December 2016</a>, hosted by <a href=\"https://calumryan.com/\">Calum</a> and <a href=\"https://barryfrost.com/\">Barry</a> who were really welcoming. Around then, I fiddled about with various platforms before switching over to WordPress.</p>\n<p>I\u2019ve really enjoyed being part of the IndieWeb community. My active involvement (at events, on IRC, etc) has peaked and waned over the years, but I\u2019ve still always felt part of the bigger whole. That\u2019s another post, though.</p>\n<p>How did you find out about the IndieWeb community?</p>\nAlso on:<p><a href=\"https://www.indieforums.net/\"> indieforums.net</a></p>",
"text": "(Hopefully this appears at https://www.indieforums.net)\nI think I first heard of the IndieWeb movement in 2016 sometime. It\u2019s a bit hazy now, but I\u2019ve a memory that I stumbled on it through a trail of links starting on Wikity.\nI\u2019ve tinkered with web sites in some form or another for a long time, and I have happy memories of various weird Geocities experiments, sadly lost to the sands of time it seems.\nAs far as independently hosting goes, I appear to have had a self-hosted blog since 2006 at my old domain noodlemaps.net \u2013 thanks Wayback Machine for that! My first self-hosted post is seemingly on the topic of data sonification and playing non-audio files through /dev/dsp on Linux. Excellent.\nI\u2019ve had a self-hosted blog up at doubleloop.net since around 2013 (thanks again Internet Archive). I went through a through static site generators. I actually really like how my old Hexo-based site looked. Better than my current site\u2026\nMy first documented attendance of HWC London looks to be December 2016, hosted by Calum and Barry who were really welcoming. Around then, I fiddled about with various platforms before switching over to WordPress.\nI\u2019ve really enjoyed being part of the IndieWeb community. My active involvement (at events, on IRC, etc) has peaked and waned over the years, but I\u2019ve still always felt part of the bigger whole. That\u2019s another post, though.\nHow did you find out about the IndieWeb community?\nAlso on: indieforums.net"
},
"name": "When did you join the IndieWeb?",
"post-type": "article",
"_id": "20870866",
"_source": "1895",
"_is_read": true
}
{
"type": "entry",
"published": "2021-05-29T07:54:10.689Z",
"url": "https://barryfrost.com/2021/05/using-tailwind-css-with-microformats-2",
"category": [
"tailwind",
"css",
"microformats"
],
"name": "Using Tailwind CSS with Microformats 2",
"content": {
"text": "Finding a workaround for MF2 parsers to work with HTML marked up with Tailwind height classes."
},
"author": {
"type": "card",
"name": "Barry Frost",
"url": "https://barryfrost.com/",
"photo": "https://barryfrost.com/barryfrost.jpg"
},
"post-type": "article",
"_id": "20862107",
"_source": "189",
"_is_read": true
}
{
"type": "entry",
"published": "2021-05-25T09:44:20.505Z",
"url": "https://www.jvt.me/mf2/2021/05/kdsnb/",
"category": [
"homebrew-website-club"
],
"content": {
"text": "Reminder that it's #HomebrewWebsiteClub Nottingham tomorrow! I hope to see you there at 1730 for some website stuff! https://events.indieweb.org/2021/05/homebrew-website-club-nottingham-QbtrPT07Bwn5",
"html": "<p>Reminder that it's <a href=\"https://www.jvt.me/tags/homebrew-website-club/\">#HomebrewWebsiteClub</a> Nottingham tomorrow! I hope to see you there at 1730 for some website stuff! <a href=\"https://events.indieweb.org/2021/05/homebrew-website-club-nottingham-QbtrPT07Bwn5\">https://events.indieweb.org/2021/05/homebrew-website-club-nottingham-QbtrPT07Bwn5</a></p>"
},
"author": {
"type": "card",
"name": "Jamie Tanna",
"url": "https://www.jvt.me",
"photo": "https://www.jvt.me/img/profile.png"
},
"post-type": "note",
"_id": "20757920",
"_source": "2169",
"_is_read": true
}
I had some fun using the open standard #Microformats2 to update my CV to be machine-parseable - you can check it out at https://hire.jvt.me and there's a bit more info on https://www.jvt.me/posts/2021/05/25/microformats-resume/
{
"type": "entry",
"published": "2021-05-25T09:43:24.253Z",
"url": "https://www.jvt.me/mf2/2021/05/e5drf/",
"category": [
"microformats2"
],
"content": {
"text": "I had some fun using the open standard #Microformats2 to update my CV to be machine-parseable - you can check it out at https://hire.jvt.me and there's a bit more info on https://www.jvt.me/posts/2021/05/25/microformats-resume/",
"html": "<p>I had some fun using the open standard <a href=\"https://www.jvt.me/tags/microformats2/\">#Microformats2</a> to update my CV to be machine-parseable - you can check it out at <a href=\"https://hire.jvt.me\">https://hire.jvt.me</a> and there's a bit more info on <a href=\"https://www.jvt.me/posts/2021/05/25/microformats-resume/\">https://www.jvt.me/posts/2021/05/25/microformats-resume/</a></p>"
},
"author": {
"type": "card",
"name": "Jamie Tanna",
"url": "https://www.jvt.me",
"photo": "https://www.jvt.me/img/profile.png"
},
"post-type": "note",
"_id": "20757921",
"_source": "2169",
"_is_read": true
}
Creating a public, metadata-rich Curriculum Vitae / Resume for myself at https://hire.jvt.me.
{
"type": "entry",
"published": "2021-05-25 10:11:26 +0100 BST",
"summary": "Creating a public, metadata-rich Curriculum Vitae / Resume for myself at https://hire.jvt.me.",
"url": "https://www.jvt.me/posts/2021/05/25/microformats-resume/",
"category": [
"microformats",
"cv",
"interviewing",
"hire.jvt.me"
],
"name": "Marking up my Curriculum Vitae with Microformats2",
"author": {
"type": "card",
"name": "Jamie Tanna",
"url": "https://www.jvt.me",
"photo": "https://www.jvt.me/img/profile.png"
},
"post-type": "article",
"_id": "20757922",
"_source": "2169",
"_is_read": true
}
The fact that so many people publish their thoughts and share knowledge, is something I’ve always loved about the web. Whether it is practical stuff about how to solve a coding issue or some kind of opinion… everyone’s brain is wired differently. It may resonate, it may not, that’s also fine.
{
"type": "entry",
"published": "2021-05-22T14:48:27Z",
"url": "https://adactio.com/links/18128",
"category": [
"blogging",
"writing",
"sharing",
"blogs",
"indieweb",
"personal",
"publishing"
],
"bookmark-of": [
"https://hiddedevries.nl/en/blog/2021-05-18-150"
],
"content": {
"text": "150\n\n\n\n\n The fact that so many people publish their thoughts and share knowledge, is something I\u2019ve always loved about the web. Whether it is practical stuff about how to solve a coding issue or some kind of opinion\u2026 everyone\u2019s brain is wired differently. It may resonate, it may not, that\u2019s also fine.",
"html": "<h3>\n<a class=\"p-name u-bookmark-of\" href=\"https://hiddedevries.nl/en/blog/2021-05-18-150\">\n150\n</a>\n</h3>\n\n<blockquote>\n <p>The fact that so many people publish their thoughts and share knowledge, is something I\u2019ve always loved about the web. Whether it is practical stuff about how to solve a coding issue or some kind of opinion\u2026 everyone\u2019s brain is wired differently. It may resonate, it may not, that\u2019s also fine.</p>\n</blockquote>"
},
"author": {
"type": "card",
"name": "Jeremy Keith",
"url": "https://adactio.com/",
"photo": "https://adactio.com/images/photo-150.jpg"
},
"post-type": "bookmark",
"_id": "20692977",
"_source": "2",
"_is_read": true
}
{
"type": "entry",
"author": {
"name": "Manton Reece",
"url": "https://www.manton.org/",
"photo": "https://micro.blog/manton/avatar.jpg"
},
"url": "https://www.manton.org/2021/05/19/webmention-and-twitter.html",
"name": "Webmention and Twitter",
"content": {
"html": "<p>After the <a href=\"https://indieweb.org/2021/Pop-ups/Webmentions_Beyond_Webmention.io\">Webmention session</a> last weekend, I was inspired to revisit a quirk of Micro.blog\u2019s Webmention implementation. <a href=\"https://brid.gy/\">Bridgy</a> is an IndieWeb-friendly service commonly used to forward tweet replies via Webmention. If you were using Bridgy to connect your blog to Twitter, Micro.blog had been essentially ignoring any tweet replies to your blog post. Unlike Micro.blog\u2019s support for Mastodon and blogs, there was no way to represent a Twitter user in Micro.blog, and so it didn\u2019t make sense to thread tweets into a Micro.blog conversation.</p>\n\n<p>Including tweets in Micro.blog would have other ripple effects that I wanted to avoid. For example, what happens if you reply to a tweet? I\u2019m not interested in turning Micro.blog into a Twitter client. Quite the opposite. I\u2019m actively trying to distance myself from Twitter and avoid dependencies on any big social networks unless they are based on open standards.</p>\n\n<p>Back to Webmention. I think I\u2019ve found a good compromise solution for compatibility with Bridgy, bringing Micro.blog\u2019s Webmention support more in line with what <a href=\"https://www.manton.org/2021/05/19/webmention-and-twitter.html#\">Webmention.io</a> can provide.</p>\n\n<p>When Micro.blog receives a Webmention for a tweet via Bridgy, it now <em>does</em> create a special reference for that Twitter user and stores the tweet text. The tweet still does not appear anywhere on Micro.blog. The tweet is available as part of the conversation on your blog, though. If you don\u2019t have replies enabled on your blog, you can learn more <a href=\"https://help.micro.blog/t/replies-with-conversation-js/67\">in the Help Center about using Conversation.js</a>.</p>\n\n<p>This is all a long way of saying: when you post a link to your blog post on Twitter, tweet replies will be collected and included under your blog post on the web.</p>\n\n<p>There\u2019s an additional gotcha you should know about using Bridgy and Micro.blog together. Bridgy needs a link to your blog post for it to be able to match up tweet replies to that blog post. When cross-posting to Twitter from Micro.blog, Micro.blog only includes a link back to your blog if your blog post has a title, or if it needs to be truncated to fit in the tweet.</p>\n\n<p>If you want <em>all</em> cross-posted tweets to link back to the microblog post, even if they were short, you can use Bridgy itself for the cross-posting instead of Micro.blog, and disable cross-posting in Micro.blog. I\u2019m not planning any changes to Micro.blog\u2019s cross-posting in the near term.</p>",
"text": "After the Webmention session last weekend, I was inspired to revisit a quirk of Micro.blog\u2019s Webmention implementation. Bridgy is an IndieWeb-friendly service commonly used to forward tweet replies via Webmention. If you were using Bridgy to connect your blog to Twitter, Micro.blog had been essentially ignoring any tweet replies to your blog post. Unlike Micro.blog\u2019s support for Mastodon and blogs, there was no way to represent a Twitter user in Micro.blog, and so it didn\u2019t make sense to thread tweets into a Micro.blog conversation.\n\nIncluding tweets in Micro.blog would have other ripple effects that I wanted to avoid. For example, what happens if you reply to a tweet? I\u2019m not interested in turning Micro.blog into a Twitter client. Quite the opposite. I\u2019m actively trying to distance myself from Twitter and avoid dependencies on any big social networks unless they are based on open standards.\n\nBack to Webmention. I think I\u2019ve found a good compromise solution for compatibility with Bridgy, bringing Micro.blog\u2019s Webmention support more in line with what Webmention.io can provide.\n\nWhen Micro.blog receives a Webmention for a tweet via Bridgy, it now does create a special reference for that Twitter user and stores the tweet text. The tweet still does not appear anywhere on Micro.blog. The tweet is available as part of the conversation on your blog, though. If you don\u2019t have replies enabled on your blog, you can learn more in the Help Center about using Conversation.js.\n\nThis is all a long way of saying: when you post a link to your blog post on Twitter, tweet replies will be collected and included under your blog post on the web.\n\nThere\u2019s an additional gotcha you should know about using Bridgy and Micro.blog together. Bridgy needs a link to your blog post for it to be able to match up tweet replies to that blog post. When cross-posting to Twitter from Micro.blog, Micro.blog only includes a link back to your blog if your blog post has a title, or if it needs to be truncated to fit in the tweet.\n\nIf you want all cross-posted tweets to link back to the microblog post, even if they were short, you can use Bridgy itself for the cross-posting instead of Micro.blog, and disable cross-posting in Micro.blog. I\u2019m not planning any changes to Micro.blog\u2019s cross-posting in the near term."
},
"published": "2021-05-19T09:17:54-05:00",
"category": [
"Essays"
],
"post-type": "article",
"_id": "20614635",
"_source": "12",
"_is_read": true
}
