Jeremy Keith adactio.com

Democratising dev

{
    "type": "entry",
    "published": "2022-08-10T16:11:54Z",
    "url": "https://adactio.com/journal/19356",
    "category": [
        "democratisation",
        "frontend",
        "development",
        "indieweb",
        "hosting",
        "blockprotocol",
        "patterns",
        "nocode",
        "publishing",
        "talks",
        "presentations"
    ],
    "syndication": [
        "https://adactio.medium.com/db9ceab2156e"
    ],
    "name": "Democratising dev",
    "content": {
        "text": "I met up with a supersmart programmer friend of mine a little while back. He was describing some work he was doing with React. He was joining up React components. There wasn\u2019t really any problem-solving or debugging\u2014the individual components had already been thoroughly tested. He said it felt more like construction than programming.\n\nMy immediate thought was \u201cthat should be automated.\u201d\n\nOr at the very least, there should be some way for just about anyone to join those pieces together rather than it requiring a supersmart programmer\u2019s time. After all, isn\u2019t that the promise of design systems and components\u2014freeing us up to tackle the meaty problems instead of spending time on the plumbing?\n\nI thought about that conversation when I was listening to Laurie\u2019s excellent talk in Berlin last month.\n\nChatting to Laurie before the talk, he was very nervous about the conclusion that he had reached and was going to share: that the time is right for web development to be automated. He figured it would be an unpopular message. Heck, even he didn\u2019t like it.\n\nBut I reminded him that it\u2019s as old as the web itself. I\u2019ve seen videos from very early World Wide Web conferences where Tim Berners-Lee was railing against the idea that anyone would write HTML by hand. The whole point of his WorldWideWeb app was that anyone could create and edit web pages as easily as word processing documents. It\u2019s almost an accident of history that HTML happened to be just easy enough\u2014but also just powerful enough\u2014for many people to learn and use.\n\nAnyway, I thoroughly enjoyed Laurie\u2019s talk. (Except for a weird bit where he dunks on people moaning about \u201cthe fundamentals\u201d. I think it\u2019s supposed to be punching up, but I\u2019m not sure that\u2019s how it came across. As Chris points out, fundamentals matter \u2026at least when it comes to concepts like accessibility and performance. I think Laurie was trying to dunk on people moaning about fundamental technologies like languages and frameworks. Perhaps the message got muddled in the delivery.)\n\nI guess Laurie was kind of talking about this whole \u201cno code\u201d thing that\u2019s quite hot right now. 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\nThe problem is that unless they work 100%, and always produce good accessible performant code, then they\u2019re going to be another example of the law of leaky abstractions. If a no-code tool can get someone 90% of the way to what they want, that seems pretty good. But if that person than has to spend an inordinate amount of time on the remaining 10% then all the good work of the no-code tool is somewhat wasted.\n\nFunnily enough, the person who coined that law, Joel Spolsky, spoke right after Laurie in Berlin. The two talks made for a good double bill.\n\n(I would link to Joel\u2019s talk but for some reason the conference is marking the YouTube videos as unlisted. If you manage to track down a URL for the video of Joel\u2019s  talk, let me know and I\u2019ll update this post.)\n\nIn a way, Joel was making the same point as Laurie: why is it still so hard to do something on the web that feels like it should be easily repeatable?\n\nHe used the example of putting an event online. Right now, the most convenient way to do it is to use a third-party centralised silo like Facebook. It works, but now the business model of Facebook comes along for the ride. Your event is now something to be tracked and monetised by advertisers.\n\nYou could try doing it yourself, but this is where you\u2019ll run into the frustrations shared by Joel and Laurie. It\u2019s still too damn hard and complicated (even though we\u2019ve had years and years of putting events online). Despite what web developers tell themselves, making stuff for the web shouldn\u2019t be that complicated. As Trys put it:\n\n\n  We kid ourselves into thinking we\u2019re building groundbreakingly complex systems that require bleeding-edge tools, but in reality, much of what we build is a way to render two things: a list, and a single item. Here are some users, here is a user. Here are your contacts, here are your messages with that contact. There ain\u2019t much more to it than that.\n\n\nAnd yet here we are. You can either have the convenience of putting something on a silo like Facebook, or you can have the freedom of doing it yourself, indie web style. But you can\u2019t have both it seems.\n\nThis is a criticism often levelled at the indie web. The barrier to entry to having your own website is too high. It\u2019s a valid criticism. To have your own website, you need to have some working knowledge of web hosting and at least some web technologies (like HTML).\n\nDon\u2019t get me wrong. I love having my own website. Like, I really love it. But I\u2019m also well aware that it doesn\u2019t scale. It\u2019s unreasonable to expect someone to learn new skills just to make a web page about, say, an event they want to publicise.\n\nThat\u2019s kind of the backstory to the project that Joel wanted to talk about: the block protocol. (Note: it has absolutely nothing to do with blockchain\u2014it\u2019s just an unfortunate naming collision.)\n\nThe idea behind the project is to create a kind of crowdsourced pattern library\u2014user interfaces for creating common structures like events, photos, tables, and lists. These patterns already exist in today\u2019s silos and content management systems, but everyone is reinventing the wheel independently. The goal of this project is make these patterns interoperable, and therefore portable.\n\nAt first I thought that would be a classic /927 situation, but I\u2019m pleased to see that the focus of the project is not on formats (we\u2019ve been there and done that with microformats, RDF, schema.org, yada yada). The patterns might end up being web components or they might not. But the focus is on the interface. I think that\u2019s a good approach.\n\nThat approach chimes nicely with one of the principles of the indie web:\n\n\n  UX and design is more important than protocols, formats, data models, schema etc. We focus on UX first, and then as we figure that out we build/develop/subset the absolutely simplest, easiest, and most minimal protocols and formats sufficient to support that UX, and nothing more. AKA UX before plumbing.\n\n\nThat said, I don\u2019t think this project is a cure-all. Interoperable (portable) chunks of structured content would be great, but that\u2019s just one part of the challenge of scaling the indie web. You also need to have somewhere to put those blocks.\n\nConvenience isn\u2019t the only thing you get from using a silo like Facebook, Twitter, Instagram, or Medium. You also get \u201cfree\u201d hosting \u2026until you don\u2019t (see GeoCities, MySpace, and many, many more).\n\nWouldn\u2019t it be great if everyone had a place on the web that they could truly call their own? Today you need to have an uneccesary degree of technical understanding to publish something at a URL you control.\n\nI\u2019d love to see that challenge getting tackled.",
        "html": "<p>I met up with a supersmart programmer friend of mine a little while back. He was describing some work he was doing with React. He was joining up React components. There wasn\u2019t really any problem-solving or debugging\u2014the individual components had already been thoroughly tested. He said it felt more like construction than programming.</p>\n\n<p>My immediate thought was \u201cthat should be automated.\u201d</p>\n\n<p>Or at the very least, there should be some way for just about anyone to join those pieces together rather than it requiring a supersmart programmer\u2019s time. After all, isn\u2019t that the promise of design systems and components\u2014freeing us up to tackle the meaty problems instead of spending time on the plumbing?</p>\n\n<p>I thought about that conversation when I was listening to <a href=\"https://www.youtube.com/watch?v=hWjT_OOBdOc\">Laurie\u2019s excellent talk in Berlin last month</a>.</p>\n\n<p>Chatting to Laurie before the talk, he was very nervous about the conclusion that he had reached and was going to share: that the time is right for web development to be automated. He figured it would be an unpopular message. Heck, even <em>he</em> didn\u2019t like it.</p>\n\n<p>But I reminded him that it\u2019s as old as the web itself. I\u2019ve seen videos from very early World Wide Web conferences where Tim Berners-Lee was railing against the idea that anyone would write HTML by hand. The whole point of <a href=\"https://worldwideweb30.com/\">his WorldWideWeb app</a> was that anyone could create and edit web pages as easily as word processing documents. It\u2019s almost an accident of history that HTML happened to be just easy enough\u2014but also just powerful enough\u2014for many people to learn and use.</p>\n\n<p>Anyway, I thoroughly enjoyed Laurie\u2019s talk. (Except for a weird bit where he dunks on people moaning about \u201cthe fundamentals\u201d. I think it\u2019s supposed to be punching up, but I\u2019m not sure that\u2019s how it came across. As Chris points out, <a href=\"https://gomakethings.com/fundamentals-matter/\">fundamentals matter</a> \u2026at least when it comes to <em>concepts</em> like accessibility and performance. I think Laurie was trying to dunk on people moaning about fundamental <em>technologies</em> like languages and frameworks. Perhaps the message got muddled in the delivery.)</p>\n\n<p>I guess Laurie was kind of talking about this whole \u201cno code\u201d thing that\u2019s quite hot right now. 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\n<p>The problem is that unless they work 100%, and always produce good accessible performant code, then they\u2019re going to be another example of <a href=\"https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/\">the law of leaky abstractions</a>. If a no-code tool can get someone 90% of the way to what they want, that seems pretty good. But if that person than has to spend an inordinate amount of time on the remaining 10% then all the good work of the no-code tool is somewhat wasted.</p>\n\n<p>Funnily enough, the person who coined that law, Joel Spolsky, spoke right after Laurie in Berlin. The two talks made for a good double bill.</p>\n\n<p>(I would link to Joel\u2019s talk but for some reason the conference is marking the YouTube videos as unlisted. If you manage to track down a URL for the video of Joel\u2019s  talk, let me know and I\u2019ll update this post.)</p>\n\n<p>In a way, Joel was making the same point as Laurie: why is it still so hard to do something on the web that feels like it should be easily repeatable?</p>\n\n<p>He used the example of putting an event online. Right now, the most convenient way to do it is to use a third-party centralised silo like Facebook. It works, but now the business model of Facebook comes along for the ride. Your event is now something to be tracked and monetised by advertisers.</p>\n\n<p>You could try doing it yourself, but this is where you\u2019ll run into the frustrations shared by Joel and Laurie. It\u2019s still too damn hard and complicated (even though we\u2019ve had years and years of putting events online). Despite what web developers tell themselves, making stuff for the web shouldn\u2019t be that complicated. <a href=\"https://www.trysmudford.com/blog/city-life/\">As Trys put it</a>:</p>\n\n<blockquote>\n  <p>We kid ourselves into thinking we\u2019re building groundbreakingly complex systems that require bleeding-edge tools, but in reality, much of what we build is a way to render two things: a list, and a single item. Here are some users, here is a user. Here are your contacts, here are your messages with that contact. There ain\u2019t much more to it than that.</p>\n</blockquote>\n\n<p>And yet here we are. You can either have the convenience of putting something on a silo like Facebook, or you can have the freedom of doing it yourself, <a href=\"https://indieweb.org/\">indie web</a> style. But you can\u2019t have both it seems.</p>\n\n<p>This is a criticism often levelled at <a href=\"https://indieweb.org/\">the indie web</a>. The barrier to entry to having your own website is too high. It\u2019s a valid criticism. To have your own website, you need to have some working knowledge of web hosting and at least some web technologies (like HTML).</p>\n\n<p>Don\u2019t get me wrong. I love having my own website. Like, I <em>really</em> love it. But I\u2019m also well aware that it doesn\u2019t scale. It\u2019s unreasonable to expect someone to learn new skills just to make a web page about, say, an event they want to publicise.</p>\n\n<p>That\u2019s kind of the backstory to the project that Joel wanted to talk about: <a href=\"https://blockprotocol.org/\">the block protocol</a>. (Note: it has absolutely nothing to do with block<em>chain</em>\u2014it\u2019s just an unfortunate naming collision.)</p>\n\n<p>The idea behind the project is to create a kind of crowdsourced pattern library\u2014user interfaces for creating common structures like events, photos, tables, and lists. These patterns already exist in today\u2019s silos and content management systems, but everyone is reinventing the wheel independently. The goal of this project is make these patterns interoperable, and therefore portable.</p>\n\n<p>At first I thought that would be <a href=\"https://xkcd.com/927/\">a classic <code>/927</code> situation</a>, but I\u2019m pleased to see that the focus of the project is <em>not</em> on formats (we\u2019ve been there and done that with microformats, RDF, schema.org, yada yada). The patterns might end up being web components or they might not. But the focus is on the <em>interface</em>. I think that\u2019s a good approach.</p>\n\n<p>That approach chimes nicely with one of <a href=\"https://indieweb.org/principles\">the principles of the indie web</a>:</p>\n\n<blockquote>\n  <p>UX and design is more important than protocols, formats, data models, schema etc. We focus on UX first, and then as we figure that out we build/develop/subset the absolutely simplest, easiest, and most minimal protocols and formats sufficient to support that UX, and nothing more. AKA UX before plumbing.</p>\n</blockquote>\n\n<p>That said, I don\u2019t think this project is a cure-all. Interoperable (portable) chunks of structured content would be great, but that\u2019s just one part of the challenge of scaling the indie web. You also need to have somewhere to put those blocks.</p>\n\n<p>Convenience isn\u2019t the only thing you get from using a silo like Facebook, Twitter, Instagram, or Medium. You also get \u201cfree\u201d hosting \u2026until you don\u2019t (see GeoCities, MySpace, and <a href=\"https://indieweb.org/site-deaths\">many, many more</a>).</p>\n\n<p>Wouldn\u2019t it be great if everyone had a place on the web that they could truly call their own? Today you need to have an uneccesary degree of technical understanding to publish something at a URL you control.</p>\n\n<p>I\u2019d love to see that challenge getting tackled.</p>"
    },
    "author": {
        "type": "card",
        "name": "Jeremy Keith",
        "url": "https://adactio.com/",
        "photo": "https://adactio.com/images/photo-150.jpg"
    },
    "post-type": "article",
    "_id": "30772785",
    "_source": "2",
    "_is_read": false
}

Ben Werdmüller werd.io/profile/benwerd

Comments are hard

{
    "type": "entry",
    "published": "2022-08-02T20:38:43+00:00",
    "url": "https://werd.io/2022/comments-are-hard",
    "name": "Comments are hard",
    "content": {
        "text": "Building a comments system is really hard. I tried to build one for Known, which powers my website, but found that spammers circumvented it surprisingly easily. You can flag spam using Akismet (which was built for WordPress but works across platforms), but this process tends to require you to pre-screen comments and make them public after the fact. That\u2019s a fair amount of work and a fair amount of unnecessary friction for building community.If you have a blog - you do have a blog, don\u2019t you? - you can post a response to one of my posts and send a webmention. But not everybody has their own website, and the barrier to entry for sending webmentions is pretty high.So I\u2019ve been looking for something else.Fred Wilson gave up on comments and asks people to discuss on Twitter. That works pretty well, but I\u2019m not really into forcing people to use a particular service. That\u2019s also why I\u2019m not particularly into using Disqus embeds, which also unnecessarily track you across sites. Finally, I was using Cactus Comments, which is based on the decentralized Matrix network for a while, but it occasionally seemed to break in ways that were disconcerting for site visitors. (It\u2019s still a very cool project.)I love comments, and I guess that means I\u2019m writing my own system again. To do so means getting into an arms race with spammers, which I\u2019m not very excited about, but I don\u2019t see an alternative that I\u2019m completely happy about.Do you run a blog with comments? How do you deal with these issues? I\u2019d love to learn from you.",
        "html": "<p>Building a comments system is really hard. I tried to build one for <a href=\"https://withknown.com\">Known</a>, which powers my website, but found that spammers circumvented it surprisingly easily. You can flag spam using <a href=\"https://akismet.com/\">Akismet</a> (which was built for WordPress but works across platforms), but this process tends to require you to pre-screen comments and make them public after the fact. That\u2019s a fair amount of work and a fair amount of unnecessary friction for building community.</p><p>If you have a blog - you <em>do</em> have a blog, don\u2019t you? - you can post a response to one of my posts and send a <a href=\"https://indieweb.org/Webmention\">webmention</a>. But not everybody has their own website, and the barrier to entry for sending webmentions <a href=\"https://jamesmead.org/blog/2020-10-13-sending-webmentions-from-a-static-website\">is pretty high</a>.</p><p>So I\u2019ve been looking for something else.</p><p><a href=\"https://avc.com/\">Fred Wilson gave up on comments and asks people to discuss on Twitter</a>. That works pretty well, but I\u2019m not really into forcing people to use a particular service. That\u2019s also why I\u2019m not particularly into using <a href=\"https://disqus.com/\">Disqus</a> embeds, which also <a href=\"https://fatfrogmedia.com/delete-disqus-comments-wordpress/\">unnecessarily track you across sites</a>. Finally, I was using <a href=\"https://cactus.chat/\">Cactus Comments</a>, which is based on the decentralized <a href=\"https://matrix.org/\">Matrix network</a> for a while, but it occasionally seemed to break in ways that were disconcerting for site visitors. (It\u2019s still a very cool project.)</p><p>I love comments, and I guess that means I\u2019m writing my own system again. To do so means getting into an arms race with spammers, which I\u2019m not very excited about, but I don\u2019t see an alternative that I\u2019m completely happy about.</p><p>Do you run a blog with comments? How do you deal with these issues? I\u2019d love to learn from you.</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": "30628125",
    "_source": "191",
    "_is_read": false
}

Jeremy Keith adactio.com

{
    "type": "entry",
    "published": "2022-08-02T15:20:05Z",
    "url": "https://adactio.com/links/19343",
    "category": [
        "indieweb",
        "personal",
        "publishing",
        "writing",
        "sharing",
        "blogging",
        "blogs"
    ],
    "bookmark-of": [
        "https://marcoheine.com/blog/just-hit-publish/"
    ],
    "content": {
        "text": "Just hit publish | Marco Heine - Freelance Web Developer\n\n\n\n\n  I have days were I can write a well researched blog post in a few hours. And I have days were I don\u2019t feel like writing. Or I want to add one more thing but don\u2019t know how to speak my mind. So this is a reminder to myself: just hit publish.",
        "html": "<h3>\n<a class=\"p-name u-bookmark-of\" href=\"https://marcoheine.com/blog/just-hit-publish/\">\nJust hit publish | Marco Heine - Freelance Web Developer\n</a>\n</h3>\n\n<blockquote>\n  <p>I have days were I can write a well researched blog post in a few hours. And I have days were I don\u2019t feel like writing. Or I want to add one more thing but don\u2019t know how to speak my mind. So this is a reminder to myself: <strong>just hit publish</strong>.</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": "30623598",
    "_source": "2",
    "_is_read": false
}

Ben Werdmüller werd.io/profile/benwerd

Building an inclusive, independent, open newsroom

{
    "type": "entry",
    "published": "2022-08-01T18:07:32+00:00",
    "url": "https://werd.io/2022/building-an-inclusive-independent-open-newsroom",
    "name": "Building an inclusive, independent, open newsroom",
    "content": {
        "text": "I didn\u2019t make a big announcement about it, but for the last few months I\u2019ve been working as the CTO at The 19th, a nonprofit newsroom that reports on stories at the intersection of gender, politics, and policy.It was a necessary move for me: I needed stronger work/life balance for my own health, and I also wanted to feel like I was helping in the midst of a very tumultuous social and political climate. It was also a move back into the core ideas my career has been built on.The 19th was launched in January 2020 by veterans of the Texas Tribune and ProPublica who understood the need to report stories from a more diverse perspective than is normally offered by an industry still dominated by white men. I\u2019ve been following it from the beginning as a prominent subscription in my RSS reader, and was deeply impressed by the detailed, empathetic, unsensational reporting.The 19th\u2019s technical platform is largely based on self-hosted WordPress, with some interesting theme modifications that allow for visualizations and in-page interactivity. (Did I immediately add simple microformats support to articles as soon as I arrived? Yes, I did.) Importantly for me, the team cares about the same privacy issues I do: particularly in an environment where abortion-related surveillance is becoming a safety issue, dealing with audience data intentionally is crucial.Openness is core to what The 19th is. Its financial backers are published in full, so you know exactly whose is bankrolling the non-profit. Since the beginning, the newsroom has also made its content available via a Creative Commons license that allows anyone else to republish it for free. Those partners have included the Guardian, USA Today, Teen Vogue, PBS NewsHour, Ms. Magazine, RawStory, and many more. It could be you, too, if you wanted to: you can find the full HTML source to republish on every article page. Because The 19th\u2019s newsroom is more diverse, every republished article furthers its mission of improving representation in the news media overall.It\u2019s an obvious extension to this strategy to make our technology available as well, via a permissive open source license. That\u2019s my ambition: to package up some of our supporting tools and make them available in a way that other newsrooms can take advantage of. If they have the technical capability to collaborate on building them, great; if not, they can still pick up the technology and use them. Open source itself has a giant diversity problem, and if we can apply an equity lens to building our technical community in the same way we build our journalistic ecosystem, perhaps we can be a part of the solution there, too.I\u2019ve long been a member of the indieweb community, which encourages everyone to own and control their own website and domain. Both technically and ideologically, the overlaps with news are obvious: every newsroom must own its relationship with its audience in order to build trust, understand their needs, and above all to build community. Trends on the web have been in the opposite direction for most of the last decade: social media platforms like Facebook seek to intermediate and monetize that relationship, stripping newsrooms of resources and undermining the ability of voters to receive information in the process. Building an independent website for representative news content and community, and then helping others to do the same, is an important mission.Right now it\u2019s a very small team: Abby Blachman and me. I\u2019m looking for a third member of the technology team to help with everything I\u2019ve discussed.And so far, it\u2019s been joyful. Abby is amazing; everyone is. I\u2019ve never been part of an organization - least of all a remote team - that understands the need for a supportive culture so clearly. As an organization, it continues to listen and evolve. The people team - led by Jayo Miko Macasaquit - has put procedures and benefits in place that I haven\u2019t seen in organizations ten times the size. To build representative, empathetic news, you first need to build a representative, empathetic organization, and that\u2019s what\u2019s happening here. I hope they do more to tell their story and share what they\u2019re doing, because it\u2019s genuinely phenomenal.I can\u2019t believe my luck; it\u2019s a real privilege to be on this team. I want to be a good ambassador: although I knew about the journalism, which should always be front and center, I wasn\u2019t as familiar with the organization\u2019s ecosystem and openness chops before I joined. It was the nicest of surprises, and I want to tell you more about it. We don\u2019t have an internal blog right now, so from time to time I\u2019ll discuss what we\u2019ve been working on over here.I\u2019m also working on building some tools of my own to support my management process; the first is all about building a consistent culture of transparent feedback. More on that when I\u2019m ready.In the meantime, if you have any questions, I\u2019d love to answer them. And if you happen to be interested in our technology position, you should definitely apply.",
        "html": "<p><a href=\"https://19thnews.org\"><img src=\"https://werd.io/file/62e8178716d1b4005910d4b2/thumb.png\" alt=\"\" width=\"1024\" height=\"462\" /></a></p><p>I didn\u2019t make a big announcement about it, but for the last few months I\u2019ve been working as the CTO at <a href=\"https://19thnews.org\">The 19th</a>, a nonprofit newsroom that reports on stories at the intersection of gender, politics, and policy.</p><p>It was a necessary move for me: I needed stronger work/life balance for my own health, and I also wanted to feel like I was helping in the midst of a very tumultuous social and political climate. It was also a move back into the core ideas my career has been built on.</p><p><a href=\"https://www.washingtonpost.com/lifestyle/new-media-outlet-covering-the-intersection-of-women-and-politics-launches-as-2020-election-kicks-off/2020/01/25/34c2a2ac-3ee9-11ea-baca-eb7ace0a3455_story.html\">The 19th was launched in January 2020</a> by veterans of the Texas Tribune and ProPublica who understood the need to report stories from a more diverse perspective than is normally offered by an industry <a href=\"https://womensmediacenter.com/news-features/why-white-male-dominance-of-news-media-is-so-persistent\">still dominated by white men</a>. I\u2019ve been following it from the beginning as a prominent subscription in my RSS reader, and was deeply impressed by the detailed, empathetic, unsensational reporting.</p><p>The 19th\u2019s technical platform is largely based on self-hosted WordPress, with some interesting theme modifications that allow for visualizations and in-page interactivity. (Did I immediately add <a href=\"https://indieweb.org/microformats\">simple microformats support</a> to articles as soon as I arrived? Yes, I did.) Importantly for me, the team cares about the same privacy issues I do: particularly in an environment where <a href=\"https://www.pbs.org/newshour/economy/why-some-fear-that-big-tech-data-could-become-a-tool-for-abortion-surveillance\">abortion-related surveillance is becoming a safety issue</a>, dealing with audience data intentionally is crucial.</p><p>Openness is core to what The 19th is. Its financial backers <a href=\"https://19thnews.org/membership/\">are published in full</a>, so you know exactly whose is bankrolling the non-profit. Since the beginning, the newsroom has also made its content available <a href=\"https://19thnews.org/republishing-guidelines/\">via a Creative Commons license</a> that allows anyone else to republish it for free. Those partners have included the Guardian, USA Today, Teen Vogue, PBS NewsHour, Ms. Magazine, RawStory, and many more. It could be you, too, if you wanted to: you can find the full HTML source to republish on every article page. Because The 19th\u2019s newsroom <a href=\"https://19thnews.org/team/\">is more diverse</a>, every republished article furthers its mission of improving representation in the news media overall.</p><p>It\u2019s an obvious extension to this strategy to make our <em>technology</em> available as well, via a permissive open source license. That\u2019s my ambition: to package up some of our supporting tools and make them available in a way that other newsrooms can take advantage of. If they have the technical capability to collaborate on building them, great; if not, they can still pick up the technology and use them. <a href=\"https://en.wikipedia.org/wiki/Diversity_in_open-source_software\">Open source itself has a giant diversity problem</a>, and if we can apply an equity lens to building our technical community in the same way we build our journalistic ecosystem, perhaps we can be a part of the solution there, too.</p><p>I\u2019ve long been a member of the <a href=\"https://indieweb.org\">indieweb</a> community, which encourages everyone to own and control their own website and domain. Both technically and ideologically, the overlaps with news are obvious: every newsroom must own its relationship with its audience in order to build trust, understand their needs, and above all to build community. Trends on the web have been in the opposite direction for most of the last decade: social media platforms like Facebook seek to intermediate and <em>monetize</em> that relationship, stripping newsrooms of resources and undermining the ability of voters to receive information in the process. Building an independent website for representative news content and community, and then helping others to do the same, is an important mission.</p><p>Right now it\u2019s a very small team: <a href=\"https://twitter.com/abbyblachman\">Abby Blachman</a> and me. I\u2019m looking for <a href=\"https://19thnews.org/19th-news-web-applications-engineer-job-posting/\">a third member of the technology team</a> to help with everything I\u2019ve discussed.</p><p>And so far, it\u2019s been <em>joyful</em>. Abby is amazing; everyone is. I\u2019ve never been part of an organization - least of all a remote team - that understands the need for a supportive culture so clearly. As an organization, it <a href=\"https://www.businessinsider.com/how-the-19th-case-study-survived-pandemic-2021-2\">continues to listen and evolve</a>. The people team - led by <a href=\"https://twitter.com/jayomiko\">Jayo Miko Macasaquit</a> - has put procedures and benefits in place that I haven\u2019t seen in organizations ten times the size. To build representative, empathetic news, you first need to build a representative, empathetic organization, and that\u2019s what\u2019s happening here. I hope they do more to tell their story and share what they\u2019re doing, because it\u2019s genuinely phenomenal.</p><p>I can\u2019t believe my luck; it\u2019s a real privilege to be on this team. I want to be a good ambassador: although I knew about the journalism, which should always be front and center, I wasn\u2019t as familiar with the organization\u2019s ecosystem and openness chops before I joined. It was the nicest of surprises, and I want to tell you more about it. We don\u2019t have an internal blog right now, so from time to time I\u2019ll discuss what we\u2019ve been working on over here.</p><p>I\u2019m also working on building some tools of my own to support my management process; the first is all about building a consistent culture of transparent feedback. More on that when I\u2019m ready.</p><p>In the meantime, if you have any questions, I\u2019d love to answer them. <a href=\"https://19thnews.org/19th-news-web-applications-engineer-job-posting/\">And if you happen to be interested in our technology position, you should definitely apply.</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": "30606285",
    "_source": "191",
    "_is_read": false
}

Ben Werdmüller werd.io/profile/benwerd

The Quest for a Memex

{
    "type": "entry",
    "published": "2022-08-01T00:12:20+00:00",
    "url": "https://werd.io/2022/the-quest-for-a-memex",
    "category": [
        "Technology"
    ],
    "bookmark-of": [
        "https://www.kevinmarks.com/memex.html"
    ],
    "name": "The Quest for a Memex",
    "content": {
        "text": "\u201cThis made me think about making a new view of a post, where the inbound and outbound links are shown in the margins of the page, and the flow is more dynamic. The inbound links can be found with Webmention, which is already here, but scanning the outbound links and making previews for them is a separate task. It seems related though - if a webmention tool can provide a prevew for inbound lnks, why not for outbound ones too?\u201d  #Technology\n            [Link]",
        "html": "<p>\u201cThis made me think about making a new view of a post, where the inbound and outbound links are shown in the margins of the page, and the flow is more dynamic. The inbound links can be found with Webmention, which is already here, but scanning the outbound links and making previews for them is a separate task. It seems related though - if a webmention tool can provide a prevew for inbound lnks, why not for outbound ones too?\u201d  <a href=\"https://werd.io/tag/Technology\" class=\"p-category\">#Technology</a></p>\n            <p>[<a href=\"https://www.kevinmarks.com/memex.html\">Link</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": "30592587",
    "_source": "191",
    "_is_read": false
}

Marty McGuire martymcgui.re

Switching costs for an IndieAuth server

{
    "type": "entry",
    "published": "2022-07-31T14:32:34-0400",
    "url": "https://martymcgui.re/2022/07/31/switching-costs-for-an-indieauth-server/",
    "category": [
        "site-update",
        "IndieAuth"
    ],
    "name": "Switching costs for an IndieAuth server",
    "content": {
        "text": "One of the things I love about building with IndieWeb building blocks is that (sometimes through more work than anticipated) you can swap out pieces of your site without (much) disruption because the seams between building blocks are well specified.\n\nSo, this is me documenting how I replaced my IndieAuth setup to stop leaning on Aaron\u2019s IndieAuth.com (which has been on the verge of retiring any day now for some years).\n\nPlease excuse this long and rambling post. Feel free to skip around!\n\n\n\nWhat is IndieAuth?\n\nAt a high-level, IndieAuth is a way to sign in using your website as an identity.\n\nWithout digging too deeply into the plumbing, you start by updating your website\u2019s homepage with some extra header info that says \u201cmy IndieAuth service is over there\u201d. From there, you can sign into services that support IndieAuth (like the IndieWeb wiki, the social feed reader service Aperture, and more. And you can use your IndieAuth server to protect your own services, such as a Micropub server that can create new posts on your site.\n\nWhy switch?\n\nI\u2019ve been using indieauth.com as my IndieAuth setup since late 2016 because it was easy to set up, because it uses something called RelMeAuth to let me sign in using services I already trust (like GitHub).\n\nHowever, indieauth.com has been growing stale as the IndieAuth spec has evolved. indieauth.com\u2019s maintainer has been discussing replacing it since at least 2017.\n\nThe inciting incident for my switch was looking at OwnCast - a self-hostable video streaming service with attached chatroom. OwnCast\u2019s chat allows using IndieAuth to sign in, which sounded great to me, but OwnCast\u2019s implementation wasn\u2019t expecting indieauth.com\u2019s old-style response format.\n\nWhy set up my own?\n\nThere are a bunch of IndieAuth server implementations listed on the IndieWeb wiki. However: simplest of them (selfauth + mintoken) are now out of date with the spec and haven\u2019t been replaced, yet. Others tend to be built into other CMSes like WordPress. A couple of standalone servers exist but are in languages I am not comfortable working in (hello Rust and Go) or have deployment requirements I wasn\u2019t thrilled about supporting (hello Rails).\n\nI found Taproot/IndieAuth on this page and that looked promising - a PHP library intended to be deployed within a fairly standard PHP web app style (\u201cany PSR-7 compatible app\u201d).\n\nI knew this would be some work but it sounded promising and so I began the week-ish long process of actually writing and deploying that \u201cPSR-7 compatible app\u201d built on taproot/indieauth.\n\ntl;dr say hello to Belding\n\nBelding is an \u201cPSR-7 compatible\u201d PHP web app that provides a standalone IndieAuth endpoint for a single user with a simple password form for authentication.\n\nI would love to go into the process and pitfalls of putting it together, but instead I\u2019ll link to the README where you can learn more about how it works, how to use it, its limitations, etc.\n\nSwitching costs for an IndieAuth server\n\n1. Tell the World\n\nFirst up, you\u2019ll need to update the headers on your site. I switched my authorization_endpoint and token_endpoint to my new server from indieauth.com. Since I\u2019m updating to support the latest spec, I also added the indieauth-metadata header (which should eventually replace the other two).\n\nNow that your site is advertising the new IndieAuth server, you will likely experience logouts or weird access denied reponses everywhere that your site has been used with IndieAuth.\n\n2. Tell your own services\n\nI needed to configure my own \u201crelying apps\u201d so they know to talk to the new server when checking that a request is allowed. This list thankfully wasn\u2019t too long.\n\nMy Micropub server\nMy Micropub media server\nBeyond the effort of getting my server working as an indieauth.com replacement, I also took steps to try and support the latest in the IndieAuth spec. That meant updating these micropub servers to use the new \u201ctoken introspection\u201d feature which has some tighter security requirements.\n\n(Note: I initially made the same change for my self-hosted copy of Aperture, but found it would be too many changes for me to take on at the moment. Instead, I updated by IndieAuth server to allow the older and less secure token verification method used by Aperture.)\n\n3. Sign-in to all the things again \\o|\n\nOnce all my relying apps were all talking to the new IndieAuth server, it was time to re-sign-in to all the things:\n\nThe IndieWeb wiki\n\nMonocle social reader client\n\nQuill Micropub posting client\nOwnYourSwarm\niOS apps\n\nmicro.blog\nIndigenous\n\nManually issue new IndieAuth tokens for automation that uses them:\n\nMy personal YouTube manager\n\nMy command line tool for media uploads\niOS shortcuts like the one I use to post Caturday.\n\nTakeaways\n\nThere are a lot of improvements I\u2019d like to make to Belding, but in general I am happy that it seems to work and, outside of the time to develop the server itself, my website and the tools I use to manage it were only broken for about a day.\n\nI think it\u2019d also be really nice to wrap up Belding a bit so it\u2019s easy to configure and deploy on free-and-cheap platforms like fly.io. I believe it should be easier for folks to spin up and control their own IndieWeb building blocks where possible!\n\nIt\u2019s also become clear to me that there are some user- and developer-experience holes around setting up relying apps. The auth requirements for token introspection, for example, means you need a way to manage access for each \u201cbackend\u201d that you have that relies on IndieAuth to protect itself!\n\nLong story short (too late) I am finally able to sign into OwnCast server chat using my domain. \ud83d\ude02\ud83d\ude05",
        "html": "<p>One of the things I love about building with <a href=\"https://indieweb.org/Category:building-blocks\">IndieWeb building blocks</a> is that (sometimes through more work than anticipated) you can swap out pieces of your site without (much) disruption because the seams between building blocks are well specified.</p>\n\n<p>So, this is me documenting how I replaced my <a href=\"https://indieauth.spec.indieweb.org/\">IndieAuth</a> setup to stop leaning on <a href=\"https://aaronparecki.com/\">Aaron\u2019s</a> <a href=\"https://indieauth.com/\">IndieAuth.com</a> (which has been on the verge of retiring any day now for some years).</p>\n\n<p>Please excuse this long and rambling post. Feel free to skip around!</p>\n\n\n\n<h2>What is IndieAuth?</h2>\n\n<p>At a high-level, IndieAuth is a way to sign in using your website as an identity.</p>\n\n<p>Without digging too deeply into the plumbing, you start by updating your website\u2019s homepage with some extra header info that says \u201cmy IndieAuth service is over there\u201d. From there, you can sign into services that support IndieAuth (like the <a href=\"https://indieauth.org/\">IndieWeb wiki</a>, the social feed reader service <a href=\"https://aperture.p3k.io/\">Aperture</a>, and more. And you can use your IndieAuth server to protect your own services, such as a <a href=\"https://indieweb.org/Micropub\">Micropub server</a> that can create new posts on your site.</p>\n\n<h2>Why switch?</h2>\n\n<p>I\u2019ve been using indieauth.com as my IndieAuth setup since late 2016 because it was easy to set up, because it uses something called <a href=\"https://indieweb.org/RelMeAuth\">RelMeAuth</a> to let me sign in using services I already trust (like GitHub).</p>\n\n<p>However, indieauth.com has been growing stale as the IndieAuth spec has evolved. indieauth.com\u2019s maintainer has been <a href=\"https://chat.indieweb.org/dev/2017-12-17#t1513485617181300\">discussing replacing it since at least 2017</a>.</p>\n\n<p>The inciting incident for my switch was looking at <a href=\"https://owncast.online/\">OwnCast</a> - a self-hostable video streaming service with attached chatroom. OwnCast\u2019s chat allows using IndieAuth to sign in, which sounded great to me, but OwnCast\u2019s implementation wasn\u2019t expecting indieauth.com\u2019s old-style response format.</p>\n\n<h3>Why set up my own?</h3>\n\n<p>There are <a href=\"https://indieweb.org/IndieAuth#Server_Implementations\">a bunch of IndieAuth server implementations listed on the IndieWeb wiki</a>. However: simplest of them (selfauth + mintoken) are now out of date with the spec and haven\u2019t been replaced, yet. Others tend to be built into other CMSes like WordPress. A couple of standalone servers exist but are in languages I am not comfortable working in (hello Rust and Go) or have deployment requirements I wasn\u2019t thrilled about supporting (hello Rails).</p>\n\n<p>I found <a href=\"https://github.com/taproot/indieauth\">Taproot/IndieAuth</a> on this page and that looked promising - a PHP library intended to be deployed within a fairly standard PHP web app style (\u201cany PSR-7 compatible app\u201d).</p>\n\n<p>I knew this would be some work but it sounded promising and so I began the week-ish long process of actually writing and deploying that \u201cPSR-7 compatible app\u201d built on taproot/indieauth.</p>\n\n<h2>tl;dr say hello to Belding</h2>\n\n<p><a href=\"https://git.schmarty.net/schmarty/belding\">Belding</a> is an \u201cPSR-7 compatible\u201d PHP web app that provides a standalone IndieAuth endpoint for a single user with a simple password form for authentication.</p>\n\n<p>I would love to go into the process and pitfalls of putting it together, but instead I\u2019ll link to the <a href=\"https://git.schmarty.net/schmarty/belding#user-content-belding\">README</a> where you can learn more about how it works, how to use it, its limitations, etc.</p>\n\n<h2>Switching costs for an IndieAuth server</h2>\n\n<h3>1. Tell the World</h3>\n\n<p>First up, you\u2019ll need to update the headers on your site. I switched my <code>authorization_endpoint</code> and <code>token_endpoint</code> to my new server from indieauth.com. Since I\u2019m updating to support the latest spec, I also added the <code>indieauth-metadata</code> header (which should eventually replace the other two).</p>\n\n<p>Now that your site is advertising the new IndieAuth server, you will likely experience logouts or weird access denied reponses everywhere that your site has been used with IndieAuth.</p>\n\n<h3>2. Tell your own services</h3>\n\n<p>I needed to configure my own \u201crelying apps\u201d so they know to talk to the new server when checking that a request is allowed. This list thankfully wasn\u2019t too long.</p>\n\n<ul><li><a href=\"https://github.com/martymcguire/micropub-1\">My Micropub server</a></li>\n<li><a href=\"https://github.com/martymcguire/spano\">My Micropub media server</a></li>\n</ul><p>Beyond the effort of getting my server working as an indieauth.com replacement, I also took steps to try and support the latest in the IndieAuth spec. That meant updating these micropub servers to use the new \u201ctoken introspection\u201d feature which has some tighter security requirements.</p>\n\n<p>(<em><strong>Note:</strong> I initially made the same change for my self-hosted copy of Aperture, but found it would be too many changes for me to take on at the moment. Instead, I updated by IndieAuth server to allow the older and less secure token verification method used by Aperture.</em>)</p>\n\n<h3>3. Sign-in to all the things again \\o|</h3>\n\n<p>Once all my relying apps were all talking to the new IndieAuth server, it was time to re-sign-in to all the things:</p>\n\n<ul><li><a href=\"https://indieweb.org/\">The IndieWeb wiki</a></li>\n<li>\n<a href=\"https://indieweb.org/Monocle\">Monocle</a> social reader client</li>\n<li>\n<a href=\"https://indieweb.org/Quill\">Quill</a> Micropub posting client</li>\n<li><a href=\"https://indieweb.org/OwnYourSwarm\">OwnYourSwarm</a></li>\n<li>iOS apps\n\n<ul><li><a href=\"https://indieweb.org/Micro.blog\">micro.blog</a></li>\n<li><a href=\"https://indieweb.org/Indigenous_for_iOS\">Indigenous</a></li>\n</ul></li>\n<li>Manually issue new IndieAuth tokens for automation that uses them:\n\n<ul><li>My <a href=\"https://martymcgui.re/2020/10/03/unsubscribing-from-youtubes-recommender/\">personal YouTube manager</a>\n</li>\n<li>My command line tool for media uploads</li>\n<li>iOS shortcuts like the one I use to post <a href=\"https://martymcgui.re/tag/caturday/\">Caturday</a>.</li>\n</ul></li>\n</ul><h2>Takeaways</h2>\n\n<p>There are <a href=\"https://git.schmarty.net/schmarty/belding#user-content-possible-future-work\">a lot of improvements I\u2019d like to make to Belding</a>, but in general I am happy that it seems to work and, outside of the time to develop the server itself, my website and the tools I use to manage it were only broken for about a day.</p>\n\n<p>I think it\u2019d also be really nice to wrap up Belding a bit so it\u2019s easy to configure and deploy on free-and-cheap platforms like <a href=\"https://fly.io/\">fly.io</a>. I believe it should be easier for folks to spin up and control their own IndieWeb building blocks where possible!</p>\n\n<p>It\u2019s also become clear to me that there are some user- and developer-experience holes around setting up relying apps. The auth requirements for token introspection, for example, means you need a way to manage access for each \u201cbackend\u201d that you have that relies on IndieAuth to protect itself!</p>\n\n<p>Long story short (too late) I am finally able to sign into OwnCast server chat using my domain. \ud83d\ude02\ud83d\ude05</p>"
    },
    "author": {
        "type": "card",
        "name": "Marty McGuire",
        "url": "https://martymcgui.re/",
        "photo": "https://martymcgui.re/images/logo.jpg"
    },
    "post-type": "note",
    "_id": "30589793",
    "_source": "175",
    "_is_read": false
}

gRegor Morrill gregorlove.com

{
    "type": "entry",
    "published": "2022-07-29 14:09-0700",
    "url": "https://gregorlove.com/2022/07/the-webmentioning/",
    "category": [
        "indieweb"
    ],
    "syndication": [
        "https://news.indieweb.org/en"
    ],
    "bookmark-of": [
        "https://lukeb.co.uk/blog/2022/06/28/no-comment-2-the-webmentioning/"
    ],
    "content": {
        "text": "No Comment 2: The Webmentioning",
        "html": "<p><a class=\"u-bookmark-of\" href=\"https://lukeb.co.uk/blog/2022/06/28/no-comment-2-the-webmentioning/\">No Comment 2: The Webmentioning</a></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": "bookmark",
    "_id": "30564841",
    "_source": "95",
    "_is_read": false
}

fluffy rambles: VRChat continued

{
    "type": "entry",
    "author": {
        "name": "fluffy",
        "url": "http://beesbuzz.biz/",
        "photo": null
    },
    "url": "http://beesbuzz.biz/blog/10109-VRChat-continued",
    "published": "2022-07-27T00:12:59-07:00",
    "content": {
        "html": "<a href=\"http://beesbuzz.biz/blog/?id=10109&amp;tag=vrchat\">#VRChat</a><a href=\"http://beesbuzz.biz/blog/?id=10109&amp;tag=vr\">#VR</a><a href=\"http://beesbuzz.biz/blog/?id=10109&amp;tag=indieweb\">#indieweb</a>",
        "text": "#VRChat#VR#indieweb"
    },
    "name": "fluffy rambles: VRChat continued",
    "post-type": "article",
    "_id": "30509167",
    "_source": "3782",
    "_is_read": false
}

Vika fireburn.ru

Proposal for a new-generation social reader concept

{
    "type": "entry",
    "published": "2022-07-27T09:43:57.419006560+03:00",
    "url": "https://fireburn.ru/posts/a-new-generation-of-social-readers",
    "category": [
        "IndieWeb",
        "Microsub",
        "social reader"
    ],
    "syndication": [
        "https://news.indieweb.org/en"
    ],
    "name": "Proposal for a new-generation social reader concept",
    "content": {
        "text": "This content is also featured in IndieNews, the IndieWeb news aggregator.The new generation of my own website was in its early stages of development for way too long. Several years passed before I was able to finally ship even a proof-of-concept, and yet ambitious thoughts don't stop leaving my head. While not being able to use my website and fully engage with the IndieWeb, I was forced to regress to some older technologies, such as RSS feeds and traditional social network silos, and yet I think this might've inspired me to create something new.\nThis is a proposal for a new generation of social readers, built right into the browser and based on open standards, such as Microsub and Micropub; allowing the user to seamlessly transition from the old-style web that we know to the new generation of social web - self-hosted, self-sovereign and free of unneccesary corporate influence, while not being bound to inferior and redundant technologies such as the blockchain and the \"Web 3.0\" fad that it started.\nThe role of a modern web browser\nThe modern web landscape has significantly changed since the invention of the World Wide Web by Tim Berners-Lee in 1989. From a document sharing system it was then transformed by its users into a proto-social network of personal webpages that mixed graphical media with textual content. Then it was once again transformed by the \"dot-com boom\", which accelerated both development of the technology and its commercialization and centralization.\nThe modern web browser is now the center-piece of every computing device, since without the web, modern computing as we know it wouldn't exist. The Internet supports many usecases we have, from simple filesharing to videoconferencing, completely transforming our lives. And all of this in a single app. But... something is lacking here.\nCurrent social networks present in the Internet landscape are mostly designed to show undesirable and irrelevant advertisments to users, and not to connect them and facilitate communication. Many services which were used by friend groups to communicate now transition away from a social network paradigm and turn into content-pushing machines, where the only choice the user has is to whether scroll down or stay on the current page. Control is being slowly taken away from users, turning what was intended into a primary means of communication and information exchange in the 21st century into a glorified TV with a touchscreen instead of buttons.\nThe fundamental concepts of \"self-hosting\" and \"the social web\"\nBut control can be taken back. Taking control of one's own social web experience and shaping it can primarily be facilitated through the concept of \"self-hosting\" - provisioning resources for oneself that facilitate information exchange and are controlled by the user instead of third-parties. Delegation of control is possible when neccesary and authorized - but data souvereignity is a must. Corporations come and go; their services may come down and never return. By taking control of one's own data and the responsibility for hosting content produced, an individual will gain the ability to fully control and curate their own unique online experience.\n\n  The\u00a0IndieWeb\u00a0community is based on exactly that thought and is building new Internet protocols to help people reclaim their space on the modern web. As part of their work, open standards and protocols were developed to facilitate the new generation of social web and data exchange, using a personal website as the centerpoint of data souvereignity and control. The user, being in control of their website, uses it to engage with other people on the social web while staying in control of the content they produce and consume, unlike current social networks, where accounts can be banned instantly with all their data gone, and instead of choosing things to read or watch or listen to, content is being forced down a user's throat by a black-box set of numbers masquerading as \"artificial intelligence\" (which is sometimes acting directly against its own moniker, lacking any true intelligence or understanding of human nature and humanity's wishes).\n  \n\nHowever, this concept, while being perfect otherwise, is incomplete. The level of integration between the IndieWeb and its protocols and the old-style web is lower than it could be, and the main point where the two can be reconciled is what we use the most to interact with the web - the web browser itself.\nCurrent state of affairs in the social web\nIn the collection of protocols and concepts developed by the IndieWeb community, there is a certain one that stands out the most, encompassing one of the central concepts of any social network - the feed. It's called a \"social reader\" - an application, most commonly a web app, that presents to user a social network-style interactive feed or a set of feeds that allows not only to consume content, but actively engage and interact with it. It borrows from conventional social network experience, but uses modern IndieWeb protocols such as Microsub\u00a0to let the user stay in control of their data and prevent any third parties from messing with it without the user's explicit consent or disrespecting the user's freedoms in any way.\nThe social reader allows one to curate a set of feeds filled with content, and then interact with them, posting replies, comments and notes (and even bookmarking whole articles, or expressing their appreciation of content with a \"like\" post, mirroring the \"like\" feature of conventional social network silos) to one's own website, allowing the user to stay in control of their own data and rely on third parties as little as possible while retaining the ability to interact with the wider World Wide Web. Sadly, being often confined to a web application, social readers are limited in their ability to interact with anything outside of the user's feeds, which limits the user's reach on the social web. While discovery engines based on syndication (such as indieweb.xyz, created by the community, or the old-style \"planet\" content aggregators) allow to expand that, the current experience of discovering new content can eventually take the user out of the social reader on a standalone non-social-web-aware webpage, where social interactions on one's own website are harder to facilitate. Solutions are being explored to remedy that, such as \"webactions\" - custom protocol handlers that indicate a prompt for an action to be performed inside of a social reader app and posted to the user's website.\nHowever, webactions are not natively supported by browsers, requiring JavaScript polyfills and often degrading user experience because of that. The epitome of that concept would be integrating the social reader directly into the browser, allowing it to facilitiate social web interactions without any external client-side software.\nA new generation of social readers\nModern web browsers include a \"new tab\" page that opens whenever an empty tab or window is opened. This experience can be redesigned to take users straight to their social reader, integrated directly into the browser instead of being a standalone web page. This will allow users to never degrade their experience, even when they're taken out of their reader to a standalone webpage - the browser could show buttons corresponding to actions that can be taken on the current page being viewed - for example, posting a comment on one's own website and then notifying the author using a Webmention, or syndicating the content to one's own website (commonly called \"repost\" in social network silo parlance), or simply bookmarking it as something interesting to refer to in later discussions, or for personal use.\nNative UX should be designed so that the social reader doesn't feel like a wart on top of a browser, but a natural extension of it. Such a design could allow users to seamlessly interact even with pages that aren't aware of the new generation of \"social web\", since the user's website will still be able to retain their interactions with the old-style page.\nMost browsers allow usage of so-called \"Web Extensions\" to augment the browser experience. Sadly, this often leaves the \"extension\" with minimal UI to show the user, aside from a single button beside the omnibox, or injecting itself into every webpage and projecting its UI in there, potentially breaking the page's layout in process. This leaves this mechanism ill-suited for integrating a social reader experience into the browser. Therefore, development of a new browser chrome, powered by one of the conventional engines such as Gecko or Blink, would be the most likely way to proceed with the implementation of this concept.\u00a0\nWeb Extensions could still be used to prototype and experiment with the concept. Omnibear\u00a0is an existing extension that allows one to author posts and interact with the social web. However, it was abandoned around 2019, and doesn't provide the social reader experience - only minimal ways to send interactions with foreign content to one's own website. Some of the concepts are similar enough to be reused, and inspiration could be taken from its UX.\nThe endgame\nBy fully taking control of one's own data, the user will gain control over their social web life. A modern web browser must be augmented with features to faciliate social web interactions to prevent UX degradation when inevitably landing on a page not aware of social web features. This will help users have a more pleasant and seamless experience on the social web, and help boost adoption by enhancing experience where social web interactions aren't natively supported by the websites themselves, due to ignorance, oversight or corporate malice.",
        "html": "<p><i>This content is also featured in <a href=\"https://news.indieweb.org/en\" class=\"u-syndication\">IndieNews</a>, the IndieWeb news aggregator.</i></p><p>The new generation of my own website was in its early stages of development for way too long. Several years passed before I was able to finally ship even a proof-of-concept, and yet ambitious thoughts don't stop leaving my head. While not being able to use my website and fully engage with the IndieWeb, I was forced to regress to some older technologies, such as RSS feeds and traditional social network silos, and yet I think this might've inspired me to create something new.</p>\n<p>This is a proposal for a new generation of social readers, built right into the browser and based on open standards, such as Microsub and Micropub; allowing the user to seamlessly transition from the old-style web that we know to the new generation of social web - self-hosted, self-sovereign and free of unneccesary corporate influence, while not being bound to inferior and redundant technologies such as the blockchain and the \"Web 3.0\" fad that it started.</p>\n<h2>The role of a modern web browser</h2>\n<p>The modern web landscape has significantly changed since the invention of the World Wide Web by <a href=\"https://www.w3.org/People/Berners-Lee/\">Tim Berners-Lee</a> in 1989. From a document sharing system it was then transformed by its users into a proto-social network of personal webpages that mixed graphical media with textual content. Then it was once again transformed by the \"dot-com boom\", which accelerated both development of the technology and its commercialization and centralization.</p>\n<p>The modern web browser is now the center-piece of every computing device, since without the web, modern computing as we know it wouldn't exist. The Internet supports many usecases we have, from simple filesharing to videoconferencing, completely transforming our lives. And all of this in a single app. But... something is lacking here.</p>\n<p>Current social networks present in the Internet landscape are mostly designed to show undesirable and irrelevant advertisments to users, and not to connect them and facilitate communication. Many services which were used by friend groups to communicate now transition away from a social network paradigm and turn into content-pushing machines, where the only choice the user has is to whether scroll down or stay on the current page. Control is being slowly taken away from users, turning what was intended into a primary means of communication and information exchange in the 21st century into a glorified TV with a touchscreen instead of buttons.</p>\n<h2>The fundamental concepts of \"self-hosting\" and \"the social web\"</h2>\n<p>But control can be taken back. Taking control of one's own social web experience and shaping it can primarily be facilitated through the concept of \"self-hosting\" - provisioning resources for oneself that facilitate information exchange and are controlled by the user instead of third-parties. Delegation of control is possible when neccesary and authorized - but data souvereignity is a must. Corporations come and go; their services may come down and never return. By taking control of one's own data and the responsibility for hosting content produced, an individual will gain the ability to fully control and curate their own unique online experience.</p>\n<p>\n  The\u00a0<a href=\"https://indieweb.org/\" style=\"font-weight:bold;\">IndieWeb</a>\u00a0community is based on exactly that thought and is building new Internet protocols to help people reclaim their space on the modern web. As part of their work, open standards and protocols were developed to facilitate the new generation of social web and data exchange, using a personal website as the centerpoint of data souvereignity and control. The user, being in control of their website, uses it to engage with other people on the social web while staying in control of the content they produce and consume, unlike current social networks, where accounts can be banned instantly with all their data gone, and instead of choosing things to read or watch or listen to, content is being forced down a user's throat by a black-box set of numbers masquerading as \"artificial intelligence\" (which is sometimes acting directly against its own moniker, lacking any true intelligence or understanding of human nature and humanity's wishes).\n  <br /></p>\n<p>However, this concept, while being perfect otherwise, is incomplete. The level of integration between the IndieWeb and its protocols and the old-style web is lower than it could be, and the main point where the two can be reconciled is what we use the most to interact with the web - the web browser itself.</p>\n<h2>Current state of affairs in the social web</h2>\n<p>In the collection of protocols and concepts developed by the IndieWeb community, there is a certain one that stands out the most, encompassing one of the central concepts of any social network - the feed. It's called a \"<a href=\"https://indieweb.org/social_reader\">social reader</a>\" - an application, most commonly a web app, that presents to user a social network-style interactive feed or a set of feeds that allows not only to consume content, but actively engage and interact with it. It borrows from conventional social network experience, but uses modern IndieWeb protocols such as <a href=\"https://indieweb.org/Microsub\">Microsub</a>\u00a0to let the user stay in control of their data and prevent any third parties from messing with it without the user's explicit consent or disrespecting the user's freedoms in any way.</p>\n<p>The social reader allows one to curate a set of feeds filled with content, and then interact with them, posting replies, comments and notes (and even bookmarking whole articles, or expressing their appreciation of content with a \"like\" post, mirroring the \"like\" feature of conventional social network silos) to one's own website, allowing the user to stay in control of their own data and rely on third parties as little as possible while retaining the ability to interact with the wider World Wide Web. Sadly, being often confined to a web application, social readers are limited in their ability to interact with anything outside of the user's feeds, which limits the user's reach on the social web. While discovery engines based on syndication (such as <a href=\"https://indieweb.xyz/\">indieweb.xyz</a>, created by the community, or the old-style \"planet\" content aggregators) allow to expand that, the current experience of discovering new content can eventually take the user out of the social reader on a standalone non-social-web-aware webpage, where social interactions on one's own website are harder to facilitate. Solutions are being explored to remedy that, such as \"<a href=\"https://indieweb.org/webactions\">webactions</a>\" - custom protocol handlers that indicate a prompt for an action to be performed inside of a social reader app and posted to the user's website.</p>\n<p>However, webactions are not natively supported by browsers, requiring JavaScript polyfills and often degrading user experience because of that. The epitome of that concept would be integrating the social reader directly into the browser, allowing it to facilitiate social web interactions without any external client-side software.</p>\n<h2>A new generation of social readers</h2>\n<p>Modern web browsers include a \"new tab\" page that opens whenever an empty tab or window is opened. This experience can be redesigned to take users straight to their social reader, integrated directly into the browser instead of being a standalone web page. This will allow users to never degrade their experience, even when they're taken out of their reader to a standalone webpage - the browser could show buttons corresponding to actions that can be taken on the current page being viewed - for example, posting a comment on one's own website and then notifying the author using a <a href=\"https://indieweb.org/Webmention\">Webmention</a>, or syndicating the content to one's own website (commonly called \"repost\" in social network silo parlance), or simply bookmarking it as something interesting to refer to in later discussions, or for personal use.</p>\n<p>Native UX should be designed so that the social reader doesn't feel like a wart on top of a browser, but a natural extension of it. Such a design could allow users to seamlessly interact even with pages that aren't aware of the new generation of \"social web\", since the user's website will still be able to retain their interactions with the old-style page.</p>\n<p>Most browsers allow usage of so-called \"Web Extensions\" to augment the browser experience. Sadly, this often leaves the \"extension\" with minimal UI to show the user, aside from a single button beside the omnibox, or injecting itself into every webpage and projecting its UI in there, potentially breaking the page's layout in process. This leaves this mechanism ill-suited for integrating a social reader experience into the browser. Therefore, development of a new browser chrome, powered by one of the conventional engines such as Gecko or Blink, would be the most likely way to proceed with the implementation of this concept.\u00a0</p>\n<p>Web Extensions could still be used to prototype and experiment with the concept. <a href=\"https://indieweb.org/Omnibear\">Omnibear</a>\u00a0is an existing extension that allows one to author posts and interact with the social web. However, it was abandoned around 2019, and doesn't provide the social reader experience - only minimal ways to send interactions with foreign content to one's own website. Some of the concepts are similar enough to be reused, and inspiration could be taken from its UX.</p>\n<h2>The endgame</h2>\n<p>By fully taking control of one's own data, the user will gain control over their social web life. A modern web browser must be augmented with features to faciliate social web interactions to prevent UX degradation when inevitably landing on a page not aware of social web features. This will help users have a more pleasant and seamless experience on the social web, and help boost adoption by enhancing experience where social web interactions aren't natively supported by the websites themselves, due to ignorance, oversight or corporate malice.</p>"
    },
    "author": {
        "type": "card",
        "name": "Vika",
        "url": "https://fireburn.ru/",
        "photo": "https://avatars.githubusercontent.com/u/7953163?v=4"
    },
    "post-type": "article",
    "_id": "30507260",
    "_source": "1371",
    "_is_read": false
}

Vika fireburn.ru

{
    "type": "entry",
    "published": "2022-07-27T08:17:46.839915260+03:00",
    "url": "https://fireburn.ru/posts/aZMUGLe",
    "category": [
        "IndieWeb"
    ],
    "content": {
        "text": "did I just start an outline for a small essay on modern web and social readers?\n\nthis will be interesting, I promise",
        "html": "<p>did I just start an outline for a small essay on modern web and social readers?</p>\n\n<p>this will be interesting, I promise</p>"
    },
    "author": {
        "type": "card",
        "name": "Vika",
        "url": "https://fireburn.ru/",
        "photo": "https://avatars.githubusercontent.com/u/7953163?v=4"
    },
    "post-type": "note",
    "_id": "30507261",
    "_source": "1371",
    "_is_read": false
}

David Shanske david.shanske.com

Indiewebifying a WordPress Site – 2022 Edition - Sunday Sun June 12, 2022

{
    "type": "entry",
    "published": "2022-06-12T03:19:26-04:00",
    "syndication": [
        "https://news.indieweb.org/en/david.shanske.com/2022/06/12/indiewebifying-a-wordpress-site-2022-edition/",
        "https://twitter.com/dshanske/status/1535885717653622784",
        "https://micro.blog/dshanske/13015162"
    ],
    "name": "Indiewebifying a WordPress Site \u2013 2022 Edition - Sunday Sun June 12, 2022",
    "author": {
        "type": "card",
        "name": "David Shanske",
        "url": "https://david.shanske.com/",
        "photo": "https://david.shanske.com/avatar/dshanske?s=96"
    },
    "post-type": "article",
    "_id": "30326944",
    "_source": "5",
    "_is_read": false
}

David Shanske david.shanske.com

IndieAuth Spec Updates 2022 - Thursday Thu April 21, 2022

{
    "type": "entry",
    "published": "2022-04-21T11:47:38-04:00",
    "syndication": [
        "https://news.indieweb.org/en/david.shanske.com/2022/04/21/indieauth-spec-updates-2022/",
        "https://twitter.com/dshanske/status/1517168901976727553",
        "https://micro.blog/dshanske/12729173"
    ],
    "name": "IndieAuth Spec Updates 2022 - Thursday Thu April 21, 2022",
    "author": {
        "type": "card",
        "name": "David Shanske",
        "url": "https://david.shanske.com/",
        "photo": "https://david.shanske.com/avatar/dshanske?s=96"
    },
    "post-type": "article",
    "_id": "30326947",
    "_source": "5",
    "_is_read": false
}

Jeremy Keith adactio.com

{
    "type": "entry",
    "published": "2022-07-17T09:41:05Z",
    "url": "https://adactio.com/links/19279",
    "category": [
        "indieweb",
        "personal",
        "publishing",
        "independent",
        "openweb",
        "writing",
        "sharing",
        "blogging",
        "blogs"
    ],
    "bookmark-of": [
        "https://webdevlaw.uk/2022/07/15/the-week-the-open-web-won/#more-10817"
    ],
    "content": {
        "text": "The week the open web won \u2013 Hi, I\u2019m Heather Burns\n\n\n\n\n  So to me, this blog represents the original promise of the open web.\n  \n  The one that\u2019s here, and still is here, and always has been here, and is available to you.\n  \n  Right now.\n  \n  The one where you can speak the truths that you believe without the permission, or the editorial control, or the power dynamics, of anyone claiming to hold authority over you; or, perhaps, anyone keen to impose it.\n\n\nHeather takes a break from her relentless crusading in favour of users against the idiocy of the UK government and reflects on the joy of doing it all from her own personal website.\n\n\n  And perhaps you should too, on your own blog, owned on your own hosting space, using your own words, and speaking your own truth. That sounds like a good little weekend project, don\u2019t you think?",
        "html": "<h3>\n<a class=\"p-name u-bookmark-of\" href=\"https://webdevlaw.uk/2022/07/15/the-week-the-open-web-won/#more-10817\">\nThe week the open web won \u2013 Hi, I\u2019m Heather Burns\n</a>\n</h3>\n\n<blockquote>\n  <p>So to me, this blog represents the original promise of the open web.</p>\n  \n  <p>The one that\u2019s here, and still is here, and always has been here, and is available to you.</p>\n  \n  <p>Right now.</p>\n  \n  <p>The one where you can speak the truths that you believe without the permission, or the editorial control, or the power dynamics, of anyone claiming to hold authority over you; or, perhaps, anyone keen to impose it.</p>\n</blockquote>\n\n<p>Heather takes a break from her relentless crusading in favour of users against the idiocy of the UK government and reflects on the joy of doing it all from her own personal website.</p>\n\n<blockquote>\n  <p>And perhaps you should too, on your own blog, owned on your own hosting space, using your own words, and speaking your own truth. That sounds like a good little weekend project, don\u2019t you think?</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": "30324501",
    "_source": "2",
    "_is_read": false
}

Ryan Barrett snarfed.org

Bridgy stats update

{
    "type": "entry",
    "published": "2022-06-05T23:27:15-07:00",
    "url": "https://snarfed.org/2022-06-05_bridgy-stats-update-7",
    "photo": [
        "https://snarfed.org/bridgy_stats/2022/accounts_stacked_thumb.png",
        "https://snarfed.org/bridgy_stats/2022/webmentions_thumb.png",
        "https://snarfed.org/bridgy_stats/2022/publishes_increase_thumb.png",
        "https://snarfed.org/bridgy_stats/2022/publishes_thumb.png"
    ],
    "syndication": [
        "https://news.indieweb.org/en/snarfed.org/2022-06-05_bridgy-stats-update-7"
    ],
    "name": "Bridgy stats update",
    "content": {
        "text": "It\u2019s that time of year again\u2026Bridgy stats update! Top line numbers: 6471 accounts, 28M silo responses, 4.7M links, 2.3M webmentions sent, 99k posts published, 102k blog posts processed, 16k blog webmentions received.\n\n \n  \n\n\n \n  \n\n\n \n  \n\n \n  \n Continue reading \u2192",
        "html": "<p>\n <a href=\"https://brid.gy/\">\n  </a></p>\n<p>It\u2019s that time of year again\u2026<a href=\"https://brid.gy/\">Bridgy</a> stats update! Top line numbers: 6471 accounts, 28M silo responses, 4.7M links, 2.3M webmentions sent, 99k posts published, 102k <a href=\"https://brid.gy/about#blogs\">blog posts processed</a>, 16k <a href=\"https://brid.gy/about#blogs\">blog webmentions</a> received.</p>\n<p>\n <a href=\"https://snarfed.org/bridgy_stats/2022/accounts_stacked.png\">\n  </a></p>\n\n<p>\n <a href=\"https://snarfed.org/bridgy_stats/2022/webmentions.png\">\n  </a></p>\n\n<p>\n <a href=\"https://snarfed.org/bridgy_stats/2022/publishes_increase.png\">\n  </a></p>\n<p>\n <a href=\"https://snarfed.org/bridgy_stats/2022/publishes.png\">\n  </a></p>\n<p> <a href=\"https://snarfed.org/2022-06-05_bridgy-stats-update-7#more-47005\">Continue reading <span>\u2192</span></a></p>"
    },
    "author": {
        "type": "card",
        "name": "Ryan Barrett",
        "url": "https://snarfed.org/",
        "photo": "https://secure.gravatar.com/avatar/947b5f3f323da0ef785b6f02d9c265d6?s=96&d=blank&r=g"
    },
    "post-type": "photo",
    "_id": "30238458",
    "_source": "3",
    "_is_read": true
}

Ben Werdmüller werd.io/profile/benwerd

A new CEO for Medium

{
    "type": "entry",
    "published": "2022-07-12T18:51:05+00:00",
    "url": "https://werd.io/2022/a-new-ceo-for-medium",
    "name": "A new CEO for Medium",
    "content": {
        "text": "So, Medium has a new CEO, who happens to be someone I like very much.I worked at Medium in the publications group for a year. It was a pretty daunting experience: my first time working with the kind of budget Medium enjoyed, and with people who were veterans of all the products I knew and loved. I was used to being an outsider, and found myself on a world-class team trying to build something that promoted positive discourse. Honestly, although I had to level up in all kinds of ways, my biggest challenge there was managing the anxiety of working around so many people I looked up to. Happily, a lot of the people I worked with remain very good friends; if I hadn\u2019t been asked to join Matter as Director of Investments, an opportunity I couldn\u2019t say no to, I would have stayed for a lot longer.My first real interaction with Ev while I was there centered around the open web. Coming from an indieweb context, I was a bit guarded: I didn\u2019t think Medium probably had exactly my priorities, and I was a little worried that the indieweb community might think I\u2019d sold out. The jury\u2019s out on the indieweb community (I don\u2019t think mostly anyone cared), but I was pleasantly surprised to find that Ev cares deeply about the web, was interested in deep interoperability, and believes in the health of the ecosystem as well as the discourse on it.I\u2019ve known Tony Stubblebine for longer. He was working on Crowdvine while I was working on Elgg; different products, but playing in a similar-enough space that we often found ourselves at the same meetups and in the same discussions. He\u2019s a thoughtful, kind person who is also very analytical, and has always given me good advice. He built a really strong community with Coach.me, both inside and out, and he\u2019s been a really strong champion of Medium\u2019s own community.So I couldn\u2019t be more excited about two things: Tony taking over as CEO, and Ev going to investigate new ideas as part of a new holding company. I can\u2019t wait to see what they both do next.",
        "html": "<p><img src=\"https://werd.io/file/62cdc346a9c9b0795b17ae92\" alt=\"\" width=\"1024\" height=\"651\" /></p><p>So, Medium has a new CEO, <a href=\"https://coachtony.medium.com/hello-medium-readers-authors-editors-and-publishers-65bb728de2d8\">who happens to be someone I like very much</a>.</p><p>I worked at Medium in the publications group for a year. It was a pretty daunting experience: my first time working with the kind of budget Medium enjoyed, and with people who were veterans of all the products I knew and loved. I was used to being an outsider, and found myself on a world-class team trying to build something that promoted positive discourse. Honestly, although I had to level up in all kinds of ways, my biggest challenge there was managing the anxiety of working around so many people I looked up to. Happily, a lot of the people I worked with remain very good friends; if I hadn\u2019t been asked to join Matter as Director of Investments, an opportunity I couldn\u2019t say no to, I would have stayed for a lot longer.</p><p>My first real interaction with Ev while I was there centered around the open web. Coming from an indieweb context, I was a bit guarded: I didn\u2019t think Medium probably had exactly my priorities, and I was a little worried that the indieweb community might think I\u2019d sold out. The jury\u2019s out on the indieweb community (I don\u2019t think mostly anyone cared), but I was pleasantly surprised to find that Ev cares deeply about the web, was interested in deep interoperability, and believes in the health of the ecosystem as well as the discourse on it.</p><p>I\u2019ve known Tony Stubblebine for longer. He was working on Crowdvine while I was working on Elgg; different products, but playing in a similar-enough space that we often found ourselves at the same meetups and in the same discussions. He\u2019s a thoughtful, kind person who is also very analytical, and has always given me good advice. He built a really strong community with <a href=\"https://www.coach.me/\">Coach.me</a>, both inside and out, and he\u2019s been a really strong champion of Medium\u2019s own community.</p><p>So I couldn\u2019t be more excited about two things: Tony taking over as CEO, and Ev going to investigate new ideas as <a href=\"https://ev.medium.com/new-decade-new-ideas-faee8e712589\">part of a new holding company</a>. I can\u2019t wait to see what they both do next.</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": "30238107",
    "_source": "191",
    "_is_read": true
}

Ben Werdmüller werd.io/profile/benwerd

My indieweb real estate website (part two)

{
    "type": "entry",
    "published": "2022-07-11T02:19:49+00:00",
    "url": "https://werd.io/2022/my-indieweb-real-estate-website-part-two",
    "name": "My indieweb real estate website (part two)",
    "content": {
        "text": "A little earlier this year, I mentioned that I was building an indieweb real estate website.Preparing a home for sale is more difficult than I\u2019d accounted for. Digging our worldly possessions out of it, and then ensuring that the house was in the best shape it could be, took a lot of time. And in the meantime, a lot of life happened.Our family home in Santa Rosa is finally going on the market this week. And, although I\u2019ll likely keep working on it, I have my indieweb website ready to go.When I initially brought up the idea, I set myself two main restrictions. I said it needed to be online in two weeks, and I blew through that by months. But I also said:It needs to get an A for SEO, site performance, and security.It does. Here are its core web vitals via web.dev:And its security rating via Mozilla Observatory:It helped that I hand-rolled the site.You might note that performance remains at 97/100, while the other metrics are at 100. There is still a Cumulative Layout Shift at 0.14 seconds, which is almost certainly because there are a lot of images on the page which have dynamic heights and widths depending on the viewport. There\u2019s more I can do there to make those images a predictable size.There are a handful of non-obvious things I had to do. For example, both MLS and land parcels have a numeric identifier. If you view this on a phone, the mobile browser tries to intelligently turn those into phone numbers, creating unnecessary links. I didn\u2019t want to link out to a third-party site for MLS or land parcels, but it turns out you can suppress automatic phone number linking with the following meta tag:<meta name=\"format-detection\" content=\"telephone=no\">Each image is loaded from an image set; I hand-resized them for various reasonable viewport sizes. I also created independently-cropped images for Twitter and Facebook.To get the highest security rating possible, I made sure there was no inline code (no inline stylesheets or JS), and created a Content Security Policy that I apply via an .htaccess file.Finally, I said:It\u2019ll be a hand-rolled static site. No frameworks for the HTML, JS, or CSS, and no pre-set templates: just me, a text editor, and some design tools.And that\u2019s what I did. I wrote the HTML and CSS from scratch in VS Code, making liberal use of media queries and CSS grids. And I had a lot of fun doing it.My full code (which is really simple!) is available on GitHub, but the most existing way to take a look is to view the website itself at 5405spainave.com.And if you want a beautiful wine country home in Santa Rosa, California, you know who to talk to.*Some other ideas that came up:What about video or virtual reality? We didn\u2019t have a professionally-produced video of the home. We do have professionally-taken photographs, which I\u2019ve used liberally. I took some of the others (eg of wineries and Bodega Bay), and the rest came from Unsplash.What if we accepted crypto for the home? It\u2019s too difficult to do; agents, escrow, legal frameworks are not set up for this. Also, at least one member of our family makes a particular kind of face whenever crypto is mentioned. It had occurred to me that we could push the selling price for crypto sales a little higher: eg, sure, we\u2019ll take your ETH or BTC, but the dollar equivalent will be $2M. (If you would like to give us two million dollars for our home, please do get in touch.)What about a blog or regularly-updated content? Home sales in California are incredibly short. We could have written a blog about getting the home ready, but honestly, it was already a stressful enough process. We anticipate a very short sales window for the home itself, so we didn\u2019t do it. I\u2019ll likely add more narrative description in the our experience page.And analytics? The site doesn\u2019t set any cookies or collect any analytics on the front end. However, I do push it through Cloudflare\u2019s CDN, which gives me some simple stats to gauge success.It\u2019s a very simple website. Yes. And often, that\u2019s all you need.",
        "html": "<p><img src=\"https://werd.io/file/62cb885418bd47220a337442/thumb.jpg\" alt=\"\" width=\"1024\" height=\"652\" /></p><p>A little earlier this year, <a href=\"https://werd.io/2022/my-indieweb-real-estate-website-part-one\">I mentioned that I was building an indieweb real estate website</a>.</p><p>Preparing a home for sale is more difficult than I\u2019d accounted for. Digging our worldly possessions out of it, and then ensuring that the house was in the best shape it could be, took a lot of time. And in the meantime, a lot of life happened.</p><p>Our family home in Santa Rosa is finally going on the market this week. And, although I\u2019ll likely keep working on it, <a href=\"https://5405spainave.com\">I have my indieweb website ready to go</a>.</p><p>When I initially brought up the idea, I set myself two main restrictions. I said it needed to be online in two weeks, and I blew through that by months. But I also said:</p><blockquote><p>It needs to get an A for SEO, site performance, and security.</p></blockquote><p>It does. Here are its core web vitals <a href=\"https://web.dev/measure/?url=https%3A%2F%2F5405spainave.com\">via web.dev</a>:</p><p><img src=\"https://werd.io/file/62cb887118bd47220a337444/thumb.png\" alt=\"\" width=\"516\" height=\"146\" /></p><p>And its security rating <a href=\"https://observatory.mozilla.org/analyze/5405spainave.com\">via Mozilla Observatory</a>:</p><p><img src=\"https://werd.io/file/62cb889a937e5658a94eb2c2/thumb.png\" alt=\"\" width=\"483\" height=\"308\" /></p><p>It helped that I hand-rolled the site.</p><p>You might note that performance remains at 97/100, while the other metrics are at 100. There is still a Cumulative Layout Shift at 0.14 seconds, which is almost certainly because there are a lot of images on the page which have dynamic heights and widths depending on the viewport. There\u2019s more I can do there to make those images a predictable size.</p><p>There are a handful of non-obvious things I had to do. For example, both MLS and land parcels have a numeric identifier. If you view this on a phone, the mobile browser tries to intelligently turn those into phone numbers, creating unnecessary links. I didn\u2019t want to link out to a third-party site for MLS or land parcels, but it turns out you can suppress automatic phone number linking with the following meta tag:</p><p><code>&lt;meta name=\"format-detection\" content=\"telephone=no\"&gt;</code></p><p>Each image is loaded from <a href=\"https://developer.mozilla.org/en-US/docs/Learn/HTML/Multimedia_and_embedding/Responsive_images\">an image set</a>; I hand-resized them for various reasonable viewport sizes. I also created independently-cropped images for Twitter and Facebook.</p><p>To get the highest security rating possible, I made sure there was no inline code (no inline stylesheets or JS), and created <a href=\"https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP\">a Content Security Policy</a> that I apply via <a href=\"https://httpd.apache.org/docs/2.4/howto/htaccess.html\">an .htaccess file</a>.</p><p>Finally, I said:</p><blockquote><p>It\u2019ll be a hand-rolled static site. No frameworks for the HTML, JS, or CSS, and no pre-set templates: just me, a text editor, and some design tools.</p></blockquote><p>And that\u2019s what I did. I wrote the HTML and CSS from scratch in <a href=\"https://code.visualstudio.com/\">VS Code</a>, making liberal use of <a href=\"https://developer.mozilla.org/en-US/docs/Web/CSS/Media_Queries/Using_media_queries\">media queries</a> and <a href=\"https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Grid_Layout\">CSS grids</a>. And I had a lot of fun doing it.</p><p>My full code (which is really simple!) <a href=\"https://github.com/benwerd/5405spain\">is available on GitHub</a>, but the most existing way to take a look <a href=\"https://www.5405spainave.com/\">is to view the website itself at 5405spainave.com</a>.</p><p>And if you want <a href=\"https://www.5405spainave.com/\">a beautiful wine country home in Santa Rosa, California</a>, you know who to talk to.</p><p>*</p><p>Some other ideas that came up:</p><p><strong>What about video or virtual reality?</strong> We didn\u2019t have a professionally-produced video of the home. We <em>do</em> have professionally-taken photographs, which I\u2019ve used liberally. I took some of the others (eg of wineries and Bodega Bay), and the rest came from <a href=\"https://unsplash.com/\">Unsplash</a>.</p><p><strong>What if we accepted crypto for the home?</strong> It\u2019s too difficult to do; agents, escrow, legal frameworks are not set up for this. Also, at least one member of our family makes a particular kind of face whenever crypto is mentioned. It <em>had</em> occurred to me that we could push the selling price for crypto sales a little higher: eg, sure, we\u2019ll take your ETH or BTC, but the dollar equivalent will be $2M. (If you would like to give us two million dollars for our home, please do get in touch.)</p><p><strong>What about a blog or regularly-updated content?</strong> Home sales in California are incredibly short. We could have written a blog about getting the home ready, but honestly, it was already a stressful enough process. We anticipate a very short sales window for the home itself, so we didn\u2019t do it. I\u2019ll likely add more narrative description in the <a href=\"https://5405spainave.com/our-experiences.html\">our experience page</a>.</p><p><strong>And analytics?</strong> The site doesn\u2019t set any cookies or collect any analytics on the front end. However, I do push it through <a href=\"https://www.cloudflare.com/\">Cloudflare\u2019s CDN</a>, which gives me some simple stats to gauge success.</p><p><strong>It\u2019s a very simple website.</strong> Yes. <a href=\"https://5405spainave.com\">And often, that\u2019s all you need.</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": "30203645",
    "_source": "191",
    "_is_read": true
}

Vika fireburn.ru

{
    "type": "entry",
    "published": "2022-07-10T15:03:18.287307354+03:00",
    "url": "https://fireburn.ru/posts/kittybox-status-update-2022-07-10",
    "category": [
        "Kittybox"
    ],
    "content": {
        "text": "It looks like Kittybox is close to its finish line and general protocol-compliance goal. The only unimplemented parts are:\n\nIn-house IndieAuth (auth and tokens)\n\nWebmentions\n\nWebSub pings\nThen it will reach full protocol-compliance status, and I could go on to develop other things like pretty UI for posting, the Microsub server (because I really want my own!) etc.",
        "html": "<p>It looks like Kittybox is close to its finish line and general protocol-compliance goal. The only unimplemented parts are:</p>\n\n<ul><li>In-house IndieAuth (auth and tokens)</li>\n\n<li>Webmentions</li>\n\n<li>WebSub pings</li>\n</ul><p>Then it will reach full protocol-compliance status, and I could go on to develop other things like pretty UI for posting, the Microsub server (because I really want my own!) etc.</p>"
    },
    "author": {
        "type": "card",
        "name": "Vika",
        "url": "https://fireburn.ru/",
        "photo": "https://avatars.githubusercontent.com/u/7953163?v=4"
    },
    "post-type": "note",
    "_id": "30194028",
    "_source": "1371",
    "_is_read": true
}

Vika fireburn.ru

{
    "type": "entry",
    "published": "2022-07-10T15:00:33.009962176+03:00",
    "url": "https://fireburn.ru/posts/indieauth-woes-part-0",
    "category": [
        "IndieAuth",
        "kittybox"
    ],
    "content": {
        "text": "Time to traumatize myself by implementing the entire IndieAuth spec by hand. The newest version that seems to be twice as complex as the one from three years ago.\n\nI\u2019m not sure if I should draft a will first, it seems overwhelming to me... (but I\u2019m sure that in the event that I succeed, I will reap major rewards from it)",
        "html": "<p>Time to traumatize myself by implementing <a href=\"https://indieauth.spec.indieweb.org/\">the entire IndieAuth spec</a> by hand. The newest version that seems to be twice as complex as the one from three years ago.</p>\n\n<p>I\u2019m not sure if I should draft a will first, it seems overwhelming to me... (but I\u2019m sure that in the event that I succeed, I will reap major rewards from it)</p>"
    },
    "author": {
        "type": "card",
        "name": "Vika",
        "url": "https://fireburn.ru/",
        "photo": "https://avatars.githubusercontent.com/u/7953163?v=4"
    },
    "post-type": "note",
    "_id": "30194029",
    "_source": "1371",
    "_is_read": true
}

Notes: Why The Indieweb?

{
    "type": "entry",
    "author": {
        "name": "fluffy",
        "url": "http://beesbuzz.biz/",
        "photo": null
    },
    "url": "http://beesbuzz.biz/blog/chatter/5125-Why-The-Indieweb",
    "published": "2022-07-06T10:20:54-07:00",
    "content": {
        "html": "<a href=\"http://beesbuzz.biz/blog/chatter/?id=5125&amp;tag=indieweb\">#indieweb</a><a href=\"http://beesbuzz.biz/blog/chatter/?id=5125&amp;tag=humor\">#humor</a>",
        "text": "#indieweb#humor"
    },
    "name": "Notes: Why The Indieweb?",
    "post-type": "article",
    "_id": "30121693",
    "_source": "3782",
    "_is_read": true
}

Manton Reece www.manton.org

Importing check-ins from Ohai

{
    "type": "entry",
    "author": {
        "name": "Manton Reece",
        "url": "https://www.manton.org/",
        "photo": "https://micro.blog/manton/avatar.jpg"
    },
    "url": "https://www.manton.org/2022/07/05/importing-checkins-from.html",
    "name": "Importing check-ins from Ohai",
    "content": {
        "html": "<p>I\u2019ve used a few apps over the years for location check-ins. Gowalla, Foursquare, and Ohai, which was built on the App.net API. The Gowalla data was lost after they were acquired by Facebook. I\u2019ve continued to use Foursquare and have imported many of those check-ins to my location site <a href=\"https://manton.coffee\">manton.coffee</a>.</p>\n<p>I have about a year of data from Ohai, from around 2013-2014. Before App.net shut down, I exported the data. I wanted to dust it off and import it into Micro.blog.</p>\n<p>The data is stored in the App.net \u201cmessages\u201d JSON. In some cases, there is annotation data that includes the location information such as place name for the check-in and latitude/longitude.</p>\n<p>Here\u2019s an example of one of the check-ins, cleaned up slightly to remove fields I don\u2019t care about:</p>\n<pre style=\"color:#f8f8f2;background-color:#272822;\"><code>{\n  <span style=\"color:#f92672;\">\"annotations\"</span>: [\n    {\n      <span style=\"color:#f92672;\">\"type\"</span>: <span style=\"color:#e6db74;\">\"net.app.ohai.location\"</span>,\n      <span style=\"color:#f92672;\">\"value\"</span>: {\n        <span style=\"color:#f92672;\">\"address\"</span>: <span style=\"color:#e6db74;\">\"11521 N Fm 620\"</span>,\n        <span style=\"color:#f92672;\">\"country_code\"</span>: <span style=\"color:#e6db74;\">\"us\"</span>,\n        <span style=\"color:#f92672;\">\"latitude\"</span>: <span style=\"color:#ae81ff;\">30.45419</span>,\n        <span style=\"color:#f92672;\">\"locality\"</span>: <span style=\"color:#e6db74;\">\"Austin\"</span>,\n        <span style=\"color:#f92672;\">\"longitude\"</span>: <span style=\"color:#ae81ff;\">-97.8271</span>,\n        <span style=\"color:#f92672;\">\"name\"</span>: <span style=\"color:#e6db74;\">\"Starbucks\"</span>,\n        <span style=\"color:#f92672;\">\"postcode\"</span>: <span style=\"color:#e6db74;\">\"78726\"</span>,\n        <span style=\"color:#f92672;\">\"region\"</span>: <span style=\"color:#e6db74;\">\"TX\"</span>\n      }\n    }\n  ],\n  <span style=\"color:#f92672;\">\"created_at\"</span>: <span style=\"color:#e6db74;\">\"2013-11-11T14:44:25Z\"</span>,\n  <span style=\"color:#f92672;\">\"id\"</span>: <span style=\"color:#e6db74;\">\"1922259\"</span>,\n  <span style=\"color:#f92672;\">\"source\"</span>: {\n    <span style=\"color:#f92672;\">\"client_id\"</span>: <span style=\"color:#e6db74;\">\"nymmngm43jnYP2FQ4pCvXjBpT3YyfNDa\"</span>,\n    <span style=\"color:#f92672;\">\"link\"</span>: <span style=\"color:#e6db74;\">\"http://ohaiapp.net/\"</span>,\n    <span style=\"color:#f92672;\">\"name\"</span>: <span style=\"color:#e6db74;\">\"Ohai\"</span>\n  },\n  <span style=\"color:#f92672;\">\"text\"</span>: <span style=\"color:#e6db74;\">\"Working after tacos. Hoping to get some coding done with an early start to the week.\"</span>\n}\n</code></pre><p>I had originally used Ohai as a sort of private check-in journal, not intending it to be public in the way that Foursquare check-ins often are. But I\u2019ve found that after nearly 10 years, semi-private data like this can usually be public without the same kind of privacy considerations that I would have worried about at the time it was first written.</p>\n<p>So how do we get this data into Micro.blog? Micro.blog can import from a bunch of platforms, but it doesn\u2019t make sense to add support for this file format directly to Micro.blog. It\u2019s not something that most people would need. I wrote a custom script to handle this for my check-ins blog.</p>\n<p>In the script, we\u2019ll iterate over each message and look for the ones posted from Ohai, ignoring everything else. For some reason \u2014 maybe because I was offline or because of limitations in the App.net places database \u2014 not all of my messages included location information, but I still want to record the post and date because it included text I wrote about the check-in. If there is location information, we\u2019ll pass that to Micro.blog too.</p>\n<p><a href=\"https://gist.github.com/manton/50293c39b6f9c96e5e0ed19ebbff93bf\">Here\u2019s the script</a>. If you want to customize it for your own use, make sure to set the app token and blog URL.</p>\n<p>Micro.blog uses the Micropub API for creating posts. When there\u2019s location information, we\u2019ll pass a <code>checkin</code> field to store that with Micro.blog. We can then access that data from a Micro.blog theme, for example to show a map. See <a href=\"https://book.micro.blog/micropub/\">my book chapter on Micropub</a> for details on the JSON format.</p>\n<p>I had a lot of fun going through this old data and migrating it to Micro.blog so that it can be preserved. Eventually I want to have a Micro.blog-based client solution for new check-ins, starting with Sunlit for iOS, so that I don\u2019t need to keep depending on Foursquare.</p>",
        "text": "I\u2019ve used a few apps over the years for location check-ins. Gowalla, Foursquare, and Ohai, which was built on the App.net API. The Gowalla data was lost after they were acquired by Facebook. I\u2019ve continued to use Foursquare and have imported many of those check-ins to my location site manton.coffee.\nI have about a year of data from Ohai, from around 2013-2014. Before App.net shut down, I exported the data. I wanted to dust it off and import it into Micro.blog.\nThe data is stored in the App.net \u201cmessages\u201d JSON. In some cases, there is annotation data that includes the location information such as place name for the check-in and latitude/longitude.\nHere\u2019s an example of one of the check-ins, cleaned up slightly to remove fields I don\u2019t care about:\n{\n  \"annotations\": [\n    {\n      \"type\": \"net.app.ohai.location\",\n      \"value\": {\n        \"address\": \"11521 N Fm 620\",\n        \"country_code\": \"us\",\n        \"latitude\": 30.45419,\n        \"locality\": \"Austin\",\n        \"longitude\": -97.8271,\n        \"name\": \"Starbucks\",\n        \"postcode\": \"78726\",\n        \"region\": \"TX\"\n      }\n    }\n  ],\n  \"created_at\": \"2013-11-11T14:44:25Z\",\n  \"id\": \"1922259\",\n  \"source\": {\n    \"client_id\": \"nymmngm43jnYP2FQ4pCvXjBpT3YyfNDa\",\n    \"link\": \"http://ohaiapp.net/\",\n    \"name\": \"Ohai\"\n  },\n  \"text\": \"Working after tacos. Hoping to get some coding done with an early start to the week.\"\n}\nI had originally used Ohai as a sort of private check-in journal, not intending it to be public in the way that Foursquare check-ins often are. But I\u2019ve found that after nearly 10 years, semi-private data like this can usually be public without the same kind of privacy considerations that I would have worried about at the time it was first written.\nSo how do we get this data into Micro.blog? Micro.blog can import from a bunch of platforms, but it doesn\u2019t make sense to add support for this file format directly to Micro.blog. It\u2019s not something that most people would need. I wrote a custom script to handle this for my check-ins blog.\nIn the script, we\u2019ll iterate over each message and look for the ones posted from Ohai, ignoring everything else. For some reason \u2014 maybe because I was offline or because of limitations in the App.net places database \u2014 not all of my messages included location information, but I still want to record the post and date because it included text I wrote about the check-in. If there is location information, we\u2019ll pass that to Micro.blog too.\nHere\u2019s the script. If you want to customize it for your own use, make sure to set the app token and blog URL.\nMicro.blog uses the Micropub API for creating posts. When there\u2019s location information, we\u2019ll pass a checkin field to store that with Micro.blog. We can then access that data from a Micro.blog theme, for example to show a map. See my book chapter on Micropub for details on the JSON format.\nI had a lot of fun going through this old data and migrating it to Micro.blog so that it can be preserved. Eventually I want to have a Micro.blog-based client solution for new check-ins, starting with Sunlit for iOS, so that I don\u2019t need to keep depending on Foursquare."
    },
    "published": "2022-07-05T07:53:04-05:00",
    "category": [
        "Essays"
    ],
    "post-type": "article",
    "_id": "30096712",
    "_source": "12",
    "_is_read": true
}