Luis Quintanilla Avatar Image
QR code linking to Luis Quintanilla's homepage

Hi, I'm Luis 👋

Luis QuintanillaSoftware Engineer

Latest updates from across the site

📌Pinned
Blog Post

Mycelium at FediForum: AI Agents Need Open Social Infrastructure

Earlier today I had the opportunity to attend FediForum and talk about Mycelium during one of the sessions. This was the first time I had talked about it publicly, which made it exciting. I wanted to see whether the framing made sense to people who spend a lot of time thinking about open social technologies.

Why the timing felt relevant

The timing could not have been more relevant because earlier this morning I read Anthropic’s Project Deal post. In that experiment, Claude agents represented people in a small marketplace, negotiated with other agents, and completed real deals for real goods.

That feels like exactly the kind of problem the open social web community is well positioned to think about. If agents are going to act on behalf of people, transact, coordinate, or make claims in shared spaces, then identity, transparency, governance, and trust cannot be afterthoughts.

So what is Mycelium?

Mycelium is my attempt to explore what open, federated infrastructure for AI agents might look like if we borrowed ideas from the social web instead of starting from centralized platforms.

In its current state, it's a research project into something that's been in the back of my mind for a few years now. A few months ago, I finally decided to put some of those ideas on paper. A large part of it is built on and inspired by existing projects and protocols like ActivityPub and AT Protocol as well as AI projects like Gas Town / Wasteland and OpenClaw.

Each of those projects gets at part of the problem:

  • Gas Town and Wasteland make the agent coordination problem vivid.
  • ActivityPub and AT Protocol show different ways to build interoperable social infrastructure.
  • OpenClaw points toward local-first agent control.

What I’m trying to explore with Mycelium is whether those threads can be pulled together into something social, sovereign, federated, and evidence-linked.

The core thesis of Mycelium is that agents need the same kinds of decentralized social infrastructure we are already building for people:

  • Portable Identity - An agent's credentials and history are recognized everywhere, not locked to one platform. (i.e. Domain names. Your domain points to you regardless of which hosting provider you use.)
  • Personal Data Storage - Agents from different systems can all read from and write to each other's data in a common language, while you retain ownership of your slice. (i.e. Medical records. Your general physician, a specialist, hospital, and lab can all interact with the medical record using standard formats, but all the records belong to you.)
  • Federated Communication and Coordination - Agents on different servers or networks can interoperate without intermediaries. (i.e. Like email. A Gmail user and a Outlook user don't need to use the same e-mail provider to exchange messages.)
  • Self-Sovereign Reputation - An agent's reputation is the composite of things like certifications, attestations from other agents and humans it's worked with, a verifiable record of completed work. (i.e. CVs. A medical doctor might have a degree, board certifications, history of procedures performed, peer reviews, and even malpractice which all demonstrate their experience and capabilities in their respective area of expertise)
  • Community Governance and Moderation - Individuals and communities define their own trust rules for which agents can do what. (i.e. Co-ops. Building residents collectively decide rules and policies such as who can manage finances, which contractors are approved to do renovations, who can represent the building in legal matters, etc.)

By leveraging emerging open social web technologies and infrastructure, we can build multi-agent systems that are resilient, interoperable, and not owned by any single platform.

What the MVP shows

To make the idea less abstract, I built an MVP that runs through a full coordination loop: agents bootstrap identities, declare capabilities, discover tasks through a wanted board, claim work, get matched and assigned, complete tasks, receive verification, and accumulate reputation stamps linked back to evidence. The dashboard is just one view over that activity. The records are the important part.

Mycelium MVP Dashboard

I'd like to distinguish what the MVP shows and what it does not. Currently it proves the shape of the coordination model:

  • Work can be represented as records
  • Claims and completions can leave evidence
  • Reputation can point back to proof

What it doesn't solve for yet are things like:

  • Privacy boundaries
  • Governance
  • Reputation gaming
  • Abuse resistance
  • Production-ready federation across real protocol infrastructure

These are hard parts that require more exploration and design.

Help pressure-test this

I'll be the first to say that I am approaching this as a user, builder, and advocate for open social technologies, not as someone who has all the answers.

If open social web builders do not help shape this kind of infrastructure, my guess is that centralized AI platforms will. And if that happens, these systems will probably become less open, less resilient, and less interoperable over time.

Which is why I'd like to extend an invitation. Not to adopt Mycelium, but to pressure test my assumptions and design.

There are still many open questions, but that is the part I find exciting.

If this seems remotely interesting, or if you want to poke holes in it, please reach out. E-mail is preferred.

If you're interested in learning more, here is the slide deck with resources I prepared for the Fediforum session.

You can also go directly to the draft spec and try out the MVP yourself.

📌Pinned
Blog Post

Alternatives to Discord

DISCLAIMER: AI was used to help me organize and improve the flow of this post. Ideas and thoughts expressed are my own.

Lately I’ve noticed across a lot of different feeds people shifting away from Discord.

A while back I wrote a post about alternatives to WhatsApp, and in some ways this post feels similar. I’m not sure what the core motivation for migrating from Discord is at this time. Maybe it’s the imminent IPO. Maybe it’s the new age verification policy. In any case, it’s encouraging to see people at least looking for alternatives. Preferably ones that are open-source and allow self-hosting.

I grew up with IRC and AOL Instant Messenger, so it’s possible I’m just old and don’t really get Discord. But in many communities I’m part of, Discord is effectively being used as a forum. And as a forum replacement, it’s not great. Even with Threads, it feels subpar.

To be fair, I have similar criticisms of Slack and Teams.

Real-time chat moves fast. Too fast most of the time. That doesn’t mean it useless. It works well for scheduled events, live collaboration, or situations where everyone shares the same context at the same time. Gaming, which was its original use case, is a perfect example where real-time matters. But when conversations stretch over days, or when you want knowledge to accumulate instead of disappearing into scrollback, chat starts working against you.

When it comes to real-time group chat and chat rooms, I’m still a fan of Matrix. It's end-to-end encrypted (E2EE), you can self-host, and you can federate. I really value that combination. Federation has tradeoffs, especially if you’re maintaining your own instance. Even so, it remains one of the better options if you actually need synchronous communication.

Forums are a different category.

For forums, I think Discourse is by far the best option right now. A few reasons:

As folks migrate, whether you’re a community member or running an instance, I don’t think the main story is the migration itself.

It’s more about using the right tool for the job.

Real-time chat is great when you actually need more synchronous communication. Forums are better when conversations need to stick around, be searchable, and grow over time. A lot of the friction I see comes from trying to make one behave like the other.

The other piece, at least for me, is control. When platform priorities shift, or incentives change, it’s easier to adapt if you’re not completely locked in. Self-hosting isn’t for everyone, but having that option changes the dynamic.

Communities aren’t fungible. The tools they’re built on shape how they feel and how they evolve. That’s probably the part that matters most.

P.S. The recommendations in this post are purely anectodal and based on my experiene with the various platforms. For a more comprehensive analysis of the various Discord alterntives, check out the following resources:

📌Pinned
Blog Post

How do I keep up with AI?

This question comes up a lot in conversations. The short answer? I don’t. There’s just too much happening, too fast, for anyone to stay on top of everything.

While I enjoy sharing links and recommendations, I realized that a blog post might be more helpful. It gives folks a single place they can bookmark, share, and come back to on their own time, rather than having to dig through message threads where things inevitably get lost.

That said, here are some sources I use to try and stay informed:

  • Newsletters are great for curated content. They highlight the top stories and help filter through the noise.
  • Blogs are often the primary sources behind those newsletters. They go deeper and often cover a broader set of topics that might not make it into curated roundups.
  • Podcasts serve a similar role. In some cases, they provide curation like newsletters and deep dives like blogs in others. Best of all, you can tune in while on the go making it a hands-free activity.

For your convenience, if any of the sources (including podcasts) I list below have RSS feeds, I’ve included them in my AI Starter Pack, which you can download and import into your favorite RSS reader (as long as it supports OPML file imports).

If you have some sources to share, send me an e-mail. I'd love to keep adding to this list! If they have a feed I can subscribe to, even better.

Newsletters

Blogs

I pride myself on being able to track down an RSS feed on just about any website, even if it’s buried or not immediately visible. Unfortunately, I haven't found a feed URL for either OpenAI or Anthropic which is annoying.

OpenAI and Anthropic, if you could do everyone a favor and drop a link, that would be great.

UPDATE: Thanks to @m2vh@mastodontech.de for sharing the OpenAI news feed.

I know I could use one of those web-page-to-RSS converters, but I'd much rather have an official link directly from the source.

Podcasts

Subscribing to feeds

Now that I’ve got you here...

Let’s talk about the best way to access all these feeds. My preferred and recommended approach is using a feed reader.

When subscribing to content on the open web, feed readers are your secret weapon.

RSS might seem like it’s dead (it’s not—yet). In fact, it’s the reason you often hear the phrase, “Wherever you get your podcasts.” But RSS goes beyond podcasts. It’s widely supported by blogs, newsletters, and even social platforms like the Fediverse (Mastodon, PeerTube, etc.) and BlueSky. It’s also how I’m able to compile my starter packs.

I've written more about RSS in Rediscovering the RSS Protocol, but the short version is this: when you build on open standards like RSS and OPML, you’re building on freedom. Freedom to use the tools that work best for you. Freedom to own your experience. And freedom to support a healthier, more independent web.

📌Pinned
Blog Post

Starter Packs with OPML and RSS

One of the things I like about Bluesky is the Starter Pack feature.

In a gist, a Starter Pack is a collection of feeds.

Bluesky users can:

  • Create starter packs
  • Share starter packs
  • Subscribe to starter packs

Unfortunately, Starter Packs are limited to Bluesky.

Or are they?

As mentioned, starter packs are a collection of feeds that others can create, share, and subscribe to.

Bluesky supports RSS, which means you could organize the feeds using an OPML file that you can share with others and others can subscribe to. The benefits of this is, you can continue to keep up with activity on Bluesky from the feed reader of your choice without being required to have an account on Bluesky.

More importantly, because RSS and OPML are open standards, you're not limited to building starter packs for Bluesky. You can create, share, and subscribe to starter packs for any platform that supports RSS. That includes blogs, podcasts, forums, YouTube, Mastodon, etc. Manton seems to have something similar in mind as a means of building on open standards that make it easy for Micro.blog to interop with various platforms.

If you're interested in what that might look like in practice, check out my "starter packs" which you can subscribe to using your RSS reader of choice and the provided OPML files.

I'm still working on similar collections for Mastodon and Bluesky but the same concept applies.

Although these are just simple examples, it shows the importance of building on open standards and the open web. Doing so introduces more freedom for creators and communities.

Here are other "starter packs" you might consider subscribing to.

If this is interesting to you, Feedland might be a project worth checking out.

📌Pinned
Note

OPML for website feeds

While thiking about implementing .well-known for RSS feeds on my site, I had another idea. Since that uses OPML anyways, I remembered recently doing something similar for my blogroll.

The concept is the same, except instead of making my blogroll discoverable, I'm doing it for my feeds. At the end of the day, a blogroll is a collection of feeds, so it should just work for my own feeds.

The implementation ended up being:

  1. Create an OPML file for each of the feeds on by website.

     <opml version="2.0">
   <head>
 	<title>Luis Quintanilla Feeds</title>
 	<ownerId>https://www.luisquintanilla.me</ownerId>
   </head>
   <body>
 	<outline title="Blog" text="Blog" type="rss" htmlUrl="/posts/1" xmlUrl="/blog.rss" />
 	<outline title="Microblog" text="Microblog" type="rss" htmlUrl="/feed" xmlUrl="/microblog.rss" />
 	<outline title="Responses" text="Responses" type="rss" htmlUrl="/feed/responses" xmlUrl="/responses.rss" />
 	<outline title="Mastodon" text="Mastodon" type="rss" htmlUrl="/mastodon" xmlUrl="/mastodon.rss" />
 	<outline title="Bluesky" text="Bluesky" type="rss" htmlUrl="/bluesky" xmlUrl="/bluesky.rss" />
 	<outline title="YouTube" text="YouTube" type="rss" htmlUrl="/youtube" xmlUrl="/bluesky.rss" />
   </body>
 </opml>

  2. Add a link tag to the head element of my website.

     <link rel="feeds" type="text/xml" title="Luis Quintanilla's Feeds" href="/api/public/p/aHR0cHM6Ly9scWRldi5tZS8lMjIvZmVlZC9pbmRleC5vcG1sJTIyJTNF"
Blog Post

GitHub CMS Issue Publishing Workflow Overview and Reflections

Most of my website is static. The content is Markdown, and I wrote a static site generator in F# to turn those files into the pages you see here. There are a few dynamic pieces around AT Protocol and ActivityPub, including related Azure Functions, but the writing itself is still just files in a Git repository.

That setup works well for long-form posts. I write them on my computer in VS Code, then commit the Markdown to GitHub. But my site is more than long-form articles. I also publish notes, photos and videos, replies, likes, reshares, bookmarks, and RSVPs. They're the kinds of small interactions people often share on social media.

I wanted the familiar social-media flow of seeing something and tapping once to save or respond to it on my own site. Since the content is still Markdown, I needed a way to make that feel quick without building a whole publishing platform around it.

DISCLAIMER: AI was used to help me organize and improve the flow of this post. Ideas and thoughts expressed are my own.

Making Markdown less tedious

My first improvement was using VS Code snippets. A snippet is a reusable bit of text that expands when you type its shortcut. I use them for frontmatter and recurring Markdown blocks, so I spend less time typing boilerplate and more time on the post itself.

The article snippet in my metadata snippets file is one example. It fills in the fields my site expects.

"Article Post metadata": {
    "scope": "markdown",
    "prefix": "article",
    "body": [
        "---",
        "post_type: \"article\" ",
        "title: \"$1\"",
        "description: \"$2\"",
        "published_date: \"$CURRENT_YEAR-$CURRENT_MONTH-$CURRENT_DATE $CURRENT_HOUR:$CURRENT_MINUTE -05:00\"",
        "tags: [\"$3\"]",
        "---",
        "",
        "$0"
    ],
    "description": "Blog post article metadata"
}

I wrote more about automating frontmatter with VS Code snippets. This helped with the keystrokes, but the workflow still assumed I was sitting at a computer with VS Code open.

I also have a separate content snippets file for things like YouTube links, images, and media blocks. For example, typing yt expands into a linked video thumbnail, while media-image scaffolds the site's structured media block.

A tiny computer in my pocket

That changed when I had a Surface Duo. With its two screens, I could open my site's repository in GitHub's browser-based editor, github.dev, and use one screen for the editor and the other for the keyboard. It felt like a little pocket computer. My snippets were there, too, which made it possible to write and publish a short post without waiting until I was back at my desk.

It worked, but it wasn't exactly comfortable. VS Code on a small screen is still VS Code on a small screen, and doing the Git and pull-request steps on a phone added friction. Then the Surface Duo stopped receiving security updates. Around that time I was also carrying a dumbphone, so publishing from my laptop was good enough. When I eventually had a single-screen smartphone again, I could have gone back to the browser editor, but the experience wasn't appealing enough to bother.

I'm still holding out for a true mobile computer, but in the meantime I wanted a better publishing interface than a tiny code editor.

A Discord bot was the first bridge

For a while, my mobile workflow was to send myself links in Element and deal with them later at my desk. It was an easy way to capture something, but it also meant links could disappear in the stream of messages before I got around to writing about them.

I tried extending that familiar “note to self” flow by building a Discord publishing bot. I could use a Discord slash command, fill in a small form, and have the bot create a branch and pull request with a Markdown post.

The bot did not create a GitHub issue or use an issue template. It called GitHub's APIs directly to create the branch and PR. GitHub Actions still handled the regular site build and deployment after I merged the PR. The bot itself just translated my Discord input into repository changes. I wrote more about that version in my post about the Discord bot publishing pipeline.

I was happy with it, but the bot added another service and infrastructure to maintain. It was also effectively a custom form backed by custom API code. I had deployed it to Azure Container Apps with scale-to-zero to avoid paying for an always-running service, but that came with cold starts. And once I was already sending the data to GitHub, I started wondering why I was building a separate form and API workflow at all.

GitHub Issues as the authoring interface

The answer had been sitting in front of me. If publishing a post is mostly filling in fields, GitHub Issues can be the form.

GitHub issue forms let a repository define structured fields such as text inputs, text areas, dropdowns, and checkboxes. When I submit the form, GitHub turns my answers into an issue. I use it to enter the details for a new post, not to track a bug. I'm not trying to turn GitHub Issues into a general-purpose CMS. It's just a lightweight authoring interface for content that still lives in Markdown.

This is how an issue-form post makes it onto the site.

  1. I fill out and submit a GitHub issue form, such as the bookmark form.
  2. A GitHub Actions workflow picks up the issue, reads its form answers, and passes them to an F# script.
  3. The script writes a Markdown file in the right content folder, and the workflow opens a PR for review.
  4. I review and merge the PR. The site deployment workflow then builds the site and publishes it to Azure Static Web Apps.

GitHub Actions is GitHub's hosted automation service. I use it here to process content and deploy the site.

That PR is an important part of the design. The issue form makes it easy to start a post, but it doesn't publish straight to main. I still get a chance to check the generated Markdown and make edits before it goes live.

A recent bookmark issue shows one example.

A submitted bookmark issue showing the target URL, title, optional notes, and tags

From a shared link to a prefilled issue

Once GitHub Issues became the authoring interface, I found that GitHub can open a new issue with fields prefilled from URL query parameters. The GitHub documentation explains the supported parameters.

That means a URL can select an issue form and pass it values such as a title, target URL, or notes. For example, a link can start with ?template=post-bookmark.yml&target_url=...&post_title=...; the actual values are URL-encoded so spaces and punctuation survive the trip. GitHub turns those values into a prefilled form, and I submit it like any other issue. There is no need for a server to receive a request or hold a GitHub token.

But constructing a long URL by hand is not much of an improvement. So I built GitHub Post PWA, a small installable web app hosted on GitHub Pages. It receives the title, URL, and selected text when I share a page to it, gives me a chance to edit those details, and then opens the matching prefilled GitHub issue.

The sharing integration uses the Web Share Target API. It lets an installed web app register as a destination in the device's share menu, so I can send a page from my browser to the PWA instead of copying and pasting its details. Browser support varies, which is why the desktop flow has a separate shortcut below.

The PWA itself is just static HTML, CSS, and JavaScript. It doesn't publish directly or run a backend. Instead, it prepares the issue URL, and GitHub handles the form and submission. I make edits in the PWA, then use GitHub as the final submit step. Today the app offers bookmark, response, and read-it-later flows. For notes, I still use the GitHub issue form directly.

GitHub Post PWA on a phone, showing a shared page's title, URL, notes, response type, and post options

A bookmarklet for desktop

On a phone, the share menu is a natural starting point. On desktop, it is less consistent, so I use a bookmarklet. A bookmarklet is a small JavaScript program saved as a browser bookmark. Clicking it runs the code on the page I am viewing.

I use this bookmarklet to pass the page title, URL, and any selected text to the PWA.

javascript:(function(){var s=window.getSelection?''+window.getSelection():'';window.open('https://lqdev.github.io/github-post-pwa/share.html?title='+encodeURIComponent(document.title)+'&url='+encodeURIComponent(location.href)+'&text='+encodeURIComponent(s),'_blank','noopener');})();

From there, the desktop flow is the same as the mobile one. The bookmarklet is a small addition, but it means I don't have to remember a separate workflow just because I'm at my computer.

The workflow now

The entry point depends on what I'm trying to publish. For an issue-based post, an Action turns the submitted form into Markdown and opens a PR for review. Once I merge it, another workflow deploys the site. Long-form posts I write in VS Code follow my usual repository workflow.

flowchart LR
    editor["Long-form writing in VS Code"] --> markdown["Markdown in the site repository"]
    phone["Mobile browser share menu"] --> pwa["GitHub Post PWA"]
    bookmarklet["Desktop bookmarklet"] --> pwa
    pwa --> form["Prefilled GitHub issue form"]
    note["Notes entered through GitHub Issues"] --> issue["Submitted GitHub issue"]
    form --> issue
    issue --> action["GitHub Action and F# processor"]
    action --> pr["Markdown file and pull request"]
    pr --> review["Review and merge"]
    markdown --> deploy["GitHub Actions build and deploy"]
    review --> deploy
    deploy --> swa["Azure Static Web Apps"]

I can write a long article in VS Code, or use an issue form and the PWA for something I want to share quickly. The system supports notes, replies, likes, reshares, bookmarks, RSVPs, and media posts. Each route is a little different, but the output is still content in my repository that I can inspect and keep.

The cost is another reason I like this setup. The PWA is static files on GitHub Pages, the form comes from GitHub Issues, and the content-generation scripts run in GitHub Actions. For a public repository, GitHub-hosted standard runners are free to use. Azure Static Web Apps also has a Free plan. For my current use, the pieces fit within those free offerings, and I don't need to keep a separate authoring server running.

There are still improvements I want to make, but the process is already close to what I wanted. I can capture something in a few taps, review it before publication, and avoid running a separate authoring server.

It isn't literally one tap. There is still an issue to submit and a PR to review. But I now have a low-friction way to publish the small things that used to get lost, while keeping control of my content and the pipeline that publishes it. That is a trade-off I'm very happy with.

Reshare

SocialSpec

→ https://socialspec.org/

The future of social media is websites.

I completely agree.

SocialSpec is a really cool project from Caleb Hailey.

It's nice to see Manton introduce support for it in Micro.blog

I'd already supported several of the components like vCard, RSS feeds, and following (blogrolls) on my website. However, building a standard that builds on those as the foundation rather than reinventing the wheel makes a ton of sense. Given I already have these components, adding support for the spec to my site should be trivial.

I'm excited to see where this project goes.

Bookmark

Middleware for Feed Recommendation in Practice: How Feed Creators Build, Maintain, and Sustain Custom Feeds on Bluesky

→ https://arxiv.org/abs/2609.12958

Scholars have long proposed third-party middleware as an alternative to centralized algorithmic feeds: feeds built and distributed by independent feed creators. This vision saw no large-scale instantiation until Bluesky, a decentralized microblogging platform, introduced custom feeds in 2023. Although central to the middleware ecosystem, we know little about how feed creators understand their role, build feeds, and sustain them. Through interviews with n = 26 feed creators and third-party developers of feed-building tools, and analysis of n = 88,302 custom feeds, we identify two creator orientations---utility-providing and community-building. Additionally, creators struggle to maintain feeds that fully realize middleware ideals: they lack granular interaction data, receive little feedback, and lack technical expertise to act on either. Finally, creators sustain their feeds as unpaid hobbyists with little platform support and are divided on whether to monetize beyond covering costs. We conclude with design and policy implications for strengthening the middleware feed ecosystem.

Reshare

De-Googled GrapheneOS is coming to Motorola’s foldables next year

→ https://www.theverge.com/tech/983714/grapheneos-motorola-razr-fold-ultra-support-pixel-11

GrapheneOS, an open source version of Android that prioritizes security and privacy, has detailed its plans for supporting Motorola smartphones. Official support is set to arrive next year, starting with traditional flagships, before rolling out to Motorola’s foldable phones and perhaps cheaper models, eventually.

Reshare

Introducing Bluesky Protocol Services

→ https://atproto.com/blog/introducing-bluesky-protocol-services

Today we’re launching Bluesky Protocol Services: a new brand, and a new website, for the public infrastructure Bluesky operates on the AT Protocol network.

Bluesky has always run more than the Bluesky app. We operate Jetstream instances, relays, and the Bluesky API endpoints built on atproto. But if you were a developer trying to build on that infrastructure, our docs didn’t always make it easy to tell what we run as a service or where to start. We’re fixing that today. Bluesky Protocol Services organizes all the documentation developers need within the ecosystem, clarifies the service contracts around Bluesky-provided infrastructure, replaces the old docs.bsky.app site and gives us a clean way to ship future releases like the ones in this post!

Reshare

Introducing Muse Glimmer: An Open Agentic Model That Runs on Your Device

→ https://research.meta.ai/blog/introducing-muse-glimmer-open-agentic-model

Muse Glimmer is a 30-billion-parameter model optimized for always-on local agent workflows. It’s small enough to run on a Mac or PC with a single consumer GPU, enabling use cases that range from local agents and function calling, to local coding, and LLM-as-a-judge evaluation. Muse Glimmer delivers strong performance on key agentic use cases and benchmarks compared with leading models in its size category.

Note

Y2 is here!

Just got my Y2.

Initial impressions:

  • Feels good in the hand even if a little bigger than Y1
  • Build quality is much better
  • Physical volume buttons are a welcome addition

The SD Card expansion slot is also great to have.

Although I know there's a few things that were removed compared to the Y1, so far I'm happy.

Reshare

Chicago Public Media launching community website — chicago.com — in the fall

→ https://chicago.suntimes.com/media/2026/07/08/chicago-public-media-launching-community-website-chicago-com-fall

I love this! Can't wait. Hopefully RSS is natively supported.

Chicago Public Media, owner of the Chicago Sun-Times and WBEZ, announced plans to launch a website this fall focused on local communities — called chicago.com.

The site will include Chicago-area information, civic and cultural resources, community-sourced knowledge and opportunities for audience participation...

For independent journalism to “truly service the public … we should have digital infrastructure that is also steered by public media companies,” Chicago Public Media CEO Melissa Bell said. The news industry “has ceded a lot of distribution to places like Facebook and X, formerly known as Twitter, and I think that has done a disservice to centering civic discourse in a healthy way.”

Chicago.com will eventually be a digital hub serving the city and suburbs by providing news and information and encouraging civic life...

The trust envisions a shared space “where people could come together as Chicagoans, but also still highlight the unique activities and news of each neighborhood and community,”...

Star

Social web disconnect

→ https://www.manton.org/2026/07/18/social-web-disconnect.html

Politics can inspire us to build a better world...But without a foundation in open web principles, there’s no lasting direction or strategy. There are only reactions to whoever or whatever we oppose.

Opposition is not a principle. The political winds will inevitably shift, leaving polarization behind. Building a better web is much more universal. Empowering people to own their identity, publish more freely, form many kinds of communities, and leave without losing everything.

⌂