IndieWeb

Ben Werdmüller werd.io/profile/benwerd

Since Kittybox (or more precisely, its IndieAuth library) doesn’t support omitting PKCE, I found myself unable to log into some apps like Together. Kinda sad, but that’s the price of being on the bleeding edge of the spec, with almost no support for legacy clients.

Had to add authorization_endpoint and token_endpoint links into the header though, because it might be that I am pretty much the only one to use the newest spec and properly implement it. For now.

Next step could probably be actually making webmentions work...

#Kittybox #IndieWeb #IndieAuth

{
    "type": "entry",
    "published": "2022-09-28T21:02:08.513843116+03:00",
    "url": "https://fireburn.ru/posts/legacy-indieauth-in-kittybox",
    "category": [
        "Kittybox",
        "IndieWeb",
        "IndieAuth"
    ],
    "content": {
        "text": "Since Kittybox (or more precisely, its IndieAuth library) doesn\u2019t support omitting PKCE, I found myself unable to log into some apps like Together. Kinda sad, but that\u2019s the price of being on the bleeding edge of the spec, with almost no support for legacy clients.\n\nHad to add authorization_endpoint and token_endpoint links into the header though, because it might be that I am pretty much the only one to use the newest spec and properly implement it. For now.\n\nNext step could probably be actually making webmentions work...",
        "html": "<p>Since Kittybox (or more precisely, its IndieAuth library) doesn\u2019t support omitting PKCE, I found myself unable to log into some apps like <a href=\"https://alltogethernow.io/\">Together</a>. Kinda sad, but that\u2019s the price of being on the bleeding edge of the spec, with almost no support for legacy clients.</p>\n\n<p>Had to add <code>authorization_endpoint</code> and <code>token_endpoint</code> links into the header though, because it might be that I am pretty much the only one to use the newest spec and properly implement it. For now.</p>\n\n<p>Next step could probably be actually making webmentions work...</p>"
    },
    "author": {
        "type": "card",
        "name": "Vika",
        "url": "https://fireburn.ru/",
        "photo": "https://avatars.githubusercontent.com/u/7953163?v=4"
    },
    "post-type": "note",
    "_id": "31685416",
    "_source": "1371",
    "_is_read": true
}

Vika fireburn.ru

test

if u see this i have implemented indieauth and can now do stuff

#IndieWeb

{
    "type": "entry",
    "published": "2022-09-28T04:16:57.847351100+03:00",
    "url": "https://fireburn.ru/posts/afLMNj7",
    "category": [
        "IndieWeb"
    ],
    "content": {
        "text": "test\n\nif u see this i have implemented indieauth and can now do stuff",
        "html": "<p>test</p>\n\n<p>if u see this i have implemented indieauth and can now do stuff</p>"
    },
    "author": {
        "type": "card",
        "name": "Vika",
        "url": "https://fireburn.ru/",
        "photo": "https://avatars.githubusercontent.com/u/7953163?v=4"
    },
    "post-type": "note",
    "_id": "31663541",
    "_source": "1371",
    "_is_read": true
}

Ben Werdmüller werd.io/profile/benwerd

Indiepeople

September 27, 2022 6:29am +00:00

{
"type": "entry",
"published": "2022-09-27T06:29:43+00:00",
"url": "https://werd.io/2022/indiepeople",
"name": "Indiepeople",
"content": {
"text": "I\u2019ve long been a member of the indieweb, a community based around encouraging people to own their spaces on the web rather than trusting their content to centralized services that may spy on them, use their content for their own ends, or randomly go out of business. Indieweb technologies do a good job of undercutting supplier power over identity online without imposing a single technological approach, business model, or product.I believe strongly in the indieweb principles of distributed ownership, control, and independence. For me, the important thing is that this is how we get to a diverse web. A web where everyone can define not just what they write but how they present is by definition far more expressive, diverse, and interesting than one where most online content and identities must be squished into templates created by a handful of companies based on their financial needs. In other words, the open web is far superior to a medium controlled by corporations in order to sell ads. The former encourages expression; the latter encourages consumerist conformity.Of course, these same dynamics aren\u2019t limited to the web, and this conflict didn\u2019t originate there. Yes, a website that you control for your own purposes has far more possibilities than one controlled by corporations for their financial gain. A web full of diverse content and identities is richer and fuller. But you can just as easily swap out the word \u201cwebsite\u201d for \u201clife\u201d: a life that you control for your own purposes has far more possibilities than one controlled by corporations for their financial gain, too. A world full of diverse people is richer and fuller.Consider identity. There are a set of norms, established over centuries, over how we describe ourselves; we\u2019re expected to fit into boxes around gender, religion, orientation, and so on. But these boxes necessarily don\u2019t describe people in full, and depending on your true identity, may be uncomfortably inaccurate. So these days, it\u2019s becoming more acceptable to define your own gender (and accompanying descriptive pronouns), orientation, personality, etc - and rightly so. Once again it comes down to the expressive self vs the templated self. There\u2019s no need to keep ourselves to the template, so if it doesn\u2019t fit, why not shed it? Who wrote these templates anyway? (The answer, of course, is the people who they fit most cleanly, and who would benefit the most from broad adherence.) People talk about \u201cidentity politics\u201d, but they\u2019re the politics of who gets to define who you are. You should.I\u2019ve been thinking a lot about radicalism lately. While there have been protests over the last few years over racial inequality, systemic injustices, reproductive rights, and the rise of Christian nationalism, most people have been relatively docile. These are changes that either affect you today or will affect you soon, so the relative quiet has seemed strange to me. But the answer is obvious: I mean, who has the time? Really, who?The most pervasive templates going are the ones that seek to define how people create a life for themselves, enforced by a context that makes it impossible to do just about anything else. Millions upon millions of people get up at the crack of dawn to go to work, commute in their cars for an hour a day, put in their hours, potentially go to a second job and do the same, and then go to bed to do it all again the next day. It\u2019s sold as the right way to do things, but when the pay you take home barely covers your costs, and when you\u2019re forced to work until you die, there\u2019s very little life left. It\u2019s an exploitative culture that enforces conformity, and in doing so is inherently undemocratic. A thriving democracy is one where citizens can express themselves, protest for what they think is right, and enact change through building community - which is impossible if everyone has no time to do anything but work, and is too scared that they will lose their jobs to break conformity. This way of living isn\u2019t for us; in the same way that the web is templated to the decisions made by big corporations like Facebook so they can sell more ads, the way we live is templated to the needs of large financial interests, too.Who should get to choose how you live? You should. But just as many people argue for the conformist vision of identity, there are scores of people ready to argue that the exploitative version of labor is the right one.Let\u2019s continue to use the web as an analogy. It\u2019s an open platform, run in the public interest by a changing group of people, on which we can build our own identities, profiles, content, tools, and businesses. Standards are established through a kind of social contract between entities. This is the way I see government, too: contrary to, say, a libertarian view of the world, I think we need a common infrastructure to build on top of. Representative democratic government is (assuming an engaged electorate and free and open elections) an expression of the will of the people. More than that, it\u2019s infrastructure for us to build on: a common layer built in the public interest, upon which we can grow and build.What\u2019s a part of that platform has a direct relationship to what can be built. If the web didn\u2019t define links, we\u2019d spend all our time thinking of new ways to build them. But the web does define links, and we can spend our time building much more advanced interfaces and specifications because we don\u2019t have to worry about them. If government didn\u2019t provide roads, we\u2019d have to worry about what basic transit looked like; the same goes for public transport, education, or healthcare. We can reach for the stars and be far more ambitious when our basic needs are taken care of. But those needs must be open and in the public interest, rather than proprietary and designed for profit. (What would the web look like if link tags had been owned by AOL?)Perhaps it\u2019s a tortured analogy, but in a way it\u2019s not an analogy at all: the way the web evolved is a reflection of the larger societal dynamics around it. We can create an indieweb movement, and our websites may be free and open. But the real work is to create a free and open culture that serves everyone, where everyone has the right and freedom to be themselves, and where we can all reach for the stars together.The principles of openness, collaboration, independence, expression, and distributed ownership are not just about software. Really they\u2019re not about software at all. At their best, they\u2019re a glimpse at what a different kind of life might look like. One where we\u2019re free.\u00a0Photo by Ehimetalor Akhere Unuabona on Unsplash",
"html": "<img src=\"https://werd.io/file/633298c4c4d6980614191722/thumb.jpg\" alt=\"\" width=\"1024\" height=\"683\" />I\u2019ve long been a member of the <a href=\"https://indieweb.org\">indieweb</a>, a community based around encouraging people to own their spaces on the web rather than trusting their content to centralized services that may spy on them, use their content for their own ends, or randomly go out of business. Indieweb technologies do a good job of undercutting <a href=\"https://en.wikipedia.org/wiki/Porter%27s_five_forces_analysis#Bargaining_power_of_suppliers\">supplier power</a> over identity online without imposing a single technological approach, business model, or product.I believe strongly in the indieweb principles of distributed ownership, control, and independence. For me, the important thing is that this is how we get to a diverse web. A web where everyone can define not just what they write but how they present is by definition far more expressive, diverse, and interesting than one where most online content and identities must be squished into templates created by a handful of companies based on their financial needs. In other words, the open web is far superior to a medium controlled by corporations in order to sell ads. The former encourages expression; the latter encourages consumerist conformity.Of course, these same dynamics aren\u2019t limited to the web, and this conflict didn\u2019t originate there. Yes, a website that you control for your own purposes has far more possibilities than one controlled by corporations for their financial gain. A web full of diverse content and identities is richer and fuller. But you can just as easily swap out the word \u201cwebsite\u201d for \u201clife\u201d: a life that you control for your own purposes has far more possibilities than one controlled by corporations for their financial gain, too. A world full of diverse people is richer and fuller.Consider identity. There are a set of norms, established over centuries, over how we describe ourselves; we\u2019re expected to fit into boxes around gender, religion, orientation, and so on. But these boxes necessarily don\u2019t describe people in full, and depending on your true identity, may be uncomfortably inaccurate. So these days, it\u2019s becoming more acceptable to define your own gender (and accompanying descriptive pronouns), orientation, personality, etc - and rightly so. Once again it comes down to the expressive self vs the templated self. There\u2019s no need to keep ourselves to the template, so if it doesn\u2019t fit, why not shed it? Who wrote these templates anyway? (The answer, of course, is the people who they fit most cleanly, and who would benefit the most from broad adherence.) People talk about \u201cidentity politics\u201d, but they\u2019re the politics of who gets to define who you are. You should.I\u2019ve been thinking a lot about radicalism lately. While there have been protests over the last few years over racial inequality, systemic injustices, reproductive rights, and the rise of Christian nationalism, most people have been relatively docile. These are changes that either affect you today or will affect you soon, so the relative quiet has seemed strange to me. But the answer is obvious: I mean, who has the time? Really, who?The most pervasive templates going are the ones that seek to define how people create a life for themselves, enforced by a context that makes it impossible to do just about anything else. Millions upon millions of people get up at the crack of dawn to go to work, commute in their cars for an hour a day, put in their hours, potentially go to a second job and do the same, and then go to bed to do it all again the next day. It\u2019s sold as the right way to do things, but when the pay you take home barely covers your costs, and when you\u2019re forced to work until you die, there\u2019s very little life left. It\u2019s an exploitative culture that enforces conformity, and in doing so is inherently undemocratic. A thriving democracy is one where citizens can express themselves, protest for what they think is right, and enact change through building community - which is impossible if everyone has no time to do anything but work, and is too scared that they will lose their jobs to break conformity. This way of living isn\u2019t for us; in the same way that the web is templated to the decisions made by big corporations like Facebook so they can sell more ads, the way we live is templated to the needs of large financial interests, too.Who should get to choose how you live? You should. But just as many people argue for the conformist vision of identity, there are scores of people ready to argue that the exploitative version of labor is the right one.Let\u2019s continue to use the web as an analogy. It\u2019s an open platform, run in the public interest by a changing group of people, on which we can build our own identities, profiles, content, tools, and businesses. Standards are established through a kind of social contract between entities. This is the way I see government, too: contrary to, say, a libertarian view of the world, I think we need a common infrastructure to build on top of. Representative democratic government is (assuming an engaged electorate and free and open elections) an expression of the will of the people. More than that, it\u2019s infrastructure for us to build on: a common layer built in the public interest, upon which we can grow and build.What\u2019s a part of that platform has a direct relationship to what can be built. If the web didn\u2019t define links, we\u2019d spend all our time thinking of new ways to build them. But the web does define links, and we can spend our time building much more advanced interfaces and specifications because we don\u2019t have to worry about them. If government didn\u2019t provide roads, we\u2019d have to worry about what basic transit looked like; the same goes for public transport, education, or healthcare. We can reach for the stars and be far more ambitious when our basic needs are taken care of. But those needs must be open and in the public interest, rather than proprietary and designed for profit. (What would the web look like if link tags had been owned by AOL?)Perhaps it\u2019s a tortured analogy, but in a way it\u2019s not an analogy at all: the way the web evolved is a reflection of the larger societal dynamics around it. We can create an indieweb movement, and our websites may be free and open. But the real work is to create a free and open culture that serves everyone, where everyone has the right and freedom to be themselves, and where we can all reach for the stars together.The principles of openness, collaboration, independence, expression, and distributed ownership are not just about software. Really they\u2019re not about software at all. At their best, they\u2019re a glimpse at what a different kind of life might look like. One where we\u2019re free.\u00a0Photo by <a href=\"https://unsplash.com/@theeastlondonphotographer?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText\">Ehimetalor Akhere Unuabona</a> on <a href=\"https://unsplash.com/s/photos/democracy?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText\">Unsplash</a>"
},
"author": {
"type": "card",
"name": "Ben Werdm\u00fcller",
"url": "https://werd.io/profile/benwerd",
"photo": "https://werd.io/file/5d388c5fb16ea14aac640912/thumb.jpg"
},
"post-type": "article",
"_id": "31638834",
"_source": "191",
"_is_read": true
}

latl.ong

Ben Werdmüller werd.io/profile/benwerd

Meridian finds places based on a user’s latitude and longitude - and is open source and distributed. Useful for all kinds of purposes, not least indieweb checkin apps. #Indieweb

#Indieweb

September 26, 2022 6:15pm +00:00

{
    "type": "entry",
    "published": "2022-09-26T18:15:23+00:00",
    "url": "https://werd.io/2022/meridian",
    "category": [
        "Indieweb"
    ],
    "bookmark-of": [
        "https://latl.ong/"
    ],
    "content": {
        "text": "Meridian finds places based on a user\u2019s latitude and longitude - and is open source and distributed. Useful for all kinds of purposes, not least indieweb checkin apps. #Indieweb",
        "html": "<p>Meridian finds places based on a user\u2019s latitude and longitude - and is open source and distributed. Useful for all kinds of purposes, not least indieweb checkin apps. <a href=\"https://werd.io/tag/Indieweb\" class=\"p-category\">#Indieweb</a></p>"
    },
    "author": {
        "type": "card",
        "name": "Ben Werdm\u00fcller",
        "url": "https://werd.io/profile/benwerd",
        "photo": "https://werd.io/file/5d388c5fb16ea14aac640912/thumb.jpg"
    },
    "post-type": "bookmark",
    "_id": "31627720",
    "_source": "191",
    "_is_read": true
}

github.com/microformats/php-mf2/issues

gRegor Morrill gregorlove.com

Add img srcset parsing

#issue #microformats

September 24, 2022 12:43pm -07:00

{
    "type": "entry",
    "published": "2022-09-24 12:43-0700",
    "url": "https://gregorlove.com/2022/09/add-img-srcset-parsing/",
    "category": [
        "issue",
        "microformats"
    ],
    "syndication": [
        "https://github.com/microformats/php-mf2/issues/242"
    ],
    "in-reply-to": [
        "https://github.com/microformats/php-mf2/issues"
    ],
    "name": "Add img srcset parsing",
    "content": {
        "text": "Parse img.srcset per parsing issue #7. MicroMicro now supports this, so once we have 2+ implementations and rough consensus, we can update the parsing specification.",
        "html": "<p>Parse <code>img.srcset</code> per <a href=\"https://github.com/microformats/microformats2-parsing/issues/7\">parsing issue #7</a>. MicroMicro now <a href=\"https://github.com/jgarber623/micromicro/releases/tag/v3.1.0\">supports</a> this, so once we have 2+ implementations and rough consensus, we can update the parsing specification.</p>"
    },
    "author": {
        "type": "card",
        "name": "gRegor Morrill",
        "url": "https://gregorlove.com/",
        "photo": "https://gregorlove.com/site/assets/files/3473/profile-2016-med.jpg"
    },
    "post-type": "reply",
    "_id": "31592150",
    "_source": "95",
    "_is_read": true
}

www.toheeb.com

Jeremy Keith adactio.com

Web UI Engineering Book - toheeb.com

I like the way this work-in-progress is organised—it’s both a book and a personal website that’ll grow over time.

#webbook #frontend #development #ui #engineering #personal #publishing #writing #indieweb

September 20, 2022 11:20am +00:00

{
    "type": "entry",
    "published": "2022-09-20T11:20:52Z",
    "url": "https://adactio.com/links/19466",
    "category": [
        "webbook",
        "frontend",
        "development",
        "ui",
        "engineering",
        "personal",
        "publishing",
        "writing",
        "indieweb"
    ],
    "bookmark-of": [
        "https://www.toheeb.com/"
    ],
    "content": {
        "text": "Web UI Engineering Book - toheeb.com\n\n\n\nI like the way this work-in-progress is organised\u2014it\u2019s both a book and a personal website that\u2019ll grow over time.",
        "html": "<h3>\n<a class=\"p-name u-bookmark-of\" href=\"https://www.toheeb.com/\">\nWeb UI Engineering Book - toheeb.com\n</a>\n</h3>\n\n<p>I like the way this work-in-progress is organised\u2014it\u2019s both a book and a personal website that\u2019ll grow over time.</p>"
    },
    "author": {
        "type": "card",
        "name": "Jeremy Keith",
        "url": "https://adactio.com/",
        "photo": "https://adactio.com/images/photo-150.jpg"
    },
    "post-type": "bookmark",
    "_id": "31480284",
    "_source": "2",
    "_is_read": true
}

www.zylstra.org/blog/2022/09/wordpressindieweb-as-the-os-of-the-open-social-web/

Ben Werdmüller werd.io/profile/benwerd

WordPress+IndieWeb as the OS of the Open Social Web

#Technology

September 18, 2022 9:18pm +00:00

{
    "type": "entry",
    "published": "2022-09-18T21:18:16+00:00",
    "url": "https://werd.io/2022/wordpressindieweb-as-the-os-of-the-open-social-web",
    "category": [
        "Technology"
    ],
    "bookmark-of": [
        "https://www.zylstra.org/blog/2022/09/wordpressindieweb-as-the-os-of-the-open-social-web/"
    ],
    "name": "WordPress+IndieWeb as the OS of the Open Social Web",
    "content": {
        "text": "Nice indieweb thoughts and presentation. As an aside, I\u2019ve added Hypothesis annotations to my site, inspired by Ton\u2019s site.  #Technology",
        "html": "<p>Nice indieweb thoughts and presentation. As an aside, I\u2019ve added Hypothesis annotations to my site, inspired by Ton\u2019s site.  <a href=\"https://werd.io/tag/Technology\" class=\"p-category\">#Technology</a></p>"
    },
    "author": {
        "type": "card",
        "name": "Ben Werdm\u00fcller",
        "url": "https://werd.io/profile/benwerd",
        "photo": "https://werd.io/file/5d388c5fb16ea14aac640912/thumb.jpg"
    },
    "post-type": "bookmark",
    "_id": "31449836",
    "_source": "191",
    "_is_read": true
}

Manton Reece www.manton.org

I like these slides from a talk by @ton about enabling more IndieWeb features in WordPress… Includes Micro.blog screenshot too!

September 16, 2022 8:23am -05:00

{
    "type": "entry",
    "author": {
        "name": "Manton Reece",
        "url": "https://www.manton.org/",
        "photo": "https://micro.blog/manton/avatar.jpg"
    },
    "url": "https://www.manton.org/2022/09/16/i-like-these.html",
    "content": {
        "html": "<p><a href=\"https://www.zylstra.org/blog/2022/09/wordpressindieweb-as-the-os-of-the-open-social-web/\">I like these slides</a> from a talk by <a href=\"https://micro.blog/ton\">@ton</a> about enabling more IndieWeb features in WordPress\u2026 Includes Micro.blog screenshot too!</p>",
        "text": "I like these slides from a talk by @ton about enabling more IndieWeb features in WordPress\u2026 Includes Micro.blog screenshot too!"
    },
    "published": "2022-09-16T08:23:18-05:00",
    "post-type": "note",
    "_id": "31411655",
    "_source": "12",
    "_is_read": true
}

www.robinrendle.com/notes/take-care-of-your-blog-/

Jeremy Keith adactio.com

Take Care of Your Blog

Blog!

Blog your heart! Blog about something you’ve learned, blog about something you’re interested in.

Excellent advice from Robin:

There are no rules to blogging except this one: always self-host your website because your URL, your own private domain, is the most valuable thing you can own. Your career will thank you for it later and no-one can take it away.

#indieweb #personal #publishing #writing #sharing #blogging #blogs

September 12, 2022 9:03am +00:00

{
    "type": "entry",
    "published": "2022-09-12T09:03:39Z",
    "url": "https://adactio.com/links/19440",
    "category": [
        "indieweb",
        "personal",
        "publishing",
        "writing",
        "sharing",
        "blogging",
        "blogs"
    ],
    "bookmark-of": [
        "https://www.robinrendle.com/notes/take-care-of-your-blog-/"
    ],
    "content": {
        "text": "Take Care of Your Blog\n\n\n\n\n  Blog!\n  \n  Blog your heart! Blog about something you\u2019ve learned, blog about something you\u2019re interested in.\n\n\nExcellent advice from Robin:\n\n\n  There are no rules to blogging except this one: always self-host your website because your URL, your own private domain, is the most valuable thing you can own. Your career will thank you for it later and no-one can take it away.",
        "html": "<h3>\n<a class=\"p-name u-bookmark-of\" href=\"https://www.robinrendle.com/notes/take-care-of-your-blog-/\">\nTake Care of Your Blog\n</a>\n</h3>\n\n<blockquote>\n  <p>Blog!</p>\n  \n  <p>Blog your heart! Blog about something you\u2019ve learned, blog about something you\u2019re interested in.</p>\n</blockquote>\n\n<p>Excellent advice from Robin:</p>\n\n<blockquote>\n  <p>There are no rules to blogging except this one: always self-host your website because your URL, your own private domain, is the most valuable thing you can own. Your career will thank you for it later and no-one can take it away.</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": "31333408",
    "_source": "2",
    "_is_read": true
}

jamesg.blog/2022/09/07/authorship-homepage/

gRegor Morrill gregorlove.com

This is one way of several based on the authorship spec (https://indieweb.org/authorship-spec#Algorithm). The p-author h-card inside the h-feed might make the most sense in your case, but you could also have a u-author property inside each h-entry that links to a page that has your author h-card. I do this with my posts, with an invisible link to my homepage.

#indieweb #microformats

September 7, 2022 4:22pm -07:00

{
    "type": "entry",
    "published": "2022-09-07 16:22-0700",
    "url": "https://gregorlove.com/2022/09/this-is-one-way-of-several/",
    "category": [
        "indieweb",
        "microformats"
    ],
    "in-reply-to": [
        "https://jamesg.blog/2022/09/07/authorship-homepage/"
    ],
    "content": {
        "text": "This is one way of several based on the authorship spec (https://indieweb.org/authorship-spec#Algorithm). The p-author h-card inside the h-feed might make the most sense in your case, but you could also have a u-author property inside each h-entry that links to a page that has your author h-card. I do this with my posts, with an invisible link to my homepage.",
        "html": "<p>This is one way of several based on the authorship spec (<a href=\"https://indieweb.org/authorship-spec#Algorithm\">https://indieweb.org/authorship-spec#Algorithm</a>). The <code>p-author h-card</code> inside the <code>h-feed</code> might make the most sense in your case, but you could also have a <code>u-author</code> property inside each <code>h-entry</code> that links to a page that has your author <code>h-card</code>. I do this with my posts, with an invisible link to my homepage.</p>"
    },
    "author": {
        "type": "card",
        "name": "gRegor Morrill",
        "url": "https://gregorlove.com/",
        "photo": "https://gregorlove.com/site/assets/files/3473/profile-2016-med.jpg"
    },
    "post-type": "reply",
    "_id": "31267938",
    "_source": "95",
    "_is_read": true
}

Manton Reece www.manton.org

Watching the locations/venues session video from IndieWebCamp Berlin. I wasn’t able to participate in this one, even remotely, but glad to see IndieWeb folks were able to get together.

September 4, 2022 9:45am -05:00

{
    "type": "entry",
    "author": {
        "name": "Manton Reece",
        "url": "https://www.manton.org/",
        "photo": "https://micro.blog/manton/avatar.jpg"
    },
    "url": "https://www.manton.org/2022/09/04/watching-the-locationsvenues.html",
    "content": {
        "html": "<p>Watching the <a href=\"https://archive.org/details/locations-venues-indie-web-camp-berlin-2022\">locations/venues session video</a> from IndieWebCamp Berlin. I wasn\u2019t able to participate in this one, even remotely, but glad to see IndieWeb folks were able to get together.</p>",
        "text": "Watching the locations/venues session video from IndieWebCamp Berlin. I wasn\u2019t able to participate in this one, even remotely, but glad to see IndieWeb folks were able to get together."
    },
    "published": "2022-09-04T09:45:32-05:00",
    "post-type": "note",
    "_id": "31206916",
    "_source": "12",
    "_is_read": true
}

ragt.ag/code/indieweb.rocks

gRegor Morrill gregorlove.com

A couple issues I noticed on https://indieweb.rocks/gregorlove.com:

Uninterpreted h-card properties: nickname
Uninterpreted h-entry properties: post-type article

On the second one I’m not sure what it’s finding. My posts don’t have microformats properties "post-type" or "article." If it doesn’t understand how to process articles, the error message could be clarified so it doesn’t sound like an issue in the published post.

#indieweb

August 31, 2022 7:12pm -07:00

{
    "type": "entry",
    "published": "2022-08-31 19:12-0700",
    "url": "https://gregorlove.com/2022/08/indieweb-rocks-issues/",
    "category": [
        "indieweb"
    ],
    "in-reply-to": [
        "https://ragt.ag/code/indieweb.rocks"
    ],
    "content": {
        "text": "A couple issues I noticed on https://indieweb.rocks/gregorlove.com:\n\nUninterpreted h-card properties: nickname\n\n\tUninterpreted h-entry properties: post-type article\n\nOn the second one I\u2019m not sure what it\u2019s finding. My posts don\u2019t have microformats properties \"post-type\" or \"article.\" If it doesn\u2019t understand how to process articles, the error message could be clarified so it doesn\u2019t sound like an issue in the published post.",
        "html": "<p>A couple issues I noticed on <a href=\"https://indieweb.rocks/gregorlove.com\">https://indieweb.rocks/gregorlove.com</a>:</p>\n\n<ol><li>Uninterpreted h-card properties: <code>nickname</code>\n</li>\n\t<li>Uninterpreted h-entry properties: <code>post-type article</code>\n</li>\n</ol><p>On the second one I\u2019m not sure what it\u2019s finding. My posts don\u2019t have microformats properties \"post-type\" or \"article.\" If it doesn\u2019t understand how to process articles, the error message could be clarified so it doesn\u2019t sound like an issue in the published post.</p>"
    },
    "author": {
        "type": "card",
        "name": "gRegor Morrill",
        "url": "https://gregorlove.com/",
        "photo": "https://gregorlove.com/site/assets/files/3473/profile-2016-med.jpg"
    },
    "post-type": "reply",
    "_id": "31160364",
    "_source": "95",
    "_is_read": true
}

Sebastiaan Andeweg seblog.nl

Storing posts by juggling with Git internals

#indieweb #meta

August 30, 2022 5:21pm +00:00

{
    "type": "entry",
    "published": "2022-08-30T17:21:34+0000",
    "url": "https://seblog.nl/2022/08/30/1/storing-posts-with-git-internals",
    "category": [
        "indieweb",
        "meta"
    ],
    "name": "Storing posts by juggling with Git internals",
    "content": {
        "text": "I have been wanting to rework the core of this website for a couple of years now, but since the current setup still works, and since I have many other things to do, and finally since I am very picky about how I want it to work, I have never really finished this part at all. This makes me stuck at the save version of this site, both visually as behind the scenes.\nNow that I am in between jobs I wanted to work on it a bit more, but I still do not have time enough to fully finish it. I guess it all comes down to a few choices I have to make regarding trade-offs. In order to make better decisions, I wanted document my current storage and the one I have been working on. After I wrote it all out I think I am deciding not to use it, but it was a nice exploration so I will share it anyway.\nThe description heavily leans on some knowledge about Git, which is software for versioning your code, or in this case, plain text files. I will try to explain a bit along the way but it is useful to have some familiarity with it already.\ntl;dr: I did fancy with Git but might not pursue.\nHow it is currently done\nAt the time of writing, my posts are stored in a plain text format with a lot of folders. It is derived from the format which the Kirby CMS expects: folders for pages with text files within it, of which the name of the text file dictates the template that is being used to render the page. In my case, it is always entry.txt.\nI have one folder per year, one folder per day of the year and one folder per post of the day. In that last folder is the entry.txt and some other files related to the post, like pictures, but also metadata like received and sent Webmentions.\nAn example of the tree view is below. It shows two entries on two days in one year. Note that days and years also have their own .txt file that is actually almost empty and pretty much useless in this setup, but still required for Kirby to work properly. The first day of the year my site is broken because it does not automatically create the required year.txt (or did I fix that finally?).\n./content\n\u2514\u2500\u2500 2022\n\u00a0\u00a0\u00a0 \u251c\u2500\u2500 001\n\u00a0\u00a0\u00a0 \u2502\u00a0\u00a0 \u251c\u2500\u2500 1\n\u00a0\u00a0\u00a0 \u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u2514\u2500\u2500 entry.txt\n\u00a0\u00a0\u00a0 \u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u251c\u2500\u2500 .webmentions\n\u00a0\u00a0\u00a0 \u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u251c\u2500\u2500 1641117941-f6bc3209f3f33f0cb8e4d92e5d46b5090b53aa11.json\n\u00a0\u00a0\u00a0 \u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u2514\u2500\u2500 pings.json\n\u00a0\u00a0\u00a0 \u2502\u00a0\u00a0 \u2514\u2500\u2500 day.txt\n\u00a0\u00a0\u00a0 \u251c\u2500\u2500 002\n\u00a0\u00a0\u00a0 \u2502\u00a0\u00a0 \u251c\u2500\u2500 1\n\u00a0\u00a0\u00a0 \u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u251c\u2500\u2500 some_image.jpg\n\u00a0\u00a0\u00a0 \u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u2514\u2500\u2500 entry.txt\n\u00a0\u00a0\u00a0 \u2502\u00a0\u00a0 \u2514\u2500\u2500 day.txt\n\u00a0\u00a0\u00a0 \u2514\u2500\u2500 year.txt\nAlso note that there is a hidden .webmentions folder which contains a pings.json for all the sent webmentions and a JSON file with timestamp and content hash in the name for every received webmention. Not in the diagram but also present are some other folders for pages like ./login/login.txt (because that is how Kirby works) and ./isbn/9780349411903/book.txt (for books).\nAll these files are stored in a Git repository, which I manually update every so often (more bimonthly than weekly, sadly) via SSH to my server. I give it a very generic commit name (\u2019sync\u2019 or so) and push to a private repo on Github, which takes a while because the commits and the repo contain all those images and all those folders.\nWhat is wrong with this\nThe main point of wanting to move off of this structure by Kirby, is that it requires those placeholder pages in my content folder. I have no need for a ./login/login.txt: the login page is just a feature of the software and should be handled by that part of the code. But at least that file contains some text for that page: the files for year.txt and day.txt are completely useless.\nAnother point is that I want to make the Git commits automatically with every Micropub request: Git provides me with a history, but only if I actually commit the files once I changed them. Also, if I do not push the changes to Github, I have no backup of recent posts.\nThe metadata of the received and sent Webmentions are now also available in the repo. This is nice, as it stores the information right next to the post it belongs to, but on the other hand it feels kind of polluting: these Webmentions contain content by others, where as the rest of the content is by me. There is some other external content hidden in the entry.txt file but I\u2019ll get to that later.\nThe last point is that the full size images are stored in the repo and every book and article about Git says that you should not use it to store big files in it. Doing a git status takes a while and also the pushes are much slower than any other Git repository I work with.\nGit history: the Git Object Model\nBefore I go further into the avenue I am taking to solve the problem, I need to explain a bit about the Git Object Model, also known as \u2018how Git works under the hood\u2019. For a more thorough explanation, see this chapter in the Git Book.\nAs you\u2019ll learn from that chapter, every object is represented as a file, referenced by the SHA1 hash of its contents. And there are three (no, four) types of objects:\n\nblobs, which are the contents of files tracked by Git (and thus also the versions of those files)\n\ntrees, which are listings of filenames with references to blobs or other trees. These trees together create the file structure of a version.\n\ncommits, which are versions. A commit contains a reference to the root tree of the files you are tracking, a parent commit (the previous version) and a message and some metadata.\n\ntags, are not mentioned by the chapter, but do exists: these look like commits, but create a way to store a message with a tag (making annotated tags, I\u2019ll explain plain tags soon).\nNote that Git does not store diffs, it always stores the full contents of every version of the file, albeit zlib compressed and sometimes even packed in a single file, but let\u2019s not get into that right now.\nGit\u2019s tags and branches are just files and folders (they can have / in their names) which contain the hashes (names) of the specific commits they point to. The tags can also point to a tag object, which will then contain a message about the tag (which makes them \u2018annotated tags\u2019).\nThis all brings me to the final point about my storage: for every new post, Git has to create a lot of files. First, it needs to add a blob for the entry.txt, possibly also a blob for the image and blobs for other metadata. Then it needs to create a tree for the entry folder, listing entry.txt and if present the filenames of the images and metadata files. Then it creates a new tree for the day, with all the existing entries plus the newly created one. Then it creates a new tree for the year, to point to this new version (tree) of the day. Then it creates a new tree for the root, with this new version of the year in it. And finally it also needs to create a commit object to point to that new root tree. Every update requires all these new trees. The trees are cheap, but it feels wasteful.\nAlso note that a version of a file always relies on the version of all other files. This is what you want for code (code is designed to work with other code), but it does not feel like the right model for posts (I might come back on this tho).\nAnd there is also the question of identifiers: currently, my posts are identified as year, day of year, number (2022/242/1), but especially that number can only be found in the name of the folder and thus in the tree, not in the blob. I have not yet found a good solution for this, but maybe I am seeing too many problems.\nThe new setup\nTo get rid of some of the trees, I tried to apply my knowledge of the Git Object Model to store my posts in another way. To do this, I used the commands suggested by the chapter in the Git Book in a script that looped over all my files, to store them in a new blank repo to try things out.\nFor each year, for each day, for each post, I would find the entry.txt and put the contents in a Git blob with git hash-object -w ./content/2022/242/1/entry.txt. The resulting hash I used in the command git update-index --add --cacheinfo 100644 $hash entry.txt to stage the file for a new tree. I would do that too for all images and related files, and then I would run git write-tree to write the tree and get the hash for it and git commit-tree $hash -m \"commit\" to create a commit based on it (with a bad message indeed). With that last hash I would run git update-ref refs/heads/2022/242/1 $hash to create a branch for that commit. (I contemplate adding an annotated tag in between, for storing some metadata like \u2018published at\u2019 date.)\nThis would result in a Git repository with over 10,000 branches (I have many posts) neatly organised in folders per year and day. When one were to check out one of these branches, just the files of that posts will appear in the root of your repo: there are no folders. When you check out another branch, other files will appear. This is not how Git usually works, but it decouples all posts from one-another.\nMultiple types of pages\nThe posts I describe above all follow the year-day-number pattern because they are posts: they are sequential entries tied to a date. There are other objects I track, though, that are not date-specific. One example is topical wiki-style pages: these pages may receive edits over time, but their topic is not tied to a date. (I don\u2019t have these yet.)\nAnother example is the books that I track to base my \u2018read\u2019 posts off. I haven\u2019t posted them in a while, but I would like to expand this book collection to also include other types of objects to reference, such as movies, games or locations. These objects also have no date to them attached, at least not a date meaningful to my posts.\nI could generate UUIDs for these objects and pages, and store branches for those commits in the same way Git does store it\u2019s objects internally, with a folder per first two characters of the hash (or UUID) and a filename of the rest:\n./refs/heads\n\u251c\u2500\u2500 0a\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 8342d2-d6f1-4363-a287-a32948d04eaa\n\u2502\u00a0\u00a0 \u2514\u2500\u2500 edcb13-433c-48d2-b683-a407c3a88f57\n\u2514\u2500\u2500 3d\n\u00a0\u00a0\u00a0 \u251c\u2500\u2500 243a27-114e-4eee-9bd8-2a51b01939e6\n\u00a0\u00a0\u00a0 \u251c\u2500\u2500 25965b-2da5-422d-abce-f3337fa97fc4\n\u00a0\u00a0\u00a0 \u2514\u2500\u2500 611b59-499a-48a0-b931-afe06192e778\nI could even reference the same post/object with multiple identifiers this way. Maybe I want to give every book a UUID, but also reference it by its ISBN. The downside to that, however, is that I need to update both branches to point to the same commit once I make an update do the book-page.\nDrawbacks of the approach\nThe multiple identifiers are probably not feasible, but there are some other drawbacks too. My main concern is that it is much harder to know whether or not you pushed all the changes: one would have to loop over all 10,000+ branches and perform a push or check. In this loop you would probably have to check out the branch as well. It is of course better to just push right after you make a change, but my point is that the \u2018just for sure\u2019 push is a lot of work.\nAnother drawback is actually the counter to what I initially was seeking: wiki-style pages might actually reference each other, and thus their version may depend on a version of another page. In this case, you would want the history to capture all the pages, just as the normal Git workings do. My problem was with the date-specific posts, but once you are mixing date-specific and wiki-style pages, you might be better off with the all-file history.\nOne problem this whole setup still does not solve is that of large files. The git status command is much faster for it does not have to check all the blobs in the repo to get an answer, but the files are still in the repo, taking up space. And there do exist other solutions for big files in git, such as Git LFS, the Large File Storage extension.\nAlso, I am still not 100% sure it is a good idea to store metadata in the Git commits and tags. When we already store the identifier in the tree objects, I thought I could also add the \u2018published at\u2019 date into the commit. Information about the author is already present, and as my site supports private posts, it also seemed like a reasonable location to store lists of people who can view the post. But again, maybe that should be stored in another way, and not be so deeply integrated with Git.\nConclusion\nIt was very helpful to write this all out, for by doing so I made up my mind: this is just all a bit too complicated and way too much deeply coupled to Git internals. I would be throwing out the \u2018just plain text files\u2019 principle, because I would store a lot of data in Git\u2019s objects, which are actually not plain text, since they are compressed with a certain algorithm.\nMy favourite Git GUI Fork is able to work with the monstrous repository my script produced, but many of the features are now strange and unusable, because the repo is so strangely set up. I would have to create my own software to maintain the integrity of the repo and that could lead to bugs and thus faulty data and maybe even data loss.\nI still think there are some nice properties to the system I describe above, but I won\u2019t be using it. But I learned a few new things about Git internals along the way, and I hope you did too.",
        "html": "<p>I have been wanting to rework the core of this website for a couple of years now, but since the current setup still works, and since I have many other things to do, and finally since I am very picky about how I <em>want</em> it to work, I have never really finished this part at all. This makes me stuck at the save version of this site, both visually as behind the scenes.</p>\n<p>Now that I am in between jobs I wanted to work on it a bit more, but I still do not have time enough to fully finish it. I guess it all comes down to a few choices I have to make regarding trade-offs. In order to make better decisions, I wanted document my current storage and the one I have been working on. After I wrote it all out I think I am deciding not to use it, but it was a nice exploration so I will share it anyway.</p>\n<p>The description heavily leans on some knowledge about Git, which is software for versioning your code, or in this case, plain text files. I will try to explain a bit along the way but it is useful to have some familiarity with it already.</p>\n<p><em>tl;dr: I did fancy with Git but might not pursue.</em></p>\n<h2>How it is currently done</h2>\n<p>At the time of writing, my posts are stored in a plain text format with a lot of folders. It is derived from the format which the <a href=\"https://getkirby.com\">Kirby CMS</a> expects: folders for pages with text files within it, of which the name of the text file dictates the template that is being used to render the page. In my case, it is always <code>entry.txt</code>.</p>\n<p>I have one folder per year, one folder per day of the year and one folder per post of the day. In that last folder is the <code>entry.txt</code> and some other files related to the post, like pictures, but also metadata like received and sent <a href=\"https://indieweb.org/Webmention\">Webmentions</a>.</p>\n<p>An example of the <code>tree</code> view is below. It shows two entries on two days in one year. Note that days and years also have their own <code>.txt</code> file that is actually almost empty and pretty much useless in this setup, but still required for Kirby to work properly. The first day of the year my site is broken because it does not automatically create the required <code>year.txt</code> (or did I fix that finally?).</p>\n<pre><code>./content\n\u2514\u2500\u2500 2022\n\u00a0\u00a0\u00a0 \u251c\u2500\u2500 001\n\u00a0\u00a0\u00a0 \u2502\u00a0\u00a0 \u251c\u2500\u2500 1\n\u00a0\u00a0\u00a0 \u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u2514\u2500\u2500 entry.txt\n\u00a0\u00a0\u00a0 \u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u251c\u2500\u2500 .webmentions\n\u00a0\u00a0\u00a0 \u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u251c\u2500\u2500 1641117941-f6bc3209f3f33f0cb8e4d92e5d46b5090b53aa11.json\n\u00a0\u00a0\u00a0 \u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u2514\u2500\u2500 pings.json\n\u00a0\u00a0\u00a0 \u2502\u00a0\u00a0 \u2514\u2500\u2500 day.txt\n\u00a0\u00a0\u00a0 \u251c\u2500\u2500 002\n\u00a0\u00a0\u00a0 \u2502\u00a0\u00a0 \u251c\u2500\u2500 1\n\u00a0\u00a0\u00a0 \u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u251c\u2500\u2500 some_image.jpg\n\u00a0\u00a0\u00a0 \u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u2514\u2500\u2500 entry.txt\n\u00a0\u00a0\u00a0 \u2502\u00a0\u00a0 \u2514\u2500\u2500 day.txt\n\u00a0\u00a0\u00a0 \u2514\u2500\u2500 year.txt</code></pre>\n<p>Also note that there is a hidden <code>.webmentions</code> folder which contains a <code>pings.json</code> for all the sent webmentions and a JSON file with timestamp and content hash in the name for every received webmention. Not in the diagram but also present are some other folders for pages like <code>./login/login.txt</code> (because that is how Kirby works) and <code>./isbn/9780349411903/book.txt</code> (for <a href=\"https://seblog.nl/isbn/9780349411903\">books</a>).</p>\n<p>All these files are stored in a Git repository, which I <em>manually</em> update every so often (more bimonthly than weekly, sadly) via SSH to my server. I give it a very generic commit name (\u2019sync\u2019 or so) and push to a private repo on Github, which takes a while because the commits and the repo contain all those images and all those folders.</p>\n<h2>What is wrong with this</h2>\n<p>The main point of wanting to move off of this structure by Kirby, is that it requires those placeholder pages in my content folder. I have no need for a <code>./login/login.txt</code>: the login page is just a feature of the software and should be handled by that part of the code. But at least that file contains some text for that page: the files for <code>year.txt</code> and <code>day.txt</code> are completely useless.</p>\n<p>Another point is that I want to make the Git commits automatically with every <a href=\"https://indieweb.org/Micropub\">Micropub</a> request: Git provides me with a history, but only if I actually commit the files once I changed them. Also, if I do not push the changes to Github, I have no backup of recent posts.</p>\n<p>The metadata of the received and sent Webmentions are now also available in the repo. This is nice, as it stores the information right next to the post it belongs to, but on the other hand it feels kind of polluting: these Webmentions contain content by <em>others</em>, where as the rest of the content is by me. There is some other external content hidden in the <code>entry.txt</code> file but I\u2019ll get to that later.</p>\n<p>The last point is that the full size images are stored in the repo and every book and article about Git says that you should not use it to store big files in it. Doing a <code>git status</code> takes a while and also the pushes are much slower than any other Git repository I work with.</p>\n<h2>Git history: the Git Object Model</h2>\n<p>Before I go further into the avenue I am taking to solve the problem, I need to explain a bit about the Git Object Model, also known as \u2018how Git works under the hood\u2019. For a more thorough explanation, see <a href=\"https://git-scm.com/book/en/v2/Git-Internals-Git-Objects\">this chapter</a> in the Git Book.</p>\n<p>As you\u2019ll learn from that chapter, every object is represented as a file, referenced by the SHA1 hash of its contents. And there are three (no, four) types of objects:</p>\n<ul><li>\n<strong>blobs</strong>, which are the contents of files tracked by Git (and thus also the versions of those files)</li>\n<li>\n<strong>trees</strong>, which are listings of filenames with references to blobs or other trees. These trees together create the file structure of a version.</li>\n<li>\n<strong>commits</strong>, which are versions. A commit contains a reference to the root tree of the files you are tracking, a parent commit (the previous version) and a message and some metadata.</li>\n<li>\n<strong>tags</strong>, are not mentioned by the chapter, but do exists: these look like commits, but create a way to store a message with a tag (making annotated tags, I\u2019ll explain plain tags soon).</li>\n</ul><p>Note that Git does not store diffs, it always stores the full contents of every version of the file, albeit zlib compressed and sometimes even packed in a single file, but let\u2019s not get into that right now.</p>\n<p>Git\u2019s tags and branches are just files and folders (they can have <code>/</code> in their names) which contain the hashes (names) of the specific commits they point to. The tags can also point to a tag object, which will then contain a message about the tag (which makes them \u2018annotated tags\u2019).</p>\n<p>This all brings me to the final point about my storage: for every new post, Git has to create a lot of files. First, it needs to add a blob for the <code>entry.txt</code>, possibly also a blob for the image and blobs for other metadata. Then it needs to create a tree for the entry folder, listing <code>entry.txt</code> and if present the filenames of the images and metadata files. Then it creates a new tree for the day, with all the existing entries plus the newly created one. Then it creates a new tree for the year, to point to this new version (tree) of the day. Then it creates a new tree for the root, with this new version of the year in it. And finally it also needs to create a commit object to point to that new root tree. Every update requires all these new trees. The trees are cheap, but it feels wasteful.</p>\n<p>Also note that a version of a file always relies on the version of all other files. This is what you want for code (code is designed to work with other code), but it does not feel like the right model for posts (I might come back on this tho).</p>\n<p>And there is also the question of identifiers: currently, my posts are identified as year, day of year, number (<code>2022/242/1</code>), but especially that number can only be found in the name of the folder and thus in the tree, not in the blob. I have not yet found a good solution for this, but maybe I am seeing too many problems.</p>\n<h2>The new setup</h2>\n<p>To get rid of some of the trees, I tried to apply my knowledge of the Git Object Model to store my posts in another way. To do this, I used the commands suggested by the chapter in the Git Book in a script that looped over all my files, to store them in a new blank repo to try things out.</p>\n<p>For each year, for each day, for each post, I would find the <code>entry.txt</code> and put the contents in a Git blob with <code>git hash-object -w ./content/2022/242/1/entry.txt</code>. The resulting hash I used in the command <code>git update-index --add --cacheinfo 100644 $hash entry.txt</code> to stage the file for a new tree. I would do that too for all images and related files, and then I would run <code>git write-tree</code> to write the tree and get the hash for it and <code>git commit-tree $hash -m \"commit\"</code> to create a commit based on it (with a bad message indeed). With that last hash I would run <code>git update-ref refs/heads/2022/242/1 $hash</code> to create a branch for that commit. (I contemplate adding an annotated tag in between, for storing some metadata like \u2018published at\u2019 date.)</p>\n<p>This would result in a Git repository with over 10,000 branches (I have many posts) neatly organised in folders per year and day. When one were to check out one of these branches, just the files of that posts will appear in the root of your repo: there are no folders. When you check out another branch, other files will appear. This is not how Git usually works, but it decouples all posts from one-another.</p>\n<h2>Multiple types of pages</h2>\n<p>The posts I describe above all follow the year-day-number pattern because they are posts: they are sequential entries tied to a date. There are other objects I track, though, that are not date-specific. One example is topical wiki-style pages: these pages may receive edits over time, but their topic is not tied to a date. (I don\u2019t have these yet.)</p>\n<p>Another example is the books that I track to base my \u2018read\u2019 posts off. I haven\u2019t posted them in a while, but I would like to expand this book collection to also include other types of objects to reference, such as movies, games or locations. These objects also have no date to them attached, at least not a date meaningful to my posts.</p>\n<p>I could generate UUIDs for these objects and pages, and store branches for those commits in the same way Git does store it\u2019s objects internally, with a folder per first two characters of the hash (or UUID) and a filename of the rest:</p>\n<pre><code>./refs/heads\n\u251c\u2500\u2500 0a\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 8342d2-d6f1-4363-a287-a32948d04eaa\n\u2502\u00a0\u00a0 \u2514\u2500\u2500 edcb13-433c-48d2-b683-a407c3a88f57\n\u2514\u2500\u2500 3d\n\u00a0\u00a0\u00a0 \u251c\u2500\u2500 243a27-114e-4eee-9bd8-2a51b01939e6\n\u00a0\u00a0\u00a0 \u251c\u2500\u2500 25965b-2da5-422d-abce-f3337fa97fc4\n\u00a0\u00a0\u00a0 \u2514\u2500\u2500 611b59-499a-48a0-b931-afe06192e778</code></pre>\n<p>I could even reference the same post/object with multiple identifiers this way. Maybe I want to give every book a UUID, but also reference it by its ISBN. The downside to that, however, is that I need to update both branches to point to the same commit once I make an update do the book-page.</p>\n<h2>Drawbacks of the approach</h2>\n<p>The multiple identifiers are probably not feasible, but there are some other drawbacks too. My main concern is that it is much harder to know whether or not you pushed all the changes: one would have to loop over all 10,000+ branches and perform a push or check. In this loop you would probably have to check out the branch as well. It is of course better to just push right after you make a change, but my point is that the \u2018just for sure\u2019 push is a lot of work.</p>\n<p>Another drawback is actually the counter to what I initially was seeking: wiki-style pages might actually reference each other, and thus their version may depend on a version of another page. In this case, you would want the history to capture all the pages, just as the normal Git workings do. My problem was with the date-specific posts, but once you are mixing date-specific and wiki-style pages, you might be better off with the all-file history.</p>\n<p>One problem this whole setup still does not solve is that of large files. The <code>git status</code> command is much faster for it does not have to check all the blobs in the repo to get an answer, but the files are still in the repo, taking up space. And there do exist other solutions for big files in git, such as <a href=\"https://git-lfs.github.com/\">Git LFS</a>, the Large File Storage extension.</p>\n<p>Also, I am still not 100% sure it is a good idea to store metadata in the Git commits and tags. When we already store the identifier in the tree objects, I thought I could also add the \u2018published at\u2019 date into the commit. Information about the author is already present, and as my site supports private posts, it also seemed like a reasonable location to store lists of people who can view the post. But again, maybe that should be stored in another way, and not be so deeply integrated with Git.</p>\n<h2>Conclusion</h2>\n<p>It was very helpful to write this all out, for by doing so I made up my mind: this is just all a bit too complicated and way too much deeply coupled to Git internals. I would be throwing out the \u2018just plain text files\u2019 principle, because I would store a lot of data in Git\u2019s objects, which are actually not plain text, since they are compressed with a certain algorithm.</p>\n<p>My favourite Git GUI <a href=\"https://git-fork.com/\">Fork</a> is able to work with the monstrous repository my script produced, but many of the features are now strange and unusable, because the repo is so strangely set up. I would have to create my own software to maintain the integrity of the repo and that could lead to bugs and thus faulty data and maybe even data loss.</p>\n<p>I still think there are some nice properties to the system I describe above, but I won\u2019t be using it. But I learned a few new things about Git internals along the way, and I hope you did too.</p>"
    },
    "author": {
        "type": "card",
        "name": "Sebastiaan Andeweg",
        "url": "https://seblog.nl/",
        "photo": "https://seblog.nl/photo.jpg"
    },
    "post-type": "article",
    "_id": "31122609",
    "_source": "1366",
    "_is_read": true
}

html.energy

Jeremy Keith adactio.com

html energy

Can you feel the energy?

#html #energy #markup #creativity #writing #sharing #indieweb #frontend #development #complexity #simplicity

August 30, 2022 7:52am +00:00

{
    "type": "entry",
    "published": "2022-08-30T07:52:54Z",
    "url": "https://adactio.com/links/19401",
    "category": [
        "html",
        "energy",
        "markup",
        "creativity",
        "writing",
        "sharing",
        "indieweb",
        "frontend",
        "development",
        "complexity",
        "simplicity"
    ],
    "bookmark-of": [
        "https://html.energy/"
    ],
    "content": {
        "text": "html energy\n\n\n\nCan you feel the energy?",
        "html": "<h3>\n<a class=\"p-name u-bookmark-of\" href=\"https://html.energy/\">\nhtml energy\n</a>\n</h3>\n\n<p>Can you feel the energy?</p>"
    },
    "author": {
        "type": "card",
        "name": "Jeremy Keith",
        "url": "https://adactio.com/",
        "photo": "https://adactio.com/images/photo-150.jpg"
    },
    "post-type": "bookmark",
    "_id": "31110137",
    "_source": "2",
    "_is_read": true
}

Ben Werdmüller werd.io/profile/benwerd

Farewell, house

August 23, 2022 3:31am +00:00

{
    "type": "entry",
    "published": "2022-08-23T03:31:07+00:00",
    "url": "https://werd.io/2022/farewell-house",
    "name": "Farewell, house",
    "content": {
        "text": "Well, we sold the house. A new family gets to enjoy the space, and the incredible surrounds. It\u2019s the start of a new chapter for us, too.I was there over the weekend, and the memories were overwhelming: the four walls of my parents\u2019 former bedroom held newly-staged furniture for show, but I could hear the laughter, remember talking to my mother at the end of the day, could hear her feeding tube apparatus rolling across the floor. So much happened there. It\u2019s sad to see it go, but the memories stay with us. All we\u2019re really leaving behind is wood, stone, and plaster.Throughout the sale, our agent Florence Sheffer was wonderful. She held our hands through the whole process, and was as fun to work with as she was knowledgable and connected. She consistently went above and beyond to help us. I\u2019d recommend her to anyone who wants to buy or sell a home in Santa Rosa and the surrounding area.I\u2019m not sure what I\u2019ll end up doing with the indieweb website that I made for the house. Probably I\u2019ll just let the domain expire. Here it is, archived for posterity on the Internet Archive.",
        "html": "<p><img src=\"https://werd.io/file/630449e5482c4b7bd97e0532/thumb.jpg\" alt=\"\" width=\"1024\" height=\"683\" /></p><p>Well, we sold <a href=\"https://werd.io/2022/my-indieweb-real-estate-website-part-two\">the house</a>. A new family gets to enjoy the space, and the <a href=\"https://5405spainave.com/our-experiences.html\">incredible surrounds</a>. It\u2019s the start of a new chapter for us, too.</p><p>I was there over the weekend, and the memories were overwhelming: the four walls of my parents\u2019 former bedroom held newly-staged furniture for show, but I could hear the laughter, remember talking to my mother at the end of the day, could hear her feeding tube apparatus rolling across the floor. So much happened there. It\u2019s sad to see it go, but the memories stay with us. All we\u2019re really leaving behind is wood, stone, and plaster.</p><p>Throughout the sale, our agent <a href=\"https://www.coldwellbankerhomes.com/ca/santa-rosa/agent/florence-sheffer/aid_37212/\">Florence Sheffer</a> was wonderful. She held our hands through the whole process, and was as fun to work with as she was knowledgable and connected. She consistently went above and beyond to help us. I\u2019d recommend her to anyone who wants to buy or sell a home in Santa Rosa and the surrounding area.</p><p>I\u2019m not sure what I\u2019ll end up doing with <a href=\"https://5405spainave.com\">the indieweb website that I made for the house</a>. Probably I\u2019ll just let the domain expire. <a href=\"https://web.archive.org/web/20220000000000*/5405spainave.com\">Here it is, archived for posterity on the Internet Archive.</a></p>"
    },
    "author": {
        "type": "card",
        "name": "Ben Werdm\u00fcller",
        "url": "https://werd.io/profile/benwerd",
        "photo": "https://werd.io/file/5d388c5fb16ea14aac640912/thumb.jpg"
    },
    "post-type": "article",
    "_id": "30985833",
    "_source": "191",
    "_is_read": true
}

blog.jim-nielsen.com/2022/well-known-links-resource/

Jeremy Keith adactio.com

A Well-Known Links Resource - Jim Nielsen’s Blog

I really like this experiment that Jim is conducting on his own site. I might try to replicate it sometime!

#links #linking #hyperlinks #hypertext #well-known #indieweb #personal #publishing

August 22, 2022 10:08am +00:00

{
    "type": "entry",
    "published": "2022-08-22T10:08:45Z",
    "url": "https://adactio.com/links/19387",
    "category": [
        "links",
        "linking",
        "hyperlinks",
        "hypertext",
        "well-known",
        "indieweb",
        "personal",
        "publishing"
    ],
    "bookmark-of": [
        "https://blog.jim-nielsen.com/2022/well-known-links-resource/"
    ],
    "content": {
        "text": "A Well-Known Links Resource - Jim Nielsen\u2019s Blog\n\n\n\nI really like this experiment that Jim is conducting on his own site. I might try to replicate it sometime!",
        "html": "<h3>\n<a class=\"p-name u-bookmark-of\" href=\"https://blog.jim-nielsen.com/2022/well-known-links-resource/\">\nA Well-Known Links Resource - Jim Nielsen\u2019s Blog\n</a>\n</h3>\n\n<p>I really like this experiment that Jim is conducting on his own site. I might try to replicate it sometime!</p>"
    },
    "author": {
        "type": "card",
        "name": "Jeremy Keith",
        "url": "https://adactio.com/",
        "photo": "https://adactio.com/images/photo-150.jpg"
    },
    "post-type": "bookmark",
    "_id": "30971520",
    "_source": "2",
    "_is_read": true
}

Ben Werdmüller werd.io/profile/benwerd

A home on the web, revisited

August 21, 2022 4:25pm +00:00

{
    "type": "entry",
    "published": "2022-08-21T16:25:37+00:00",
    "url": "https://werd.io/2022/a-home-on-the-web-revisited",
    "name": "A home on the web, revisited",
    "content": {
        "text": "I\u2019ve been thinking a lot about redesigning my website, or even moving platforms. That\u2019s a bit of an emotional decision, because my website runs on Known, a codebase I mostly wrote myself, and started while I was taking care of my mother post-lung-transplant. It\u2019s the reason I\u2019m connected to the indieweb community, and the Matter community, and a lot of people I care deeply about. All those things are separable from this codebase now, but it got me there, and I\u2019m hugely grateful for that.The design is looking a little long in the tooth: I can make tweaks, and would commit them upstream into the open source project for other people to use, but I think there\u2019s something to be said for starting again completely, knowing what I know now.If I had unlimited time and energy - which, sadly isn\u2019t my situation; time and energy are both in very short supply right now - I\u2019d rebuild Known in something like Node, with a cleaner codebase. For now, I think I\u2019ll live with it, and clean what I can.Incidentally, I also cleaned up my public Obsidian site at werd.cloud. I intend to do more with non-linear, unbloggy writing there.",
        "html": "<p>I\u2019ve been thinking a lot about redesigning my website, or even moving platforms. That\u2019s a bit of an emotional decision, because my website runs on <a href=\"https://withknown.com\">Known</a>, a codebase I mostly wrote myself, and started while I was taking care of my mother post-lung-transplant. It\u2019s the reason I\u2019m connected to the indieweb community, and the Matter community, and a lot of people I care deeply about. All those things are separable from this codebase now, but it got me there, and I\u2019m hugely grateful for that.</p><p>The design is looking a little long in the tooth: I can make tweaks, and would commit them upstream into the open source project for other people to use, but I think there\u2019s something to be said for starting again completely, knowing what I know now.</p><p>If I had unlimited time and energy - which, sadly isn\u2019t my situation; time and energy are both in very short supply right now - I\u2019d rebuild Known in something like Node, with a cleaner codebase. For now, I think I\u2019ll live with it, and clean what I can.</p><p>Incidentally, I also cleaned up my public Obsidian site at <a href=\"https://werd.cloud\">werd.cloud</a>. I intend to do more with non-linear, unbloggy writing there.</p>"
    },
    "author": {
        "type": "card",
        "name": "Ben Werdm\u00fcller",
        "url": "https://werd.io/profile/benwerd",
        "photo": "https://werd.io/file/5d388c5fb16ea14aac640912/thumb.jpg"
    },
    "post-type": "article",
    "_id": "30961484",
    "_source": "191",
    "_is_read": true
}

Jeremy Keith adactio.com

No code

#nocode #democratisation #indieweb #blockprotocol #frontend #development #tools #personal #publishing #spring83 #protocols #squarespace #wix #wordpress #bubble #webflow #carrd #hotglue #neocities #creativity #professionalism

August 16, 2022 2:26pm +00:00

{
    "type": "entry",
    "published": "2022-08-16T14:26:24Z",
    "url": "https://adactio.com/journal/19370",
    "category": [
        "nocode",
        "democratisation",
        "indieweb",
        "blockprotocol",
        "frontend",
        "development",
        "tools",
        "personal",
        "publishing",
        "spring83",
        "protocols",
        "squarespace",
        "wix",
        "wordpress",
        "bubble",
        "webflow",
        "carrd",
        "hotglue",
        "neocities",
        "creativity",
        "professionalism"
    ],
    "syndication": [
        "https://adactio.medium.com/b357297437ef"
    ],
    "name": "No code",
    "content": {
        "text": "When I wrote about democratising dev, I made brief mention of the growing \u201cno code\u201d movement:\n\n\n  Personally, I would love it if the process of making websites could be democratised more. I\u2019ve often said that my nightmare scenario for the World Wide Web would be for its fate to lie in the hands of an elite priesthood of programmers with computer science degrees. So I\u2019m all in favour of no-code tools \u2026in theory.\n\n\nBut I didn\u2019t describe what no-code is, as I understand it.\n\nI\u2019m taking the term at face value to mean a mechanism for creating a website\u2014preferably on a domain you control\u2014without having to write anything in HTML, CSS, JavaScript, or any back-end programming language.\n\nBy that definition, something like WordPress.com (as opposed to WordPress itself) is a no-code tool:\n\n\n  Create any kind of website. No code, no manuals, no limits.\n\n\nI\u2019d also put Squarespace in the same category:\n\n\n  Start with a flexible template, then customize to fit your style and professional needs with our website builder.\n\n\nAnd its competitor, Wix:\n\n\n  Discover the platform that gives you the freedom to create, design, manage and develop your web presence exactly the way you want.\n\n\nWebflow provides the same kind of service, but with a heavy emphasis on marketing websites:\n\n\n  Your website should be a marketing asset, not an engineering challenge.\n\n\nBubble is trying to cover a broader base:\n\n\n  Bubble lets you create interactive, multi-user apps for desktop and mobile web browsers, including all the features you need to build a site like Facebook or Airbnb.\n\n\nWheras Carrd opts for a minimalist one-page approach:\n\n\n  Simple, free, fully responsive one-page sites for pretty much anything.\n\n\nAll of those tools emphasise that don\u2019t need to need to know how to code in order to have a professional-looking website. But there\u2019s a parallel universe of more niche no-code tools where the emphasis is on creativity and self-expression instead of slickness and profressionalism.\n\nneocities.org:\n\n\n  Create your own free website. Unlimited creativity, zero ads.\n\n\nmmm.page:\n\n\n  Make a website in 5 minutes. Messy encouraged.\n\n\nhotglue.me:\n\n\n  unique tool for web publishing & internet samizdat\n\n\nI\u2019m kind of fascinated by these two different approaches: professional vs. expressionist.\n\nI\u2019ve seen people grapple with this question when they decide to have their own website. Should it be a showcase of your achievements, almost like a portfolio? Or should it be a glorious mess of imagery and poetry to reflect your creativity? Could it be both? (Is that even doable? Or desirable?)\n\nRobin Sloan recently published his ideas\u2014and specs\u2014for a new internet protocol called Spring \u201983:\n\n\n  Spring \u201883 is a protocol for the transmission and display of something I am calling a \u201cboard\u201d, which is an HTML fragment, limited to 2217 bytes, unable to execute JavaScript or load external resources, but otherwise unrestricted. Boards invite publishers to use all the richness of modern HTML and CSS. Plain text and blue links are also enthusiastically supported.\n\n\nIt\u2019s not a no-code tool (you need to publish in HTML), although someone could easily provide a no-code tool to sit on top of the protocol. Conceptually though, it feels like it\u2019s an a similar space to the chaotic good of neocities.org, mmm.page, and hotglue.me with maybe a bit of tilde.town thrown in.\n\nIt feels like something might be in the air. With Spring \u201983, the Block protocol, and other experiments, people are creating some interesting small pieces that could potentially be loosely joined. No code required.",
        "html": "<p>When I wrote about <a href=\"https://adactio.com/journal/19356\">democratising dev</a>, I made brief mention of the growing \u201cno code\u201d movement:</p>\n\n<blockquote>\n  <p>Personally, I would love it if the process of making websites could be democratised more. I\u2019ve often said that my nightmare scenario for the World Wide Web would be for its fate to lie in the hands of an elite priesthood of programmers with computer science degrees. So I\u2019m all in favour of no-code tools \u2026in theory.</p>\n</blockquote>\n\n<p>But I didn\u2019t describe what no-code is, as I understand it.</p>\n\n<p>I\u2019m taking the term at face value to mean a mechanism for creating a website\u2014preferably on a domain you control\u2014without having to write anything in HTML, CSS, JavaScript, or any back-end programming language.</p>\n\n<p>By that definition, something like <a href=\"https://wordpress.com/\">WordPress.com</a> (as opposed to WordPress itself) is a no-code tool:</p>\n\n<blockquote>\n  <p>Create any kind of website. No code, no manuals, no limits.</p>\n</blockquote>\n\n<p>I\u2019d also put <a href=\"https://www.squarespace.com/\">Squarespace</a> in the same category:</p>\n\n<blockquote>\n  <p>Start with a flexible template, then customize to fit your style and professional needs with our website builder.</p>\n</blockquote>\n\n<p>And its competitor, <a href=\"https://www.wix.com/\">Wix</a>:</p>\n\n<blockquote>\n  <p>Discover the platform that gives you the freedom to create, design, manage and develop your web presence exactly the way you want.</p>\n</blockquote>\n\n<p><a href=\"https://webflow.com/\">Webflow</a> provides the same kind of service, but with a heavy emphasis on marketing websites:</p>\n\n<blockquote>\n  <p>Your website should be a marketing asset, not an engineering challenge.</p>\n</blockquote>\n\n<p><a href=\"https://bubble.io/\">Bubble</a> is trying to cover a broader base:</p>\n\n<blockquote>\n  <p>Bubble lets you create interactive, multi-user apps for desktop and mobile web browsers, including all the features you need to build a site like Facebook or Airbnb.</p>\n</blockquote>\n\n<p>Wheras <a href=\"https://carrd.co/\">Carrd</a> opts for a minimalist one-page approach:</p>\n\n<blockquote>\n  <p>Simple, free, fully responsive one-page sites for pretty much anything.</p>\n</blockquote>\n\n<p>All of those tools emphasise that don\u2019t need to need to know how to code in order to have a professional-looking website. But there\u2019s a parallel universe of more niche no-code tools where the emphasis is on creativity and self-expression instead of slickness and profressionalism.</p>\n\n<p><a href=\"https://neocities.org/\">neocities.org</a>:</p>\n\n<blockquote>\n  <p>Create your own free website. Unlimited creativity, zero ads.</p>\n</blockquote>\n\n<p><a href=\"https://mmm.page/\">mmm.page</a>:</p>\n\n<blockquote>\n  <p>Make a website in 5 minutes. Messy encouraged.</p>\n</blockquote>\n\n<p><a href=\"https://hotglue.me/\">hotglue.me</a>:</p>\n\n<blockquote>\n  <p>unique tool for web publishing &amp; internet samizdat</p>\n</blockquote>\n\n<p>I\u2019m kind of fascinated by these two different approaches: professional vs. expressionist.</p>\n\n<p>I\u2019ve seen people grapple with this question when they decide to have their own website. Should it be a showcase of your achievements, almost like a portfolio? Or should it be a glorious mess of imagery and poetry to reflect your creativity? Could it be both? (Is that even doable? Or desirable?)</p>\n\n<p>Robin Sloan recently published his ideas\u2014and specs\u2014for a new internet protocol called <a href=\"https://www.robinsloan.com/lab/specifying-spring-83/\">Spring \u201983</a>:</p>\n\n<blockquote>\n  <p>Spring \u201883 is a protocol for the transmission and display of something I am calling a \u201cboard\u201d, which is an HTML fragment, limited to 2217 bytes, unable to execute JavaScript or load external resources, but otherwise unrestricted. Boards invite publishers to use all the richness of modern HTML and CSS. Plain text and blue links are also enthusiastically supported.</p>\n</blockquote>\n\n<p>It\u2019s not a no-code tool (you need to publish in HTML), although someone could easily provide a no-code tool to sit on top of the protocol. Conceptually though, it feels like it\u2019s an a similar space to the chaotic good of <a href=\"https://neocities.org/\">neocities.org</a>, <a href=\"https://mmm.page/\">mmm.page</a>, and <a href=\"https://hotglue.me/\">hotglue.me</a> with maybe a bit of <a href=\"https://tilde.town/\">tilde.town</a> thrown in.</p>\n\n<p>It feels like something might be in the air. With <a href=\"https://www.robinsloan.com/lab/specifying-spring-83/\">Spring \u201983</a>, <a href=\"https://blockprotocol.org/\">the Block protocol</a>, and other experiments, people are creating some interesting small pieces that could potentially be <a href=\"https://www.smallpieces.com/\">loosely joined</a>. No code required.</p>"
    },
    "author": {
        "type": "card",
        "name": "Jeremy Keith",
        "url": "https://adactio.com/",
        "photo": "https://adactio.com/images/photo-150.jpg"
    },
    "post-type": "note",
    "_id": "30874653",
    "_source": "2",
    "_is_read": true
}