A wonderful introduction to the indie web—Ana really conveys her sense of excitement!
{
"type": "entry",
"published": "2020-08-27T14:25:15Z",
"url": "https://adactio.com/links/17339",
"category": [
"indieweb",
"independent",
"publishing",
"ownership",
"posse",
"webmentions",
"syndication",
"personal",
"smashingmag",
"blogs",
"blogging"
],
"bookmark-of": [
"https://www.smashingmagazine.com/2020/08/autonomy-online-indieweb/"
],
"content": {
"text": "Autonomy Online: A Case For The IndieWeb \u2014 Smashing Magazine\n\n\n\nA wonderful introduction to the indie web\u2014Ana really conveys her sense of excitement!",
"html": "<h3>\n<a class=\"p-name u-bookmark-of\" href=\"https://www.smashingmagazine.com/2020/08/autonomy-online-indieweb/\">\nAutonomy Online: A Case For The IndieWeb \u2014 Smashing Magazine\n</a>\n</h3>\n\n<p>A wonderful introduction to the indie web\u2014Ana really conveys her sense of excitement!</p>"
},
"author": {
"type": "card",
"name": "Jeremy Keith",
"url": "https://adactio.com/",
"photo": "https://adactio.com/images/photo-150.jpg"
},
"post-type": "bookmark",
"_id": "14318197",
"_source": "2",
"_is_read": true
}
Discussing the options available for posts that require authentication while using a static site, using my own personal requirements.
{
"type": "entry",
"published": "2020-08-26 22:08:28 +0100 +0100",
"summary": "Discussing the options available for posts that require authentication while using a static site, using my own personal requirements.",
"url": "https://www.jvt.me/posts/2020/08/26/static-site-private-posts/",
"category": [
"www.jvt.me",
"indieweb",
"indieauth",
"micropub",
"www-private.jvt.me"
],
"name": "Investigating Solutions for Private/Friends-Only Posts on a Static Website",
"author": {
"type": "card",
"name": "Jamie Tanna",
"url": "https://www.jvt.me",
"photo": "https://www.jvt.me/img/profile.png"
},
"post-type": "article",
"_id": "14301286",
"_source": "2169",
"_is_read": true
}
Roel asked if there was a post detailing how I set up the posting form. There is now...
Firstly, I've slimmed down the form a bit further by adding placeholder values rather than labels and adjusting the spacing. It now takes up less room at the top of the page. I've also added a toggle to show/hide the form with a quick bit of JavaScript and CSS.
So, how does it work?
It's all relatively straightforward.
As mentioned yesterday, the elements are contained within if (current_user_can('edit posts')) checks. The original form page had everything permanently visible but required a "key" to be entered so that only I could post. With this now being at the top of the home page (unless your default is the Today view) I obviously don't want it visible all the time. Hiding it with the current user check also means I can do away with the key.
The form is just regular HTML with its method set to "post" and no action so that it redirects back to the same page on submit. Inspired by micro.blog, the Title field is only shown if I change the post format to 'Post' rather than 'Status'.
Once submitted and after a quick sanity check I pull the required form values from the standard PHP $_POST variable and set up my core details:
$title = stripslashes($_POST['title']);
$body = stripslashes($_POST['body']);
$status = $_POST['status'];
$format = $_POST['format'];
$author_id = '346';
$comment_status = 'open';
$ping_status = 'open';
$post_date = gmdate("Y-m-d H:i");
If I am sending a "Like" webmention I enter the URL and the required text is added to the post as per my "Likes and Replies plugin" so I won't go in to those details here. Suffice it to say that this uses a custom field on posting.
With all the information in place I construct an array of 'post data'
$post_data = array(
'post_type' => 'post',
'post_title' => $title,
'post_content' => $body,
'post_status' => $status,
'tax_input' => array('post_format' => $format),
'post_author' => $author_id,
'comment_status' => $comment_status,
'ping_status' => $ping_status,
'post_date_gmt' => $post_date,
);
and then use this at the parameter to insert a new post
$postID = wp_insert_post($post_data);
If the post is a draft I then redirect to the post preview, otherwise I just stay on the Daily page which will then have the shiny new post.
And that's it - there's not much to it and it's simpler this was than with the standalone page.
If I did decide to go the AJAX route things would get considerably more complex but I don't think I really need to. Besides, I've not done anything of that ilk for what seems like an eternity.
{
"type": "entry",
"author": {
"name": "Colin Walker",
"url": "https://colinwalker.blog/",
"photo": null
},
"url": "https://colinwalker.blog/26-08-2020-1114/",
"published": "2020-08-26T10:32:56+00:00",
"content": {
"html": "<p><a href=\"https://colinwalker.blog/25-08-2020-1815/#55900\">Roel asked</a> if there was a post detailing how I set up the posting form. There is now...</p>\n<p>Firstly, I've slimmed down the form a bit further by adding placeholder values rather than labels and adjusting the spacing. It now takes up less room at the top of the page. I've also added a toggle to show/hide the form with a quick bit of JavaScript and CSS.</p>\n<p><img src=\"https://colinwalker.blog/wp-content/uploads/2020/08/20200826_094536.png\" alt=\"Post Form\" title=\"Post Form\" /></p>\n<p>So, how does it work?</p>\n<p>It's all relatively straightforward.</p>\n<p>As mentioned yesterday, the elements are contained within <code>if (current_user_can('edit posts'))</code> checks. The original form page had everything permanently visible but required a \"key\" to be entered so that only I could post. With this now being at the top of the home page (unless your default is the Today view) I obviously don't want it visible all the time. Hiding it with the current user check also means I can do away with the key.</p>\n<p>The form is just regular HTML with its method set to \"post\" and no action so that it redirects back to the same page on submit. Inspired by micro.blog, the Title field is only shown if I change the post format to 'Post' rather than 'Status'.</p>\n<p>Once submitted and after a quick sanity check I pull the required form values from the standard PHP <code>$_POST</code> variable and set up my core details:</p>\n<pre><code>$title = stripslashes($_POST['title']);\n$body = stripslashes($_POST['body']);\n$status = $_POST['status'];\n$format = $_POST['format'];\n$author_id = '346';\n$comment_status = 'open';\n$ping_status = 'open';\n$post_date = gmdate(\"Y-m-d H:i\");\n</code></pre>\n<p>If I am sending a \"Like\" webmention I enter the URL and the required text is added to the post as per my \"<a href=\"https://colinwalker.blog/tag/plugin/\">Likes and Replies plugin</a>\" so I won't go in to those details here. Suffice it to say that this uses a custom field on posting.</p>\n<p>With all the information in place I construct an array of 'post data'</p>\n<pre><code>$post_data = array(\n 'post_type' => 'post',\n 'post_title' => $title,\n 'post_content' => $body,\n 'post_status' => $status,\n 'tax_input' => array('post_format' => $format),\n 'post_author' => $author_id,\n 'comment_status' => $comment_status,\n 'ping_status' => $ping_status,\n 'post_date_gmt' => $post_date,\n);\n</code></pre>\n<p>and then use this at the parameter to insert a new post</p>\n<pre><code>$postID = wp_insert_post($post_data);\n</code></pre>\n<p>If the post is a draft I then redirect to the post preview, otherwise I just stay on the Daily page which will then have the shiny new post.</p>\n<p>And that's it - there's not much to it and it's simpler this was than with the standalone page.</p>\n<p>If I did decide to go the AJAX route things would get considerably more complex but I don't think I really need to. Besides, I've not done anything of that ilk for what seems like an eternity.</p>",
"text": "Roel asked if there was a post detailing how I set up the posting form. There is now...\nFirstly, I've slimmed down the form a bit further by adding placeholder values rather than labels and adjusting the spacing. It now takes up less room at the top of the page. I've also added a toggle to show/hide the form with a quick bit of JavaScript and CSS.\n\nSo, how does it work?\nIt's all relatively straightforward.\nAs mentioned yesterday, the elements are contained within if (current_user_can('edit posts')) checks. The original form page had everything permanently visible but required a \"key\" to be entered so that only I could post. With this now being at the top of the home page (unless your default is the Today view) I obviously don't want it visible all the time. Hiding it with the current user check also means I can do away with the key.\nThe form is just regular HTML with its method set to \"post\" and no action so that it redirects back to the same page on submit. Inspired by micro.blog, the Title field is only shown if I change the post format to 'Post' rather than 'Status'.\nOnce submitted and after a quick sanity check I pull the required form values from the standard PHP $_POST variable and set up my core details:\n$title = stripslashes($_POST['title']);\n$body = stripslashes($_POST['body']);\n$status = $_POST['status'];\n$format = $_POST['format'];\n$author_id = '346';\n$comment_status = 'open';\n$ping_status = 'open';\n$post_date = gmdate(\"Y-m-d H:i\");\n\nIf I am sending a \"Like\" webmention I enter the URL and the required text is added to the post as per my \"Likes and Replies plugin\" so I won't go in to those details here. Suffice it to say that this uses a custom field on posting.\nWith all the information in place I construct an array of 'post data'\n$post_data = array(\n 'post_type' => 'post',\n 'post_title' => $title,\n 'post_content' => $body,\n 'post_status' => $status,\n 'tax_input' => array('post_format' => $format),\n 'post_author' => $author_id,\n 'comment_status' => $comment_status,\n 'ping_status' => $ping_status,\n 'post_date_gmt' => $post_date,\n);\n\nand then use this at the parameter to insert a new post\n$postID = wp_insert_post($post_data);\n\nIf the post is a draft I then redirect to the post preview, otherwise I just stay on the Daily page which will then have the shiny new post.\nAnd that's it - there's not much to it and it's simpler this was than with the standalone page.\nIf I did decide to go the AJAX route things would get considerably more complex but I don't think I really need to. Besides, I've not done anything of that ilk for what seems like an eternity."
},
"post-type": "note",
"_id": "14287909",
"_source": "237",
"_is_read": true
}
Being the strictly plain text/Markdown kinda guy I am I've always resisted the move to the block editor in WordPress (aka Gutenberg) but have been curious about it for a while.
I decided to take a quick look earlier but my theme (a highly customised version of an old, old Automattic offering) isn't compatible with blocks.
I could probably make it compatible but think it wouldn't be worth the effort and I've yet to find a clear and concise guide to building block compatibility into existing themes. I could also move to a newer theme with compatibility built in but would then have to spend far too much time and effort reintroducing all the indieweb elements.
Again, it's just not worth it.
So, as the old saying says, if it ain't broke...
{
"type": "entry",
"author": {
"name": "Colin Walker",
"url": "https://colinwalker.blog/",
"photo": null
},
"url": "https://colinwalker.blog/19-08-2020-2017/",
"published": "2020-08-19T19:17:44+00:00",
"content": {
"html": "<p>Being the strictly plain text/Markdown kinda guy I am I've always resisted the move to the block editor in WordPress (aka Gutenberg) but have been curious about it for a while.</p>\n<p>I decided to take a quick look earlier but my theme (a highly customised version of an old, old Automattic offering) isn't compatible with blocks.</p>\n<p>I could <em>probably</em> make it compatible but think it wouldn't be worth the effort and I've yet to find a clear and concise guide to building block compatibility into existing themes. I could also move to a newer theme with compatibility built in but would then have to spend far too much time and effort reintroducing all the indieweb elements.</p>\n<p>Again, it's just not worth it.</p>\n<p>So, as the old saying says, if it ain't broke... </p>",
"text": "Being the strictly plain text/Markdown kinda guy I am I've always resisted the move to the block editor in WordPress (aka Gutenberg) but have been curious about it for a while.\nI decided to take a quick look earlier but my theme (a highly customised version of an old, old Automattic offering) isn't compatible with blocks.\nI could probably make it compatible but think it wouldn't be worth the effort and I've yet to find a clear and concise guide to building block compatibility into existing themes. I could also move to a newer theme with compatibility built in but would then have to spend far too much time and effort reintroducing all the indieweb elements.\nAgain, it's just not worth it.\nSo, as the old saying says, if it ain't broke..."
},
"post-type": "note",
"_id": "14277637",
"_source": "237",
"_is_read": true
}
{
"type": "entry",
"published": "2020-08-23T11:02:00+01:00",
"url": "https://www.jvt.me/mf2/2020/08/babno/",
"category": [
"web",
"indieweb"
],
"bookmark-of": [
"https://macwright.com/2020/08/22/clean-starts-for-the-web.html?s=09"
],
"author": {
"type": "card",
"name": "Jamie Tanna",
"url": "https://www.jvt.me",
"photo": "https://www.jvt.me/img/profile.png"
},
"post-type": "bookmark",
"_id": "14217882",
"_source": "2169",
"_is_read": true
}
I'm going!Looking forward to more IndieAuth discussions!
{
"type": "entry",
"published": "2020-08-21T14:04:17-0400",
"rsvp": "yes",
"url": "https://martymcgui.re/2020/08/21/140417/",
"in-reply-to": [
"https://events.indieweb.org/2020/08/indieauth-1-1-identity-protocol-standards-session-2-uCtG38aoJyju"
],
"content": {
"text": "I'm going!Looking forward to more IndieAuth discussions!",
"html": "I'm going!<p>Looking forward to more IndieAuth discussions!</p>"
},
"author": {
"type": "card",
"name": "Marty McGuire",
"url": "https://martymcgui.re/",
"photo": "https://martymcgui.re/images/logo.jpg"
},
"post-type": "rsvp",
"refs": {
"https://events.indieweb.org/2020/08/indieauth-1-1-identity-protocol-standards-session-2-uCtG38aoJyju": {
"type": "entry",
"summary": "IndieAuth is the most implemented decentralized identity protocol, built on top of OAuth 2.0.",
"url": "https://events.indieweb.org/2020/08/indieauth-1-1-identity-protocol-standards-session-2-uCtG38aoJyju",
"photo": [
"https://res.cloudinary.com/schmarty/image/fetch/w_960,c_fill/https://events.indieweb.org/storage/events/20200714-sff83XIg3Y3uKlGhPdRDUumBYgsl7O.jpg"
],
"name": "IndieAuth 1.1 Identity Protocol Standards Session 2",
"author": {
"type": "card",
"name": "events.indieweb.org",
"url": "http://events.indieweb.org",
"photo": null
},
"post-type": "photo"
}
},
"_id": "14185546",
"_source": "175",
"_is_read": true
}
{
"type": "entry",
"published": "2020-08-19T12:25:35.323Z",
"url": "https://www.jvt.me/mf2/2020/08/ovfl6/",
"category": [
"homebrew-website-club"
],
"content": {
"text": "Looking forward to seeing folks tonight at 1730 for #HomebrewWebsiteClub Nottingham! https://events.indieweb.org/2020/08/homebrew-website-club-nottingham-yPtwtlpRRU0p",
"html": "<p>Looking forward to seeing folks tonight at 1730 for <a href=\"https://www.jvt.me/tags/homebrew-website-club/\">#HomebrewWebsiteClub</a> Nottingham! <a href=\"https://events.indieweb.org/2020/08/homebrew-website-club-nottingham-yPtwtlpRRU0p\">https://events.indieweb.org/2020/08/homebrew-website-club-nottingham-yPtwtlpRRU0p</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": "14126573",
"_source": "2169",
"_is_read": true
}
A very broken desktop client for Mastodon (probably could support Pleroma and Pixelfed) and Microsub (IndieWeb so it can support silos like Twitter).
In the works.
{
"type": "entry",
"published": "2020-08-18T21:34:47.72648-07:00",
"url": "https://v2.jacky.wtf/post/d1cd7c38-f9a1-4be6-bec0-4165a01e5eb0",
"category": [
"activitydesk",
"kde"
],
"photo": [
"https://v2.jacky.wtf/media/image/entry%24d1cd7c38-f9a1-4be6-bec0-4165a01e5eb0/Screenshot_20200818_213341-ActivityDesk.png?v=original"
],
"content": {
"text": "A very broken desktop client for Mastodon (probably could support Pleroma and Pixelfed) and Microsub (IndieWeb so it can support silos like Twitter).In the works.",
"html": "<p>A very broken desktop client for Mastodon (probably could support Pleroma and Pixelfed) and Microsub (IndieWeb so it can support silos like Twitter).</p><p>In the works.</p>"
},
"author": {
"type": "card",
"name": "",
"url": "https://v2.jacky.wtf",
"photo": null
},
"post-type": "photo",
"_id": "14118628",
"_source": "1886",
"_is_read": true
}
Going to spend this week only on Rust/Qt stuff and take a break from explicit Web development. Mainly going to see if I can get some light support for Microformats2 + IndieAuth + Micropub in ActivityDesk at https://git.jacky.wtf/fediverse/activitydesk. Looks like I got a pull request for it at https://invent.kde.org/jalcine/activitydesk/-/merge_requests/2/diffs
{
"type": "entry",
"published": "2020-08-17T12:58:06.39335-07:00",
"url": "https://v2.jacky.wtf/post/dd921c27-0392-4af3-9bea-97b8de577256",
"category": [
"kde"
],
"content": {
"text": "Going to spend this week only on Rust/Qt stuff and take a break from explicit Web development. Mainly going to see if I can get some light support for Microformats2 + IndieAuth + Micropub in ActivityDesk at https://git.jacky.wtf/fediverse/activitydesk. Looks like I got a pull request for it at https://invent.kde.org/jalcine/activitydesk/-/merge_requests/2/diffs",
"html": "<p>Going to spend this week only on Rust/Qt stuff and take a break from explicit Web development. Mainly going to see if I can get some light support for Microformats2 + IndieAuth + Micropub in ActivityDesk at <a href=\"https://git.jacky.wtf/fediverse/activitydesk\">https://git.jacky.wtf/fediverse/activitydesk</a>. Looks like I got a pull request for it at <a href=\"https://invent.kde.org/jalcine/activitydesk/-/merge_requests/2/diffs\">https://invent.kde.org/jalcine/activitydesk/-/merge_requests/2/diffs</a></p>"
},
"author": {
"type": "card",
"name": "",
"url": "https://v2.jacky.wtf",
"photo": null
},
"post-type": "note",
"_id": "14082970",
"_source": "1886",
"_is_read": true
}
Reminder that it's #HomebrewWebsiteClub Nottingham on Wednesday! I hope to see you there at 1730 for some website stuff! https://events.indieweb.org/2020/08/homebrew-website-club-nottingham-yPtwtlpRRU0p
{
"type": "entry",
"published": "2020-08-17T16:12:55.143Z",
"url": "https://www.jvt.me/mf2/2020/08/nrcle/",
"category": [
"homebrew-website-club"
],
"content": {
"text": "Reminder that it's #HomebrewWebsiteClub Nottingham on Wednesday! I hope to see you there at 1730 for some website stuff! https://events.indieweb.org/2020/08/homebrew-website-club-nottingham-yPtwtlpRRU0p",
"html": "<p>Reminder that it's <a href=\"https://www.jvt.me/tags/homebrew-website-club/\">#HomebrewWebsiteClub</a> Nottingham on Wednesday! I hope to see you there at 1730 for some website stuff! <a href=\"https://events.indieweb.org/2020/08/homebrew-website-club-nottingham-yPtwtlpRRU0p\">https://events.indieweb.org/2020/08/homebrew-website-club-nottingham-yPtwtlpRRU0p</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": "14077786",
"_source": "2169",
"_is_read": true
}
Is rel=sponsored known to the Microformats community? Or is this a Google-ism? https://twitter.com/cramforce/status/1295371010124939265
{
"type": "entry",
"published": "2020-08-17T07:58:00.00000-07:00",
"url": "https://v2.jacky.wtf/post/6bb65297-3a8a-4875-93e3-bf96ec457491",
"content": {
"text": "Is rel=sponsored known to the Microformats community? Or is this a Google-ism? https://twitter.com/cramforce/status/1295371010124939265",
"html": "<p>Is <code>rel=sponsored</code> known to the Microformats community? Or is this a Google-ism? <a href=\"https://twitter.com/cramforce/status/1295371010124939265\">https://twitter.com/cramforce/status/1295371010124939265</a></p>"
},
"author": {
"type": "card",
"name": "",
"url": "https://v2.jacky.wtf",
"photo": null
},
"post-type": "note",
"_id": "14076099",
"_source": "1886",
"_is_read": true
}
For real though, I’ve been thinking more and more about the stuff I do on the side and the usefulness of it. I half promised a competitor to a platform BY myself in less time (grossly overestimating the effort and care it takes to build these platforms) and now I sometimes feel like I’ve wasted two years of my life on this stuff. It’s not like I don’t believe in the open social Web, I just challenge my thoughts on its viability in the next decade as well as the active moves working to divest from things like it into more proprietary stacks.
One thing that trips me up a lot is how a lot of the stuff in the open social Web is stuck on text (barely anything around multimedia). Text seems easy but photos require a whole different level of care and thought that’s consistently an afterthought. I don’t see much nudging on it in the IndieWeb - some progress on handling them is made in mainline projects like Mastodon but again, it’s marginal. It’s not that people are playing to catch up - I don’t think this is an interest for most at all (and it’s a safe way to prevent any of the harm found in silos from leaking into our space) but I do think we should be aiming to ween people off these platforms. I see more and more asks for alternatives and I can’t even comfortably recommend most that meet feature parity.
I’m sad. And I’m hoping to use this as motivation to keep hammering on things.
{
"type": "entry",
"published": "2020-08-16T11:08:00.00000-07:00",
"url": "https://v2.jacky.wtf/post/5803f27d-50d5-49a5-a5a4-0a4142c79689",
"category": [
"open social web",
"itch",
"indieweb",
"thoughts"
],
"content": {
"text": "For real though, I\u2019ve been thinking more and more about the stuff I do on the side and the usefulness of it. I half promised a competitor to a platform BY myself in less time (grossly overestimating the effort and care it takes to build these platforms) and now I sometimes feel like I\u2019ve wasted two years of my life on this stuff. It\u2019s not like I don\u2019t believe in the open social Web, I just challenge my thoughts on its viability in the next decade as well as the active moves working to divest from things like it into more proprietary stacks.One thing that trips me up a lot is how a lot of the stuff in the open social Web is stuck on text (barely anything around multimedia). Text seems easy but photos require a whole different level of care and thought that\u2019s consistently an afterthought. I don\u2019t see much nudging on it in the IndieWeb - some progress on handling them is made in mainline projects like Mastodon but again, it\u2019s marginal. It\u2019s not that people are playing to catch up - I don\u2019t think this is an interest for most at all (and it\u2019s a safe way to prevent any of the harm found in silos from leaking into our space) but I do think we should be aiming to ween people off these platforms. I see more and more asks for alternatives and I can\u2019t even comfortably recommend most that meet feature parity.I\u2019m sad. And I\u2019m hoping to use this as motivation to keep hammering on things.",
"html": "<p>For real though, I\u2019ve been thinking more and more about the stuff I do on the side and the usefulness of it. I half promised a competitor to a platform BY myself in less time (grossly overestimating the effort and care it takes to build these platforms) and now I sometimes feel like I\u2019ve wasted two years of my life on this stuff. It\u2019s not like I don\u2019t believe in the open social Web, I just challenge my thoughts on its viability in the next decade as well as the active moves working to divest from things like it into more proprietary stacks.</p><p>One thing that trips me up a lot is how a lot of the stuff in the open social Web is stuck on text (barely anything around multimedia). Text seems easy but photos require a whole different level of care and thought that\u2019s consistently an afterthought. I don\u2019t see much nudging on it in the IndieWeb - some progress on handling them is made in mainline projects like Mastodon but again, it\u2019s marginal. It\u2019s not that people are playing to catch up - I don\u2019t think this is an interest for most at all (and it\u2019s a safe way to prevent any of the harm found in silos from leaking into our space) but I do think we should be aiming to ween people off these platforms. I see more and more asks for alternatives and I can\u2019t even comfortably recommend most that meet feature parity.</p><p>I\u2019m sad. And I\u2019m hoping to use this as motivation to keep hammering on things.</p>"
},
"author": {
"type": "card",
"name": "",
"url": "https://v2.jacky.wtf",
"photo": null
},
"post-type": "note",
"_id": "14056406",
"_source": "1886",
"_is_read": true
}
Replied to
Good to hear! I think generated flat files are the future. How much electricity is wasted by compiling php every page load? I'm looking at something similar called hugo atm. TBH no-one comments on blogs any more anyway :/ It'd be nice to keep the old ones though..
— Alex McLean (@yaxu) August 13, 2020
Hugo’s a good un but you might personally like Hakyll… jaspervdj.be/hakyll/
One nice way to get comments on a static site is webmentions – indieweb.org/Webmention
Also on: Twitter
{
"type": "entry",
"author": {
"name": "Neil Mather",
"url": "https://doubleloop.net/",
"photo": null
},
"url": "https://doubleloop.net/2020/08/15/static-question/",
"published": "2020-08-15T16:39:36+00:00",
"content": {
"html": "Replied to \n<blockquote><blockquote><p>Good to hear! I think generated flat files are the future. How much electricity is wasted by compiling php every page load? I'm looking at something similar called hugo atm. TBH no-one comments on blogs any more anyway :/ It'd be nice to keep the old ones though..</p>\u2014 Alex McLean (@yaxu) <a href=\"https://twitter.com/yaxu/status/1294040627441807360?ref_src=twsrc%5Etfw\">August 13, 2020</a></blockquote><a href=\"https://twitter.com/yaxu/status/1294040627441807360\"></a></blockquote>\n\nHugo\u2019s a good un but you might personally like Hakyll\u2026 <a href=\"https://jaspervdj.be/hakyll/\">jaspervdj.be/hakyll/</a>\n<p>One nice way to get comments on a static site is webmentions \u2013 <a href=\"https://indieweb.org/Webmention\">indieweb.org/Webmention</a></p>\nAlso on:<p><a href=\"https://twitter.com/loopdouble/status/1294675129356759040\"> Twitter</a></p>",
"text": "Replied to \nGood to hear! I think generated flat files are the future. How much electricity is wasted by compiling php every page load? I'm looking at something similar called hugo atm. TBH no-one comments on blogs any more anyway :/ It'd be nice to keep the old ones though..\u2014 Alex McLean (@yaxu) August 13, 2020\n\nHugo\u2019s a good un but you might personally like Hakyll\u2026 jaspervdj.be/hakyll/\nOne nice way to get comments on a static site is webmentions \u2013 indieweb.org/Webmention\nAlso on: Twitter"
},
"post-type": "note",
"_id": "14032947",
"_source": "1895",
"_is_read": true
}
Matt made this website to explain RSS to people who are as-ye unfamilar with it.
{
"type": "entry",
"published": "2020-08-14T15:03:20Z",
"url": "https://adactio.com/links/17296",
"category": [
"rss",
"feeds",
"syndication",
"explanation",
"explainer",
"subscribe",
"subscriptions",
"newsreaders",
"feedreaders",
"indieweb"
],
"bookmark-of": [
"https://aboutfeeds.com/"
],
"content": {
"text": "About Feeds | Getting Started guide to web feeds/RSS\n\n\n\nMatt made this website to explain RSS to people who are as-ye unfamilar with it.",
"html": "<h3>\n<a class=\"p-name u-bookmark-of\" href=\"https://aboutfeeds.com/\">\nAbout Feeds | Getting Started guide to web feeds/RSS\n</a>\n</h3>\n\n<p>Matt made this website to explain RSS to people who are as-ye unfamilar with it.</p>"
},
"author": {
"type": "card",
"name": "Jeremy Keith",
"url": "https://adactio.com/",
"photo": "https://adactio.com/images/photo-150.jpg"
},
"post-type": "bookmark",
"_id": "14008478",
"_source": "2",
"_is_read": true
}
{
"type": "entry",
"author": {
"name": "Kh\u00fcrt",
"url": "https://islandinthenet.com/",
"photo": null
},
"url": "https://islandinthenet.com/my-ban-on-eu-website-traffic-has-been-lifted/",
"published": "2018-05-17T22:08:40+00:00",
"content": {
"html": "<p>Due to concerns about my <strong>legal</strong> responsibilities around compliance the European Union General Data Protection Regulations, I configured my Wordfence web application firewall (WAF) to block all traffic origination in EU member countries. While some people think this was an extreme move, a lack of clarity around what is expected of small website operators and that I operate an information technology related consultancy, left me feeling vulnerable. Until I could understand what/if I needed to do to comply with GDPR\u2019s \u201cright to be forgotten\u201d, I simply did not want the risk.<br />Today, I have removed the WAF rules that restrict traffic originating in the EU. <a href=\"https://automattic.com/\">Automattic</a>, the company behind WordPress.com and the supporters of WordPress.org, have updated/are <a href=\"https://automattic.com/privacy/\">updating</a> JetPack and other properties to comply with the GDPR. Currently, my self-hosted WordPress uses the Jetpack plug-in to handle things like comments and website traffic analysis. This moves some of the risks off to Automattic. They will be the data controller for information collected via comments and website analytics.<br />Automattic has provided information on what <a href=\"https://jetpack.com/support/markdown/#privacy\">information JetPack collects for comments</a> and how that data is used. They have done the same for <a href=\"https://jetpack.com/support/wordpress-com-stats/#privacy\">website analytics</a>. Click on those links to find out more.<br />I have added \u201cDo Not Track\u201d <a href=\"https://jetpack.com/support/wordpress-com-stats/#honoring-dnt\">code</a> to my WordPress config via JetPack. According to <a href=\"https://jetpack.com/support/wordpress-com-stats/#data-visibility-and-retention\">Automattic</a>.</p>\n<blockquote><p>\n Any piece of data explicitly identifying a specific user (IP address, WordPress.com ID, WordPress.com username, etc.) is not visible to the site owner when using this feature. For example, a site owner can see that a specific post has 285 views, but he/she cannot see which specific users/accounts viewed that post.<br />Stats logs \u2014 containing visitor IP addresses and WordPress.com usernames (if available) \u2014 are retained by Automattic for 28 days and are used only for the purpose of powering this feature.\n</p></blockquote>\n<p>Comments on my blog will be restricted to what JetPack and Webmentions provide. I expect that JetPack comments will soon have the ability for commenters to delete comments, allowing compliance with GDPR requirements. I expect that people using Webmentions understand how they work and understand that they can delete a comment by sending another Webmention to do so.<br />I do not intend to collect any information on visitors or commenters to this website other than what JetPacks collects.<br />I am basing my decision to remove the WAF rules based on the changes that Automattic is making and also on guidance in this <a href=\"https://www.codeinwp.com/blog/complete-wordpress-gdpr-guide/\">codeinwp.blog</a> post. Also, Wordfence has applied \u201cfor the <a href=\"https://www.wordfence.com/blog/2018/05/wordfence-gdpr-compliance-update-2/\">Privacy Shield</a> certification program for both EU-US and Swiss-US and will soon have available a Data Processing Agreement\u201d for EU customers who need one.<br />I guess what\u2019s really pissing me off is that although I live in the United States of American, some fucking European law can reach across the ocean and potentially affect me. That, that pisses me off!!<br /><img src=\"http://142.93.124.147/wp-content/uploads/2018/05/Screen-Shot-2018-05-17-at-6.12.47-PM.jpg\" alt=\"\" />Geography of the visitors to Island in the Net.</p>",
"text": "Due to concerns about my legal responsibilities around compliance the European Union General Data Protection Regulations, I configured my Wordfence web application firewall (WAF) to block all traffic origination in EU member countries. While some people think this was an extreme move, a lack of clarity around what is expected of small website operators and that I operate an information technology related consultancy, left me feeling vulnerable. Until I could understand what/if I needed to do to comply with GDPR\u2019s \u201cright to be forgotten\u201d, I simply did not want the risk.\nToday, I have removed the WAF rules that restrict traffic originating in the EU. Automattic, the company behind WordPress.com and the supporters of WordPress.org, have updated/are updating JetPack and other properties to comply with the GDPR. Currently, my self-hosted WordPress uses the Jetpack plug-in to handle things like comments and website traffic analysis. This moves some of the risks off to Automattic. They will be the data controller for information collected via comments and website analytics.\nAutomattic has provided information on what information JetPack collects for comments and how that data is used. They have done the same for website analytics. Click on those links to find out more.\nI have added \u201cDo Not Track\u201d code to my WordPress config via JetPack. According to Automattic.\n\n Any piece of data explicitly identifying a specific user (IP address, WordPress.com ID, WordPress.com username, etc.) is not visible to the site owner when using this feature. For example, a site owner can see that a specific post has 285 views, but he/she cannot see which specific users/accounts viewed that post.\nStats logs \u2014 containing visitor IP addresses and WordPress.com usernames (if available) \u2014 are retained by Automattic for 28 days and are used only for the purpose of powering this feature.\n\nComments on my blog will be restricted to what JetPack and Webmentions provide. I expect that JetPack comments will soon have the ability for commenters to delete comments, allowing compliance with GDPR requirements. I expect that people using Webmentions understand how they work and understand that they can delete a comment by sending another Webmention to do so.\nI do not intend to collect any information on visitors or commenters to this website other than what JetPacks collects.\nI am basing my decision to remove the WAF rules based on the changes that Automattic is making and also on guidance in this codeinwp.blog post. Also, Wordfence has applied \u201cfor the Privacy Shield certification program for both EU-US and Swiss-US and will soon have available a Data Processing Agreement\u201d for EU customers who need one.\nI guess what\u2019s really pissing me off is that although I live in the United States of American, some fucking European law can reach across the ocean and potentially affect me. That, that pisses me off!!\nGeography of the visitors to Island in the Net."
},
"name": "My ban on EU website traffic has been lifted.",
"post-type": "article",
"_id": "13987305",
"_source": "242",
"_is_read": true
}
{
"type": "entry",
"author": {
"name": "Kh\u00fcrt",
"url": "https://islandinthenet.com/",
"photo": null
},
"url": "https://islandinthenet.com/keyring-social-importers-wordpress/",
"published": "2018-01-01T19:12:52+00:00",
"content": {
"html": "<p>[exif id=\u201d27124\u2033]<br />Update: Developer, <a href=\"https://dentedreality.com.au/about/\">Bewu Lebens</a> has written a <a href=\"https://dentedreality.com.au/projects/wp-keyring/\">WordPress: Keyring Developer\u2019s Guide</a>. I will revisit how I used this plugin after I familiarise myself with the guide. I also plan on developing a Keyring importer for Untappd.<br />On Twitter, Xavier Roy posted a <a href=\"https://twitter.com/xavierroy/status/944186489725796352\">response</a> to my <a href=\"http://104.236.229.226/instagram-wordpress/\">post</a> about my experiment with importing Instagram post to WordPress. He suggested I try the <a href=\"https://wordpress.org/plugins/keyring-social-importers/\">Keyring Social Importers</a> plugin. After some back and forth on Twitter, I gave it a go and updated the original post.<br />The results were not pleasing. However, I was fascinated by the plugin and tried it with Foursquare.<br />The Keyring Social Importers plugin provides a set of social importers that pull in content created on other sites and re-publishes it on a WordPress site. After an initial import, the importers optionally check each hour and automatically download new content. New posts are created for each item imported with support for specific Post Formats, depending on the content type.<br />At the time of writing this, the plugin had not been tested on WordPress 4.9. The untested code can be unstable code and unstable code can lead to security leaks etc. so I configured and tested everything on a test instance of WordPress.<br />I also installed Keyring, a plugin which is required to use with Keyring Social Importer, and which provides the authentication and API connections to each of the external services. I configured API access to Foursquare and then from the \u201cTools->Import\u201d section of the dashboard I clicked the link to authenticate and to start importing from Foursquare.<br />I\u2019ve had my Foursquare account for a very long time so the import took a lot of time. Each check and photo on my Foursquare account was downloaded and imported into my WordPress Media Library. The imported image was attached to each post as a featured image, which is a feature I wanted, however, each image was also attached in the body of every post and is only 640px \u00d7 479px.<br />The importer leverages the Post Kinds and Simple Location IndieWeb plugins to set the Post Kind to Photo and set the geographic location for the post. However, syndication links were not set. But it\u2019s not too much work to set it manually later.<br />The Foursquare importer works but the results were not attractive. First, I did not want to import every one of my past check-ins. I wanted to limit the initial set of imports. Second, I wanted the higher resolution version of the image.<br />For example, for check-in at <a href=\"https://foursquare.com/khurtwilliams/checkin/5a496adec0f1632dde4f9774\">Osteria Procaccini</a>, the Keyring Social Importer imports this image.<br />I poked around the web and learned that it\u2019s possible to get at this image via the <a href=\"https://developer.foursquare.com/docs/api/users/checkins\">Foursquare API</a>. I discovered that by modifying the image URL and replacing the image dimension with the text <em>original</em>, I could get at the full-size images. But I also discovered that I could get what I wanted by removing some HTML.<br /><img src=\"https://i0.wp.com/igx.4sqi.net/img/general/640x640/108856_El7kZnp5nO4EESFJRB4KmxfXSfIcn_mbceLEOylUfdM.jpg?w=840&ssl=1\" alt=\"\" /><br />What I needed to do was to find the section of code that imports images, and change the code to import the higher-resolution image.<br />In the <code>wp-content/plugins/keyring-social-importers/keyring-importers.php</code> file, I found the following code between lines 865 to 876. If I removed that code, I would have everything I wanted.</p>\n<pre><code><br />if ( $data ) {\n$img = \u2018<img class=\"keyring-img\" src=\"' . esc_url( $data[0] ) . '\" alt=\"' . esc_attr( $post['post_title'] ) . '\" width=\"' . esc_attr( $data[1] ) . '\" height=\"' . esc_attr( $data[2] ) . '\" />\u2019;\n}\n// Regex out the previous img tag, put this one in there instead, or prepend it to the top/bottom, depending on $append\nif ( stristr( $post['post_content'], $url ) ) {\n$post['post_content'] = preg_replace( '!<img />]*src=[\\'\"]' . preg_quote( $url ) . '[\\'\"][^>]*>!', $img, $post['post_content'] ) . \"\\n\";\n} else if ( $append ) {\n$post['post_content'] = $post['post_content'] . \"\\n\\n\" . $img;\n} else {\n$post['post_content'] = $img . \"\\n\\n\" . $post['post_content'];\n}\n}\n</code></pre>\n<p><img src=\"https://i0.wp.com/igx.4sqi.net/img/general/original/108856_El7kZnp5nO4EESFJRB4KmxfXSfIcn_mbceLEOylUfdM.jpg?w=840&ssl=1\" alt=\"\" /><br />The default is for Keyring Social Imports to import 200 posts in oldest to newest order. I didn\u2019t want every post and I wanted only one newest post. A modification to line 74 of the <code>wp-content/plugins/keyring-social-importers/importers/keyring-importer-foursquare.php</code> file yielded the results I wanted.<br />Before:<br /><code>$url = \"https://api.foursquare.com/v2/users/\" . $this-&gt;get_option( 'user_id', 'self' ) . \"/checkins?limit=200\";</code><br />After:<br /><code>$url = \"https://api.foursquare.com/v2/users/\" . $this-&gt;get_option( 'user_id', 'self' ) . \"/checkins?limit=2&amp;sort=newestfirst\";</code><br />I tested the code over the last few weeks and so far I have not encountered any issues. I think with these modifications to the code, the Keyring Social Importers plugin is a reliable <a href=\"https://indieweb.org/WordPress/Plugins#PESOS_Plugins\">PESOS WordPress plugin</a> for importing Foursquare check-ins.</p>",
"text": "[exif id=\u201d27124\u2033]\nUpdate: Developer, Bewu Lebens has written a WordPress: Keyring Developer\u2019s Guide. I will revisit how I used this plugin after I familiarise myself with the guide. I also plan on developing a Keyring importer for Untappd.\nOn Twitter, Xavier Roy posted a response to my post about my experiment with importing Instagram post to WordPress. He suggested I try the Keyring Social Importers plugin. After some back and forth on Twitter, I gave it a go and updated the original post.\nThe results were not pleasing. However, I was fascinated by the plugin and tried it with Foursquare.\nThe Keyring Social Importers plugin provides a set of social importers that pull in content created on other sites and re-publishes it on a WordPress site. After an initial import, the importers optionally check each hour and automatically download new content. New posts are created for each item imported with support for specific Post Formats, depending on the content type.\nAt the time of writing this, the plugin had not been tested on WordPress 4.9. The untested code can be unstable code and unstable code can lead to security leaks etc. so I configured and tested everything on a test instance of WordPress.\nI also installed Keyring, a plugin which is required to use with Keyring Social Importer, and which provides the authentication and API connections to each of the external services. I configured API access to Foursquare and then from the \u201cTools->Import\u201d section of the dashboard I clicked the link to authenticate and to start importing from Foursquare.\nI\u2019ve had my Foursquare account for a very long time so the import took a lot of time. Each check and photo on my Foursquare account was downloaded and imported into my WordPress Media Library. The imported image was attached to each post as a featured image, which is a feature I wanted, however, each image was also attached in the body of every post and is only 640px \u00d7 479px.\nThe importer leverages the Post Kinds and Simple Location IndieWeb plugins to set the Post Kind to Photo and set the geographic location for the post. However, syndication links were not set. But it\u2019s not too much work to set it manually later.\nThe Foursquare importer works but the results were not attractive. First, I did not want to import every one of my past check-ins. I wanted to limit the initial set of imports. Second, I wanted the higher resolution version of the image.\nFor example, for check-in at Osteria Procaccini, the Keyring Social Importer imports this image.\nI poked around the web and learned that it\u2019s possible to get at this image via the Foursquare API. I discovered that by modifying the image URL and replacing the image dimension with the text original, I could get at the full-size images. But I also discovered that I could get what I wanted by removing some HTML.\n\nWhat I needed to do was to find the section of code that imports images, and change the code to import the higher-resolution image.\nIn the wp-content/plugins/keyring-social-importers/keyring-importers.php file, I found the following code between lines 865 to 876. If I removed that code, I would have everything I wanted.\n\nif ( $data ) {\n$img = \u2018<img class=\"keyring-img\" src=\"' . esc_url( $data[0] ) . '\" alt=\"' . esc_attr( $post['post_title'] ) . '\" width=\"' . esc_attr( $data[1] ) . '\" height=\"' . esc_attr( $data[2] ) . '\" />\u2019;\n}\n// Regex out the previous img tag, put this one in there instead, or prepend it to the top/bottom, depending on $append\nif ( stristr( $post['post_content'], $url ) ) {\n$post['post_content'] = preg_replace( '!<img />]*src=[\\'\"]' . preg_quote( $url ) . '[\\'\"][^>]*>!', $img, $post['post_content'] ) . \"\\n\";\n} else if ( $append ) {\n$post['post_content'] = $post['post_content'] . \"\\n\\n\" . $img;\n} else {\n$post['post_content'] = $img . \"\\n\\n\" . $post['post_content'];\n}\n}\n\n\nThe default is for Keyring Social Imports to import 200 posts in oldest to newest order. I didn\u2019t want every post and I wanted only one newest post. A modification to line 74 of the wp-content/plugins/keyring-social-importers/importers/keyring-importer-foursquare.php file yielded the results I wanted.\nBefore:\n$url = \"https://api.foursquare.com/v2/users/\" . $this->get_option( 'user_id', 'self' ) . \"/checkins?limit=200\";\nAfter:\n$url = \"https://api.foursquare.com/v2/users/\" . $this->get_option( 'user_id', 'self' ) . \"/checkins?limit=2&sort=newestfirst\";\nI tested the code over the last few weeks and so far I have not encountered any issues. I think with these modifications to the code, the Keyring Social Importers plugin is a reliable PESOS WordPress plugin for importing Foursquare check-ins."
},
"name": "Experiment with FourSquare, WordPress and the Keyring Social Importers plugin",
"post-type": "article",
"_id": "13986742",
"_source": "242",
"_is_read": true
}
Making an #IndieAuth authorization endpoint. #indieweb #webdesign
{
"type": "entry",
"published": "2020-08-13T15:37:04+00:00",
"url": "https://fireburn.ru/posts/1597333024",
"category": [
"IndieAuth",
"IndieWeb",
"webdesign"
],
"photo": [
"https://fireburn.ru/media/3f/c6/36/49/3198a77da34b0e94e1b32e0856812c32e2a1eadb691c33aa9eca3d48.png",
"https://fireburn.ru/media/4d/6c/c1/e7/bf15fc923ce566fc26827682d3a0f683af1aa0c5ed6270deaa9ab4e8.png"
],
"syndication": [
"https://twitter.com/kisik21/status/1293934634796036097"
],
"content": {
"text": "Making an #IndieAuth authorization endpoint. #indieweb #webdesign",
"html": "<p>Making an #IndieAuth authorization endpoint. #indieweb #webdesign</p>"
},
"author": {
"type": "card",
"name": "Vika",
"url": "https://fireburn.ru/",
"photo": "https://fireburn.ru/media/f1/5a/fb/9b/081efafb97b4ad59f5025cf2fd0678b8f3e20e4c292489107d52be09.png"
},
"post-type": "photo",
"_id": "13985873",
"_source": "1371",
"_is_read": true
}
{
"type": "entry",
"published": "2020-08-11T20:52:00+01:00",
"url": "https://www.jvt.me/mf2/2020/08/uilcf/",
"category": [
"indieauth"
],
"bookmark-of": [
"http://beesbuzz.biz/blog/6265-Two-PSAs-regarding-IndieAuth"
],
"author": {
"type": "card",
"name": "Jamie Tanna",
"url": "https://www.jvt.me",
"photo": "https://www.jvt.me/img/profile.png"
},
"post-type": "bookmark",
"_id": "13936090",
"_source": "2169",
"_is_read": true
}
{
"type": "entry",
"author": {
"name": "fluffy",
"url": "http://beesbuzz.biz/",
"photo": null
},
"url": "http://beesbuzz.biz/blog/6265-Two-PSAs-regarding-IndieAuth",
"published": "2020-08-11T11:32:07-07:00",
"content": {
"html": "<p><a href=\"https://indieauth.net/\">IndieAuth</a> is starting to get some traction in the greater Internet space, which is really cool! I\u2019m glad to see a protocol finally emerging around distributed/federated identity, managing to get some traction where OpenID more or less failed (despite a few hangers-on still supporting it).</p><p>There are two issues that implementers of IndieAuth clients (i.e. websites which use IndieAuth for authentication) and endpoints (i.e. the things which do the actual authentication) should be aware of.</p>\n\n\n<h2><a href=\"http://beesbuzz.biz/blog/6265-Two-PSAs-regarding-IndieAuth#6265_h2_1_Recent-spec-change\"></a>Recent spec change</h2><p>There was a <a href=\"https://github.com/indieweb/indieauth/issues/42\">recent change to the specification</a> which leads to some incompatibility around scopeless identity verification. This is a flow that\u2019s used for simple sign-on to websites; for example it\u2019s what <a href=\"https://github.com/PlaidWeb/Authl\">Authl</a> uses, as it\u2019s not requesting permission to the user\u2019s resources, but just associating the user with an identity. This is a pretty common use case for IndieAuth.</p><p>In the previous version of the spec, the scopeless identity verification used <code>response_type=id</code> and didn\u2019t specify a <code>scope</code>; these two options were mutually-exclusive, and this led to a somewhat confusing spec. The latest spec update changes this flow to use <code>response_type=code</code> and to simply omit the <code>scope</code>. This is a much better protocol in general, <em>but</em> it has the problem of being fundamentally incompatible with older endpoints which do strict parameter checking.</p><p>Unfortunately, the current spec doesn\u2019t document the legacy <code>response_type=id</code> as a backwards-compatibility path, so any newly-written endpoints will not support older clients. Newer clients will attempt to send a scopeless <code>response_type=code</code> request which will fail on older endpoints.</p><p>The nature of the IndieAuth protocol also means that there\u2019s no way for the client to know which protocol version is in use or to get notified that there was a failure, so the end result will be a bad user experience (such as their login page returning an opaque error about \u201cmissing scope\u201d or \u201cinvalid response type\u201d or whatever).</p><p>So, some suggested mitigations:</p>\n<ul><li>Endpoint authors: Accept <code>response_type=id</code> with no <code>scope</code> parameter, possibly displaying a deprecation warning to the user (asking that they reach out to the client website to update to the latest version of the specification)</li>\n<li>Client authors: Always send <code>response_type=code</code> and request a meaningful but non-invasive-sounding scope, such as <code>me</code> or <code>profile</code> or whatever. (This is what Authl will be doing as of the next release.)</li>\n</ul><p>The actual scope for clients to request is very much up for debate. Here\u2019s a few different things I\u2019ve seen proposed:</p>\n<ul><li><code>me</code>: The most straightforward, in keeping with IndieAuth nomenclature. Literally all you\u2019re asking for is the <code>me</code> URL, which is already a basic part of the verification response. But this is kind of confusing to end users.</li>\n<li><code>profile</code>: This seems user-friendly, but there\u2019s the <a href=\"https://github.com/indieweb/indieauth/issues/41\">possibility</a> that future IndieAuth endpoints might use this as a cue to send the profile directly rather than making it a separate retrieval of <code>h-card</code> data from the identity URL. There\u2019s reasons to do this, so I\u2019d much rather reserve this scope for when IndieAuth supports it natively. On the other hand, it\u2019d also be nice to just automatically start receiving profile data when endpoints start supporting that.</li>\n<li><code>email</code>: This implies that someone will be able to do something unspecified with the user\u2019s email. It\u2019s also not actually an email address that is being requested in the first place.</li>\n<li><code>read</code>: This implies being able to read private data. Keep this scope for things like micropub!</li>\n</ul><p>So for me the decision is either <code>me</code> or <code>profile</code> but both have caveats. I\u2019ll probably go with <code>profile</code> since it seems like the least-confusing thing (at least in the context of Authl), but per the IndieAuth spec you <em>should</em> be able to use any scope you want. But there effectively has to be a scope, at least until every endpoint on the Internet has been updated or at least a reasonable amount of time has passed that all endpoints \u201cshould\u201d have been updated.</p><h2><a href=\"http://beesbuzz.biz/blog/6265-Two-PSAs-regarding-IndieAuth#6265_h2_2_Identity-verification-gap\"></a>Identity verification gap</h2><p>IndieAuth is designed under the assumption that everyone has their own domain name, which is an admirable goal but has a few problems for a lot of people, who don\u2019t have the technical acumen necessary to register and/or host their own domain but do have access to shared-domain hosting (such as <a href=\"https://tilde.club/\">tilde.club</a> or their university-provided academic homepage). However, there\u2019s nothing in the spec that actually requires that someone own their domain, and it\u2019s quite possible for someone to declare an endpoint on such a webpage, with no way for someone to verify that the webpage is authoritative for the entire domain (after all, it\u2019s just a <code><link></code> tag or a response header).</p><p>Where this becomes a security concern is that since the IndieAuth spec doesn\u2019t require proof of ownership of the domain, it considers any authentication against any page on a domain to be authoritative for the entire domain. As a proof of concept, you can use <a href=\"https://tilde.club/~fluffy/\">tilde.club/~fluffy/</a> as an identity URL that will let you verify as <em>any</em> identity on tilde.club, at least for things that follow the IndieAuth spec. (This is one place where Authl diverges from the specification, because I needed a better identity guarantee for my use case.)</p><p>There are two mitigations I have proposed for client authors:</p>\n<ol><li><p>Require that the final verified URL be more specific, path-wise, than the original identity request; for example, allow <code>https://example.com/</code> to verify as <code>https://example.com/~alice/</code>, but don\u2019t allow <code>https://example.com/~alice/</code> to verify as <code>https://example.com/~bob/</code></p><p>This is what Authl does at present. Codifying this in spec-friendly language is difficult, however, and there\u2019s a bunch of sharp edges you have to watch out for (such as not allowing <code>https://example.com/~alice</code> to verify as <code>https://example.com/~alice_sucks</code> or whatever; \u201cpath components\u201d aren\u2019t really that strong of a thing in HTTP <em>per se</em>).</p></li>\n<li><p>Require that the final identity URL declares the same <code>authorization_endpoint</code> as the verified URL</p><p>This approach seems preferable, as it is much easier to clearly and concisely explain. It also allows for more exotic situations where multiple shared-domain users might want to be able to authenticate as each other for whatever reason (for example, I can see people who identify as plural systems making use of this).</p></li>\n</ol><p>Both of these approaches have been discussed somewhat on <a href=\"https://github.com/indieweb/indieauth/issues/35\">this spec issue</a> as well as on IndieWeb Chat, and the general feeling I\u2019ve gotten is that approach 2 is greatly preferable to everyone. So in the future I will probably change Authl to use approach 2.</p>\n\n<p><a href=\"http://beesbuzz.biz/blog/6265-Two-PSAs-regarding-IndieAuth#comments\">comments</a></p>",
"text": "IndieAuth is starting to get some traction in the greater Internet space, which is really cool! I\u2019m glad to see a protocol finally emerging around distributed/federated identity, managing to get some traction where OpenID more or less failed (despite a few hangers-on still supporting it).There are two issues that implementers of IndieAuth clients (i.e. websites which use IndieAuth for authentication) and endpoints (i.e. the things which do the actual authentication) should be aware of.\n\n\nRecent spec changeThere was a recent change to the specification which leads to some incompatibility around scopeless identity verification. This is a flow that\u2019s used for simple sign-on to websites; for example it\u2019s what Authl uses, as it\u2019s not requesting permission to the user\u2019s resources, but just associating the user with an identity. This is a pretty common use case for IndieAuth.In the previous version of the spec, the scopeless identity verification used response_type=id and didn\u2019t specify a scope; these two options were mutually-exclusive, and this led to a somewhat confusing spec. The latest spec update changes this flow to use response_type=code and to simply omit the scope. This is a much better protocol in general, but it has the problem of being fundamentally incompatible with older endpoints which do strict parameter checking.Unfortunately, the current spec doesn\u2019t document the legacy response_type=id as a backwards-compatibility path, so any newly-written endpoints will not support older clients. Newer clients will attempt to send a scopeless response_type=code request which will fail on older endpoints.The nature of the IndieAuth protocol also means that there\u2019s no way for the client to know which protocol version is in use or to get notified that there was a failure, so the end result will be a bad user experience (such as their login page returning an opaque error about \u201cmissing scope\u201d or \u201cinvalid response type\u201d or whatever).So, some suggested mitigations:\nEndpoint authors: Accept response_type=id with no scope parameter, possibly displaying a deprecation warning to the user (asking that they reach out to the client website to update to the latest version of the specification)\nClient authors: Always send response_type=code and request a meaningful but non-invasive-sounding scope, such as me or profile or whatever. (This is what Authl will be doing as of the next release.)\nThe actual scope for clients to request is very much up for debate. Here\u2019s a few different things I\u2019ve seen proposed:\nme: The most straightforward, in keeping with IndieAuth nomenclature. Literally all you\u2019re asking for is the me URL, which is already a basic part of the verification response. But this is kind of confusing to end users.\nprofile: This seems user-friendly, but there\u2019s the possibility that future IndieAuth endpoints might use this as a cue to send the profile directly rather than making it a separate retrieval of h-card data from the identity URL. There\u2019s reasons to do this, so I\u2019d much rather reserve this scope for when IndieAuth supports it natively. On the other hand, it\u2019d also be nice to just automatically start receiving profile data when endpoints start supporting that.\nemail: This implies that someone will be able to do something unspecified with the user\u2019s email. It\u2019s also not actually an email address that is being requested in the first place.\nread: This implies being able to read private data. Keep this scope for things like micropub!\nSo for me the decision is either me or profile but both have caveats. I\u2019ll probably go with profile since it seems like the least-confusing thing (at least in the context of Authl), but per the IndieAuth spec you should be able to use any scope you want. But there effectively has to be a scope, at least until every endpoint on the Internet has been updated or at least a reasonable amount of time has passed that all endpoints \u201cshould\u201d have been updated.Identity verification gapIndieAuth is designed under the assumption that everyone has their own domain name, which is an admirable goal but has a few problems for a lot of people, who don\u2019t have the technical acumen necessary to register and/or host their own domain but do have access to shared-domain hosting (such as tilde.club or their university-provided academic homepage). However, there\u2019s nothing in the spec that actually requires that someone own their domain, and it\u2019s quite possible for someone to declare an endpoint on such a webpage, with no way for someone to verify that the webpage is authoritative for the entire domain (after all, it\u2019s just a <link> tag or a response header).Where this becomes a security concern is that since the IndieAuth spec doesn\u2019t require proof of ownership of the domain, it considers any authentication against any page on a domain to be authoritative for the entire domain. As a proof of concept, you can use tilde.club/~fluffy/ as an identity URL that will let you verify as any identity on tilde.club, at least for things that follow the IndieAuth spec. (This is one place where Authl diverges from the specification, because I needed a better identity guarantee for my use case.)There are two mitigations I have proposed for client authors:\nRequire that the final verified URL be more specific, path-wise, than the original identity request; for example, allow https://example.com/ to verify as https://example.com/~alice/, but don\u2019t allow https://example.com/~alice/ to verify as https://example.com/~bob/This is what Authl does at present. Codifying this in spec-friendly language is difficult, however, and there\u2019s a bunch of sharp edges you have to watch out for (such as not allowing https://example.com/~alice to verify as https://example.com/~alice_sucks or whatever; \u201cpath components\u201d aren\u2019t really that strong of a thing in HTTP per se).\nRequire that the final identity URL declares the same authorization_endpoint as the verified URLThis approach seems preferable, as it is much easier to clearly and concisely explain. It also allows for more exotic situations where multiple shared-domain users might want to be able to authenticate as each other for whatever reason (for example, I can see people who identify as plural systems making use of this).\nBoth of these approaches have been discussed somewhat on this spec issue as well as on IndieWeb Chat, and the general feeling I\u2019ve gotten is that approach 2 is greatly preferable to everyone. So in the future I will probably change Authl to use approach 2.\n\ncomments"
},
"name": "Plaidophile: Two PSAs regarding IndieAuth",
"post-type": "article",
"_id": "13933853",
"_source": "3782",
"_is_read": true
}
This bit around compiling and rendering sounds specific to the problems with using static sites. If it’s done completely remotely, to the level that something like Disqus or Commento could handle it, it’d just handle a fraction of what Webmentions are capable of. This, of course, requires time and effort to build. And since there isn’t a huge VC company backing such a notion, we won’t see it anytime soon.
{
"type": "entry",
"published": "2020-08-11T09:55:09.43979-07:00",
"url": "https://v2.jacky.wtf/post/cc7c38d9-4688-4384-806c-8c1bd3cb0a3c",
"in-reply-to": [
"https://lobste.rs/s/2kb9qt/what_we_talk_about_when_we_re_talking_about#c_trowmt"
],
"content": {
"text": "This bit around compiling and rendering sounds specific to the problems with using static sites. If it\u2019s done completely remotely, to the level that something like Disqus or Commento could handle it, it\u2019d just handle a fraction of what Webmentions are capable of. This, of course, requires time and effort to build. And since there isn\u2019t a huge VC company backing such a notion, we won\u2019t see it anytime soon.",
"html": "<p>This bit around compiling and rendering sounds specific to the problems with using static sites. If it\u2019s done completely remotely, to the level that something like Disqus or Commento could handle it, it\u2019d just handle a fraction of what Webmentions are capable of. This, of course, requires time and effort to build. And since there isn\u2019t a huge VC company backing such a notion, we won\u2019t see it anytime soon.</p>"
},
"author": {
"type": "card",
"name": "",
"url": "https://v2.jacky.wtf",
"photo": null
},
"post-type": "reply",
"refs": {
"https://lobste.rs/s/2kb9qt/what_we_talk_about_when_we_re_talking_about#c_trowmt": {
"type": "entry",
"url": "https://lobste.rs/s/2kb9qt/what_we_talk_about_when_we_re_talking_about#c_trowmt",
"author": {
"type": "card",
"name": "",
"url": "https://v2.jacky.wtf/stream",
"photo": null
},
"post-type": "note"
}
},
"_id": "13930737",
"_source": "1886",
"_is_read": true
}
