Jamie Tanna www.jvt.me

{
    "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
}

Plaidophile: Two PSAs regarding IndieAuth

{
    "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>&lt;link&gt;</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
}

{
    "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
}

A tapestry of humanity and what we know

{
    "type": "entry",
    "author": {
        "name": "Neil Mather",
        "url": "https://doubleloop.net/",
        "photo": null
    },
    "url": "https://doubleloop.net/2020/08/10/a-tapestry-of-humanity-and-what-we-know/",
    "published": "2020-08-10T22:10:04+00:00",
    "content": {
        "html": "<blockquote><p>The World Wide Web was all about you create knowledge and how you create hyperlinks to different pieces of knowledge. So over time we kind of create this tapestry of humanity and what we know, which at another level of abstraction is kind of creating this meta-map of humanity. This meta-map of humanity is now controlled by these companies that are the ones who have access to the backend.</p>\n<p>\u2013 <a href=\"https://www.buzzsprout.com/1004689/4587590-the-global-south-holds-a-better-future-of-tech-w-juan-ortiz-freuler\">The Global South Holds a Better Future of Tech w/ Juan Ortiz Freuler</a></p></blockquote>\n<p>I love the phrase tapestry of humanity here. I like the <a href=\"https://commonplace.doubleloop.net/indieweb.html\">IndieWeb</a> and <a href=\"https://commonplace.doubleloop.net/wikis.html\">personal wikis</a> as a way of being part of the warp and weft of that tapestry.</p>",
        "text": "The World Wide Web was all about you create knowledge and how you create hyperlinks to different pieces of knowledge. So over time we kind of create this tapestry of humanity and what we know, which at another level of abstraction is kind of creating this meta-map of humanity. This meta-map of humanity is now controlled by these companies that are the ones who have access to the backend.\n\u2013 The Global South Holds a Better Future of Tech w/ Juan Ortiz Freuler\nI love the phrase tapestry of humanity here. I like the IndieWeb and personal wikis as a way of being part of the warp and weft of that tapestry."
    },
    "name": "A tapestry of humanity and what we know",
    "post-type": "article",
    "_id": "13911719",
    "_source": "1895",
    "_is_read": true
}

{
    "type": "entry",
    "published": "2020-08-10T07:23:26.43947-07:00",
    "url": "https://v2.jacky.wtf/post/5032f89e-dcb7-45b7-b958-7d242f72042a",
    "in-reply-to": [
        "https://twitter.com/Cambridgeport90/status/1292803078723219458"
    ],
    "content": {
        "text": "I\u2019m not explicitly sure but from the large demographic of people on Parler that seem to conflate the First Amendment to apply to social media companies and not who it\u2019s intended for (the feds), I\u2019d personally block that whole site from my IndieWeb setup.",
        "html": "<p>I\u2019m not explicitly sure but from the large demographic of people on Parler that seem to conflate the First Amendment to apply to social media companies and not who it\u2019s intended for (the feds), I\u2019d personally block that whole site from my IndieWeb setup.</p>"
    },
    "author": {
        "type": "card",
        "name": "",
        "url": "https://v2.jacky.wtf",
        "photo": null
    },
    "post-type": "reply",
    "refs": {
        "https://twitter.com/Cambridgeport90/status/1292803078723219458": {
            "type": "entry",
            "url": "https://twitter.com/Cambridgeport90/status/1292803078723219458",
            "author": {
                "type": "card",
                "name": "twitter.com",
                "url": "https://twitter.com/Cambridgeport90/status/1292803078723219458",
                "photo": null
            },
            "post-type": "note"
        }
    },
    "_id": "13911704",
    "_source": "1886",
    "_is_read": true
}

Jamie Tanna www.jvt.me

{
    "type": "entry",
    "published": "2020-08-09T18:41:00+01:00",
    "url": "https://www.jvt.me/mf2/2020/08/gedst/",
    "category": [
        "indieweb"
    ],
    "bookmark-of": [
        "http://cascadiainspired.com/excited-about-the-indie-web/"
    ],
    "author": {
        "type": "card",
        "name": "Jamie Tanna",
        "url": "https://www.jvt.me",
        "photo": "https://www.jvt.me/img/profile.png"
    },
    "post-type": "bookmark",
    "_id": "13881767",
    "_source": "2169",
    "_is_read": true
}

{
    "type": "entry",
    "published": "2020-08-08T09:54:43.51138-07:00",
    "url": "https://v2.jacky.wtf/post/79cd622f-7ae5-47cd-a94e-e15bfaf6b4b1",
    "category": [
        "events"
    ],
    "content": {
        "text": "Currently at https://events.indieweb.org/2020/08/indieauth-1-1-identity-protocol-standards-session-6xlxgeCEMgv8 talking shop about http://indieauth.spec.indieweb.org/.",
        "html": "<p>Currently at <a href=\"https://events.indieweb.org/2020/08/indieauth-1-1-identity-protocol-standards-session-6xlxgeCEMgv8\">https://events.indieweb.org/2020/08/indieauth-1-1-identity-protocol-standards-session-6xlxgeCEMgv8</a> talking shop about <a href=\"http://indieauth.spec.indieweb.org/\">http://indieauth.spec.indieweb.org/</a>.</p>"
    },
    "author": {
        "type": "card",
        "name": "",
        "url": "https://v2.jacky.wtf",
        "photo": null
    },
    "post-type": "note",
    "_id": "13867702",
    "_source": "1886",
    "_is_read": true
}

Tantek Çelik tantek.com

{
    "type": "entry",
    "published": "2020-08-07 10:18-0700",
    "rsvp": "yes",
    "url": "http://tantek.com/2020/220/t1/",
    "category": [
        "IndieAuth",
        "identity",
        "protocol",
        "OAuth",
        "IndieWeb",
        "OpenWeb",
        "WebIdentity",
        "noBlockchain"
    ],
    "in-reply-to": [
        "https://events.indieweb.org/2020/08/indieauth-1-1-identity-protocol-standards-session-6xlxgeCEMgv8"
    ],
    "content": {
        "text": "going to part of the IndieAuth Pop-up Session\n\ud83d\uddd3 9:30-11:30am PDT, Sat 8/8\n\ud83c\udf9f RSVP: https://events.indieweb.org/2020/08/indieauth-1-1-identity-protocol-standards-session-6xlxgeCEMgv8\n\n#IndieAuth is the most implemented decentralized #identity #protocol, built on #OAuth 2.\n\n#IndieWeb #OpenWeb #WebIdentity \n#noBlockchain needed",
        "html": "going to part of the IndieAuth Pop-up Session<br />\ud83d\uddd3 9:30-11:30am PDT, Sat 8/8<br />\ud83c\udf9f RSVP: <a href=\"https://events.indieweb.org/2020/08/indieauth-1-1-identity-protocol-standards-session-6xlxgeCEMgv8\">https://events.indieweb.org/2020/08/indieauth-1-1-identity-protocol-standards-session-6xlxgeCEMgv8</a><br /><br />#<span class=\"p-category\">IndieAuth</span> is the most implemented decentralized #<span class=\"p-category\">identity</span> #<span class=\"p-category\">protocol</span>, built on #<span class=\"p-category\">OAuth</span> 2.<br /><br />#<span class=\"p-category\">IndieWeb</span> #<span class=\"p-category\">OpenWeb</span> #<span class=\"p-category\">WebIdentity</span> <br />#<span class=\"p-category\">noBlockchain</span> needed"
    },
    "author": {
        "type": "card",
        "name": "Tantek \u00c7elik",
        "url": "http://tantek.com/",
        "photo": "https://aperture-media.p3k.io/tantek.com/acfddd7d8b2c8cf8aa163651432cc1ec7eb8ec2f881942dca963d305eeaaa6b8.jpg"
    },
    "post-type": "rsvp",
    "refs": {
        "https://events.indieweb.org/2020/08/indieauth-1-1-identity-protocol-standards-session-6xlxgeCEMgv8": {
            "type": "entry",
            "url": "https://events.indieweb.org/2020/08/indieauth-1-1-identity-protocol-standards-session-6xlxgeCEMgv8",
            "name": "an IndieWeb event",
            "post-type": "article"
        }
    },
    "_id": "13839016",
    "_source": "1",
    "_is_read": true
}

{
    "type": "entry",
    "published": "2020-08-07T08:05:00.00000-07:00",
    "url": "https://v2.jacky.wtf/post/9b364ffa-bc81-4ce5-a77c-67ef02f1355b",
    "category": [
        "bugs",
        "JavaScript"
    ],
    "content": {
        "text": "For some reason specific to Bluebird, I can\u2019t get the Microformats JavaScript library working. I can see how this would be a huge road block for anyone wanting to build IndieWeb stuff if a core component of it (Microformats) can\u2019t be worked. Lemme see if I can reproduce this and figure out if it can be patched.",
        "html": "<p>For some reason specific to Bluebird, I can\u2019t get the Microformats JavaScript library working. I can see how this would be a huge road block for anyone wanting to build IndieWeb stuff if a core component of it (Microformats) can\u2019t be worked. Lemme see if I can reproduce this and figure out if it can be patched.</p>"
    },
    "author": {
        "type": "card",
        "name": "",
        "url": "https://v2.jacky.wtf",
        "photo": null
    },
    "post-type": "note",
    "_id": "13832907",
    "_source": "1886",
    "_is_read": true
}

Tantek Çelik tantek.com

backfeed GitHub labels on your issues

{
    "type": "entry",
    "published": "2020-08-06 13:08-0700",
    "url": "http://tantek.com/2020/219/b2/",
    "category": [
        "backfeed"
    ],
    "in-reply-to": [
        "https://github.com/snarfed/bridgy/issues"
    ],
    "name": "backfeed GitHub labels on your issues",
    "content": {
        "text": "On GitHub, project team members are able to add labels to your issues on a project. If your issue is a POSSE copy of an original post on your site, Bridgy should backfeed these as \"tag-of\" responses to the original post.\n\n\nBridgy Publish already \nsupports POSSEing tag-of posts in reply to GitHub issues, \nas labels on those issues, and this is the backfeed counterpart. Brainstormed here: \nhttps://indieweb.org/tag-reply#How_to_post_a_tag-reply.\n\n\nThis is similar to \nissue #776 \nwhich is the same backfeed feature request but for Flickr.\n\n\nThis is also the \u201clabeled\u201d specific subfeature of \nissue #833 \nwhich documents many more backfeed for GitHub requests.\n\n\nAnd similar to \nthis comment on #811 \n(original post) \nrequesting Bridgy Publish untag-of support, \nit\u2019s worth considering Bridgy Backfeed untag-of support \n(the \u201cunlabeled\u201d specific subfeature of #833), \nso when someone removes a label from your issue, your original issue post is notified. However, the \nbrainstorming of how to markup untagging \nis still ongoing, and thus may need to wait for more discussion before implementing.\n\n\nLabel: backfeed.",
        "html": "<p>\nOn GitHub, project team members are able to add labels to your issues on a project. If your issue is a POSSE copy of an original post on your site, Bridgy should backfeed these as \"tag-of\" responses to the original post.\n</p>\n<p>\nBridgy Publish already \n<a href=\"https://github.com/snarfed/bridgy/issues/811\">supports POSSEing tag-of posts in reply to GitHub issues</a>, \nas labels on those issues, and this is the backfeed counterpart. Brainstormed here: \n<a href=\"https://indieweb.org/tag-reply#How_to_post_a_tag-reply\">https://indieweb.org/tag-reply#How_to_post_a_tag-reply</a>.\n</p>\n<p>\nThis is similar to \n<a href=\"https://github.com/snarfed/bridgy/issues/776\">issue #776</a> \nwhich is the same backfeed feature request but for Flickr.\n</p>\n<p>\nThis is also the \u201clabeled\u201d specific subfeature of \n<a href=\"https://github.com/snarfed/bridgy/issues/833\">issue #833</a> \nwhich documents many more backfeed for GitHub requests.\n</p>\n<p>\nAnd similar to \n<a href=\"https://github.com/snarfed/bridgy/issues/811#issuecomment-382469530\">this comment on #811</a> \n(<a href=\"https://tantek.com/2018/108/t2/untag-of-bridgy-publish-github-label\">original post</a>) \nrequesting Bridgy Publish untag-of support, \nit\u2019s worth considering Bridgy Backfeed untag-of support \n(the \u201cunlabeled\u201d specific subfeature of #833), \nso when someone removes a label from your issue, your original issue post is notified. However, the \n<a href=\"https://indieweb.org/untag#How_to_mark_up.3F\">brainstorming of how to markup untagging</a> \nis still ongoing, and thus may need to wait for more discussion before implementing.\n</p>\n<p>\nLabel: <span class=\"p-category\">backfeed</span>.\n</p>"
    },
    "author": {
        "type": "card",
        "name": "Tantek \u00c7elik",
        "url": "http://tantek.com/",
        "photo": "https://aperture-media.p3k.io/tantek.com/acfddd7d8b2c8cf8aa163651432cc1ec7eb8ec2f881942dca963d305eeaaa6b8.jpg"
    },
    "post-type": "reply",
    "refs": {
        "https://github.com/snarfed/bridgy/issues": {
            "type": "entry",
            "url": "https://github.com/snarfed/bridgy/issues",
            "name": "GitHub project \u201cbridgy\u201d",
            "post-type": "article"
        }
    },
    "_id": "13813244",
    "_source": "1",
    "_is_read": true
}

Tantek Çelik tantek.com

Should we specify a MIME type / Content-Type for canonical JSON from parsed mf2?

{
    "type": "entry",
    "published": "2020-08-06 11:46-0700",
    "url": "http://tantek.com/2020/219/b1/",
    "category": [
        "enhancement",
        "question",
        "needs proposed resolution"
    ],
    "in-reply-to": [
        "https://github.com/microformats/microformats2-parsing/issues"
    ],
    "name": "Should we specify a MIME type / Content-Type for canonical JSON from parsed mf2?",
    "content": {
        "text": "There has been some past brainstorming about possible MIME types for the JSON resulting from a compliant microformats2 parsing implementation:\nmicroformats2-mime-type. \nIt seems one in particular, application/mf2+json, has seen some adoption in the wild: https://indieweb.org/application/mf2+json.\nShould we specify an explicit MIME type for the parsed JSON result of an mf2 parser? And if so, should we adopt application/mf2+json or some other alternative?\n\n\nLabels: enhancement, \nquestion, \nneeds proposed resolution.",
        "html": "<p>\nThere has been some past brainstorming about possible MIME types for the JSON resulting from a compliant microformats2 parsing implementation:\n<a href=\"https://microformats.org/wiki/microformats2-mime-type\">microformats2-mime-type</a>. \nIt seems one in particular, <code>application/mf2+json</code>, has seen some adoption in the wild: <a href=\"https://indieweb.org/application/mf2+json\">https://indieweb.org/application/mf2+json</a>.\nShould we specify an explicit MIME type for the parsed JSON result of an mf2 parser? And if so, should we adopt <code>application/mf2+json</code> or some other alternative?\n</p>\n<p>\nLabels: <span class=\"p-category\">enhancement</span>, \n<span class=\"p-category\">question</span>, \n<span class=\"p-category\">needs proposed resolution</span>.\n</p>"
    },
    "author": {
        "type": "card",
        "name": "Tantek \u00c7elik",
        "url": "http://tantek.com/",
        "photo": "https://aperture-media.p3k.io/tantek.com/acfddd7d8b2c8cf8aa163651432cc1ec7eb8ec2f881942dca963d305eeaaa6b8.jpg"
    },
    "post-type": "reply",
    "refs": {
        "https://github.com/microformats/microformats2-parsing/issues": {
            "type": "entry",
            "url": "https://github.com/microformats/microformats2-parsing/issues",
            "name": "GitHub project \u201cmicroformats2-parsing\u201d",
            "post-type": "article"
        }
    },
    "_id": "13813245",
    "_source": "1",
    "_is_read": true
}

{
    "type": "entry",
    "published": "2020-08-06T12:21:00.00000-07:00",
    "url": "https://v2.jacky.wtf/post/464372b9-9221-4a92-b9f2-70a2e65208c8",
    "content": {
        "text": "I\u2019m thinking about Webmention feeds and I\u2019m noticing now how special they might be compared to some other feeds. For example, if I wanted to do something that just spat out every Webmention I\u2019ve received, that\u2019d get noisy fast if I have a very busy stream of incoming Webmentions. I do want to consider generating a feed that\u2019d resort itself based on the last recent activity but also provide context about the volume of activity that happened on said resource. Perhaps making the specific feed of activity of said resource be the target of the feed as well as linking to the resource in question would work. Lots of variability here to be honest and I\u2019ve an interest in keeping the \u201chow\u201d this works very straight forward. This would be all stuff you\u2019d see in a social reader, for some context.",
        "html": "<p>I\u2019m thinking about Webmention feeds and I\u2019m noticing now how special they might be compared to some other feeds. For example, if I wanted to do something that just spat out every Webmention I\u2019ve received, that\u2019d get noisy fast if I have a very busy stream of incoming Webmentions. I do want to consider generating a feed that\u2019d resort itself based on the last recent activity but also provide context about the volume of activity that happened on said resource. Perhaps making the specific feed of activity of said resource be the target of the feed as well as linking to the resource in question would work. Lots of variability here to be honest and I\u2019ve an interest in keeping the \u201chow\u201d this works very straight forward. This would be all stuff you\u2019d see in a social reader, for some context.</p>"
    },
    "author": {
        "type": "card",
        "name": "",
        "url": "https://v2.jacky.wtf",
        "photo": null
    },
    "post-type": "note",
    "_id": "13811330",
    "_source": "1886",
    "_is_read": true
}

{
    "type": "entry",
    "published": "2020-08-05T06:40:00.00000-07:00",
    "url": "https://v2.jacky.wtf/post/299e4167-19f2-41bf-9dc2-7dc539feca79",
    "category": [
        "indieweb",
        "thoughts"
    ],
    "content": {
        "text": "I think I either want native \u201clink quoting\u201d / citations in my site and in Indigenous or someway to automatically do that. This hints back at a conversation in the IndieWeb channels about how posting interfaces have homogenized to be \u201cintelligent\u201d (in the sense that by setting certain fields, the post type can be inferred). I think it\u2019s more constraint driven for sure but due to the hyper plurality of content types we\u2019ve engaged with, it\u2019s easier to throw users a kitchen sink versus providing more intelligent interfaces. We\u2019re making strides towards that though!",
        "html": "<p>I <em>think</em> I either want native \u201clink quoting\u201d / citations in my site and in Indigenous <em>or</em> someway to automatically do that. This hints back at a conversation in the IndieWeb channels about how posting interfaces have homogenized to be \u201cintelligent\u201d (in the sense that by setting certain fields, the post type can be inferred). I think it\u2019s more constraint driven for sure but due to the hyper plurality of content types we\u2019ve engaged with, it\u2019s easier to throw users a kitchen sink versus providing more intelligent interfaces. We\u2019re making strides towards that though!</p>"
    },
    "author": {
        "type": "card",
        "name": "",
        "url": "https://v2.jacky.wtf",
        "photo": null
    },
    "post-type": "note",
    "_id": "13775069",
    "_source": "1886",
    "_is_read": true
}

Jeremy Keith adactio.com

{
    "type": "entry",
    "published": "2020-08-05T09:53:42Z",
    "url": "https://adactio.com/links/17246",
    "category": [
        "indieweb",
        "independent",
        "publishing",
        "writing",
        "books",
        "crowdfunding",
        "kickstarter",
        "platforms",
        "archives",
        "longevity"
    ],
    "bookmark-of": [
        "https://craigmod.com/roden/042/"
    ],
    "content": {
        "text": "Kissa. Book. Launch. \u2014 Roden Explorers Archive\n\n\n\n\n  Own. Your. Nook. There\u2019s power in owning your nook of the \u2018net \u2014 your domain name, your design, your archives \u2014 and it\u2019s easier than ever to do so, and run a crowdfunding campaign at the same time.",
        "html": "<h3>\n<a class=\"p-name u-bookmark-of\" href=\"https://craigmod.com/roden/042/\">\nKissa. Book. Launch. \u2014 Roden Explorers Archive\n</a>\n</h3>\n\n<blockquote>\n  <p>Own. Your. Nook. There\u2019s power in owning your nook of the \u2018net \u2014 your domain name, your design, your archives \u2014 and it\u2019s easier than ever to do so, and run a crowdfunding campaign at the same time.</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": "13772679",
    "_source": "2",
    "_is_read": true
}

{
    "type": "entry",
    "published": "2020-08-04T15:00:31.90875-07:00",
    "url": "https://v2.jacky.wtf/post/2af484c8-0674-4354-835d-dcaa5788fb6f",
    "content": {
        "text": "Patched Lighthouse so it can allow you to resend Webmentions for a particular URL when provided. I had a moment when I noticed some Webmentions weren\u2019t sent (due to being queued) and this helped bump it on the list.",
        "html": "<p>Patched Lighthouse so it can allow you to resend Webmentions for a particular URL when provided. I had a moment when I noticed some Webmentions weren\u2019t sent (due to being queued) and this helped bump it on the list.</p>"
    },
    "author": {
        "type": "card",
        "name": "",
        "url": "https://v2.jacky.wtf",
        "photo": null
    },
    "post-type": "note",
    "_id": "13760211",
    "_source": "1886",
    "_is_read": true
}

Jamie Tanna www.jvt.me

{
    "type": "entry",
    "published": "2020-08-04T18:56:48.114Z",
    "url": "https://www.jvt.me/mf2/2020/08/kdjw1/",
    "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/2020/08/online-homebrew-website-club-nottingham-qZ0U2nBYUpZT",
        "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/2020/08/online-homebrew-website-club-nottingham-qZ0U2nBYUpZT\">https://events.indieweb.org/2020/08/online-homebrew-website-club-nottingham-qZ0U2nBYUpZT</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": "13757026",
    "_source": "2169",
    "_is_read": true
}

Manton Reece www.manton.org

Bringing back GitHub archiving

{
    "type": "entry",
    "author": {
        "name": "Manton Reece",
        "url": "https://www.manton.org/",
        "photo": "https://micro.blog/manton/avatar.jpg"
    },
    "url": "https://www.manton.org/2020/08/04/bringing-back-github.html",
    "name": "Bringing back GitHub archiving",
    "content": {
        "html": "<p>Micro.blog used to have a feature that would mirror the HTML and photos for your blog to GitHub, so that you\u2019d always have an extra copy as a backup outside of Micro.blog. The initial version of this feature had some limitations that forced me to disable it over a year ago. I always hoped to bring it back in another form, and today I rolled out the replacement.</p>\n\n<p>The new version of GitHub archiving has a few changes:</p>\n\n<ul><li>It uses a new structure based on the Blog Archive Format. It is a single HTML file (with Microformats), a JSON Feed (with both HTML and original Markdown), and all your uploads, like photos, videos, and podcast episodes.</li>\n<li>It now has more limited access to your GitHub account for better security. It only works with your own public repositories. If you previously used this feature, I\u2019ve cleared any access that Micro.blog used to have.</li>\n<li>It is designed as an archive, not a live mirror, so it only sends changes to GitHub about once a week. You can enable it and then forget its there, and I can keep supporting it because it uses fewer server resources.</li>\n</ul><p>I\u2019ve updated <a href=\"https://help.micro.blog/2016/mirroring-to-github/\">the help page</a> to describe the new feature. It\u2019s available under Posts \u2192 Design.</p>",
        "text": "Micro.blog used to have a feature that would mirror the HTML and photos for your blog to GitHub, so that you\u2019d always have an extra copy as a backup outside of Micro.blog. The initial version of this feature had some limitations that forced me to disable it over a year ago. I always hoped to bring it back in another form, and today I rolled out the replacement.\n\nThe new version of GitHub archiving has a few changes:\n\nIt uses a new structure based on the Blog Archive Format. It is a single HTML file (with Microformats), a JSON Feed (with both HTML and original Markdown), and all your uploads, like photos, videos, and podcast episodes.\nIt now has more limited access to your GitHub account for better security. It only works with your own public repositories. If you previously used this feature, I\u2019ve cleared any access that Micro.blog used to have.\nIt is designed as an archive, not a live mirror, so it only sends changes to GitHub about once a week. You can enable it and then forget its there, and I can keep supporting it because it uses fewer server resources.\nI\u2019ve updated the help page to describe the new feature. It\u2019s available under Posts \u2192 Design."
    },
    "published": "2020-08-04T14:01:43-05:00",
    "category": [
        "Essays"
    ],
    "post-type": "article",
    "_id": "13756854",
    "_source": "12",
    "_is_read": true
}

{
    "type": "entry",
    "published": "2020-08-04T03:09:00.00000-07:00",
    "url": "https://v2.jacky.wtf/post/bf00f445-555e-4b55-98bd-5b36edc354f3",
    "category": [
        "bugs",
        "lighthouse"
    ],
    "content": {
        "text": "Need to patch Lighthouse to not have expiring tokens when attempting to send out Webmentions. I\u2019m using JWTs (only because this inbuilt system is using that by default) and it\u2019s a bit annoying to have this huge token string. Might consider implementing a simpler token that keeps data on the server so the client knows less",
        "html": "<p>Need to patch Lighthouse to not have expiring tokens when attempting to send out Webmentions. I\u2019m using JWTs (only because this inbuilt system is using that by default) and it\u2019s a bit annoying to have this huge token string. Might consider implementing a simpler token that keeps data on the server so the client knows less</p>"
    },
    "author": {
        "type": "card",
        "name": "",
        "url": "https://v2.jacky.wtf",
        "photo": null
    },
    "post-type": "note",
    "_id": "13745686",
    "_source": "1886",
    "_is_read": true
}

{
    "type": "entry",
    "published": "2020-08-03T04:32:19.88007-07:00",
    "url": "https://v2.jacky.wtf/post/24121330-ced3-4d59-b2e7-f9d4c0eba8d0",
    "category": [
        "micropub",
        "koype publish"
    ],
    "content": {
        "text": "So I\u2019ve been working on Koype Publish and I learned quite a bit on it. I\u2019ve managed to build a UI that can be self-composing on the client side so I can send whatever I need up to the server. It\u2019ll translate it into a Microformats payload. The goal of this over the last month was to see if I can use it to build everything for my site (edit my homepage, adjust custom pages and even adjust the layout of a feed\u2019s markup). I know it\u2019s doable. But now, I need to look into adjusting the editor UX so it can adaptive depending on the URL provided versus having to \u201cselect\u201d what you need - the way it should be.",
        "html": "<p>So I\u2019ve been working on Koype Publish and I learned quite a bit on it. I\u2019ve managed to build a UI that can be self-composing on the client side so I can send whatever I need up to the server. It\u2019ll translate it into a Microformats payload. The goal of this over the last month was to see if I can use it to build <em>everything</em> for my site (edit my homepage, adjust custom pages and even adjust the layout of a feed\u2019s markup). I know it\u2019s doable. But now, I need to look into adjusting the editor UX so it can adaptive depending on the URL provided versus having to \u201cselect\u201d what you need - the way it <em>should</em> be.</p>"
    },
    "author": {
        "type": "card",
        "name": "",
        "url": "https://v2.jacky.wtf",
        "photo": null
    },
    "post-type": "note",
    "_id": "13719401",
    "_source": "1886",
    "_is_read": true
}

Vika fireburn.ru

{
    "type": "entry",
    "published": "2020-08-02T04:50:05+00:00",
    "url": "https://fireburn.ru/posts/1596343805",
    "syndication": [
        "https://twitter.com/kisik21/status/1289785536341671937"
    ],
    "content": {
        "text": "also hi again, couldn\u2019t break my #IndieWeb addiction, Twitter\u2019s not helping anymore",
        "html": "<p>also hi again, couldn\u2019t break my #IndieWeb addiction, Twitter\u2019s not helping anymore</p>"
    },
    "author": {
        "type": "card",
        "name": "Vika",
        "url": "https://fireburn.ru/",
        "photo": "https://fireburn.ru/media/f1/5a/fb/9b/081efafb97b4ad59f5025cf2fd0678b8f3e20e4c292489107d52be09.png"
    },
    "post-type": "note",
    "_id": "13695852",
    "_source": "1371",
    "_is_read": true
}