More than a year ago, I told people that ORMs like Entity Framework were going to feel like relics. That LLMs would just generate the SQL you need, making all that object-relational mapping overhead pointless. A few people told me I was crazy and doing things wrong (and to be honest I wasn't good enough at explaining why I thought this).

Well, time seems to have been on my side (Wwo is laughing now hahahaha!!).

Now, this is a hot take, so I will go forward and talk as a hot take. If I put my devil's advocate hat on, I would probably rage against whoever wrote this post. But because I LOVE MYSELF, I won't do it. I certainly see flaws in my arguments. So buckle up—this is not rage bait, it is just a hot take from a Mexican developer who spent the weekend arguing with AI agents instead of sleeping like a normal person.

The ORM Prediction, or How I Accidentally Became Right About Something

Here's the thing about ORMs: they exist because writing SQL is supposedly "hard" and "error-prone." Meanwhile, I've been writing raw SQL since my first job at a tiny shop in Tepic where we didn't have the luxury of Entity Framework or Hibernate or whatever fancy abstraction layer the cool kids were using. We just wrote the queries, crossed ourselves, and hit execute. Catholic upbringing has some unexpected engineering applications.

Now, to be fair—we did end up building our own tailored ORM for the common cases. Because once you've written the same parameterized INSERT fifteen times, even the most stubborn raw-SQL purist starts thinking "maybe I should abstract this." And ORMs do earn their keep in some areas: SQL injection prevention, enforcing parameterized queries, handling connection lifecycle stuff that nobody wants to think about. Security guardrails that your 2 AM brain will absolutely forget to implement on its own. I get it. ORMs aren't stupid—they solved real problems.

But here's the trap: as soon as you start getting into complex queries, you're no longer just maintaining your application logic—you're also maintaining the ORM and the complex queries. You end up fighting the abstraction to make it do what raw SQL does naturally, and now you have two problems instead of one. The thing that was supposed to simplify your life becomes another layer you have to debug, optimize, and keep in your head at the same time. And whoever has run a high-performance application—like an ecommerce site during Black Friday—knows exactly what I'm talking about. That query you spent weeks trying to optimize through the ORM, doing quirky reflection tricks and fighting with expression trees? You ended up raw-dogging the SQL anyway, because that was the only way to get the performance you needed. The ORM was never going to get you there. It was just standing in the way, politely.

Now Claude just writes you the exact SQL you need—parameterized, injection-safe, the whole deal. No mapping, no configuration, no surprises. Just the data access pattern you actually want. It's like having a DBA who never sleeps, never complains about schema changes, and doesn't passive-aggressively CC your manager when you write a bad join. The abstraction layer that was supposed to save us from SQL is now the thing standing between us and the AI that's better at SQL than most of us ever were.

Agentic Development and the Death of One-Size-Fits-None

This isn't just about ORMs. I've been thinking about how agentic development fundamentally changes the whole premise of general-purpose libraries and building blocks.

Platform teams across the industry are going to start questioning their investments in broad, one-size-fits-all libraries. And honestly? Good. Because "one-size-fits-all" always meant "fits nobody perfectly but everyone tolerably." Like those beach ponchos they sell at every tourist shop in Nayarit—technically covers you, technically functions, but you look ridiculous and you know it.

Take CSS frameworks. Bootstrap, Bulma, Fluent UI—they're great for getting started quickly. But you end up learning their specific class naming conventions, carrying tons of CSS you'll never use, fighting against the framework the moment you want something custom, and—my personal favorite—looking like every other Bootstrap site on the internet. Your site ends up with more unused CSS than empty beer bottles after a Sunday carne asada in Nayarit. And that's a lot of bottles, trust me.

With agentic development? You just tell the agent what you want your UI to look like. It generates exactly the CSS you need. No framework lock-in, no unused code, no learning curve. The agent doesn't need to know Bootstrap's grid system (although it probably was trained on such codebases)—it just writes "vanilla" CSS that does what you asked for. I know this because that's exactly what happened with this blog. The CSS you're looking at right now? Generated. By an agent. Who understood what I wanted better than I understood what I wanted (debatable).

MCP is Already Feeling Old

Speaking of things that are aging quickly: the Model Context Protocol. MCP. Remember when everyone was wrapping every CLI tool as an MCP server like it was the new hotness? That was, what, months ago? In AI time that's basically the Paleolithic era.

Here's the thing—CLI tools already come with perfect documentation in the form of man pages. They're basically documented APIs already. Your agent doesn't need a special protocol wrapper to use gh pr create or az webapp deploy. It just reads the docs, fumbles the first attempt (like any of us), and then figures it out. Combine Claude Code with existing CLI tools—GitHub CLI, Azure CLI, kubectl, whatever—and you've got everything MCP promised, but without the ceremony.

Microsoft's already doing something interesting with their dotnet/skills repo. Skills that are just prompts guiding the agent through repeatable processes. No protocol, no server, no serialization format drama. Just a well-written prompt. Turns out the best API for an AI agent is just... words. Who knew. (Okay, a lot of people knew. But still.)

Hugo Drove Me to Build My Own (Again, Because I Never Learn)

I just finished redoing my entire publishing workflow. Hugo felt limiting and bloated—all these features I'm maintaining, constantly broken by dependency updates, GitHub workflows failing for mysterious reasons. Every time I pushed a new post it was a coin flip whether the build would succeed or I'd spend an hour debugging some Go template issue that made me question my life choices.

So I rewrote it in .NET. Dead simple. I don't expect anyone else to use it—exclusive distribution, zero units available—but damn, it felt liberating. The CSS and HTML of this blog changed completely, and I actually understand every piece of it now. No more cargo-culting Hugo partials I copied from a theme three years ago and was afraid to touch.

This is the pattern I keep seeing: when AI can generate exactly what you need, the appeal of heavyweight, general-purpose solutions just evaporates. Like fog burning off in the morning sun in Tepic. One moment it's there, thick and omnipresent, and then it's just... gone.

The Accountability Problem

Here's something that's been bugging me. I saw a conversation on the fediverse about more and more tools being created with no clear ownership. Developers suspect some might be entirely AI-generated, with humans just shepherding them into existence like zookeepers who can't actually control the animals.

That sucks. Humans should be in charge and taking responsibility for the software they put into the world. There's a difference between using AI as a tool and letting AI be the architect while you nod along pretending you reviewed the blueprints.

When something breaks, when there's a security issue, when users need support—who's accountable? You can't file a bug report against GPT-4. And "the AI did it" is not an incident postmortem. Not yet, anyway. Give it a year (debatable).

Copilot's Infinite Loop of Self-Criticism

Speaking of AI quirks: Copilot keeps finding issues in my PRs, I ask it to fix them, it fixes them, and then when I ask it to review again, it finds more issues. In the code it just wrote. In the code. It. Just. Wrote.

This is like watching someone argue with themselves in the mirror. Except the mirror is burning tokens, the person is burning my budget, and the argument never ends. The AI equivalent of "works on my machine" syndrome, except it doesn't even work on its own machine.

Blog Posts Are Better Than Repos for Teaching AI

Here's something that genuinely surprised me. A friend at Microsoft pointed his AI agent to my blog series to implement ActivityPub. Not to a GitHub repo with code samples. Not to the official W3C spec. To my blog posts. The ones I write at 1 AM like a gremlin-raccoon, full of rambling asides and half-baked metaphors.

Turns out prose explanations with context and reasoning are way more effective for agents than just dumping code at them. Blog posts tell the story of why decisions were made, not just what the final result looks like. The agent needs to understand intent, not just syntax. It needs the narrative—the "I tried this and it broke spectacularly, so I did this other thing instead" part that never makes it into a README.

So all those years of writing meandering blog posts about my projects instead of writing proper documentation? Turns out I was ahead of my time. Or just lazy. Probably both.

Where This Is All Heading

I think we're heading toward a world where general-purpose libraries become luxury items—nice to have, but not essential. Where AI-generated, purpose-built solutions become the norm. Where documentation and prose become more important than code artifacts. And where human accountability becomes the thing that actually differentiates good software from the rest.

This doesn't mean libraries disappear overnight. But the incentives are shifting. Why build and maintain a framework used by millions when everyone can have their own custom solution?

The future might be less about sharing code and more about sharing knowledge, context, and decision-making frameworks. Less "here's my npm package" and more "here's the blog post explaining why I built it this way so your agent can do something better."

Anyway

This post is a collection of half-formed thoughts and observations. I'm not claiming to have all the answers—hell, I'm not even sure these are the right questions. But something is shifting under our feet, and pretending it isn't doesn't make it stop.

Are we heading toward a more fragmented, AI-generated software landscape? Or am I just another old developer yelling at algorithmic clouds from a small corner of the internet?

Honestly, I don't know. But I'd rather be wrong and loud about it than quiet and surprised when the whole toolchain landscape looks unrecognizable in five years.

"If there are nine people sitting at a table and a Nazi sits down, and nobody gets up, there are ten Nazis at the table." – Unknown

When people first started saying Substack had a Nazi problem, I did what most of us do. I rationalized it. I assumed they were using "Nazi" the way the internet uses it—loosely, carelessly, as a blunt rhetorical weapon. Maybe it was white supremacist adjacent content hiding behind edgy language. Maybe it was dubious newsletters with dogwhistles that linked to actual extremist groups but maintained plausible deniability.

What I did not expect was to find actual, mask-off, unambiguous Nazi content. Full-blown antisemitism. Newsletters celebrating and promoting National Socialism. Not buried in some dark corner—hosted openly, on a platform where I was also publishing my work.

If you don't believe me, go look at what was at natsoctoday1.substack.com. Or read the reporting. It's all there:

• The Atlantic: Substack Has a Nazi Problem
• The Guardian: How Substack Makes Money From Nazi Newsletters
• Engadget: Substack Accidentally Sent Push Alerts Promoting a Nazi Publication

That last one is almost darkly funny. Accidentally promoted a Nazi newsletter through push notifications. An algorithm so indifferent to the content it amplifies that it just... pushed Nazism to people's phones. Like a coupon for hate.

This reminds me of something I learned early in my career. When you build software, the defaults matter. The things a platform chooses to allow, the content it monetizes, the guardrails it refuses to install—those aren't neutral decisions. They're architectural choices. A platform that takes a cut from Nazi content isn't a free speech champion. It's a business partner.

I've thought about this the way I think about any system design problem. There's always a tradeoff. Substack made theirs: growth and "openness" over basic human decency. And look, I'm no stranger to messy tradeoffs in tech. But there's a line. And if your platform is literally making revenue from people who celebrate genocide, you've blown past that line at full speed.

So I'm out. I've backed up everything to my blog, where it always should have lived anyway. You can find me on Hachyderm.

The bar metaphor is overused, but it's overused because it's true. If a Nazi sits down at your bar and you serve them, you've made a choice. If you profit from serving them, you've made an even louder one. And I don't want to drink at that bar.

Peace.

"We reject: kings, presidents and voting. We believe in: rough consensus and running code." – David D. Clark

The Dream

When I was a young hacker—yeah, believe it or not—my dream was to find other hackers in real life and just hang out together. That's it. That was the whole dream.

It sounds modest now, but you have to understand the context. I come from a very small town in Mexico, the kind of place where internet was a luxury, Linux was a word nobody recognized, and "Windows" was mostly what you opened to let the heat out. The idea of attending a tech conference was absurd. Attending one in English? In another country? That was pure science fiction—like telling my block friends about Dragon Ball Z spoilers I'd read online, except even less believable.

But with time, and a painfully slow DSL connection, I found my people. I stumbled into the local Linux user group—fewer than ten of us in a city of thousands—and we built something from nothing. A hackerspace. Community events. Workshops with maybe a dozen attendees if we were lucky. Eventually, I found my way to national conferences and even talked at a few of them. Each one felt like a small victory, a tiny crack in the wall between where I was and where I wanted to be.

The Shot

So when the opportunity to submit a talk to FOSDEM 2026 appeared, I just shot my shot.

I did it almost by instinct, without overthinking it. FOSDEM—the Free and Open Source Software Developers' European Meeting—is one of the largest open-source conferences in the world. Thousands of developers, hundreds of talks, legendary project booths. It had always been a place that existed on the other side of a dream for me. But here's the thing: I'm more financially stable now, I've traveled to Europe for both leisure and work, and I speak comfortable (but still heavily accented) English. I've made peace with my accent—it's part of the package, take it or leave it.

So, why not? The real surprise was that I hadn't applied before.

The Logistics of Madness

When my proposed talk was accepted, my first reaction wasn't joy—it was panic. The kind of panic you feel when you push to main and then read the diff. The real problem was logistics.

I already had a trip to Mexico planned for personal reasons. Going to FOSDEM meant extending the family travel by a week, rerouting flights, and solving the kind of logistical puzzle that makes your brain hurt. Tepic, a small city in the mountains of western Mexico → Mexico City → London → Brussels. With a seven-year-old. And a month's worth of luggage packed for both the scorching Mexican beach and a freezing European winter—flip-flops sharing suitcase space with thermal jackets, sunscreen next to wool scarves. And sanity (debatable).

After my wife—bless her patience—said "just go for it," and after numerous conversations with both AI and non-AI advisors about how to make it less stressful, we committed. At the end of January, I found myself at the tiny airport of Tepic, eating the most amazing torta de pierna, beginning an absurd journey to Belgium.

We crossed through London, hopped on the Eurostar to Brussels, and somewhere between countries, we lost a pillow—a bear-shaped one my kid had shamelessly stolen from his grandma. Rest in peace, little bear pillow. You survived a Mexican grandmother's house only to perish somewhere in the English Channel.

The Candy Store

And then, there I was. At FOSDEM. With my kid. In Brussels.

The place was electric. People from every imaginable background wandered through the halls of the Université libre de Bruxelles. I'll be honest—there's still a noticeable lack of diversity, especially in gender representation—but the energy was undeniable. It felt like a living, breathing monument to what open source can be.

Seeing the project booths was like being a kid in a candy store—except I literally had a kid with me in this candy store. Mozilla, Thunderbird, Let's Encrypt, SUSE, and of course Mastodon, to name a few. I couldn't help myself; I told my son that when I was young, one of my first dreams was to work for SUSE. He listened carefully, the way seven-year-olds do when they're filing away information for later use (probably to embarrass me at dinner).

Keeping a seven-year-old entertained at a developer conference is its own extreme sport. Thankfully, a friend I hadn't seen in over a decade was there—with his kid. He's a no-gringo, a Dutchman who happens to have worked at Innox in Mexico. Our kids hit it off, and suddenly the conference had a parallel track: unsupervised children's chaos edition.

The Talk

When the time came for my talk, I walked in, set up, and delivered something far from perfect—but unmistakably mine. I stumbled on a couple of words, my accent was thick, and I'm sure I made at least one joke that only landed for me. But that's the style. That's always been the style.

Just before stepping up, Elena handed me the most fabulous FOSDEM sweater in existence. People noticed. People asked where to get one. But no—only I could have it. Exclusive distribution, zero units available. (Okay fine, I was just lucky, but let me have this moment.)

If I have one regret, it's not spending more time in other talks. It's not that I didn't try—I did—but balancing a seven-year-old's attention span with a conference schedule is a negotiation no diplomacy course prepares you for. I caught fragments, glimpses, enough to know I was missing incredible stuff. But that's the thing about FOSDEM: it's not a one-time event. I'll be back. And next time, I want to do more than speak—I want to listen, linger, and actually have those hallway conversations that everyone says are the best part of any conference.

The Kid and the Dream

Here's what got me, though. The part I didn't expect.

My kid watched me speak at FOSDEM. He didn't fully understand the content—he's seven, and ActivityPub isn't exactly bedtime story material—but he saw his dad on a stage, in front of a room full of people, in another continent, talking about something he built. When the Q&A started, he wanted to raise his hand. He got shy, though, and didn't. Later, visibly upset about his missed opportunity, he told me what he wanted to ask: "Do you play Minecraft?" In front of an auditorium full of open-source developers discussing federation protocols, my kid's burning question was about Minecraft. I love this human being more than I can express.

He asked questions the entire trip back: "What does SUSE do?" "Will you talk at another one?" "Can I have my own desk computer?"

He saw the booths, the projects, the people. He kept posing for photos with each open-source mascot like a tiny celebrity on a press tour. His favorite was the PostgreSQL elephant, though we were genuinely concerned about its health. Based on the state of that costume, I think he might be right—PostgreSQL could use your donations, folks. That elephant has seen better days.

And the trip back was no less insane than the trip there. Brussels → Iceland → Seattle. Because apparently, when you're already doing something absurd, you might as well add a layover near the Arctic Circle. We landed in Reykjavík with our beach-and-winter Frankenstein luggage, stepped outside into wind that felt personally offended by our existence, and my kid asked if the land was actually made of ice. Close enough, kid. Close enough.

A week later, during a conversation with his teacher, my son was asked about the most memorable thing from the trip. He didn't say the beach in Mexico, or the train through Europe, or the wind in Iceland, or even the lost bear pillow. He said the most memorable thing was seeing his dad talk at a university. That it made him proud (I'm not going to pretend I didn't need a moment after hearing that).

I thought about my own childhood. About the kid who couldn't find a single hacker in his town. About the dusty streets and half-built houses. About how representation works in mysterious ways—how seeing someone like you doing something impossible makes it feel possible. My son doesn't know what it's like to not see a path. For him, this is just what dad does. And maybe that's the whole point.

Full Circle

Twenty years ago, I was a teenager in a small Mexican town, writing code in paper notebooks and dreaming of a world I could barely imagine. Today, I stood in Brussels and spoke to a room full of open-source developers about a project I created.

The path from there to here wasn't straight. It was messy, full of detours, broken English, lost pillows, and more coffee than any doctor would recommend. But every step—every hackerspace meetup with eight people, every local conference talk, every late night wrestling with code—was a brick in the road that led to that stage.

And yeah, I get it, talking for half an hour at a conference with hundreds of talks may seem like a small feat. One slot among many. But it wasn't small to me. For the kid who couldn't find a single hacker in his hometown, standing in front of that room was enormous.

FOSDEM wasn't just a conference for me. It was proof that the kid from Tepic who dreamed of finding hackers in real life finally did. They were in Brussels all along, waiting for him to show up.

And he brought his kid.

Find the index and earlier parts of this series here.

Quote Posts for Static Sites: A Practical Guide to FEP-044f Implementation

Transform your static blog into a consent-respecting quote-enabled node in the fediverse. This guide shows you how to implement quote post support that works with Mastodon, GoToSocial, and other ActivityPub servers while respecting author preferences.

In this guide: You'll learn to build quote-enabled blog posts that can be responsibly shared across the fediverse

Why Quote Posts Matter (And Why They're Controversial)

The User Experience Problem

Picture this: Someone finds your blog post fascinating and wants to share it with their followers, but they also want to add their own perspective or why is important. Without quote posts, they have two unsatisfying options:

1. Simple share: Just boost with no commentary (or reply)
2. Link sharing: Add a link to the blog post in their note

Neither option creates the rich, attributed conversations that make social media engaging.

The Solution: Consent-First Quote Implementation

We're implementing FEP-044f: Consent-respecting quote posts in our federated blog.

What this means for your readers:

• They can quote your posts with confidence that you've opted in
• Their quotes include proper attribution and linking

What this means for you:

• Automatic handling of quote requests
• Future-ready for advanced moderation features (like in the fuuutuuure)

Implementation Overview

We are going to:

1. Modify the Notes JSON to assert that the notes are quotable.
2. Modify our Index function (the only dynamic POST endpoint) to handle quote requests and send the appropriate approval back (blanket approval).

1. Modifying the Notes: Enhanced ActivityPub Context

What We Changed: Extended the @context from a simple string to a rich object array supporting the GoToSocial namespace.

Before:

"@context": "https://www.w3.org/ns/activitystreams"

After:

"@context": [
  "https://www.w3.org/ns/activitystreams",
  {
    "gts": "https://gotosocial.org/ns#",
    "interactionPolicy": {"@id": "gts:interactionPolicy", "@type": "@id"},
    "canQuote": {"@id": "gts:canQuote", "@type": "@id"},
    "automaticApproval": {"@id": "gts:automaticApproval", "@type": "@id"}
  }
]

We are also adding this section at the end of the Note:

"interactionPolicy": {
  "canQuote": {
    "automaticApproval": "https://www.w3.org/ns/activitystreams#Public"
  }
}

If you want to be specific about who can quote your post, this is where you do it, read more in here.

You can see an example of the implementation in RssUtils.cs - in the GetNote method.

2: Quote Request Processing

Now we need to add the quote request handling system that processes incoming quote requests and automatically approves them based on our interaction policy.

New Components:

• QuoteRequestService: Processes incoming quote requests from the fediverse
• Auto-Approval Logic: Automatically approves public quote requests as defined in our interaction policy
• Quote Authorization: Issues authorization tokens (stamps) for approved quotes

The Quote Request Flow:

{{< mermaid >}} sequenceDiagram participant Requester as Fediverse User participant Inbox as Our Inbox participant QRS as QuoteRequestService
participant Target as Target Instance

Requester->>Inbox: QuoteRequest for our post
Inbox->>QRS: Process quote request
QRS->>QRS: Check interaction policy
QRS->>QRS: Generate authorization stamp
QRS->>Target: Send Accept + Authorization
Target->>Requester: Quote approved

{{< /mermaid >}}

Checkout the implementation in the QuoteRequestService.cs.

3: The Missing Piece - Quote Authorization Stamps

After implementing steps 1 and 2, I tried to test quotes and it seems to be working. However, although the post looked like quotes in my home instance (e.g. hachyderm.io) the same post in other instances (e.g. theforkiverse.com) was still showing as pending. This is because we're missing the QuoteAuthorization verification mechanism described in FEP-044f.

The Solution:

When we approve a quote request, we need to generate a static QuoteAuthorization file at the stamp URL that third-party instances can fetch to verify the quote is legitimate. The home instance does not need this because it relies on the original Accept handshake, but it will send an Update activity to other instances with the stamp URL. It is in that URL where we need to store our quote authorization.

Implementation:

This is very similar to the replies generation explained in part 8, where each time we receive a reply we update a collection of the note.

You can take a look at my dontnet implementation in StampsGenerator.cs.

The trick here, and something to pay attention to, is the interactingObject, interactionTarget, and attributedTo fields. This is one example:

{
  "@context": [
    "https://www.w3.org/ns/activitystreams",
    {
      "QuoteAuthorization": "https://w3id.org/fep/044f#QuoteAuthorization",
      "gts": "https://gotosocial.org/ns#",
      "interactingObject": {
        "@id": "gts:interactingObject",
        "@type": "@id"
      },
      "interactionTarget": {
        "@id": "gts:interactionTarget",
        "@type": "@id"
      }
    }
  ],
  "type": "QuoteAuthorization",
  "id": "https://maho.dev/socialweb/quotes/e7f5a28d-26d8-4c19-8bae-6d9bbb040b5e",
  "attributedTo": "https://maho.dev/@blog",
  "interactingObject": "https://theforkiverse.com/ap/users/115868408494460202/statuses/116014861405475931",
  "interactionTarget": "https://maho.dev/socialweb/notes/6078d5c5d08f3a17aca4642bba3d61f9"
}

It took me a few times to actually get it right. attributedTo and interactionTarget refer to the original quoted post, while interactingObject is the note doing the quoting (from the remote server).

I decided to go with this file structure, but you can do whatever you want—also not necessarily unique GUIDs, but maybe hashes instead:

File Structure:

your-site.com/socialweb/
├── quotes/
│   └── {guid}/          # QuoteAuthorization stamps files
└── notes/
    └── {post-id}/       # Your original posts

A clever alternative

Claire from a Mastodon dev chat suggested a clever approach in case you use dynamic endpoints: instead of storing the actual authorization, you craft it at runtime. The cleverness is that you can encode interactingObject and interactionTarget as base64 and include them as part of the URL, e.g.:

https://maho.dev/socialweb/quotes/{base64-encoded-interacting-object}/{base64-encoded-interaction-target}

Example:

• interactingObject: https://theforkiverse.com/ap/users/115868408494460202/statuses/116014861405475931
• interactionTarget: https://maho.dev/socialweb/notes/6078d5c5d08f3a17aca4642bba3d61f9

When base64-encoded and used in the URL:

https://maho.dev/socialweb/quotes/aHR0cHM6Ly90aGVmb3JraXZlcnNlLmNvbS9hcC91c2Vycy8xMTU4Njg0MDg0OTQ0NjAyMDIvc3RhdHVzZXMvMTE2MDE0ODYxNDA1NDc1OTMx/aHR0cHM6Ly9tYWhvLmRldi9zb2NpYWx3ZWIvbm90ZXMvNjA3OGQ1YzVkMDhmM2ExN2FjYTQ2NDJiYmEzZDYxZjk%3D

This approach eliminates the need for static file storage while maintaining the same verification capabilities. Your dynamic endpoint can decode the URLs and generate the QuoteAuthorization JSON on-demand. And just in case it's not obvious, this is the URL that you return as stamp ID in the QuoteAuthorization on step 2.

Key Takeaways

By implementing FEP-044f, we're not just adding quote functionality - we're building consent-respecting social interactions into the protocol level.

Why This Matters:

This implementation shows how static sites can participate in modern social web standards while keeping their simplicity and performance benefits. Right now, we're automatically allowing all public quotes, but this foundation sets us up for more granular consent controls in the future - like requiring approval for specific users or implementing follower-only quoting.

The consent-respecting approach means our content can be shared thoughtfully across the fediverse, with the infrastructure already in place to handle more sophisticated permission systems as they evolve.

Next Steps: The Quote Visualization Challenge

Now that we've successfully implemented the backend infrastructure for consent-respecting quote posts, we face an equally important question: How should we display these quotes on our website?

Treat quoted posts as special reply types? Quotes have different semantic meaning than replies - they're more like "shared with commentary" So maybe create a separate "Quoted By" section similar to how we handle likes and shares?

Any ideas?

So here I am, 3 AM, can't sleep, supposed to give a talk at FOSDEM in a few hours, and I'm pretty sure I'm getting sick after three weeks of travel. What does any rational human do in this situation? Watch 2 Broke Girls, obviously.

And holy shit, does that show feel anachronistic now.

Hipsters Don't Exist Anymore (And Other Revelations)

First off, the hipster jokes. Nobody makes hipster jokes anymore because hipsters either don't exist or became less culturally relevant than emos. Remember emos? Yeah, that's how dead hipsters are.

But it wasn't just the cultural references that felt ancient. It was the internet itself.

There's this scene where Caroline (the blonde one) takes Max's laptop to do some business stuff and stumbles upon her browser history. Not search history—browser history. And what's in there? Cat videos. A cat ringing a doorbell. A kitten doing funny stuff. She rattles off 5 or 6 different videos.

And I'm sitting there, exhausted and probably feverish, thinking: "Holy crap, that's how we used to consume content."

When Million Views Actually Meant Something

Remember when a video with a million views was a big deal? Not just numerically, but culturally? It meant millions of people actively sought that thing out. Someone told them about it—word of mouth, in real life—and they went home, opened their browser, fired up YouTube or Google, and searched for "cat ringing doorbell" or whatever.

They made a conscious choice to watch it.

That's so radically different from today it might as well be from a different species of internet.

Today, a million views means an algorithm shoved something in front of a million eyeballs. Half those people probably didn't even want to see it. They were just scrolling, trapped in the engagement machine, and the algorithm decided their attention belonged to that video for the next 30 seconds.

The Browser History Archaeological Dig

Let's talk about browser history for a second. When was the last time you checked yours? I mean really looked at it?

Back in the day? Browser history was like an archaeological dig of your curiosity. It told the story of how you discovered things, how you followed rabbit holes from one interesting thing to another. You'd see the path from "funny cat videos" to "how do cats see color" to "are cats colorblind" to "evolution of feline vision" to "why are my eyes dry" to "computer screen blue light" to "buying blue light glasses"

That was the internet. A web of curiosity, not a feed of algorithmic manipulation.

The Walled Garden Apocalypse

Today, that same cat video discovery journey happens inside TikTok or Instagram Reels or YouTube Shorts. It's all contained within one app, one ecosystem, one company's idea of what you should see next.

The browser? It's basically just a container for apps now. Gmail, Slack, whatever productivity tool your company forces you to use. The actual web—the place where you could stumble upon weird personal blogs and random forums and people's actual thoughts—that's mostly dead.

We traded the open web for engagement algorithms and dopamine slot machines.

When Sharing Was Intentional

Here's another thing that hit me during my 2 Broke Girls insomnia spiral: sharing used to require effort.

If I wanted to show you a video, I had to copy the URL, paste it in an email or IM, and send it to you. You had to click it, wait for it to load, and make the conscious decision to watch it. There was friction, and that friction meant something.

Now? I can "share" something by double-tapping it, and it gets blasted to everyone who follows me, whether they want it or not. The algorithm decides who sees it and when. There's no intentionality, no curation, no thought.

We optimized the friction out of sharing and accidentally optimized the meaning out of it too.

The Great Attention Heist

This is what really gets me: somewhere along the way, we agreed to let algorithms decide what deserves our attention. We handed over one of the most precious resources we have—our focus—to systems designed to extract maximum engagement, not deliver maximum value.

In the old internet, your attention was yours. You decided to search for something. You decided to click on a link. You decided to bookmark something for later. You were the curator of your own experience.

Now? Your attention is a commodity being traded in real-time auctions you don't even know are happening.

But Wait, It Gets Worse

The really messed up part is how normalized this has become. We act like this is just how the internet works, like it's some natural law. But it's not. It's a business model. A very specific, very recent business model that prioritizes engagement over everything else.

Quality? Doesn't matter as long as people keep scrolling. Truth? Secondary to virality. Your mental health? Not their problem. Your time? Their most valuable asset.

We're not users anymore. We're the product. And we're being sold to advertisers who want to influence our behavior.

The FOSDEM Connection (Because Why Not?)

Speaking of influencing behavior—I'm supposed to talk about social web and community building at FOSDEM in a few hours. And maybe that's the connection here. The old internet was more like open source: decentralized, community-driven, built by people who cared about the craft, not the profit.

The new internet is more like proprietary software: controlled by a few big players, optimized for their benefit, not yours, and increasingly hostile to alternatives.

Maybe that's why I'm feeling so nostalgic for browser histories and intentional sharing and cat videos that people actually searched for. It wasn't just a different internet—it was a different philosophy about how technology should work.

So What Now?

I don't have a grand solution here. I'm literally writing this at 5 AM while probably getting sick and definitely procastinating.

But maybe awareness is the first step? Maybe we can start making more intentional choices about where we spend our attention? Maybe we can support platforms and tools that respect our agency instead of exploiting it?

Or maybe I'm just being an old man yelling at algorithmic clouds.

Either way, I should probably try to get some sleep before I have to explain why social web matters to a room full of people who already know why social web matters.

At least that's one thing that hasn't changed: programmers still love stating the obvious to each other at conferences.

Update: The FOSDEM talk will be fine. Caffeine is a hell of a drug.

The Forkiverse is a deliberate experiment by the Search Engine and Hard Fork podcasts. They created a Mastodon instance for themselves and their audience with an ambitious but familiar goal: try to fix what feels broken about the internet. I joined the bandwagon quickly. I already have accounts on other instances, but the experience here felt immediately different. The feed felt fresh, curious, and genuinely fun.

There is also something quietly genius about the idea itself. Podcasts and other large content creators creating their own social platforms, where their audience can interact not just with the hosts but with each other, feels like a natural evolution. This idea has been discussed for years, but rarely tested. It worked. Within 48 hours of releasing their episode, the Forkiverse had already attracted around 2.5K new accounts. That is not just excitement is some kind of proof of demand. Of course, their audience was mostly techie, and they have thousands of followers, which makes this a low digit % conversion, but still, it is interesting.

That does not mean everything was frictionless. Almost immediately, people began debating why it is called the Forkiverse, whether it is trying to compete with the Fediverse, or whether it is creating yet another Fediverse inside the Fediverse. These questions led to discussions about identity and structure. Is the Fediverse a single social network, or is it a collection of independent social spaces connected by shared protocols? Not new discussions, but old ideas surfacing. The point is the friction.

After a few years in the fediverse, I am in the second camp. Each instance is its own social network. Federation connects them, but it does not flatten their cultures, values, or social norms.g

This brings me to a belief I have held, and often repeated, like a parrot, for a long time. We used to say that it does not really matter which instance you choose when joining the Fediverse. Pick one, get started, and move later if you want. I still think this advice is useful for lowering the barrier to entry. But I no longer think it tells the full story.

Choosing an instance matters more than we tend to admit.

I have what Mike Cue called maxifediversed. I maintain multiple accounts across different servers, mainly to test features for BadgeFed, but also to observe how each space feels. What I noticed is that the differences go far beyond software features or moderation rules. The experience itself changes.

My main account is on hachyderm.io. It feels curated and thoughtful, but it also carries a lot of political weight. My account on mastodon.social feels faster and noisier, closer to what X used to feel like, and often better suited for shitposting. The Forkiverse feels new, friendly, and optimistic. At the same time, I already see signs of people who are enthusiastic about AI and who are looking for a more mainstream experience. That energy will inevitably clash with parts of the broader Fediverse, and that tension is part of the experiment, not a failure.

If you join an instance like infosec or dotnet.social, your experience will be different from the very beginning. The first people you interact with will shape your early network. The tone of conversations, the shared references, and what feels encouraged or discouraged will influence how you participate. Those early connections matter more than we usually acknowledge.

Of course, you are still you. Over time, as you follow people across instances and build your own connections, many experiences begin to converge. You find familiar voices. You establish your rhythm. But that convergence is never complete. The instance you call home continues to shape what you see, who discovers you, and how conversations evolve.

The Forkiverse makes all of this visible because it is unfolding in real time. We are watching a community take shape, with excitement, disagreement, and inevitable growing pains. Whether or not it fixes the internet is almost beside the point. What it clearly shows is that in the Fediverse, community is not abstract.

Community matters more than algorithms. Community is what makes the Fediverse diverse and resilient. It is intentional, contextual, and deeply shaped by where you choose to belong. And there is space, even if you have too many faces.

We have a new project where we're going to build... yes, you got it—an agent. Or maybe many agents? That's exactly the question we needed to answer, and spoiler alert: the answer isn't as obvious as your last Tinder swipe.

We conducted thorough research and design sessions to determine the best approach. Here's what we found, complete with the battle scars and "oh shit" moments that came with it. I hope you can benefit from our findings without stepping on the same architectural landmines.

When building AI-powered systems, one of the fundamental architectural decisions is whether to implement a single comprehensive agent or multiple specialized agents working together. This choice significantly impacts performance, maintainability, user experience, and—let's be honest—your sanity as a developer.

But first, let's establish what we mean by an AI agent, because apparently everyone and their startup has a different definition.

What is an Agent?

In the context of AI, specifically generative AI, an agent is software that can perform actions semi-autonomously or fully autonomously based on a set of instructions and can interact using natural language. Think of it as ChatGPT that actually does things instead of just talking about doing things.

Modern AI agents are built on Large Language Models (LLMs) enhanced with function calling capabilities. This functionality allows chatbots to perform actions beyond text generation—they can execute code, interact with APIs, modify files, and integrate with external systems. What started as simple Python code execution has evolved into sophisticated systems like Model Context Protocol (MCP) servers that enable agents to interact with virtually any external service. It's like giving your chatbot hands, and sometimes those hands have hammers.

So, what exactly defines an agent? The definition is somewhat fluid (shocking, I know—tech definitions being vague), but in my view, an AI agent is software that can:

• Execute actions semi-autonomously or fully autonomously
• Follow a set of instructions or goals
• Interact using human natural language
• Make decisions based on context and feedback

This broad definition could include everything from a grammar correction tool to a comprehensive marketing assistant—the possibilities are extensive, and the marketing departments (and CEOs with quarterly "optimization" coff coff, layoffs targets) are salivating.

The key distinction in development environments like VS Code is between "Ask" mode (traditional chat) and "Agent" mode. In Ask mode, the AI can only provide suggestions and answers—it's basically a very expensive rubber duck. In Agent mode, it can automatically modify files, execute commands, and potentially burn down your codebase in a blink if not properly configured. This autonomous capability is what makes agents both powerful and potentially the reason you'll be working weekends.

What is a Multi-Agent Design?

A single agent is essentially a monolithic piece of software—one component handling all functionality. It's the AI equivalent of that one coworker who insists they can handle "everything" and usually can't.

A multi-agent system consists of multiple specialized agents communicating with each other to accomplish complex tasks. The comparison to microservices is apt here, though agents don't need to be "micro"—hence the term "multi-agent" rather than "micro-agent." Because apparently we learned nothing from the microservices hype cycle.

I researched what others in the field are saying about this. For instance, my colleague has written extensively about agent sizing, arguing that micro-agents don't make sense due to orchestration complexity, while overly large agents become difficult to manage. There should be clear principles for determining when an agent becomes too large—basically, the "you know it when you see it" approach to software architecture.

One critical limitation is function calling capacity. Agents typically become overwhelmed when dealing with more than 10-20 function calls. They start selecting inappropriate tools and their performance degrades significantly. This happens because function calling relies on tool descriptions, and it's much easier to choose between 2-3 tools than among 100 options. It's decision paralysis, but for robots.

The technical implementation compounds this problem. Since LLMs are stateless, you must pass complete function descriptions, parameters, and arguments as extensive JSON in the context window for every request. There's no magic here—the model literally reads through all available function definitions and tries to match them to your request. While companies often absorb or hide these token costs, the underlying issue remains: LLMs get cognitively overwhelmed when parsing through dozens of function options, leading to poor selection decisions. It's like having to reintroduce yourself and explain every tool in your toolbox at every meeting because your AI colleague has the memory retention of a particularly forgetful goldfish.

So Which Approach is Better?

I've built agents before, but nothing as complex as what we're planning for production. The tooling considerations alone are substantial.

According to conversations with Microsoft engineers (though this isn't officially validated, so take it with a grain of corporate salt), Microsoft deliberately chose not to create a single orchestrating agent in Copilot. Instead, in Copilot Studio, you create multiple independent specialized agents, and users select which one they want to interact with. This approach is primarily driven by UX considerations—humans are naturally wired to interact with specific experts rather than some omnipresent AI overlord who claims to know everything. It eliminates the need for complex orchestration while providing a more intuitive user experience: just create domain-specific agents and let users pick their poison.

And for a reason, the multi-agent approach has its own complexities. Drawing from my experience with monolith vs microservices (where 90% of the time the answer is "it depends," and the other 10% is "you should have asked this question six months ago"), there's a crucial difference here: agents are non-deterministic.

In microservices, you can reliably test individual units and perform integration testing to ensure predictable behavior. With agents, this becomes significantly more challenging—it's like trying to unit test a creative writing class. Microsoft engineers shared an interesting case where a single agent worked perfectly in isolation, but failed spectacularly when integrated into a multi-agent system. The orchestrating agent was inadvertently filtering out critical pieces of user request data that the specialized agent needed to function properly. It's the AI equivalent of playing telephone with important business requirements.

Trade-offs to Consider

Here's the brutal reality check you've been waiting for:

Multi-agent challenges:

• Additional observability, logging, security, and tracing complexity (because debugging one black box wasn't hard enough)
• Each agent layer adds an extra LLM call, increasing latency and cost (your AWS bill will thank you)
• Non-deterministic behavior makes testing and debugging difficult (good luck explaining this to QA)
• Orchestration complexity can introduce unexpected failure modes (surprise! Your AI just became sentient and decided to take a coffee break)

Single agent challenges:

• Function calling limitations (performance degrades beyond 10-20 functions like a smartphone after two years)
• Increased complexity in a monolithic structure (the "god object" problem, but with AI)
• Harder to maintain and update specific capabilities (changing one thing breaks three others)
• Context window limitations with extensive tool descriptions

Recap and Recommendations

After thorough research, analysis, and a few existential crises about the nature of artificial intelligence, here's what I recommend:

Choose Single Agent When:

• Your use case requires fewer than 15-20 function calls
• You need predictable, deterministic behavior (good luck with that)
• You're building a focused, domain-specific solution
• You want to minimize latency and cost
• Your team has limited experience with agent orchestration
• You value your sleep and mental health

Choose Multi-Agent When:

• You need to handle diverse, complex workflows that exceed function calling limits
• You have distinct domains that require specialized expertise
• You can afford the additional complexity and cost (both financial and psychological)
• You have robust observability and testing infrastructure
• User experience benefits from specialized interactions
• You enjoy debugging distributed systems with non-deterministic behavior

Key Takeaways

1. Start Simple: Begin with a single agent and evolve to multi-agent only when you hit clear limitations. It's easier to split than to merge, unlike your last relationship.

2. Function Limits Matter: The 10-20 function calling threshold is real and impacts performance significantly. Respect the limit, or the limit will disrespect you.

3. Non-deterministic Nature: Unlike microservices, agents require different testing and debugging approaches. Traditional testing strategies go out the window faster than your productivity after discovering TikTok.

4. Cost Considerations: Each agent layer adds LLM calls—budget accordingly. Your CFO will either love you or hate you, probably both.

5. Orchestration is Hard: Multi-agent coordination introduces complex failure modes that would make a Byzantine general weep.

The decision ultimately depends on your specific requirements, team capabilities, and tolerance for complexity. Like the microservices debate, there's no universal answer—but understanding these trade-offs will help you make an informed choice instead of a panicked one at 2 AM when everything's on fire.

Remember: you can always start with a single agent and refactor to multi-agent as your requirements evolve. This is what we are going to do. The key is building with future flexibility in mind while avoiding premature optimization. Because the only thing worse than over-engineering is under-engineering and then frantically re-engineering when your simple solution becomes the bottleneck for your entire product.

Choose wisely, debug extensively, and may the odds of deterministic behavior be ever in your favor.

From Toy to Framework

At some point, every developer has this moment: you start with a couple of scripts. Some command-line helpers. Then you add a CLI. Then some templates. A half-baked web UI I slapped on top.

At some point, it crossed that invisible line. Suddenly, it’s not “my random collection of hacks” anymore. It’s a framework. That’s exactly how VocalCat was born.

Originally, it was just a suite of tiny automations I needed for my own social media workflow. Over time, it became more than a toy, more than a set of tools—closer to a fully fleshed-out side project.

Naming Things Is Hard (And Fun)

When it got serious, it needed a name. I bought a couple of domains—vocalfox and vocalcat—and even entertained names like we-eat-cats and a-whisker-wave (don’t ask).

I leaned toward vocalcat because it felt quirky but memorable. And since I was already building in public, I started posting about logo ideas, naming debates, and the messy in-between decisions most people never share.

Building in Public, But Also… Ego

Here’s the honest bit.

For a while, I wanted VocalCat to be mine. My little Frankenstein. My secret sauce. The thing that worked because I built it. That’s ego.

I wanted VocalCat to succeed quietly—like some secret sauce I had all to myself. Again, that’s ego talking.

But at the same time, I’ve always been an open-source person at heart. And ego doesn’t scale. Ego doesn’t invite collaboration. Ego doesn’t let people build with you. Reconciling those two instincts—“keep it private” vs “throw it to the wild”—was the tension that pushed me to make a choice.

So I asked myself: what’s the actual value? Keeping it locked away? Or putting it out there so anyone can learn, break it, improve it, or even fork it?

The answer was obvious.

What’s the Real Value?

The real value wasn’t in hoarding the code. It was in:

• Dogfooding my own workflow
• Rejecting pointless automation (no generic AI spam here)
• Focusing on creators, not faceless content farms

If VocalCat helps even one small creator publish work with intention instead of noise, then it’s already successful.

VocalCat didn’t appear fully formed. It evolved.

First it automated the boring parts of my own workflow.

Then it grew a web interface.

Then I bolted on publishing across platforms.

And recently? I turned it into an MCP server.

That means you can publish to all your socials straight from your editor—say, VS Code—or even from Copilot itself. No detour, no extra UI, just “write → ship.”

This isn’t vaporware. It works because I’ve been dogfooding it every day.

Customer Zeros, You Rock

The best part of this journey has been my “customer zeros.”

The early folks who were willing to try something half-finished. Who gave me unfiltered feedback. Who didn’t care that the docs were rough or that the logo was a cat I drew in five minutes.

Tools like Make or Honeybee made this easier to stitch together—but it’s the humans at the other end who shaped it into more than a toy.

Without them, VocalCat would still be a bunch of lonely scripts on my machine.

A Saturated Market of Alternatives

Now, let’s be real for a second: the social media tooling space is brutally saturated.

My “market research” (read: late-night Googling) turned up plenty. There are dozens—if not hundreds—of tools promising to “automate everything,” “maximize engagement,” or “10x your content pipeline.”

And honestly? They’re great. If you want bulk uploads, AI-generated captions, and auto-scheduling across a thousand accounts, you’re spoiled for choice.

But that’s not what gets me out of bed in the morning.

VocalCat is for the scrappy individuals like me who wants something more thoughtful. But mainly, VocalCat is for creators who want something a little more deliberate. Less noise. More intent.

Why Open Source?

Because that’s where it belongs.

I don’t want to build another walled garden. I want to build something transparent, trustworthy, and communal. Open source lets anyone inspect it, contribute to it, or just learn from it.

And more importantly: open source keeps me honest. If the code sucks, you’ll see it. If the design is smart, you’ll see that too.

The truth is, VocalCat isn’t a billion-dollar SaaS. It’s a passion project. And passion projects thrive in the open.

What’s Next?

Honestly? I don’t know.

I’ve taken it from scripts to suite, from private toy to public project, and from ego trip to open source. At the end, VocalCat isn’t trying to be the everything-tool for everyone. It’s not about “growth hacking” or “maximizing engagement.”

It’s about creators making work that matters. And open source is the only way that vision makes sense—because the internet needs more shared tools and fewer walled gardens.

What’s next should come from the community. Maybe someone will add integrations I never imagined. Maybe the project will die and will be back to my personal tool. Maybe someone will fork it into something I couldn’t dream up. Maybe it’ll stay small but useful.

That’s the beauty of putting it out there: the story doesn’t just belong to me anymore.

So that is why VocalCat is now open. The code, the vision, the rough edges. What happens next—I hope you’ll help decide.

"The factory of the future will have only two employees, a man and a dog. The man will be there to feed the dog. The dog will be there to keep the man from touching the equipment." – Warren G. Bennis

The first piece of software I ever sold was to a local hardware store.

I can still remember the smell of that place: a mix of sawdust, metal, and paint thinner. Their inventory was a glorious, chaotic mess, tracked on paper and by the owner's memory. He needed a better way.

So, we (me and a high-school friend) built him one. A simple CRUD app in Visual FoxPro. It wasn't pretty. It probably had more bugs than a summer night the beach of San Blas, Mexico. But it worked. Seeing the owner use it for the first time, seeing his relief as he could finally track his nuts, bolts, and screws—was a revelation. I had taken a real-world problem and solved it with nothing but a keyboard and my brain.

That feeling is why I fell in love with coding. It’s a mix of craft, art, and mastery.

And it’s that feeling that has me thinking about our future.

Then, a few weeks ago, I stumbled upon a mesmerizing ASMR video of a master woodworker making tiles. This guy wasn’t just making tiles; he was conducting a symphony of efficiency. He felled a tree, milled the wood, and meticulously shaped each piece, transforming raw timber into a perfect stack. Every movement was precise, honed by years of practice to maximize his materials and work with incredible speed.

I saw myself in him. I saw that kid in the hardware store, wrestling with Visual FoxPro. It was the same spark.

That video was a lightbulb moment. One day, coding by hand with nothing but a reference book will be seen just like that—a beautiful craft, a hobby, maybe even a performance art. But building commercial apps? That’s going to be a different beast entirely, just like manufacturing tiles is different from that woodworker's art. The designers and builders will still be essential, but their jobs will be unrecognizable. The skills they need will have shifted dramatically.

Carpentry wasn't eliminated, just as grocery cashiers haven't completely disappeared. But their jobs have evolved. Cashiers now often manage inventory, handle customer relations, and even recognize theft patterns. Woodworkers now need to understand industrial design, LEAN techniques, and how to operate sophisticated equipment. The fundamentals remain, knowledge of wood, materials, and problem-solving, just as software engineering will always require a grasp of its core principles.

There will always be a human in the loop. But this human is not just a passive observer, like the man watching the dog. They will be a master of system design, a strategic thinker with a deeper understanding of the entire process. AI will augment their capabilities, not replace them.

The whole "Gen-AI will replace coders" panic feels like déjà vu. Remember 15 years ago? Every car manufacturer and hotshot startup was promising fully autonomous driving in 3-5 years. Sound familiar? It’s the same breathless hype we’re hearing from some AI CEOs today, talking about replacing coders in six months or a "single-digit number of years." Well, 15 years later, Waymo is still getting stumped by a chaotic street protest. The auto industry was absolutely disrupted—we got amazing cruise control and semi-autonomous features out of it—but it wasn't the total revolution we were sold. The software engineering industry has been disrupted too, but it's going to need a human in the driver's seat for many years to come.

The question is, what kind of humans will be needed? It's time to prepare and upskill in the areas that will position you to be the one who matters.

As for me, I imagine a future where we look back at coders who worked without Gen-AI, using only a reference manual, as artisans. Perhaps they’ll have YouTube channels, and people will watch in awe as they create a fun application without a search engine or a copilot. It will be a fascinating glimpse into a lost art.

And maybe, just maybe, some kid will be in a local shop, see a problem, and feel that same spark I did in that hardware store all those years ago.

However, because Satya and others were constantly giving demos and mentioning MCP every few seconds, this was one of the most visited booths. I got my fair share of people.

I didn't think I needed to do yet another blog post about MCP, after all, there are already hundreds of resources out there, but in the spirit of recollection, here are the most common questions I got this week. I hope some people find it useful.

What is MCP?

The most common question I received was either, "What is MCP?" or, "I think I understand MCP, but I want to confirm."

I first answered as an analogy:

• Analogy: MCP is a spec/protocol that allows agents to perform actions outside their realm of "thinking." Think of it like adding skills to Alexa: by default, Alexa can answer questions, but to control your Samsung oven, you need to add a skill. Similarly, MCP lets agents do more by exposing new capabilities.

Then I used to get:

But WHAT is MCP? Is MCP like HTTP? Is it an app? A layer?

• Technical: MCP is a protocol—a specification for communication between agents. It's not a network protocol like HTTP or FTP, but more like ATProto (behind Bluesky) or ActivityPub (behind the Fediverse). In remote scenarios, MCP runs over HTTP (ports 80, 443, etc.), using endpoints like /sse and /message, and defines how to expose tools, resources, receive messages, and manage sessions.

People seems to get confused by the word protocol, so I reiterated that it was not a network protocol.

How it works?

You implement an MCP server that exposes tools (APIs, functions, or resources) and follows the MCP protocol for message exchange. MCP defines a standard way for agents (like AI assistants or bots) to communicate and perform actions. Agents connect to your server, discover available tools, and send or receive messages using the defined endpoints. Sessions are maintained (often via Server-Sent Events for remote servers), and agents can poll or stream updates. An MCP client can, for example, ping at regular intervals to retrieve new tools.

It can work in two ways—local or remote—but the specification and the way to expose tools (APIs, functions, prompts, or resources) are the same: the MCP protocol for message exchange.

How much does MCP cost? How can I enable it in my Azure Portal?

MCP does not cost anything. It's an open specification—anyone can implement it, either as a client or a server. There is nothing to enable in the Azure Portal (one customer even asked me to look for MCP there); instead, you host an MCP server yourself, such as in a Web App, HTTP service, or Azure Functions.

How can I bring my whole legacy data or 100 tables of databases to MCP?

You don't.

Before jumping to answer this question (or similar ones), I drill down into the why. What is the purpose? In MCP, like any other tool (GraphQL, BigData, OpenAPI, etc.), it is just one more tool. What you really need to define—and this depends on your scenario—are questions like: Who is the consumer? How are you limiting data to certain parts? Are they only reading or writing? How fast do you need it? How are you partitioning? What level of granularity do you want to expose (entire tables, specific queries, or business operations)? How will you handle data privacy and compliance requirements? What monitoring or auditing will you need for agent access to your data?

You don't need to expose your entire database. Instead, you create MCP tools that wrap the specific actions or queries you want agents to perform (e.g., “GetCustomerById" or “ListOrders"). MCP is about exposing capabilities, not raw data.

Bringing the data is fairly straightforward, but we should think on the why before jumping to the solution. I expect tools like Microsoft Fabric to provide MCP servers soon, so hopefully this part is solved.

How can I do (X) type of authentication?

MCP itself doesn't mandate a specific authentication method. You can use standard HTTP authentication mechanisms (OAuth, API keys, JWT, user/password, Microsoft Entra, etc.) at your endpoints. If you're using an existing Agent MCP client (like VSCode, Cursor, Copilot Connectors), you're limited to the auth mechanisms it supports. For custom scenarios, you can handle authentication externally and pass tokens to your local MCP server.

I often used extreme examples to illustrate this. For instance, if you needed a unique authentication mechanism—say, verifying a user by having them dance and sing on video—you would handle that authentication externally in your own app. After validating the user, you would store the resulting tokens and pass them to your local MCP server.

I compared this to how az login (the Azure CLI utility) works: it opens a browser for authentication, stores credentials locally, and then uses them to connect to Azure. Similarly, your local MCP server can manage custom authentication, store tokens, and allow tools like VSCode to use those tokens for access. This is essentially how the Azure MCP server operates.

While this approach can be cumbersome—since it may require users to install software locally—solutions like Docker have helped streamline the process. In the future, I expect VSCode and other agentic clients to offer more integrated authentication options. You could even create a VSCode extension for your custom authentication method and pass the tokens into the configuration's $input field.

How can I be the official MCP server for X?

There's no central registry for “official" MCP servers, but you can list your server at the official server list for visibility. Discovery is organic and depends on each MCP client implementation. In the future, agent platforms (e.g Copilot Studio) may have their own directories or marketplaces.

What is the difference between OpenAPI (or REST API, or SOAP, etc.) and MCP? Why can't I just use OpenAPI?

Sure you can. You can expose OpenAPI schemas to agents, and many people do this to enable agent actions. However, MCP is fundamentally different and simpler, representing a new paradigm.

OpenAPI describes REST APIs for both humans and machines, but it doesn't define how agents should dynamically discover, interact with, or invoke tools. MCP, on the other hand, is purpose-built for agent-to-agent or agent-to-tool communication, with conventions for discovery, invocation, and session management. While OpenAPI is focused on CRUD operations and endpoint definitions (and most of the time single stateless requests), MCP is more intent-driven—its tools are designed to map directly to user intents rather than just exposing low-level endpoints.

In few words, OpenAPI is schema-first and stateless, while MCP is intent-first and session-aware.

For example, in a typical REST API for an e-commerce scenario, you might need to call several endpoints to complete a checkout (e.g., GET /products, GET /product/{id}, POST /cart, PUT /cart/checkout). In MCP, you could expose a single tool like addProductToCartAndCheckout, which encapsulates the entire user intent in one action. This makes MCP tools more aligned with how agents interpret and fulfill user requests.

In practice, I've added C# annotations to an existing HTTP REST API and was able to expose both REST and MCP interfaces from the same service, serving different types of clients. However, to get the most out of MCP, you should design your tools thoughtfully; just as you wouldn't map business entities 1:1 to database tables or REST endpoints, you shouldn't map every REST endpoint directly to an MCP tool. The goal is to expose meaningful capabilities that match user or agent intents.

Can I use MCP to communicate between Agent-to-Agent?

Absolutely. MCP is designed to support agent-to-agent communication. For example, you could have one agent dedicated to handling CRM-related intents (such as Salesforce requests). This agent might expose a single MCP tool (like "CRM handler"), which receives natural language requests from other agents. The CRM agent then uses MCP to communicate with the underlying Salesforce MCP server and fulfill the request. Because MCP is a protocol and specification, you can extend it to fit custom scenarios and workflows, enabling flexible agent-to-agent interactions.

How does an agent know which MCP tool to call?

I don't have insights over how internally VSCode or other MCP clients handle that call. Of course, if you implement your own MCP client you would have complete control over it. What I know is that description is super important. It is a shame, that you cannot provide few-shots to VSCode yet, or other tools to make it more deterministic. I could think in 3 strategies of how to route calls:

1. NLP, tokenizing, using utterances and trying to detect the user intent. Not different that how LUIS and bot framework use todo it.
2. Vector embeddings, storing the MCP tools in a vector embeddings database, and finding the closest one to the user request.
3. LLM matching, asking to an LLM to find the closest match (which is at the end an expensive modification of vector embeddings).

Customers and people seems to try to find to make it more deterministic.

Where do I start?

We shared this repo as the holy grail of MCP and recommend looking at the sample implementations. Try exposing a simple tool (like a “hello world" function) as an MCP server, then connect an agent to it. Don't be misled by the name "beginners" in the title, "mcp-for-beginners" repo is comprehensive, covering everything from the basics to advanced concepts and early insights from real-world implementation.

Is it good to invest in MCP for my company?

If you want to make your services accessible to AI agents or participate in the growing ecosystem of agent-based automation, MCP is a good investment. It's open, flexible, and designed for interoperability. Early adoption can be advantageous.

How do I distribute my MCP server to users/developers/customers? How can they find me?

You can publish your MCP server's endpoint and documentation on your website, developer portal, or relevant directories. As the ecosystem grows, more discovery mechanisms will emerge (like registries or marketplaces). For now, clear documentation and outreach are key. Some share configuration files (like mcp.json for VSCode) directly with developers (I don't recommend this).

Anthropic is actively collaborating on the development of an official MCP Registry, as outlined in the MCP roadmap. This registry aims to provide a centralized directory for MCP servers, making it easier for agents and developers to discover, register, and connect to available MCP endpoints. While this would allow to have private registries, or it will be only a public one, I don't know.

Final thoughts

MCP isn't complicated, but it does require intentional design. The key is to focus on exposing meaningful capabilities, not just raw data or low-level endpoints. Think in terms of what an agent should be able to do, not just what your API can do.

The ecosystem is evolving fast. What feels like a hack today might be a best practice tomorrow. We're already seeing early patterns emerge, like wrapping business operations as tools, using MCP for agent-to-agent orchestration, and integrating with developer environments like VSCode.

Experimentation isn't just encouraged—it's essential. Try building a small MCP server, wire it up to an agent, and see what happens. You'll learn more in a weekend of tinkering than in a week of reading docs. There is no better way to understand and click with MCP than by experimenting with it hands-on.

And if you're still unsure where to start, just remember: “hello world" (or better, "water my plants!") is a valid MCP tool.

If you have more questions or want to jam on ideas, reach out. I'd love to hear what you're building.

Why MCP?

MCP is an open standard that simplifies connecting AI models to external tools and data systems. In plain terms, MCP is a way to give "hands" to copilots—a protocol that lets AI models not just answer questions, but actually take actions, even in the real world. Imagine connecting your copilot to your IoT devices, so it can control things in your home or office. It's a bit dangerous, but incredibly exciting: suddenly, copilots can do more than just talk—they can act.

For VocalCat, integrating MCP meant enabling seamless interaction between APIs designed to control and create content for social media. A simple example of how MCP can help is when I'm coding and want to share small pieces of advice or tricks. Often, I get so focused on coding that I forget to document or share these insights. With MCP, I could automate this process—perhaps by creating a tool that captures my thoughts as I code and formats them into a blog post draft.

In fact, this very blog post is a good example of how MCP can streamline workflows.

Reusing an Existing API

One of the most exciting aspects of this integration was reusing the existing ApiController API, which was built using ASP.NET Core. This API was meant to use in the traditional way, for our partner MeetNearMe. Instead of creating a new API from scratch, I added MCP annotations to the existing endpoints. This approach saved time and ensured consistency across the platform.

Here's an example of how I annotated an existing endpoint:

[McpServerTool, Description("Get social accounts for the user from VocalCat")]
[HttpGet("socials")]
public async Task<IActionResult> GetSocials()
{
    if (userId == null)
    {
        // Handle missing user ID
    }
    // Existing logic...
}

By adding the [McpServerTool] attribute, the endpoint became MCP-compatible without requiring significant changes to its core functionality. This approach contrasts with many MCP examples, which often involve creating new classes solely for MCP integration. It's worth noting that this codebase, running on a single Azure Web App, efficiently handles the frontend and backend (Blazor), API, and now MCP, all within a unified architecture.

Handling Authentication with MCP

Authentication was a critical part of the integration. In MCP, sessions are long-lived, especially in Server-Sent Events (SSE) scenarios. This required a different approach to handling HttpContext.

Instead of using the HttpContext available in ControllerBase, I injected it via Dependency Injection (DI). This ensured that the HttpContext was consistent across the entire session.

Here's how I implemented it:

private readonly IHttpContextAccessor _httpContextAccessor;

public MeetAuthController(IConfiguration configuration, IDbService dbService, IBlobService blobService, CreateContentService createContentService, IHttpContextAccessor httpContextAccessor)
{
    _configuration = configuration;
    _dbService = dbService;
    _blobService = blobService;
    _createContentService = createContentService;
    _httpContextAccessor = httpContextAccessor;
}

private async Task<string?> ValidateAndRetrieveUserId()
{
    var accessCode = _httpContextAccessor.HttpContext?.Request.Headers["X-AccessCode"];
    
    // Validation logic...
}

This approach ensured that the authentication logic was robust and compatible with MCP's requirements.

Integrating APIs and MCP in a Blazor App

One of the unique aspects of this Blazor app is how it seamlessly integrates APIs and MCP. The Program.cs file demonstrates how the app maps different functionalities, including traditional APIs and MCP endpoints.

Mapping APIs

The app uses MapGroup to organize API endpoints under a common route. For example, all API endpoints are grouped under /api:

app.MapGroup("/api").MapControllers();

This approach keeps the API routes clean and organized, making it easier to manage and scale.

Mapping MCP

In addition to traditional APIs, the app integrates MCP using the MapMcp method. This maps all MCP-related endpoints under the /mcp route:

app.MapMcp("mcp");

By combining these two approaches, the app supports both standard API interactions and advanced MCP functionalities.

This dual mapping strategy highlights the flexibility of the app. It allows developers to leverage the strengths of both traditional APIs and MCP, enabling seamless integration with external tools and AI-powered systems.

Tips and Tricks

1. Leverage Existing Tools

If you're integrating MCP into an existing project, look for opportunities to reuse existing APIs and services. Adding MCP annotations is often enough to make your endpoints compatible and avoid duplicating code.

2. Understand SSE

Server-Sent Events (SSE) play a crucial role in MCP. Unlike traditional HTTP requests, SSE sessions are persistent and require careful resource management, particularly with HttpContext. Injecting HttpContext via Dependency Injection (DI) ensures consistency and avoids potential issues during long-lived sessions.

MCP primarily operates through two endpoints: /message and /sse. The /message endpoint handles messages sent by the MCP server, while the /sse endpoint receives messages from the copilot.

3. Debugging MCP

Debugging MCP integrations can be tricky. Enable detailed logging in your application to capture MCP-specific errors.

4. Secure Your Endpoints

MCP endpoints often expose sensitive data. Use authentication and authorization mechanisms to ensure that only authorized users can access your APIs.

Conclusion

Integrating MCP into VocalCat was a rewarding experience. By reusing existing APIs and adopting best practices, I was able to bring MCP closer to production with minimal effort. If you're considering MCP for your project, I hope this guide provides valuable insights and inspiration.

Have questions or want to share your own MCP integration story? Let me know in the comments or in my socials!

Integrating static sites into this ecosystem via the ActivityPub protocol presents unique challenges and opportunities. In this post, I share recent updates and discoveries from my journey to seamlessly connect static sites to the Fediverse.

Enhancing Content Delivery with Customizable Templates

One of the primary goals in integrating static sites with ActivityPub is to ensure that content is delivered effectively within the Fediverse. To achieve this, I've introduced customizable templates for note generation. This enhancement allows the full content of a blog post to be included directly in ActivityPub notes, moving beyond mere link sharing—a practice often associated with bots—and leveraging the full potential of the Fediverse.

This approach ensures that followers can read and engage with complete articles within their preferred platforms, without the need to open a new browser, enhancing the user experience and fostering deeper connections.

Navigating Signed Requests in ActivityPub Implementations

During this integration journey, I encountered instances where certain servers require signed requests to retrieve author information. Starting for my instance hachyderm.io. This necessitated updates to the AuthorHelper component to handle such scenarios.

The implementation involves constructing a string to sign, incorporating elements like the request target, host, and date. This string is then signed using RSA-SHA256, and the resulting signature is included in the HTTP header. This process ensures that requests are authenticated and trusted by servers requiring signed interactions.

Disclaimer: This post also serves as a test for some of these recent changes. LOL so if you see it like weird is because of that

For a comprehensive guide on implementing ActivityPub in static sites, refer to my earlier series:

• A Guide to Implementing ActivityPub in a Static Site (or Any Website) - Part 1

I code to relax. Some people do yoga, some meditate—I open VS Code at 11 PM like a gremlin-raccoon. Don't judge.

I work full-time at Microsoft, and between family time and my other hobbies, I somehow keep starting new side projects. I've got VocalCat, an AI interviewer for SOMOS.tech, some fediverse experiments, and a Mastodon fork where I play with identity and static blog integrations. And last night, against all common sense, I started another one.

I couldn't help it. The itch was too strong. I spent hours before sleeping, just thinking about the implementation, and suddenly, I blacked out and woke up at 1 AM with a new repo and a half-baked ActivityPub prototype in .NET.

Now, if you know the fediverse, you know that Microsoft isn't exactly its favorite company, and for a reason. If you are not in the fediverse, you should know that Microsoft is one of the less "appreciated" companies there, and with reason. The Microsoft of 20 years ago is not the same as today. I am proud to work at the Microsoft of today, but I don't blame someone who has reservations about it. I would probably have them as well if I hadn't seen things from the inside. Still, using .NET for an ActivityPub project is basically me speedrunning how fast I can get ignored by the community. Whatever. I was on a mission.

So, I did what any reasonable person would do: I called in the AI reinforcements. Copilot, Claude, ChatGPT, GitHub Copilot, you name it—I use them all like a chaotic symphony of artificial intelligence. Planning travel, reformatting documents, fixing grammar, mainly coding. Sometimes I get better answers by just asking directly to ChatGPT, sometimes I use the inline GitHub Copilot, sometimes the Cursor IDE. And if you're about to tell me “Did you try X prompt?” in the comments—don't. I know what I'm doing (most of the time).

Anyway, I asked Copilot for some help cleaning up my prototype, and the response made me look like a complete clown.

It regurgitated my own shitty code.

I mean, not just similar code—my code. My messy magic strings, my lazy namespace choices, my shortcuts, my missing activitypub implementations. I hadn't even used Copilot for the first implementation. But it was open-sourced, got slurped into some LLM training set, and now it was getting thrown back at me like a loogie that missed its target.

So now, I'm sitting here with two conflicting emotions:

1. Pride – I made it. My code is out there, influencing AI. I am immortal (in the most insignificant, background-noise kind of way).
2. Existential crisis – If the AI is just regurgitating my own mess, how the hell am I supposed to trust it to know better than me?!

Look, I don't blindly trust AI, but I do check its suggestions. And I hate to admit it, but often it is right. Many times, I've grumbled and copy-pasted its fix because it was better than my first draft. But sometimes? Sometimes it's just like getting code reviews from an overly confident junior engineer who barely skimmed the requirements.

Moral of the story? AI copilots are cool, but they are not wizards. They're just fancy autocomplete with an attitude. The Agile Manifesto says “Individuals and interactions over processes and tools,” and damn, was that reinforced for me today. AI is a tool.

So, yeah. Trust your instincts, use AI wisely, and if your own garbage code comes back to haunt you—well, congratulations, you've contributed to the collective digital chaos.

A friend just landed a job after a long hiatus. The very next day, I asked him if he'd been fired yet. I know, I'm mean, but with my close friends, this is how we communicate. Don't judge.

He laughed (Narrator: in fact he did not) and then, for the bazillionth time, told me how nice it must be working at Microsoft. "You guys have all the processes, all the resources. Everything just works!"

Bro.

I spent almost 15 years working in "the third world" before Microsoft, and let me tell you—some of the development processes we had back then were better than what I see today at a trillion-dollar company. Money and expertise don't automatically solve scaling challenges. It's easier to implement great dynamics in a 20-person startup than in a massive corporation with legacy systems, layers of approvals, and a decision-making process that sometimes feels like a UN summit.

Now, don't get me wrong, Microsoft is an incredible company. But the idea that every team runs like a well-oiled machine? Yeah, no. The reality is more like a massive airport: some gates are efficient, others make you question the meaning of life while waiting for baggage claim.

And speaking of processes, my friend then went off about how his company manages risks. Apparently, they… don't. At all. (Yikes.)

But here's the thing—I don't believe risk management, planning, estimation, or any software development process should be rigidly standardized. A napkin with risks scribbled in coffee stains? Sometimes that's all you need. The right process is the one that fits the context. My friend should have just observed for a few weeks before making recommendations. Instead, he came in on day two ready to change the world. Rookie mistake.

That's when I thought, "Man, I need to write about Agile again."

Because Agile—real Agile, not the bloated, over-processed, meeting-heavy nonsense some companies call Agile—is one of the greatest things to happen in software development. Maybe even the greatest. It wasn't "created" so much as it was documented, an aspirational state that too many teams have somehow managed to turn into a bureaucratic nightmare.

But first, let's be clear: SCRUM IS NOT AGILE. Agile is not a process or a set of processes, it is a mindset, a philosophy, a set of values and principles that guide how we work and interact.

So, let's revisit the core Agile values, shall we?

1. Individuals and interactions over processes and tools.
2. Working software over comprehensive documentation.
3. Customer collaboration over contract negotiation.
4. Responding to change over following a plan.

Think about it—what really matters? Having a process for communication, or actual communication? Working software, or a beautiful 200-page requirements doc that nobody reads? A solid plan for managing risks, or actually mitigating risks in real-time?

It's like a restaurant. You don't care how the kitchen is managed, what inventory system they use, or whether their supply chain is AI-powered—you just want good food, served on time, and not poisoned. Michelin-star restaurants have meticulous processes, sure, but at the end of the day, the result is what matters.

So next time you're drowning in meetings about processes, ask yourself:

• Is it working?
• If not, is more process really the solution?
• Or is it actually about the people, the team dynamics, and the way we collaborate?

Think about it. And stay tuned—I'll be writing more into these Agile values soon.

Take care. And share this with only friend in need.

Dear Leaders of Nonprofits and Public Organizations,

In our digital age, social media platforms have become indispensable tools for communication, outreach, and community engagement. However, the landscape of these platforms is evolving, it’s crucial for organizations like yours to rethink where and how you engage online.

The Challenge with Centralized Platforms

Centralized social media platforms, such as X (formerly Twitter), operate under profit-driven models that can influence the dissemination of information. Studies have shown that Twitter’s algorithms tend to amplify content from right-wing politicians and news outlets more than from the left. Regardless of political orientation, algorithmic biases driven by profit interests are incompatible with the public interest.

This inherent bias can inadvertently skew public discourse, affecting the visibility of crucial information.

For public entities — such as fire departments, police departments, universities, and other essential services — this presents a significant concern. Relying on platforms where private entities control content algorithms poses risks, as these algorithms may inadvertently delay or obscure urgent messages. For instance, during recent emergencies, platforms like TikTok, Instagram, and X/Twitter were inundated with disaster-related content, yet they often failed to provide timely, practical assistance to those affected. Even worse, the algorithms can also amplify misinformation, further complicating efforts to deliver accurate, life-saving information.

This underscores the challenges of relying on algorithm-driven platforms for emergency communications.

I don’t like that public entities are giving power to private individuals, but I am even more troubled that these individuals have used this power indiscriminately for self-benefit. We gave them too much power, and now it is time to demand that such organizations embrace open standards and open platforms. In an ideal world, public entities would self-host services for video, microblogging, alerts, newsletters, and more — just as they self-host or contract email and web services. I am okay with platforms like YouTube offering a white-label platform, free from algorithm-driven motivators that work against public self-interest. But for organizations like Amtrak or NOAA to rely on X/Twitter for alerts or YouTube for videos is akin to using a @gmail email address or hosting their website on Geocities. We deserve better.

The Public Discourse in the Control of Individuals

The centralized control of influential digital platforms has empowered individuals like Elon Musk to significantly influence political discourse. Independently if you agree or not with views of the individuals, their dual role as a senior adviser to Government and owner of X has raised concerns about potential conflicts of interest, especially regarding decisions like influencing federal contracts to favor his business interests.

This convergence of media ownership and political advisory roles exemplifies how centralized control over digital platforms can enable private individuals to shape public discourse and policy decisions, often aligning with their personal or corporate interests.

The Decentralized Alternative

Decentralized platforms, such as Mastodon, offer a compelling alternative. By distributing control among users rather than centralizing it within a single entity, these platforms enhance transparency and reduce the likelihood of algorithmic manipulation serving specific agendas. This structure ensures that communications remain unbiased, and engagement with communities is authentic and free from corporate interference.

Moreover, decentralized platforms provide greater ownership over personal data and improved control over user-generated content. Nonprofits, for example, can migrate to different servers or even run their own Mastodon instance, just as they manage their websites and email services. This gives them the ability to communicate directly with their audience, without relying on third-party platforms that may prioritize profit over public interest or restrict their reach.

A Word on Emerging Platforms

While new platforms like Bluesky present themselves as decentralized social networks, it is essential to approach them with caution. Despite their decentralized architecture, they remain for-profit entities, which could influence their operational decisions and priorities. As such, the potential for profit motives to impact content visibility and platform policies cannot be entirely dismissed.

What is next?

Given these considerations, we urge nonprofits and public organizations to reevaluate their social media strategies critically. Transitioning away from platforms that enable oligarchic control and corporate interests over the public square is a step towards preserving the integrity and efficacy of your communications.

We understand that this process is not easy or simple. That’s why we encourage nonprofits to adopt Mastodon alongside their existing social networks while migrating or condensing their social media presence. It’s important to start building that presence now so your audience knows where to find reliable, unfiltered information about your organization — without interference or misinformation.

Embracing decentralized platforms like Mastodon can empower your organization to maintain direct, unbiased, and effective engagement with the communities you serve.

By making this shift, you not only safeguard your organization’s mission but also contribute to a more equitable and transparent digital ecosystem.

There is a whole community ready to help you, and I am eager to assist your nonprofit or public organization in migrating to a more sustainable and independent platform.

With commitment to change,

and unwavering support,

Sincerely,

Maho Pacheco

Where to start?

• Join Mastodon.
• Public Broadcasters of Europe, Let’s All Start Microblogging.
• Mastodon Resources for non-profits and public organizations.

Motivation

Ever looked at those $15–$20/month streaming services and thought, "I have Azure credits—why am I paying for this?" Same here. Plus, my friend Luis Quintanilla introduced me to Owncast , which I plan to use soon. So, the question became: Can I achieve multistreaming using open-source tools? And if so, how do I stream to Owncast and other platforms at the same time?

Overview

The multistreaming setup works as follows:

1. OBS Studio streams to a relay server running on an Azure VM.
2. MonaServer 2 acts as an RTMP server, receiving the stream.
3. FFmpeg restreams the RTMP feed to LinkedIn Live and YouTube Live simultaneously.

This approach minimizes bandwidth usage on your local machine (which is a pain in my home with so many devices and one kid) while ensuring a stable stream to multiple platforms.

Step 1: Setting Up an Azure VM

First, provision a virtual machine on Azure:

• Choose an Ubuntu-based VM (e.g., Standard B2s or higher).
• Ensure inbound ports for SSH (22) and RTMP (1935) are open.
• Install dependencies:

sudo apt update && sudo apt upgrade -y
sudo apt install -y ffmpeg git

Step 2: Installing MonaServer 2

MonaServer 2 is a lightweight RTMP server that will handle incoming streams from OBS Studio.

I followed the instructions on https://github.com/MonaSolutions/MonaServer2 which involved installing gcc++, libss-dev (sudo apt get install gcc++ libssl-dev) and LuaJIT manually.

With LuaJit I did not had an issue to compile it manually. With MonaServer 2 however, I modified:

MonaBase/include/Mona/Mona.h and added #include <stdexcept> after the includes (#include <cmath>) and then it compiled successfully. Then I manually copied MonaBase/lib/libMonaBase.so into MonaServer.

Run MonaServer

./MonaServer &

By default, MonaServer listens for RTMP streams on rtmp://<your-vm-ip>/live.

Step 3: Configuring OBS Studio

1. Open OBS Studio and go to Settings > Stream.
2. Select ‘Custom’ as the streaming service.
3. Set the RTMP server to:

   rtmp://<your-vm-ip>/live
   

4. No need to set the Stream Key.
5. Click Apply and Start Streaming.

At this point, OBS will send the stream to your Azure VM running MonaServer.

You could test this by using VLC and opening rtmp://<your-vm-ip>/live.

Step 4: Using FFmpeg to Restream

Now that MonaServer is receiving the stream, we use FFmpeg to send it to LinkedIn Live and YouTube Live.

ffmpeg -i rtmp://localhost/live/my_stream \
    -c:v copy -c:a aac -b:a 128k -f flv "rtmp://a.rtmp.youtube.com/live2/YOUR_YOUTUBE_STREAM_KEY" \
    -c:v copy -c:a aac -b:a 128k -f flv "rtmp://live.linkedin.com/media-server/YOUR_LINKEDIN_STREAM_KEY"

This command:

• Takes the RTMP input from MonaServer.
• Copies the video codec (avoiding re-encoding).
• Sends the output to YouTube and LinkedIn.

There are other options described here.

Step 5: Automating FFmpeg

For a more robust setup, create a script to keep FFmpeg running:

echo '#!/bin/bash
while true; do
  ffmpeg -i rtmp://localhost/live/my_stream \
      -c:v copy -c:a aac -b:a 128k -f flv "rtmp://a.rtmp.youtube.com/live2/YOUR_YOUTUBE_STREAM_KEY" \
      -c:v copy -c:a aac -b:a 128k -f flv "rtmp://live.linkedin.com/media-server/YOUR_LINKEDIN_STREAM_KEY"
  sleep 5
done' > start-stream.sh

chmod +x start-stream.sh
nohup ./start-stream.sh &

Or you can even put your streams in a txt file.

This ensures FFmpeg restarts automatically if it stops.

Conclusion

With this setup, you can multistream from OBS Studio to LinkedIn Live and YouTube Live using Azure, an Azure VM, MonaServer 2, and FFmpeg. This method optimizes bandwidth and ensures a stable stream for multiple platforms.

If you are interested in what I stream checkout The Raccoon Bytes, otherwise if you have questions or run into issues, let me know in the comments!

Find the index and earlier parts of this series here.

We're almost there! Thanks for sticking with me on this journey. In this final part, we'll integrate replies and comments into your static website.

Motivation

Integrating replies is quite similar to how we handled subscriptions. Since our posts now exist in the Fediverse, we want to treat them as first-class citizens. This means replies to our posts should appear on our site.

Think of our site as an ActivityPub implementation (with some limitations and that it's not fully compliant). The key tasks here are:

1. Handling replies
2. Displaying replies

Fortunately, we've already set up an Inbox endpoint and handled one type of message: Follow. Now we'll extend this to support Create activities (notes).

Overview

The Inbox handles POST HTTP requests for various actions. These requests may or may not be signed, and you can choose how to respond. There's no strict minimum for an ActivityPub implementation, as seen with Threads' phased federation rollout. Building on Part 6, we'll now add support for replies.

Replies: The Flow

Here's a high-level view of the process (we'll break it down step-by-step):

{{< mermaid >}}
sequenceDiagram
participant Commenter instance participant Inbox
participant Table-Storage
participant Static-Storage
Commenter instance->>Inbox: Create activity note (reply) request Inbox->>Commenter instance: 200 OK
Inbox->>Table-Storage: Save reply URI/ID
Inbox->>Static-Storage: Generate replies collection
{{< /mermaid >}}

In Part 4, we added a replies endpoint for each post, like this:

"replies": {  
  "id": "https://maho.dev/socialweb/replies/a9e885b19fe0a2aceaf7696eb6d4b646",  
  "type": "Collection",  
  "first": {  
    "type": "CollectionPage",  
    "next": "https://maho.dev/socialweb/replies/a9e885b19fe0a2aceaf7696eb6d4b646?page=true",  
    "partOf": "https://maho.dev/socialweb/replies/a9e885b19fe0a2aceaf7696eb6d4b646",  
    "items": []  
  }  
}

The endpoint is predictable because we know the internal ID of the note (a9e885b19fe0a2aceaf7696eb6d4b646). Even if the URL doesn't exist when the post is created, it's still referenced in the note.

Note: This collection isn't truly paginated—it just mimics Mastodon's structure.

In the last step, we generate the replies collection. It looks like this:

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "id": "https://maho.dev/socialweb/replies/a9e885b19fe0a2aceaf7696eb6d4b646?page=true",
  "partOf": "https://maho.dev/socialweb/replies/a9e885b19fe0a2aceaf7696eb6d4b646",
  "type": "CollectionPage",
  "items": [
    "https://hachyderm.io/users/mapache/statuses/113868758629132410"
  ]
}

The items array holds URIs for replies. To avoid managing deleted or modified statuses, we only store identifiers and fetch the data in real-time.

.NET Implementation

Find the implementation in my repo: Almost Static ActivityPub. Check out these key files:

• RepliesGenerator.cs
• RepliesService.cs

In RepliesService.cs, the Inbox only processes Create messages originating from our domain:

if (!objectNote!.InReplyTo?.StartsWith(Domain) ?? true) {
    return; // Ignore messages from other domains
}

This filters out irrelevant messages from federated instances. You may want to add other filters?

Displaying Replies

Now that replies are stored, how do we show them on the site? Inspired by other implementations, I fetch comments based on the Mastodon post URL, which in our case is our ActivityPub post URL.

Here's the logic:

1. Fetch the replies URL (https://maho.dev/socialweb/replies/bcc93f1e77a9eaa4277b430815352ddd), appending a timestamp to bypass caching.
   • If 404, no replies exist yet.
2. For each reply, fetch its data (application/activity+json).
3. Parse the comment and display it.

This is the JavaScript powering the "Load Comments" button:

function loadComments() {
    let commentsWrapper = document.getElementById("comments-wrapper");
    const timestamp = Date.now();

    document.getElementById("load-comment").innerText = "Loading";
    fetch(`https://maho.dev/socialweb/replies/bcc93f1e77a9eaa4277b430815352ddd?timestamp=${timestamp}`)
        .then(response => {
            if (response.ok) return response.json();
            if (response.status === 404) {
                commentsWrapper.innerHTML = "<p>No comments found</p>";
                return Promise.reject("No comments found");
            }
            commentsWrapper.innerHTML = "<p>Error fetching comments.</p>";
            return Promise.reject("Error fetching comments");
        })
        .then(data => Promise.all(
            data.items.map(replyId => fetch(replyId, {
                headers: { 'Content-Type': 'application/activity+json', 'Accept': 'application/activity+json' }
            }).then(response => response.ok ? response.json() : Promise.reject("Error fetching reply")))
        ))
        .then(responses => {
            responses.sort((a, b) => new Date(a.created_at) - new Date(b.created_at));
            commentsWrapper.innerHTML = responses.map(status => `<p>${status.content}</p>`).join("");
        })
        .catch(console.error);
}
document.getElementById("load-comment").addEventListener("click", loadComments);

As you can see, nothing out of the world. You can find the full implementation here or just peeking to my page source code.

Final note

With this final piece in place, your static site now integrates seamlessly with the Fediverse by handling replies and comments. By leveraging ActivityPub, you've turned a static site into a social participant, capable of engaging with decentralized networks like Mastodon. This implementation not only enhances the interactivity of your site but also keeps it lightweight and maintainable.

If you have a static site on the Fediverse, feel free to share it—I'd love to check it out and follow your journey! Thank you for reading this series!

Yeah, I know the last 3 chapters are titled "The Power of..." but let me tell you, I like it, and it's my blog.

When I was a kid, I always knew I wanted to make something different for myself. Different from what? That was the question.

I didn't limit my imagination to a subset of possibilities. Everything was on the table: President of Mexico one day? Archaeologist discovering new dinosaurs? Sure, sounds fun. Composer and musician? Maybe, just maybe. But each possibility carried a hint of reality, shaped by moments like watching my mom count coins in desperation to buy a kilo of tortillas, or by the fact that everyone around me was low-income, grappling with the unjust lack of opportunities faced by kids like me—dark brown-skinned children in a deeply classist country.

As I grew older, the table of possibilities began to empty, one dream dropping off after another. My passion for music wasn't enough to get me into a conservatory; after all, we couldn't afford an instrument, let alone lessons (and to be honest I wasn't good enough). Becoming an archaeologist required moving to another city, an impossibility with no money to fund it. Instead, a narrow but promising path emerged: my hobby of tinkering with computers could actually become a career. By middle school, I was already coding in COBOL, Basic, and Pascal. An old computer lent by an uncle and code written in paper notebooks allowed a kid to teach himself the craft.

Despite the lack of material wealth, my childhood was a happy one. There was never a shortage of love and support—even if my father's way of expressing it was limited—and my mother's care was boundless. My parents made extraordinary efforts to provide for me. My mom worked up until the final weeks of a pregnancy at a private school to secure a highly discounted scholarship. My dad worked endless overtime. Thanks to them, I attended a school where I didn't fit in. Kids made fun of my backpack and school supplies. Birthday parties were held in houses so grand I couldn't navigate the etiquette. These houses were in neighborhoods where public transportation was absent, so I'd walk blocks and blocks to get there. Meanwhile, my afternoons were spent playing soccer in the dusty streets of our neighborhood, surrounded by half-built houses, some made of cardboard. My neighbors were working-class families: trash pickers, chicken sellers, construction workers, carpenters.

A Google Street View of My Neighborhood 2014

I was stuck between two worlds. At school, I struggled to find my place among wealthier kids who, despite everything, became my friends. Back home, my neighborhood friends often saw me as cocky or condescending. What I didn't realize then was that both groups were longing for what the other had.

Time passed, and this duality became part of my personality. Life went on, with me enjoying fancy dinners I couldn't afford and camping in places nobody else would. I was still happy, still grateful, still hopeful to make a name for myself. But the "industry" I aimed for remained a vague idea. I bounced between sysadmin, graphical designer, IT support, and software developer roles. Meanwhile, many of my childhood friends stayed the same, some never finishing middle school due to crime, drugs, unexpected pregnancies, or the necessity to work.

I vividly remember reading The Hacker Manifesto, trying to explain its allure to a neighbor who looked at me with confusion—or maybe disbelief. The idea of teaching transistors and semiconductors what to do, transforming electricity into something tangible and valuable, amazed me. I remember how my dad's job gave us a heavily subsidized but still expensive computer and DSL connection. I discovered Dragon Ball Z spoilers online (with my broken English) and shared them with my block friends, who mocked me for saying such "crazy" things would happen. Two years later, when those episodes finally aired on TV, I proved I was right (who is laughing now mxxfers!!)

No one around me was like me. The limited career scope for IT professionals was clear: be like my dad, an internet technician; like my uncle, a networking guy at Mexico's largest ISP; or like the people who occasionally hired me, programming systems for local businesses or teaching at a local university. I turned down the possibility of a stable job at my father's company. I wanted more, or at least something different.

Still living at my parents' house, I decided to make my first Amazon order in 2005: the Mono.NET book. It took months to arrive in Mexico, and when it did, I devoured it, treasured it. Immersed in open-source projects, install-linux days and the GNU Manifesto, I discovered GNOME. At the time, GNOME and KDE were the two dominant Linux desktop environments. When I learned that GNOME's creator was Miguel de Icaza, I knew immediately I was Team GNOME.

My first Amazon order, just paying in USD and shipping something to Mexico was extraordinary

Miguel de Icaza, the creator of GNOME and later Mono.NET, came from a vastly different background than mine—different skin color, different opportunities: a prestigious university, and a city brimming with possibilities. Yet, seeing a Mexican thriving in the "big leagues" made a crack in the wall of impossibility that surrounded me. I didn’t understand it fully at the time, but representation isn’t just inspiring—it’s transformative.

Miguel went on to create Xamarin and eventually joined (or was acquired by) Microsoft before moving on. Back then, I was busy creating clones of famous applications using GTK#. After spending a few years attempting to build an open-source community in my hometown and unsuccessfully applying for Google summer internships, I decided to move to a larger city—and the rest is a story that continues in other posts and other time.

However, I wasn't aware of all this until a few days ago, when a flood of memories came crashing into my brain.

Last week, I attended an ugly sweater event at SOMOS.tech. Joey Cruz gave me a branded sweater, and when I got home, my kid put it on, making funny faces. That moment inspired this post. That moment nearly brought tears to my eyes, as they threaten to now while I write. My child casually says he wants to work at Microsoft, as if it's something normal and achievable. For him, it might be. He doesn't know the struggle of not seeing anyone like you on the path you're trying to forge.

My kid stealing my hoodie

What I didn't realize was the impact I'm having on others. Returning to LinkedIn, I was surprised by messages from old friends expressing pride in my journey. They were proud—proud!—to see someone from their city, their university, their circle of friends, achieving what I have. (But what have I achieved anyway?) I don’t feel special; I don’t feel I’ve achieved anything extraordinary. I’m just here coding as I was 20 years ago. I believe anyone can do what I do—I’ve just been lucky with the opportunities that came my way. That’s not to say I don’t feel I’ve earned my place, but I know others might have made even more of the same chances.

Every couple of years, I visit my old neighborhood. Some childhood friends are gone—victims of the narco wars, some beheaded, others disappeared. These were people I played with for hours, for days, for years, sharing dreams and teenager ambitions (or the lack thereof). A neighbor once told me how many on the block had been rooting for me to succeed, to escape. They saw in the few of us who did that there was a chance for them too, maybe for their kids. How did I not realize it back then?

This is why I write, why I mentor, and why I strive to stay visible in spaces where others might need to see themselves reflected. Representation isn't just about achieving something for yourself—it's about holding the door open for the ones who come after you, showing them that the impossible can indeed become reality. And sometimes, it's about making sure that when they look up, they see a version of themselves already there, paving the way so they can achieve something extraordinary.

Representation matters. It bridges the gap between the impossible and the attainable. It plants the seed of belief in others, even if they don't realize it at the moment, even if they don't know they're watching. Even if, like me, they can't point to someone specific but are forever grateful for the path that was unknowingly illuminated. I can't wait to see what others achieve, breaking glass ceilings I am physically impossible of dream anymore.

Breaking Free: Reclaiming Visibility and Voice from the Algorithmic Gatekeeping. aka F**ck the algorithm.

So, I have an account with about 20 followers on BlueSky, and I generate some engagement on almost every post. In stark contrast, I have another account on X/Twitter that has over 2000 followers, yet 99% of the time, it feels like I'm talking to the void. My impressions hover around 30, which means roughly 30 people see my tweets—about 1.5% of my followers.

To increase these impressions, there's a well-known requirement: purchase the blue Twitter checkmark and the premium or pro subscription. I've seen posts from people claiming that impressions on LinkedIn drastically improve once you go premium, but since I don’t have it, I can’t really say for sure.

It's all quite crazy—bananas, really. On platforms like Mastodon or the Fediverse, 100% of my followers receive my posts in their feeds. This level of control that social networks hold over their algorithms feels like gatekeeping. They are essentially restricting access to their algorithms, creating walled gardens that control what we see.

They wield enormous power, controlling the infrastructure and influencing visibility. It’s astonishing how these algorithms dictate the reach of content on centralized platforms. Freedom of speech, not of reach. The notion that your reach—something inherently tied to the audience you've worked hard to cultivate—hinges on paying for premium features feels like a tax on digital self-expression. This gatekeeping discourages genuine engagement, creating a pay-to-play ecosystem that often sidelines smaller creators in favor of monetization over meaningful connections.

What are my options now? Do I really need to pay just to get my voice out there? Heck not! This is one of the reasons I am creating vocalcat. It really started as a personal tool, but I am working to get others benefit of it. Small creators need the tools to battle these algorithms without compromising their unique voices or the subjects they are passionate about.

How many people find themselves talking about things they don't truly care about or feel pressured to create engaging memes and videos just to garner attention, while their high-effort, thought-provoking posts get minimal likes? Yes, some of this is on us as consumers, as we sometimes prioritize entertainment. But when we give control of what we want to see and what we value over to the profit-driven algorithms, we ultimately lose a crucial battle.

TLDR;

In this digital age, it's essential for creators to reclaim their power. We need to explore alternatives that allow for genuine expression and connection. Let’s not allow algorithms to define our worth.

Join the fediverse/mastodon, be yourself, also visit VocalCat website and register for the beta, help me so we can thrive without the constraints of traditional social media algorithms. You will find your tribe. Keep going.

A few months back, I received a free book at a Microsoft event: Infectious Generosity by Chris Anderson. It sat on my bookshelf for a couple of weeks until one day, out of sheer boredom, I grabbed the shiniest cover one (a deep yellow) and started flipping through it. To my surprise, it's written by the Head of TED (I love TED!), and while much of the book is gold, this blog is about a particular section that completely resonated with a thought I've had for years. It touches on a phenomenon we've all noticed but rarely talk about: the media's relentless focus on the worst of humanity.

If you've read my previous piece The Digital Umwelt: Beyond the Noise and Crap Content, you'll know where I'm coming from.

Turn on any news channel, scroll through social media, and you'll see it: tragedy, disaster, scandal. After the 2024 U.S. presidential election, this only got worse, especially on platforms like Twitter and even BlueSky. The media is saturated with stories that tap into our deepest fears, often amplifying the most alarming aspects of any event. It's not hard to see why—these stories attract clicks, views, and engagement. Fear sells. Fear brings money. Fear even helped elect a divisive candidate. It's addictive, like watching a train wreck you can't look away from. We're hardwired for it; evolution made us that way. But here's the problem: we're now stuck in a feedback loop where negativity dominates the narrative, even though the majority of human interactions are positive. And they really are!

Think about it. When was the last time you saw a heartwarming story go viral on the same scale as a scandal or tragedy? Sure, you'll find examples—a dog rescue video, a touching reunion, Mr. Beast early videos—but they're exceptions, not the rule. It's not because these positive stories don't exist; it's because they're not prioritized. The media's business model thrives on our attention, and our attention is most easily captured by fear, not by warmth.

This realization was one of the reasons I shifted my focus in my videos. Instead of showcasing purely tech content, I started highlighting the voices of others—people who inspire me and have left a mark on my journey. My short videos now feature snippets of advice from people I admire, with the hope of creating a "good infection". I want to spread feel-good stories and amplify the voices of those who have shaped me, making space for genuine connection in a world obsessed with clicks.

So how do we break the cycle? How do we shift the narrative from one of fear to one of hope?

We have more power than we think. It starts with a simple act of choice—what we choose to engage with, share, and amplify. Instead of doom-scrolling through anxiety-inducing headlines, we can consciously seek out and share stories that inspire us, stories that showcase the best of humanity rather than the worst. I know it sounds small, almost naive. But media outlets watch closely what their audience engages with; their survival depends on it. By shifting what we choose to amplify, we can nudge the focus away from fear-driven narratives toward stories of generosity, kindness, and connection. There is a whole section in the book named What Mainstream Media Can Do.

So, yesterday's night code rush led me to create the The Bright Side bot on Mastodon. Using .NET and AI, the bot curates and publishes microblogging threads featuring feel-good stories from news sites. It's my small attempt to bring more bright news into people's social media feeds, injecting a little bit of hope to counterbalance the flood of negativity. I wanted to create something that could act as a beacon, even if it's just a tiny spark in the vast online darkness.

It's about creating a new kind of feedback loop—one where positive stories aren't the outliers but the norm. Where tales of everyday acts of kindness get as much attention as tales of conflict. This doesn't mean ignoring the bad or pretending problems don't exist. It's about balance. It's about making space for the good and acknowledging that the world is filled with generosity, even if it doesn't always make the headlines.

Next time you find yourself being pulled into a negative news spiral, pause. Take a moment to seek out stories that lift you up instead of dragging you down. Share them. Talk about them. Not just to counteract the bad, but to remind yourself—and others—that there is so much good out there waiting to be recognized.

In a world where fear sells, let's be the ones who choose to spread hope. Because if fear can be infectious, then so can generosity.

You can find the index and other parts of this series here.

We are almost done! Thank you for coming all the way into this journey. In this part we will learn how to broadcast (aka federate) your site posts to your folowers.

Overview

The federation of your posts (aka. sending your posts to live infitely in the fediverse) is pretty straighforward:

{{< mermaid >}} sequenceDiagram BroadcastTool->>Storage: Retrieve followers (actor uris) BroadcastTool->>Follower-instance: Get actor info (including inbox uri) BroadcastTool->>Filesystem: Get note json (post) BroadcastTool->>Follower-inbox: Send a create action (wrapper of note) {{< /mermaid >}}

In a few words, you will iterate your list of followers, get their inbox url, and send a request to such url to create an fediverse object (note, article, etc.).

Details

On part 4, we already generated the notes. These are static files living in our site. However, we need to send such notes to the fediverse again, so they are aware that these exists.

Once a note hits one fediverse server, it is very likely that if this object gets shared and visible to other instances, these instances will already be aware of your post. Your notes are being federated. So how a fediverse instance know if a note is already in their database? With the object id. This is what a create note looks like:

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "id": "https://hachyderm.io/users/mapache/statuses/111876223052500122/activity",
  "type": "Create",
  "actor": "https://hachyderm.io/users/mapache",
  "published": "2024-02-05T01:14:48Z",
  "to": [
      "https://www.w3.org/ns/activitystreams#Public"
  ],
  "cc": [
      "https://hachyderm.io/users/mapache/followers",
      "https://maho.dev/@blog"
  ],
    "object": {
       <original note>
    },
    "signature": {
        "type": "RsaSignature2017",
        "creator": "https://hachyderm.io/users/mapache#main-key",
        "created": "2024-02-05T01:14:48Z",
        "signatureValue": "dYIs1ZFExg5LeqHrZ5o905/fDv7WGyxC71kl1Jjlq9kqSDjMlhXP3/159fgwF+ouJRjBWEOIUUAwHhHFmbcuMbqFNxxPZ1nQ6A10HSL8osb4CycUsTOtu0XoOp2x5eufB8dgsVqb8LfCOlpGyuNLewbAheqUN3mjO+QyaKQJ0PTRqxKt5gUcAlpkGYTGLx8f+b9dIwHUM9F4VzueWJ7UiVqOMxS1Lb7mXn2qmEyj3hN81W5jttHyUmQ+qB5nNjKc/u8eOGcV+p5yy/auCSq4im2JsvmwK4fCpsfC2gqSl4gRknTng8T/DAoVUbW1bQC5YJg14uqeEKN5QGkqZxWikA=="
    }
}

This id is unique ("https://hachyderm.io/users/mapache/statuses/111876223052500122/activity") and in the example above is a mastodon generated one. At difference that the original note or object, these does not need to be reachable, in my case I get away with just adding "/create" to the original id. But it is important this id is consistent, to avoid generating multiple notes.

Another important part to mention is the cc, which I have not figure it out yet, honestly. Mastodon seems to either ignore this, probably because it already has a database of who follows who, and decides to show the timeline of posts not based in the create requests received, but based in what should they see. In any case, is important to at least cc your followers url.

Finally the object, really important that the signature matches the object.

One important aspect that I am figure it out is the "published" field. This can be different from the date the note is mention to publish. But I am pretty sure, mastodon uses this to decide if a post will hit the "#hashtag" list or timeline. Mastodon seems to determine if the post is "recent" so it appears in the hashtags. I have not mastered this yet, so I may have an update weeks later.

Another important consideration is taht, if you have more than one follower with the same inbox, you don't need to send the same note again.

Putting everything together

I have implemented this in my favorite language (C#), but should be straighforward to implement in other places. You can find the code (and contribute) here.

Remember, as long as the id is the same, there is no harm in sending the same create note again. It won't get duplicated, but to avoid wasting bandwith, processing power and bytes, you don't want to do this. This is what my bash script to broadcast looks like:

# hugo deploy code ...
# azure deploy code ...

# at this point the generated notes are in public/socialweb/notes of the local runner (local dev or cicd worker)

for file in public/socialweb/notes/*; do
    # getting the base filename
    fileName=$(basename "$file")
    
    # echo for logging purposes
    echo "socialweb/notes/$fileName"

    # Use Azure CLI to set content type of the note
    az storage blob update -c "\$web" -n "socialweb/notes/$fileName" --content-type "application/activity+json;" --account-key "$AZURE_STORAGE_KEY" --account-name "$AZURE_STORAGE_ACCOUNT"

    # if the note is in the file "broadcasted.txt" then we don't need to broadcast it again
    grep -q "$fileName" broadcasted.txt && continue
    
    # Broadcast post
    BroadcastPost --notePath $file

    # Add the note to the list of broadcasted notes
    echo "$fileName" >> broadcasted.txt
done

As you can see the BroadcastPost command does all the magic. The broadcast post needs these 3 environment variables:

export ACTIVITYPUB_DOTNET_PRIVATEKEY=`cat privkey.pem`
export ACTIVITYPUB_DOTNET_KEYID="https://maho.dev/blog#main-key"
export ACTIVITYPUB_DOTNET_STORAGE_CONNECTIONSTRING="DefaultEndpointsProtocol=https;...secrets...;EndpointSuffix=core.windows.net"

Next steps

• If you want to integrate this in a CI/CD check my example of github actions and some utility scripts here.
• Another alternative instead of using a broadcasted.txt local file, would be to create a table in a database (e.g. local sqlite) or in the same Azure Storage.
• What happens if you update a post? There is a update action in activitypub, I have not implemented that yet, but the more complex part would be to "detect" changes on posts. Maybe with a hash? or datetime? Or maybe manually, idk.
• I have some crazy ideas of how we should send different objects for the same origin. Keep posted, because that is some crazy shit.

So, as you can see this is not super complicated, and I will in this moment broadcast this post.

Consider this: Have you ever tried explaining the fourth dimension to someone? You might find some videos online, but since we explore the universe through our senses, it’s incredibly difficult to truly comprehend what it would look and feel like, even though this dimension is part of our universe. Similarly, how could we possibly explain concepts like love to a whale, or understand their world when their sensory organs are so different from ours?

A few weeks later, I was recommended a book called An Immense World by Ed Yong. The first chapter felt incredibly connected (or maybe I was already biased) to this scenario, and it introduced me to a fascinating new concept: Umwelt.

Umwelt, as explained in Ed Yong's book, refers to the unique sensory world of every animal, including humans. Every species lives in its own perceptual world, shaped by its sensory organs and neurological architecture.For instance, a dog’s world is filled with smells that are invisible to us, while birds can see ultraviolet light that we cannot perceive. In the case of whales, their umwelt is shaped by senses we can barely fathom, like echolocation. They live in a completely alien reality. This gives us an idea of the challenge scientists face in trying to interpret whale communication - they are not merely deciphering sounds but attempting to enter an entirely different sensory world.

Imagine being able to hear the world through echolocation like Daredevil, or see ultraviolet light. It’s a cool idea, right? These abilities are explored in many comics, where humans possess sensory powers far beyond the norm. But take Madame Web, for example; she struggles to make sense of the overwhelming flood of information her abilities bring.

The reason we perceive the world differently from whales, dogs, and other creatures is, as you might have guessed, because we evolved in distinct ways. Each species has developed sensory perceptions that are most efficient for its survival. A key concept in the book An Immense World is that you don’t want to perceive everything. Perceiving more is actually detrimental to efficiency. If humans could see ultraviolet light or sense echolocation, we would likely be less efficient — perhaps even overwhelmed to the point of madness. Our senses are finely tuned to give us just enough information to thrive without becoming overloaded.

The whole 4-5 paragraphs before of this is to explain this idea, so I will repeat it once again: Our senses are finely tuned to give us just enough information to thrive without becoming overloaded. And you know what? I'm not a scientist, and I'm not here to talk about the book or animals. I'm here to pitch a new concept: The Umwelt of Internet Content.

I used to fill my RSS feeds with every major and interesting website I could find—Slashdot, personal blogs, technical blogs, news sites. I still follow some of them, along with newer ones like Hacker News. One of my daily goals was to go through all the articles, every single one, to ensure I didn’t miss anything. I wanted to stay ahead of each new technology stack, framework, and idea. I use to follow hundreds if not thousands of twitter accounts. I was overwhelmed, yet I was determined to consume everything as fast as I could. If I could go back in time, I’d slap myself in the face to realize that I was drowning in useless information. What I really needed was to curate the content that mattered to me.

I've heard this expressed differently: It's not the content you consume that matters, but the content you don’t consume. The power of saying "no." The internet is a vast universe of information, but that universe is shaped by what you choose to engage with and the social networks you frequent. Your Umwelt—your personal perceptual window to the world—is defined by the content you allow in. Just as our biological senses are fine-tuned to avoid overload, we need to be just as selective with the digital content we consume. By curating our digital environment, we can focus on what truly matters, enhancing our understanding and avoiding the chaos of unnecessary noise. And each one of us will have a different Umwelt, and that is fine. We are different; we come from different places and have different opportunities. Our goals vary as well. To survive, we need to make our sensory world as efficient as possible.

And there’s a lot of noise out there. A lot of crap, garbage, and AI-generated content. Many unoriginal voices are willing to do anything to get engagement—likes, clicks, whatever it takes. We're constantly bombarded with meaningless motivation. As consumers of content, we must be careful about what we choose to consume and engage with. Community is one of the best ways to filter content—finding like-minded people with strong bonds and connections—but it’s not the only way. As content creators, we also need to be mindful of this. Do we really want to be in the Umwelt of everyone? Every creature on earth perceives the sun differently—a lizard, for example, experiences it differently than a shark. If you did not get it, this analogy talks about how content is perceived differently by different people. When you reach a large enough audience, there’s no such thing as homogeneous content—you’ll have haters, fans, followers, and friends. Is that really what you want as a content creator?

My belief is that it’s not. You need to be intentional about the channels through which you deliver your content. Just as writing a book is different from making a movie based on that book, creating a YouTube video is not the same as writing a LinkedIn post. We need to be deliberate about the platforms we use to reach the people we want to connect with. The goal should be to talk about what truly matters to us, rather than trying to appeal to the largest possible group. Instead of trying to be everything to everyone—blinding or annoying people with a broad approach—we should focus on being a limited set of frequency bands in the light spectrum, reaching only those who resonate with our message. You’ll want to find your niche, where you’re genuinely happy and passionate about the content you create.

Your voice is unique, and that’s something worth protecting. Content creators have the power—and the responsibility—to shape the digital landscape with intentionality. AI can be a powerful tool, but it should serve as an extension of your creativity, not a substitute for it. By being deliberate about how we use AI and the content we produce, we can avoid contributing to the flood of meaningless noise online. Instead, we can create work that reflects our true passions and resonates with our audience.

Don’t settle for adding more clutter to the internet; be better, have a purpose, tell your story, cut the crap. And maybe you did not like it this article, is fine, it should not be in your universe, but if you do, subscribe, and welcome this publication to your Umwelt.

My mother would probably say that my first encounter with coffee was at 3 years old. There may be a physical picture, but the image that lives in my head is of a little kid, using my small hands to mix baby food into coffee with milk, just to create the messiest concoction possible. As she would gladly tell you many times, I was unable to drink milk from just a few days old, not because I was lactose intolerant, but because I did not like the flavor of it. So she tried -very hard- different ways to mask the flavor, and one of them was coffee.

Coffee in my childhood was always a supporting character in the main story. It wasn't even a fancy or pleasant character; it was a soluble powder that required unhealthy amounts of sugar and a hint of milk to make it taste good. I loved it at the time, and I'm not ashamed of my humble beginnings—it was all I knew. On rainy afternoons in May, I was responsible for making a two-block journey to the store to buy bulk cookies and a single or double cup package of coffee for me and my mom. The coffee was a pretext, a small escape when money was short.

I was not unfamiliar with good coffee, though. Those occasions arose during funerals, very occasional restaurant visits, but mainly at my grandmother's house in the small town, where the coffee was prepared in the Mexican way known as "café de olla," which simply means "pot coffee." It's a mix of coffee grounds, cinnamon, and piloncillo (solidified cane juice), which came from the closest sugar cane factories, adding more ashes to the already volcanic town. I still enjoy café de olla sometimes, although it's too sweet for my current taste.

Fast forward, I went to university, and as we say in Latin America, to be young and not revolutionary is almost a biological contradiction. I was involved in subversive (although completely legal) student progressive movements, which often involved late-night meetings or visits to local coffee shops frequented by politicians and elderly people. It was during this time that my taste for coffee began to refine, to the point where I completely eliminated sugar to free my taste buds to a new world of sensations. It was also a time when I worked for a newspaper as a graphic designer, every evening after college, ending my shift after midnight. It was a time of coffee, not only to keep me awake but also to socialize with other journalists, especially one who was almost 70 years old at the time. He meticulously prepared his coffee each evening in his own drip machine, and through him, I learned about the care one should give to the preparation. I am afraid to think he is no longer living in this world, so I prefer to think his passion for coffee and the art of its preparation still lives somewhere.

After college, I moved to another city to escape, explore the world, and devour it. This involved not only living alone but also experimenting with more complex flavors. I became the designated coffee maker in my 2-bedroom, 5-person apartment, and I was the coffee officer in the startup where I worked. I experimented with different types, amounts, and grind levels, each morning before everyone arrived. This was a time of explosion—of coffee with shisha in hookah lounges, of learning the thermodynamics of plastic and water to prepare coffee while tent-camping on the beach. This was also a time of learning about coffee regions, altitudes, humidity, and traveling to places like Michoacán and Chiapas, world-famous for coffee quality in Mexico. From then on, coffee was no longer a second-class character in my world.

Coffee was no longer the nostalgic drink of funerals as my older relatives started passing away. I experimented with different preparation methods, like the "Cuban press" (aka Italian press) that I acquired shortly after getting married and used to prepare coffee for my wife every morning. Or the French press, which I got after we adopted a dog, and which I used before she asked me to go for a walk.

We moved to the US in 2016 to the Puget Sound, without knowing that Seattle is somewhat of a coffee capital of the world. I enjoy visiting local coffee shops (technically Starbucks can be considered local, although that's not what I mean). With just the two of us in a new country and shortly after she got pregnant, I received for my birthday one of those very fancy-looking coffee dripper filters for one person and a spice grinder.

I still went back to Mexico a few times for vacations, one of them to make artisanal coffee. And by that, I don't mean just making a cup of black magma; I mean cleaning the beans with only air and gravity, roasting them with just an iron pot, and grinding them with a corn-grinder machine. I still envision creating my own brand in the future.

I have been fortunate in this life, I am grateful. I recently acquired a brand new Breville Barista, and I enjoy making coffee every day. I sometimes joke that I could live without everything—beer, meat, seafood, sugar—but not coffee. But it's not really a joke.

You could say that I am more of a coffee snob today; I only buy whole bean bags, and I haven't touched soluble coffee in years. I have changed, yes, but coffee around me has changed as well. While I may have become more discerning in my taste for coffee, it's the essence of coffee itself that has transformed, enriching my life in ways I never imagined possible.

But advice, like wisdom, can be tricky. It's not always suitable for everyone, and any phrase can become wisdom with the right context. Generic advice from sources like LinkedIn can often be too broad or superficial, and should be taken with a grain of salt. While I have a wealth of wisdom to share, I will save that for my one-on-one conversations.

That's why I am asking the people who have contributed to my growth not what advice they would give to others, but what advice they would give to their younger selves.

I will update this index with more details about the purpose of this video series. For now, I want to highlight that my goal is to document the career advice of people I admire.

• Emmeline Hoops - Sofware Engineer @ Microsoft - Video: Embrace Chaos - LinkedIn
• Olha Konstantinova - Software Engineer @ Microsoft - Video: Get a mentor - LinkedIn
• Marcia Dos Santos - PM @ Microsoft - Video: Work life balance in the beach - LinkedIn
• Zach Miller - Software Engineer @ Microsoft - Video: Be kind to yourself - LinkedIn
• Yani Ariunbold - Sofware Engineer @ Microsoft - Video: College is to explore - LinkedIn
• Renato Marciano - Sofware Engineer @ Microsoft - Video: Stay curious - LinkedIn

Copy-catting is rampant in content creation, especially among illustrators, musicians, and other artists. Artists have grappled with this for decades, prompting the creation of copyright laws. Gen-AI threats have already worsened this respect. But I didn't truly understand the coolness of being copied until I co-founded a startup with my partner.

We joined a few incubators, which helped to prepare our projects with extensive consulting on marketing, management, etc. Eventually, we pitched our projects to venture capital investors. You’ve seen this story on shows like SharkTank or in YouTube and TikTok videos: someone delivers an elevator pitch (named for the time it takes to ride an elevator) and then fields questions before investors decide to fund them. It is a rewarding experience that makes you humble.

Among all the feedback and questions, one always stuck with me: "What will stop me from going out there and creating the very same product myself?" It's a hard question—devastatingly cold the first time you hear it. Basically, it asks: What makes you so special?

Ideas are not unique

Ideas, you see, are not special by themselves. I have a friend who often grumbles that someone implemented his business idea, claiming we all told him he or his idea was crazy (we never did). Even monumental ideas like electricity or computers aren't unique and did appear in multiple places simultaneously. Content creation is no different. What makes you and your content so special? What stops me from copying your content and pasting it on my timeline? Spoiler alert: there is something.

While ideas aren't special and content isn't unique, the people behind them are. Similarly, in startups, a high-performing creative team is often more valuable than the product it creates. Companies are frequently acquired to embrace and absorb (and sometimes extinguish) their teams, which they see as a threat, not just to reuse their products. Big Tech has many examples of this kind of adquisitions. What's stopping Apple from Sherlocking apps?

If you’re unfamiliar with “Sherlocking,” here's a quick recap: Apple's predecessor to its Spotlight search feature in macOS was Sherlock, which searched the Mac and included some web-searching capability. A developer named Dan Wood created an app called Watson to supplement Sherlock by expanding its Internet search features. Watson was popular and successful—until Mac OS X 10.2, when Apple integrated everything Watson did right into Sherlock, eliminating the need for Watson. The app was effectively Sherlocked. Now each year there’s a list of apps released that Apple has sherlocked during WWDC.

As I said before, this applies to everything from content to diets. I recently learned this from a famous nutritionist online. She had a successful diet and exercise program with a close-knit community. However, she focused so much on protecting her content from being copied that she neglected (and even attacked) the community members, and her numbers started to decline. Diets can be easily replicated, and by "easy," I mean that others can replicate it, but I don't want to disregard all the effort and experience required to create one from scratch. That is the true value—the value behind who created those diets, the value of the person, not just the content itself.

Niches can be beneficial

That is why, you will see niches can be beneficial. Sometimes, it's preferable to have a few loyal customers (followers are customers) who engage deeply and are willing to pay well, rather than millions of disengaged customers.

Conversion rates matter. They are a crucial metric that can determine the success or failure of any business or content creation endeavor. Conversion rates measure how many of your audience members actually take the desired action—whether it's making a purchase, subscribing to a newsletter, or engaging with your content. A high conversion rate indicates that your message resonates with your audience, leading to greater engagement and profitability. Conversion rates in niches are greater. You may not don't need millions of followers, you just need 1000 in your niche. If you have time Jack Conte explains this very nicely in the Death of the Follower & the Future of Creativity on the Web.

This brings us to the concept of blue waters versus red waters. Blue waters represent untapped markets, fresh opportunities where competition is minimal. Here, you have the chance to innovate, to carve out a unique niche, and to attract a dedicated following. In blue waters, your ideas can flourish with less fear of immediate imitation or saturation.

On the other hand, red waters are markets teeming with competition—think of them as shark-infested waters where everyone is fighting over the same small piece of bloody meat. In such environments, differentiation becomes challenging, and standing out requires extraordinary effort and creativity. You’re constantly defending your territory and trying to outdo countless others who are vying for the same audience’s attention. Going back to the LinkedIn story of the beginning that is a red water, that content attracted 40k likes, the content that everybody is fighting to create in such social network.

Navigating between blue and red waters is a strategic decision. While blue waters offer open spaces and new possibilities, they also come with the risk of the unknown. Red waters, though competitive, provide a clear picture of what works and what doesn't. However, staying in red waters can lead to burnout and diminished returns if the market becomes too crowded and cutthroat.

Understanding where to position yourself can significantly impact your conversion rates. By finding your unique space in blue waters, you can build a loyal audience who values your originality and innovation. Conversely, in red waters, you must leverage exceptional strategies and continuously evolve to maintain a high conversion rate amidst fierce competition. You face the threat of burnout.

Immitation means that it is already working

Market viability is another key concept. If someone copies your product or content, it means there's a market for it. It indicates that other people are interested, and with billions of people out there, you can carve a niche for yourself. This is a positive signal that your idea has value and appeal. Even Bing, which holds only a single-digit market share, has proven to be profitable for Microsoft. This example shows that even a relatively small piece of a large market can be lucrative if managed well.

Market viability underscores the importance of differentiation. When others copy your product, it forces you to innovate and continually improve your offerings. Those who copy won't have your creativity, and the way you can reinvent yourself. This competition can drive you to refine your unique value proposition, making your product or content even more compelling. It encourages you to find new ways to engage your audience and to offer something that your competitors can’t easily replicate. And each time you do it, it is get noticed.

Fuck Copyright

Of course, certain technologies can be patented, representing intellectual property. Copyright laws were created for a reason: to protect the creators' rights and ensure they benefit from their inventions and creative works. But sometimes, I feel like saying, "Fuck copyright, fuck patents, welcome innovation, welcome creativity." This sentiment stems from the belief that overly rigid intellectual property laws can stifle creativity and hinder the free flow of ideas.

I LOVE when creators or companies collaborate. Collaboration and open exchange of ideas can lead to breakthroughs that benefit everyone, not just a select few. This is not to say that creators shouldn't be rewarded for their work, but rather that the balance between protection and openness needs to be carefully managed to encourage true innovation.

I follow my favorite people on LinkedIn, Twitter, Mastodon, and TikTok not just for their content but for who they are. That uniqueness is irreplaceable. It’s their personality, their perspective, and their way of engaging with the world that draws me in. The authenticity they bring to their platforms cannot be copied or faked. It's this genuine connection and individuality that make their content stand out in a sea of trash.

When you follow someone for who they are, you’re not just consuming content; you’re engaging with a vision and theiur way of thinking. This deeper connection fosters loyalty and a sense of community. It is being part of this community what it matters, not how funny was that last joke.

This is why I value the creators I follow—because they offer more than just information or entertainment; they offer a piece of themselves. And I will buy them a coffee or a beer anytime without a hint of hesitation.

Gen-AI has brought a uniform style to some of the things I read lately. After some time using tools like ChatGPT, you start detecting the patterns. Search for "Demystifying," and you will see. And sometimes I miss that raw, personal, unique touch in everything. In today's world, where technology plays an ever-expanding role in shaping how we communicate, there is a temptation to prioritize efficiency over nuance. Tools like that risk diluting the individuality that once defined personal expression.

Convenience and efficiency have overshadowed creativity. Colors have disappeared as in cars—white, black, red, and gray cars dominate the market, and it is increasingly difficult to find the purples, yellows, and blues. The imperfections, the quirks, and the genuine voice are becoming more appreciated, and it is what will persevere. It is very difficult to replicate individuality, making those unique touches even more valuable in a world where uniformity is on the rise. So, I decided to be that, raw and authentic, imperfect connection.

But the other side is a double-edged sword. Words have an impact; I have forgotten that in the last few days. I have become lazy, carefree, raw, and unfiltered. I have said "f*ck" on LinkedIn, brain-dumped to my friends, and led my teammates by the unwise example of unhealthy discussions. People are not machines, or virtual entities. I am grateful, though, that my teammates and friends can tell me when I am communicating wrong. Feedback is a gift if you know how to listen. I would always remember, for example the time my PM told me to not call her girl.

And feedback can be wake-up call to reconnect with the thoughtful, deliberate side of writing and to remember the power that words carry. As I continue to evolve as a professional, I embrace technology while holding fast to the belief that the human touch—genuine, heartfelt expression—is what truly resonates with others, even if it's sometimes in a negative way.

I don't expect much to change immediately in terms of politics, although I hope for significant progress. It won't erase machismo overnight. Women all over Mexico are not only still underpaid and undervalued but also face violence and disappearances. They are getting killed and mistreated. I am not physically violent, but I used to embrace that toxic masculinity without realizing it. Each time I return to Mexico, it becomes evident to me how normalized such behaviors are, sometimes even among my close friends and family, in work settings, and in general society.

Paradoxically, in Mexico, we have a deep and almost religious respect for our mothers. Big fights can be diffused with the power of a mother's flop- joke, but it is true. Mothers can work miracles in Mexico and still do. As example the current president went to visit the mother of one of the most famous cartel leaders, el Chapo, and stretched her hand. This is why our culture is so surreal.

I am deeply grateful to my partner for helping me identify certain traits that kept me inside that vicious circle. She is very patient, and most of the things I have learned about breaking free from toxic masculinity come from her guidance and support. She has taught me to be more self-aware and to challenge my own behaviors and beliefs, fostering a more respectful and equal environment.

I want to share some tips I've learned to break this cycle:

• Unconscious Bias. It's not that men don't understand what unconscious gender bias is—logically, we can grasp it. But because of its unconscious nature, we cannot always detect it. I need to ask myself each time, "Am I being unfair? Am I thinking this way because of a bias I don't recognize?" My kid always asks questions that open my eyes to new perspectives.

• Mansplaining. Before I want to jump in and explain something, I need to stop myself and approach the situation with curiosity. Like a detective, I try to ask why the other person thinks a certain way. Asking questions allows me to understand their point of view before trying to explain something that may not need explaining.

• Active Listening. One of the most important things I've learned is the value of truly listening. This means paying full attention to what someone is saying without preparing your response in advance or interrupting them. I always like to solve things and get things done, but that prevents me from listening. I've learned that listening is also an act of respect and trust. By actively listening, I can better understand the perspectives and feelings of others, which helps foster mutual respect and break down ingrained biases.

• Challenging Stereotypes. It is crucial to question and challenge gender stereotypes that we encounter in everyday life. Whether through media, language, or social interactions, being aware of and actively opposing stereotypes helps dismantle the harmful narratives that perpetuate toxic masculinity. This includes speaking up when I see or hear something that reinforces these stereotypes. Be an ally whenever you can, and challenge stereotypes yourself.

• Promoting Equality at Home and with Friends. Change begins at home, and promoting gender equality within my household has been a significant step. This means sharing household responsibilities equally, encouraging my child to pursue their interests regardless of gender norms, and demonstrating respectful behavior toward all family members and friends. If he wants that pink, rainbow unicorn purse, so be it. If he wants to play any game he likes, so be it. By modeling equality at home, I hope to instill these values in the next generation and contribute to a more inclusive society.

I want to help break that cycle in tech, and hopefully next generations will get the same opportunities, no matter who they are.

You can find the index and other parts of this series here.

Let's dig in into the most controversial part of my guide: the inbox. As far as I know, there is no way to make this inbox static. However, thanks to the fact that ActivityPub does not require the inbox to share the same domain as the other elements, we can host it anywhere.

I believe it could be controversial for two reasons. First, it is not truly static; you require a backend somewhere running on some kind of server. The second reason is that I am using Azure, and I know from the get-go that will put some of you off. But I believe this guide is still valid, as you can easily deploy to AWS, GCP, or even Vercel. I am writing this in .NET, but as you may already know, translating the logic should be trivial for most modern languages. I will actually encourage people to contribute these implementations to my repo and make it our repo.

Overview

The Inbox receives POST HTTP requests for different actions. These requests may or may not be signed, and you can decide to take action or not on those. There is no definition of what minimal implementation should be, and one example is how Threads implemented their federation in phases. You could implement just the follow feature, leaving your followers without any ability to unfollow you, but that is not cool. For a static site, I would suggest that the core should be follow/unfollow and replies.

Follow

This is how the process looks like; we will go into the details of each step:

{{< mermaid >}} sequenceDiagram participant Follower-instance participant Inbox participant Storage Follower-instance->>Inbox: Follow request Inbox->>Follower-instance: 200 OK Inbox->>Follower-instance: Request actor info Inbox->>Storage: Save follower record Inbox->>Follower-instance: AcceptRequest {{< /mermaid >}}

When a user requests to follow your site, they will send a request like this:

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "id": "https://mastodon.social/64527582-3605-4d19-ac99-6715df3b0707",
  "type": "Follow",
  "actor": "https://mastodon.social/users/mictlan",
  "object": "https://maho.dev/@blog"
}

1. Context is the namespace for the JSON request.
2. Id is a unique ID for the follow request.
3. Type is the type of the message.
4. Actor is who is trying to follow you.
5. Object is what is trying to follow. In this case, your actor URI.

The request itself should be answered by a 200 OK, but that is not the end of the process, and will just mark the follow request as pending in the Mastodon or any other client side.

What I do with this is to create a record in my database (an Azure Table, but it can be anything, even SQLite). I only store the actor URI and nothing else.

The actor by itself is not useful, so you need to request more information about it. This is a GET request to the actor URI. The result will give you a lot of things (it actually returns what we saw in part 3 of implementing an actor), but the most important one is the Public Key.

Once you store the actor and fetch extra information, you need to send a request to their inbox (this inbox URL comes from the actor object). This is an AcceptRequest, and this is how mine looks:

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "id": "https://maho.dev/@blog#accepts/follows/mictlan@mastodon.social",
  "type": "Accept",
  "actor": "https://maho.dev/@blog",
  "object": {
    "@context": "https://www.w3.org/ns/activitystreams",
    "id": "https://mastodon.social/64527582-3605-4d19-ac99-6715df3b0707",
    "type": "Follow",
    "actor": "https://mastodon.social/users/mictlan",
    "object": "https://maho.dev/@blog"
  }
}

• id: An unique ID of the accept request; it can be anything, just make sure it is unique.
• type: Accept string.
• actor: Who is making the request; in this case, your static site actor.
• object: The original follow request. Tip: Make sure it is the original and not recreated (unserialized/serialized).

This request should be signed; otherwise, it won't work. Mastodon is very fast to process any request. If you see the follow request not being reflected in the instance, it may be an issue with the signature. Mastodon will also return just a 200 OK if the signature is valid, but may not process the message if any of the elements do not match wherever Mastodon is expecting.

You may find better documentation about the signature that ActivityPub instances are expecting, but this is the summary:

1. Four request headers are necessary:

• Host: with the host part of the follower actor inbox URI.
• Date: UTC date string in the ISO format.
• Digest: the SHA256 checksum of the whole payload in this format:

SHA-256={payloadHash}

• Signature: A base64 encoded signed string using your private key. The signature string looks like this:

(request-target): post {inboxUrl.AbsolutePath}\nhost: {inboxUrl.Host}\ndate: {date}\ndigest: {digest}

Note: Remember to add the Content-Type "application/activity+json" element to your request.

You can find my .NET implementation here.

Unfollow

This is how the process looks like; we will go into the details of each step:

{{< mermaid >}} sequenceDiagram participant Follower-instance participant Inbox participant Storage Follower-instance->>Inbox: Unfollow request Inbox->>Follower-instance: 200 OK Inbox->>Storage: Remove follower record Inbox->>Follower-instance: Request actor info Inbox->>Follower-instance: AcceptRequest {{< /mermaid >}}

The unfollow request is very similar to the follow request. For example:

{ 
  "@context":"https://www.w3.org/ns/activitystreams",
  "id":"https://mastodon.social/users/mictlan#follows/51971777/undo",
  "type":"Undo",
  "actor":"https://mastodon.social/users/mictlan",
  "object":{
    "id":"https://mastodon.social/f722c435-5a8a-4e94-b7c8-529cdcdf12a6",
    "type":"Follow",
    "actor":"https://mastodon.social/users/mictlan",
    "object":"https://maho.dev/@blog"
  }
}

You can see that the object element contains the whole Follow object. As in the follow part, you may want to check the signature of this request, since a bad actor could "unfollow" other people without their consent.

As in the follow request, you need to return a 2XX HTTP code and send an AcceptRequest to the follower inbox to confirm the unfollow request. The AcceptRequest is exactly the same, and remember the object element just contains the whole original request, in this case, the undo request (which also includes an object inside).

Again, you can find the .NET implementation here.

Replies

This is how the process looks like; we will go into the details of each step:

{{< mermaid >}} sequenceDiagram participant Follower-instance participant Inbox participant Storage Follower-instance->>Inbox: Reply to post Inbox->>Follower-instance: 200 OK Inbox->>Storage: Create the replies JSON file {{< /mermaid >}}

If someone is replying to your site in the fediverse, you will receive a request like this:

{
  "@context": [
    "https://www.w3.org/ns/activitystreams",
    {
      "ostatus": "http://ostatus.org#",
      "atomUri": "ostatus:atomUri",
      "inReplyToAtomUri": "ostatus:inReplyToAtomUri",
      "conversation": "ostatus:conversation",
      "sensitive": "as:sensitive",
      "toot": "http://joinmastodon.org/ns#",
      "votersCount": "toot:votersCount"
    }
  ],
  "id": "https://hachyderm.io/users/mapache/statuses/112281648967418926/activity",
  "type": "Create",
  "actor": "https://hachyderm.io/users/mapache",
  "published": "2024-04-16T15:39:57Z",
  "to": [
    "https://www.w3.org/ns/activitystreams#Public"
  ],
  "cc": [
    "https://hachyderm.io/users/mapache/followers",
    "https://maho.dev/@blog"
  ],
  "object": {
    "id": "https://hachyderm.io/users/mapache/statuses/112281648967418926",
    "type": "Note",
    "summary": null,
    "inReplyTo": "https://hachyderm.io/users/mapache/statuses/111910324565541779",
    "published": "2024-04-16T15:39:57Z",
    "url": "https://hachyderm.io/@mapache/112281648967418926",
    "attributedTo": "https://hachyderm.io/users/mapache",
    "to": [
      "https://www.w3.org/ns/activitystreams#Public"
    ],
    "cc": [
      "https://hachyderm.io/users/mapache/followers",
      "https://maho.dev/@blog"
    ],
    "sensitive": false,
    "atomUri": "https://hachyderm.io/users/mapache/statuses/112281648967418926",
    "inReplyToAtomUri": "https://hachyderm.io/users/mapache/statuses/111910324565541779",
    "conversation": "tag:hachyderm.io,2024-02-11:objectId=125092496:objectType=Conversation",
    "content": "<p><span class=\"h-card\" translate=\"no\"><a href=\"https://maho.dev/\" class=\"u-url mention\">@<span>blog</span></a></span> I will reply to this post for the part 6.</p>",
    "contentMap": {
      "en": "<p><span class=\"h-card\" translate=\"no\"><a href=\"https://maho.dev/\" class=\"u-url mention\">@<span>blog</span></a></span> I will reply to this post for the part 6.</p>"
    },
    "attachment": [],
    "tag": [
      {
        "type": "Mention",
        "href": "https://maho.dev/@blog",
        "name": "@blog@maho.dev"
      }
    ],
    "replies": {
      "id": "https://hachyderm.io/users/mapache/statuses/112281648967418926/replies",
      "type": "Collection",
      "first": {
        "type": "CollectionPage",
        "next": "https://hachyderm.io/users/mapache/statuses/112281648967418926/replies?only_other_accounts=true&page=true",
        "partOf": "https://hachyderm.io/users/mapache/statuses/112281648967418926/replies",
        "items": []
      }
    }
  },
  "signature": {
    "type": "RsaSignature2017",
    "creator": "https://hachyderm.io/users/mapache#main-key",
    "created": "2024-04-16T15:39:57Z",
    "signatureValue": "am2S196mTFCudcFl5GwghZu93aE2WwNTcmFVIzR18YgHso9qVAd4mE2dkJH9WygJnGikS+yPvHAHXK2bP/6qq6NkTCf3p3F0JR8UlbunT06qbZTa4Vi6KKGsXjL4PA7AzjMd0Wk8jUxYm2yJtDm8xzEr7SH8rwBxg8u+ozkIY0cPBAPoBZwb8+j7DQYxN67YJp0MQCRj6TmODgw/ywZySijs1sbCO1Q6U53icHiW19P27vwZzD41i9tMZajosBJHCNX2Bh6uop/LCRiXbAwvbqVPoS3T8k0x22kwdo4oo3tdtfrUAL9giBjQ/nTHGSPDbCvygQT2U43FbN1u47Feww=="
  }
}

As you can see, this is a full note creation, and it is very similar to when we are generating notes for our posts. The only difference is the inReplyTo field (e.g., "inReplyTo": "https://hachyderm.io/users/mapache/statuses/111910324565541779"), which is the post URL where we are replying.

What I do is to store only the note URL (the reply URL) and the reply-to URL, not the content. You may want to store the content if you want, but just be aware the author may edit the content, so it won't be up-to-date unless you catch the edit/delete requests. With the note URL, I render the comments on-demand on the static site and always get the latest of them.

You could also skip implementing replies and just use a Mastodon instance as a "gateway," searching your post and retrieving the replies. This has the downside that you will only see the replies that that specific instance was aware of.

The last step is to generate the replies collection. Each post/note has a "replies" URI, which contains a collection of the replies (a list of URLs as well). This looks similar to this:

{
    "@context": "https://www.w3.org/ns/activitystreams",
    "id": "https://maho.dev/socialweb/replies/4f2756ff205d2e4b15e5c65c17f961e5?page=true",
    "partOf": "https://maho.dev/socialweb/replies/4f2756ff205d2e4b15e5c65c17f961e5",
    "type": "CollectionPage",
    "items": [
        "https://dotnet.social/users/SmartmanApps/statuses/111910545030985527"
    ]
}

This is a static resource, generated by my Azure Function in my site storage.

Putting all together

A dotnet implementation of these features can be found here. I will try to record a video of how to deploy it and add some IaC/CI-CD in the next few weeks.

One important aspect is that the Inbox backend should have access to your private key, which I am storing as a secret.

As I said before, I hope/wish/expect that others will contribute/fork their own non-Azure and/or non-dotnet implementations. I will buy you a coffee if you do.

Final notes

Once your site "federates" with other instances, it is very likely the instance will start broadcasting other requests other than follow/unfollow/replies. For example, each time an account is deleted, it will send a "Delete" request. Since I am using Azure Functions, and one of the elements of pricing is runtime, the first thing I do in my inbox is to check the type of message and immediately discard or end execution of things I don't recognize (returning an 500 error for the messages I don't want to process).

And final note, there is some similar implementation named Social Inbox from Distributed.Press but it adds more features like moderation and stuff like that.

I've chosen to revisit this post, originally published in 2017, which was likely the second entry on this blog. Much has unfolded since then: it was my first year in the US (still thinking in getting back to Mexico), my brother was still in Mexico, the onset of Trump's presidency, and the world was not expecting a pandemic yet. Seven years later, I'm appending Part 2 following a recent visit to San Francisco. What changes have transpired, and what might I have overlooked? Let's delve into it.

Part 1: From Mexico to Seattle

Originally published on September 28, 2017

Every engineer aspiring to turn their hometown into a Silicon Valley should reside in one or at least consider themselves insiders.

I wish I had learned this years ago and, if not ready to move immediately, prepared for it. I can't change the past, but I have the opportunity to alter the futures of some people — including my brother. That's the purpose of this blog.

I moved to the US just a year ago. The transition hasn't been painful or difficult; my partner supports me, and my dog is small enough to travel onboard. There's a low-cost airline offering direct flights to my hometown three times a week, and I don't have kids. Hence, as we say in Mexico, "I fell into soft" (Cai en blandito). But that doesn't mean everything has been flawless.

With over 30 years on my human back and 15 years in my professional belt, I relocated to work for an IT company in the Greater Seattle Area. This migration is temporary, as is my visa, and I expect to return to Mexico soon... ish. But before I return, I want to equip myself with the tools needed to transform Mexico. In the past year, during the slow pursuit of those tools, I've realized it's a task I can't undertake alone — neither can you, nor the Mexican institutions.

Fortunately, the government and institutions in my hometown understand this. They've established incubators with ties to US-based accelerators, organized challenges, hackathons, and large-scale conferences. They invite individuals like Jon "Maddog" Hall, Wozniak, Kevin Mitnick, Akira Yamaoka, or Buzz Aldrin. They send our best and brightest (or let's say those with specific qualifications who navigate the process better than others) for months-long internships. But that's not enough, and sponsored programs alone will never suffice.

My hometown — the second-largest city in Mexico — boasted 113,944 graduate engineers in 2015. Most of them have at least basic English skills. But how many of these engineers can the government/institutions send abroad? My guess is just a small percentage (<1%) — a percentage that, though numerically insignificant, has made a significant impact in shaping the city's technological landscape.

Thanks to various programs, Guadalajara (dubbed the Mexican Silicon Valley) has truly become a technological hub, a software engineering cluster housing engineering sites of big corporates like Oracle, IBM, Intel, Tata, etc., as well as new-age startups such as Wizeline, Ooyala, etc. It's an incredible place with world-class culture, food, entertainment, people, and ample career growth opportunities.

Can you imagine if 20% of engineers could transform it with a clear vision of what they want to change? Can you imagine if 50% of engineers had the experience to avoid the same mistakes as Silicon Valley?

Living and working abroad not only involves improving language skills and acquiring new technical expertise (things one can more or less do in their home country) but also entails learning to interact with new cultures, adapting to different management styles, and fostering unconventional synergies. It's about discerning what's beneficial and what's not in cities, gaining experience, and using it as a tool to avoid major mistakes, dead ends, and pitfalls. It's only with our collective efforts that we can reshape the landscape of our cities for the common good — and, why not, for the sheer joy of it.

"The best way to learn something is to play with it."

Part 2: From Seattle to ... Seattle

Well, 7 years later, I find myself still in the US. Unexpectedly, it has gradually become my home. I've settled down in the suburbs of Seattle, and I now have a little one to care for.

After working in downtown Bellevue for a little over a year, I interviewed and received an offer to work for Microsoft. At that time, I was still contemplating returning to Mexico. However, after a year at Microsoft (my third year in the US), we began to consider that this might be a long-term journey.

Last week, I visited San Francisco for the second time in my life, not just any Silicon Valley, but THE Silicon Valley. Driving through downtown, South SFO, Palo Alto, and Mountain View, I was still amazed by the hundreds of companies generating a tech-hub synergy. The crypto-boom and startup-boom may not be what they were a few years ago, and you can certainly notice that on the streets.

During my previous visit, I had the opportunity to visit the offices of Facebook (now Meta) and over the dinner compare the culture there with that of Microsoft. Now, I can also observe the flaws of the tech-boom, for example, the constant gentrification of neighborhoods pushing out those who cannot afford to live there, forcing them to move elsewhere or resign to perpetual renting. Tech cannot solve everything.

My brother moved to the US, specifically Los Angeles, and experienced a taste of a tech hub, albeit not quite like Seattle or San Francisco. However, something in my thoughts has shifted. I'm unsure if once an engineer moves abroad, they will consider returning. Different priorities come into play, of course. For some, family and community may represent a stronger driving force than the pursuit of tech knowledge.

The culture at companies like Microsoft, IBM, Meta, Amazon, Google, Oracle, and others is vastly different from their headquarters than in other places, even within the same country. The history, culture, synergy, but mainly the opportunities for impact, exciting projects, and tech choices are markedly different. I've witnessed how many projects or products at Microsoft are very Redmond-centric, even though companies have become more flexible after the pandemic. The same can be said for others, and although we now have more remote positions available all over the place, particularly for startups, the big tech hubs still dominate job listings.

Nevertheless, I am still in favor of migration. Diversity benefits both ways, enriching not only the lives of those who migrate but also those left behind in the home country and those who become part of your new team. I still believe that every engineer needs to experience a Silicon Valley, whether for making it their permanent home or simply as an enriched journey. After all, it's through embracing new experiences and environments that we evolve, both as individuals and as a global community.

So, this was an upgrade. There was no internet, no means to get new software, and basically, all the bytes on any floppy disk that I could have in my hands were tried, dissected, and modified ad-infinitum. The software was usually not installed on any hard drive; whenever you wanted to use something, like Lotus 1-2-3, you would need to find the right disk and insert it into the computer.

I spent a fair amount of my childhood playing solitaire, coding, drawing in Paint, and creating presentations in Word. But, as with everything, the mechanical keyboard and mouse eventually succumbed to the crumbs of my tacos on the desk.

Cleaning the mechanical keyboard was not difficult; I learned from another relative who worked with mainframes in the biggest bank of my small town. The mouse was similar; you just needed to clean a small ball inside that looked like a boiled egg yolk. However, the cable eventually failed. Irreparable, fatal error.

We did not have enough money; the economic crisis of 1994, also known as the Tequila Effect, particularly affected my family. There was barely enough money for food, and we were running into debt. I remember clearly the moment all of this was announced on a small color TV in the living room, and the expression on my dad's face, but that is another story; the summary is that there was no way I could get a replacement for a mouse.

As you may have figured out, it did not temper my grit for learning more about computers. So I kept trying to use it with just the keyboard; after all, a mouse was just a recent addition. But in this new graphical user interface, things were a little more tricky. Thankfully, everything in Windows 3.11 (EVERYTHING) was designed to be used by the keyboard. I got better; I could navigate tabs, minimize windows, browse and manage files, learned shortcuts, played solitaire again. When I touched a computer again with a mouse, I was faster than everyone navigating, and I kept trying to do that for years.

Eventually, I got lazy and started using the mouse again, but I never stopped being an advocate of web accessibility and keyboard navigation, up to this day. It happened when I worked at Innox, and I made sure that any new fancy HTML dropdown supported arrow navigation. Or that all HTML forms were able to submit by hitting enter (some error that I commonly see, and that particularly can be missed when using React and other frameworks).

Accessibility is a guiding principle that should shape every line of code, every pixel on the screen. I mean it; for example, did you check that the fancy ASCII art on your command-line interface can be read by a screen reader? I have been fortunate to have blind colleagues in software development; we should ensure that we create better software for them as well.

Accessibility should not be an afterthought or a luxury. It should be a fundamental aspect of software design from the very beginning. My experience taught me a valuable lesson: accessibility isn't just about accommodating people with disabilities; it's about making technology usable for everyone, regardless of their circumstances. Whether it's a physical limitation like a broken mouse or a cognitive impairment that makes navigating complex interfaces challenging, accessible design ensures that no one is left behind.

I urge you: let accessibility be more than just an afterthought. For in championing accessibility, we not only create better products; we create a better world for all.

If you like to see how I test basic keyboard navigation and web accessibility of Substack, check out this video.

You can also navigate the other parts of this series here.

The Motivation

The motivation behind this simple feature is quite strong:

1. Increasing awareness of the Fediverse/Mastodon: By treating subscriptions from the Fediverse as a first-class citizen, rather than using email or other mechanisms, we can increase awareness and potentially drive more users to the Fediverse.

2. Avoiding the management of additional information: If you don't have to deal with other people's emails, even if it's just a simple database table, you'll simplify your life, reduce security concerns, and have fewer things to maintain in general.

The Implementation

I aim to keep all JavaScript/CSS as vanilla as possible, allowing you to easily customize and extend it to your liking. You can implement SCSS or deploy the JavaScript to a separate file for CDN hosting.

You will need to add the following code to the footer.html. In the case of Hugo sites, this is typically located under themes/<theme>/layouts/partials/footer.html. You only need to modify the first line (blogActor) for your Mastodon account:

  <script>
      var blogActor = '@blog@maho.dev';

      var showSubscribeModal = function () {
        var modal = document.getElementById("subscribe-modal");
        modal.style.display = "block";
      };

      var subscribeInMastodon = function () {
        var mastodonUrl = document.getElementById('subscribe-mastodon-url-host').value;

        if (mastodonUrl == undefined || mastodonUrl == '') {
          document.getElementById('error-subscribe').style.display = 'block';
          document.getElementById('error-subscribe').innerText = 'Please enter your Mastodon server URL. For example: techhub.social';
          return;
        }

        // validate that mastodonUrl is a valid domain with a dot
        if (!mastodonUrl.includes('.')) {
          document.getElementById('error-subscribe').style.display = 'block';
          document.getElementById('error-subscribe').innerText = 'Please enter a valid Mastodon server URL. For example: techhub.social';
          return;
        }
        var mastodonUrl = document.getElementById('subscribe-mastodon-url-host').value;

        if (!mastodonUrl.startsWith('http')) {
          mastodonUrl = "https:\/\/" + mastodonUrl;
        }

        document.location.href = mastodonUrl + '/authorize_interaction?uri=' + encodeURIComponent(blogActor);
      };

      var closeBtnOnClick = function () {
        var modal = document.getElementById("subscribe-modal");
        modal.style.display = "none";
      };

      // When the user clicks anywhere outside of the modal, close it
      window.onclick = function (event) {
        if (event.target == modal) {
          var modal = document.getElementById("subscribe-modal");
          modal.style.display = "none";
        }
      }
  </script>

<div id="subscribe-modal" class="modal" style="display: none">
  <div class="modal-content">
    <span id="close-modal" class="close" onclick="closeBtnOnClick();">&times;</span>
    <h3>Subscribe</h3>
    <p>
      You can subscribe to this blog by following with any existing account on any Mastodon server.
    </p>
    <p>
      <strong>Where is your account hosted?</strong>
    </p>
    <form onsubmit="subscribeInMastodon(); return false;">
      <span id="error-subscribe" style="display: none; color: red;">&nbsp;</span>
      <input type="text" class="mastodon-url-input" id="subscribe-mastodon-url-host" placeholder="ex. mastodon.social">
      <input class="button-9" type="submit" value="Take me home!" />
    </form>
    <p></p>
    <p>Not on Mastodon? <a class="join-mastodon-link" href="https://joinmastodon.org/">Join now!</a></p>
  </div>
</div>

That's it, if you like this, do not forget to subscribe and see this nugget in action!

There is a video version of this post in my YouTube Channel.

So we have our boilerplate app, and we are ready to start adding fun stuff. If you do not have that, check the part 1 of this series.

We will start by making sure we have Semantic.Kernel in our usings:

using Microsoft.SemanticKernel;

Now we will configure the "Kernel", which as the name says is the heart of SK (Semantic Kernel). We will add this to our services configuration helper method:

  .AddSingleton((sp) => 
          {
              var builder = Kernel.CreateBuilder();

              builder.AddAzureOpenAIChatCompletion(
                  Environment.GetEnvironmentVariable("AZURE_OPENAI_MODEL")!,
                  Environment.GetEnvironmentVariable("AZURE_OPENAI_ENDPOINT")!,
                  Environment.GetEnvironmentVariable("AZURE_OPENAI_KEY")!);

              return builder.Build();
          });

As you can see we will need to set 3 environment variables in order to get it working. We could use the configuration extension, documented here, if we prefer to use a .json file or other options. We can even add these variables as global options in our System.CommandLine.

I like environment variables because these are easier to set, work in pretty much any OS (or platform like GitHub actions), and I don't need to worry on secrets being push to the repo. The cons, is that you need to set them up each time.

Now we are ready to start doing queries against OpenAI.

Step 2

Now we will create a class that will do that LLM operation. I like to call it skill or service, but in different platforms could be called plugin, method, chain, etc.

It will look like this, make sure to read the comments:

// PostGeneratorService.cs
using Microsoft.SemanticKernel;

namespace PostGenerator;

public class PostGeneratorService
{
    // Function that represents a prompt
    private readonly KernelFunction _createUserStoryFunction;

    private readonly Kernel _kernel;

    public PostGeneratorService(Kernel kernel, KernelFunction promptFunction)
    {
        _createUserStoryFunction = promptFunction;
        _kernel = kernel;
    }

    public async Task<string?> CreatePost(string topic, string persona, string style)
    {
        // This prompt will receive 3 arguments to be replaced in the template
        var context = new KernelArguments
        {
            { "Topic", topic },
            { "Persona", persona },
            { "Style", style }
        };

        // This is where it goes to Azure OpenAI to invoke the LLM
        var result = await _createUserStoryFunction.InvokeAsync(_kernel, context);

        return result.ToString();
    }
}

As you can see we are passing the parameters as something call KernelArguments. These are filled into the prompt template. If you remember, in our part 1, uur prompt should look like this:

You are a expert. Generate a short tweet in a