I'll be straight with you: Linux has a lot of great development tools for a lot of different things, from vector art to audio / video production to software development. In a lot of respect, this is the best we've ever had it. But there's one area where we still fall desperately short: character creation tools. ## What is Character Creation? Before we get too into the weeds, let me first acknowledge that, yes, Blender exists, and there's a bunch of extensions that can make it do cool things. In capable hands, an artist can create 3D characters and assets from scratch, which is great. Character Creation tools are something of a niche product that's useful for people who aren't super interested in trying to spend 1,000 hours perfecting face sculpting, topology, and body rigging. There are a handful of tools out there, like Character Creator, Daz3D, and MetaHuman Creator that can produce remarkable-looking characters. Add in tools like ZBrush or Mavelous Designer, and you can make pretty much whatever your heart desires... ...as long as you're on Windows or macOS. For Linux gamedevs, your options are pretty slim. Let's review what's available to us specifically. ## MakeHuman Plugin for Blender MakeHuman is kind of the granddaddy of free, libre character creation tools. The MakeHuman Plugin for Blender (MHPFB) continues this effort. The plugin is actually quite serviceable, even if the models and community assets look rather plain out of the box. Lots of customization options, though. The biggest upside to this effort is that it's all open source, and offers a ton of useful documentation on how to do everything, from making skin to clothing to hair. There's a significant learning curve, but if you're willing to learn how to make all of your assets with it, this could serve you well. Source: Humanizer project As a neat little bonus, there's a super cool effort to port all of the MHPFB functionality directly into Godot itself. It hasn't been updated in a while, but the building blocks are there. If you wanted to leverage a full 3D character system in Godot 4, with support for adding equipment to bodies, this would be my recommendation. In theory, this could support putting a full custom character creator in your game. ### Using It In Practice Overall, MHPFB is not too difficult to use, but there's a number of things I had to trial-and-error through. The biggest challenge involved ensuring that my character exports looked correct, and that I was properly exporting with a special game rig skeleton. This was my first attempt at importing the model into Godot. What a monstrosity! It turns out that you need to follow a very special series of options for export: * **Limit To:** Visible Objects * **Transform:** +Y Up * **Data:** Shape Keys, Skinning * **Data > Armature:** Use Rest Position * **Data > Scene Graph:** Uncheck Everything * **Mesh:** Only check Apply Modifiers, UVs, Normals When creating your character, also make sure to use a proper Game Rig skeleton, otherwise, this happens: 0:00 /0:24 1× Once you're properly set up, you can use Godot's native Animation Retargeting feature to map existing animations onto a compatible human model. Overall, it looks pretty good! 0:00 /0:24 1× The main limitations of MHPFB involve a lack of graphical fidelity. It by no means looks _bad_ , and can definitely get the job done for a small indie game. In theory, you could greatly improve the models by creating custom skin, custom textures, custom hair, and custom clothing, and then leveraging some kind of eye shader and skin shader for the game engine itself. Here's a really good Godot4 demo showing what's already possible with skin and eye shaders. ## Human Generator for Blender I wanted something with a bit higher fidelity. A friend of mine had recommended Superhive Market, which offers a wide variety of paid plugins and assets for Blender. This is where I found Human Generator. **As of this writing, HG costs $128 USD for a commercial license.** At first glance, Human Generator looks like the answer to my prayers. The models and assets look quite good, there's a decent amount of flexibility in terms of character customization, and it doesn't take long at all to put something together that looks relatively nice. The documentation is relatively solid, although the Custom Content sections are pretty sparse, and leaves a lot of guessing to you, the user. My first stab at a custom character. I was still getting a hang of making clothing at the time. Where Human Generator falls apart is in its export system. To call it fussy would be an understatement, as various exports came out looking wrong in a variety of ways. Hair wouldn't correctly attach to a character's head, hair ended up being translucent, skin ended up looking waxy, and weird distortions would show up in costumes. He didn't look like this in Blender. More maddening is the fact that **Human Generator models just aren't really designed to be game assets.** There are no options to attach a game rig skeleton to a generated character, and the rest pose always defaults to an A-pose. This makes animation retargeting a _nightmare_ , as many freely licensed character animations only use T-pose as the rest pose, meaning even a simple walk animation will have your character walking around with their arms crossed backwards. The biggest downside to this plugin, aside from failing to meet my expectations, is the overall lack of a community surrounding it. There are not many pre-made assets available for use, and development appears to move at a snail's pace. Sure, there's a Discord community, but it's often very dead. ## CharMorph CharMorph is the descendant of the venerable MB_Lab project for Blender, which offers a handful of high-quality models and customization options. Unfortunately, CharMorph feels very unfinished compared to other efforts. Its own code repo is somehow out of date compared to the latest code release, with different version numbers and versioning schemes. Source: CharMorph The workflow for CharMorph is kind of hard to wrap your head around. Every other tool out there seems to have a pretty straightforward process: generate a human-shaped model, move some sliders to adjust various features, set skin tone and eye color, play around with hairstyles, add clothing. CharMorph is a bit more confusing in that the sidebar comes with a ton of bells and whistles, but very little information on what any of it does. In order to apply cosmetic changes, you have to hunt for this little menu, and make sure that Clamp Props is checked. I only found this out after diving in to the documentation. CharMorph is still a cool project, and I wish the best to the people developing it. I just think this needs a lot of UX love and optimization before I can recommend it. ## MetaHuman Creator for Unreal Engine Believe it or not, there are native builds available for Linux! But don't get your hopes up too much, because the entire editor is glitchy, and does not work all that well in a Wayland environment. Even navigating the menus is extremely cumbersome, although the engine itself seems to perform quite well. Despite creating relatively good-looking models, there's a lot of extra work involved in trying to make a MetaHuman compatible with Godot, let alone Blender. In theory, it's possible, but there's not a lot of good documentation online. ## Is That It? That's about it. The big commercial offerings don't work well in Wine, and probably aren't coming to Linux any time soon. As an indie dev, I have to think about a path forward for myself that doesn't create a whole lot of extra work. My main conclusion right now is that MHPFB probably offers the most amount of mileage right now. Humanizer for Godot remains extremely interesting as a project, and I really hope to see it pick up on development again soon. **My thinking is simply this:** * Create high-quality assets (hair, clothing, skin, etc) inside of Blender using MHPFB and other extensions like Hair Tool and Divine Cut. Figure out how to make created assets work well with MakeHuman models. * Port the results directly to Humanizer, manage it all in-engine with Godot. Instead of modeling characters with clothes, use systems that allow them to equip assets like clothing, hair, * You might notice that this approach is not unlike how Bethesda manages characters in their Creation Engine. Basically, characters are generic dolls that have generated facial attributes, and assigned hairstyles, clothing, and accessories. I think there's something to designing a game this way, although not every game necessarily has to go full-RPG with swappable clothing.

For years, I've wanted to switch from my trusty, crusty gamedev tool, Adventure Game Studio, to Godot. This is not because AGS is bad, in fact I have a deep love for it. But after spending years learning the ins and outs of it, and hacking together a bunch of crazy extensions, I realized that maybe it's time to try something new. I've been eyeing Godot for years now. It's a rising star in the gamedev community, it's open source, and all of the tooling I need works out of the box on Linux. There's a level of flexibility in this engine that would allow me to develop many different kinds of games, rather than a point-and-click engine with hacks on top. I dragged my feet for a long time, but I decided to bite the bullet with the recent release of Godot 4.6. It has just about everything I need to get started, regardless of what I want to build or prototype. So I dove in. ## Initial Experiments As a complete newbie, I decided to start with some basic resources to get a rudimentary 3D game working, to better understand what the process looks like: * MakeHuman - Basic 3D character models with some degree of customization. They aren't the best-looking, but work out of the box. * Mixamo - a bunch of freely available animations that can be used in 3D games. Handy for saving time while prototyping. * Terrain3D - a Godot plugin for a 3D Terrain system. * Godot Third-Person Controller - a Godot Asset Library template demonstrating how a character can be controlled with a third-person camera. These all will come up in subsequent posts dedicated to them, but I want to really focus on the camera first, because it's a core piece of the 3D game experience. ### Getting Set Up Initially, the third-person controller template looks like this: It's not a bad starting point. You can walk, run, and jump, and the camera automatically adjusts when backed up against a surface. Nice! #### Camera and Controllers There are a few limitations that I had to initially work through. The template wasn't set up for controller support, so it was up to me to hack that in. Thankfully, this is relatively easy to do, since you're just mapping existing script functions to an input source. Godot makes this really easy. For the third-person camera, this ended up working really well! I still want to adjust the camera position on the rig, for a more over-the-shoulder view, but it's perfectly serviceable for now. 0:00 /0:09 1× I then decided that I wanted to implement both a first-person and third-person view, and that's where I started running into problems. Take a look at what happens when we swap over to the second camera source, which is attached to the player's head. 0:00 /0:10 1× It looks...bad. In fact, this doesn't look at all like a first-person view, but some kind of drunken stagger that would make somebody sick. What's going on here? Well, here's my messy, hacky code, which lives at the top-level script of the game: func _process(delta): # Handle camera controls, determined by mode if Input.is_action_pressed("camera_left"): if camera_mode == 1: spring_pivot.rotation.y += 1.0 * delta if camera_mode == 2: player_head.rotation.y += 1.0 * delta if Input.is_action_pressed("camera_right"): if camera_mode == 1: spring_pivot.rotation.y -= 1.0 * delta if camera_mode == 2: player_head.rotation.y -= 1.0 * delta if Input.is_action_pressed("camera_up"): if camera_mode == 1: spring_pivot.rotation.x += 0.3 * delta if camera_mode == 2: player_head.rotation.x -= 1.0 * delta if Input.is_action_pressed("camera_down"): if camera_mode == 1: spring_pivot.rotation.x -= 0.3 * delta if camera_mode == 2: player_head.rotation.x += 1.0 * delta if Input.is_action_just_pressed("switch_camera"): switchCamera() There's probably a cleaner, neater way to write this. It turns out that I had made some assumptions about how 3D cameras work in games that was, in fact, wildly incorrect. * **Camera Position:** This was the first mistake. There's an assumption that putting a camera in the guy's head would result in something similar to normal human vision. In reality, it's a bit more complicated: you're probably better off by putting the camera closer to the player model's mouth. * **Camera Attachment:** The FPS camera is attached to the player model's head, so that body motion determines where the character is looking. The assumption is sound, but there's a third problem that messes this up. * **Camera Control:** In a first-person view, we actually don't want to control the camera independently of the head. Instead, we want to rotate the head and neck within a limited range of motion. Unfortunately, I was actually moving the bone attachment around instead of the camera! In order to resolve all of this, we need to clearly define our desired first-person camera behavior: FPS camera rotation should match up with the player's body and facing positions. We can look around from a stationary position, but extending beyond certain thresholds should rotate the player's body around accordingly. ## Handling Things in the Short Term I spent a lot of time debugging things, in a bid to better understand where I had gone so wrong. My first good idea was to get rid of the 2-camera system entirely, to minimize the amount of things I'd have to deal with. Thankfully, Godot's `spring_arm` system can imitate a lot of what I want to do here. It turns out, if you set the arm length to zero, you get something that looks a lot better for a first-person view. 0:00 /0:09 1× Granted, there's some alignment issues to clean up, but this is actually pretty decent! There was just one thing I needed to adjust: I wanted to make sure that when you switch perspectives, the camera always matches up with the direction the player character is facing. My camera code now looked like this: func switchCamera(): match camera_mode: 1: spring_arm_pivot.rotation.y = player_mesh.rotation.y / -1 spring_arm.spring_length = 0.0 spring_arm.margin = 1.0 camera_one.v_offset = 0.13 camera_one.position.z = -0.2 camera_one.h_offset = 0.0 camera_one.fov = 90 print("Camera Mode One - First-Person") print(" Spring Arm Pivot Rotation: ", spring_arm_pivot.rotation.y) print(" Body Rotation: ", player_mesh.rotation.y) camera_mode = 2 2: spring_arm_pivot.rotation.y = player_mesh.rotation.y / -1 spring_arm.spring_length = 2.0 spring_arm.margin = 0.0 camera_one.v_offset = 0.0 camera_one.h_offset = 0.0 camera_one.fov = 75 print("Camera Mode One - Third-Person") print(" Spring Arm Pivot Rotation: ", spring_arm_pivot.rotation.y) print(" Body Rotation: ", player_mesh.rotation.y) camera_mode = 1 Just as I thought I had everything to my liking, I caught a really nasty flaw in how I had designed things. Somehow, there was a complete 360 degree offset when I faced certain directions. 0:00 /0:10 1× aww, hell no This made no sense to me at first. I ran all sorts of tests, tracking variables and reading outputs as I fiddled with my messy code. Why would a directional result _sometimes_ be correct, and _other times_ be wrong? After asking for advice from a few different Godot devs, the solution hit me like a ton of bricks. It's not immediately obvious: I was making the pivot rotate to face the same degree that the player model was facing, but I failed to account for a positional offset. It wasn't that my alignment was sometimes right, and sometimes wrong. It was always wrong! That offset would always be between 90 to 180 degrees out of alignment...which means half of those degrees, you probably wouldn't notice due to overlap. I needed to add Pi. Every time I was calling the `camera_switch` function, I was doing this: `spring_arm_pivot.rotation.y = player_mesh.rotation.y / -1` But what I actually needed to be doing was this: `spring_arm_pivot.rotation.y = player_mesh.rotation.y + PI` Originally, I was taking the rotation value and flipping it, believing that this was what I needed to have my camera face the player from behind. It half works, but when you try to shift the axis by 90 degrees in either direction, suddenly everything is backwards. What I needed was to add a whole circle of rotation to compensate. 0:00 /0:23 1× ## Looking Ahead There's still a fair amount of cleanup I want to do in the future. I still want to try to get the head camera matched up, and I think rotating the neck and head bone to a limited threshold makes a lot of sense from a design perspective. Those are still a bit more advanced than where I'm at currently, though, so I'm sticking with what I have. * * * That's it for this part of the journey! Tune in next time to learn about my adventures with 3D models, animation for characters, and 3D terrain! It's a struggle, and I'm going to make tons of mistakes, but I feel like I'm already learning a lot. For my ongoing fork of the Godot template, check it out here! godot-hybridcamSome WIP code trying to make a camera that honors a first-person / third-person perspective system.Codeberg.orgdeadsuperhero

Every major version is a milestone, and 8.0.0 is no exception. Your WordPress blog just became a two-way street in the Fediverse. Visitors can like and boost your posts directly on your site. Media from federated replies is handled more reliably, and new block patterns make it easy to drop ActivityPub features into your pages. ## Like and Boost, Right From Your Blog The Fediverse Reactions block now has optional **Like**  and **Boost**  action buttons, inline with each reaction group. When a visitor clicks one, a modal opens where they can enter their Fediverse handle or copy the post URL to interact from their home server. The plugin remembers the visitor’s profile in their browser, so the second time around it’s even faster. And for folks who aren’t familiar with how the Fediverse works, each modal now includes a collapsible **“ Why do I need to enter my profile?”** help section that explains the open social web in plain language. This dramatically lowers the friction for cross-platform engagement. ## Block Patterns and Templates Setting up a Fediverse-ready profile page used to mean manually assembling Follow Me, Extra Fields, and Followers blocks. Not anymore. We’ve added a **“ Fediverse” block pattern category** with four pre-configured layouts: * **Author Profile with Follow** , a compact profile card. * **Fediverse Follow Page** , a full-page follow experience. * **Author Header with Follow** , great for author archive headers. * **Fediverse Sidebar** , drop it into any sidebar or widget area. If you’re running a block theme on WordPress 6.7+, there’s also a new **Author Archive (Fediverse)**  block theme template ready to go. ## Publish Smarter With Post Format Suggestions A new **pre-publish panel**  now analyzes your post content and suggests an appropriate post format when your object type is set to “Post Format.” Got a post that’s mostly images? It’ll nudge you toward the Image format. A video post? Video format. This matters because media-focused Fediverse platforms like Pixelfed and Vernissage display Notes differently than Articles, so choosing the right format means your content looks its best everywhere it lands. ## Community Snippets We’ve added a `snippets/` folder to the GitHub repository, a home for lightweight, community-contributed extensions that don’t belong in the core plugin but are too useful to lose. The first batch includes: * **FediBlog Tag**, automatically adds `#FediBlog` to standard blog posts for better Fediverse discovery. * **Locale from Tags**, derives post locale from taxonomy tags. * **Bot Account**, marks your profile as automated and displays a “BOT” badge in the Fediverse. * **Blockless ActivityPub**, renders Fediverse reactions as pure server-side HTML, no JS required. * **Photon CDN**, serves cached remote media through Jetpack’s Photon CDN for faster delivery. Got a snippet of your own? Check out the snippets folder and send a PR. ## Smarter Media Caching Under the hood, we’ve rebuilt how the plugin handles remote media, avatars, emoji, images, audio, and video from across the Fediverse. Instead of importing everything into the WordPress Media Library at insert time, media is now wrapped in custom blocks and **cached lazily at render time**. What does that mean for you? Faster processing of incoming content, less disk usage, and better rendering of audio and video attachments. Original remote URLs are preserved in block attributes, so caches can be regenerated without data loss. If you’re using Jetpack’s Site Accelerator, that works too, the new system is built filter-first. For site admins, there are new CLI commands to keep things tidy: wp activitypub cache status wp activitypub cache clear ## Minimum PHP 7.4 With WordPress 7.0 deprecating PHP 7.2 and 7.3, we’ve raised the minimum requirement to **PHP 7.4**. This lets us clean up compatibility polyfills and use more modern PHP features going forward. If you’re still on an older version, update your PHP before updating the plugin. ## Changelog ### Added * Add a help section to interaction dialogs explaining the Fediverse and why entering a profile is needed. * Add a notice on the Settings page to easily switch from legacy template mode to automatic mode. * Add a pre-publish suggestion that recommends a post format for better compatibility with media-focused Fediverse platforms. * Add a Site Health check that warns when plugins are causing too many federation updates. * Add backwards compatibility for the `ACTIVITYPUB_DISABLE_SIDELOADING` constant and `activitypub_sideloading_enabled` filter from version 7.9.1. * Add bot account snippet that marks ActivityPub profiles as automated accounts, displaying a “BOT” badge on Mastodon and other Fediverse platforms. * Add Cache namespace for remote media caching with CLI commands, improved MIME validation, and filter-based architecture. * Add federation of video poster images set in the WordPress video block. * Add Locale from Tags community snippet. * Add optional Like and Boost action buttons to the Fediverse Reactions block, allowing visitors to interact with posts from their own server. * Add pre-built Fediverse block patterns for easy profile, follow page, and sidebar setup. * Add snippet for blockless fediverse reactions. * Add `wp activitypub fetch` CLI command for fetching remote URLs with signed HTTP requests. ### Changed * Improved active user counting for NodeInfo to include all federated content types and comments. * Improve language map resolution to strictly follow the ActivityStreams spec. * Superseded outbox activities are now removed instead of kept, reducing clutter in the outbox. * The minimum required PHP version is now 7.4. ### Fixed * Accept incoming activities from servers that use standalone key objects for HTTP Signatures. * Fix a crash on servers where WordPress uses FTP instead of direct file access for media caching. * Fix a crash when receiving posts from certain federated platforms that send multilingual content. * Fix automatic cleanup of old activities failing silently on sites with large numbers of outbox, inbox, or remote post items. * Fix comment count to properly exclude likes, shares, and notes. * Fix follow button redirect from Mastodon not being recognized. * Fix modal overlay not covering the full screen on block themes. * Fix outbox invalidation canceling pending Accept/Reject responses to QuoteRequests for the same post. * Fix QuoteRequest handler to derive responding actor from post author instead of inbox recipient. * Fix reactions block buttons inheriting theme background color on classic themes. * Fix reactions block layout on small screens and remove unwanted button highlight when clicking action buttons. * Fix signature verification rejecting valid requests that use lowercase algorithm names in the Digest header. * Fix soft-deleted posts being served instead of a tombstone when the post is re-saved. * Improve compatibility with federated services that use a URL reference for the actor’s public key. * Improve handling of all public audience identifiers when sending activities to followers and relays. * Prevent private recipient lists from being shared when sending activities to other servers. ## Get It Download from WordPress.org or grab it on GitHub. Remember to check your PHP version first — 7.4 or higher is now required. A huge thank you to everyone who contributed code, testing, bug reports, and ideas to this release. Special thanks to @kraft, @jeremy, and @futtta for their snippet contributions. Update, try out those Like and Boost buttons, and let us know what you think — what’s the feature you’ve been waiting for? What would you like to see next?

I've long been an advocate for the Fediverse, or at the very least, some manifestation of a decentralized Social Web that anyone can take part in. As a whole, it is a revolutionary alternative vision to the concept of corporate social media. I wholeheartedly believe that an effort like this could change the Web. Here's the rub: we're still not very good at advocating _why_ people should join, or helping facilitate groups of people in their migration over here. The Fediverse, sadly, has something of a Linux problem. Fediverse advocacy often resembles Linux User advocacy, and aside from attracting some enthusiasts, doesn't often work well. Here are a few examples of what that looks like: * "You should ditch Windows and switch to Linux, it's better and respects you as a user!" * "Linux can do anything that Windows or MacOS can!" * "It's so easy to use, you should totally try it!" **Cards on the table:** I've been a desktop Linux user for almost 20 years at this point. I, too, have been this kind of advocate in the past, going as far as to start a petition to get Blizzard's games ported to Linux. Whether you're advocating to a person or a company, this method of outreach and advocacy just doesn't work. ## Why doesn't this work? For anyone with even a rudimentary understanding of marketing, it's pretty obvious that these kind of efforts are missing something. I can break it down into three points: * **Messaging:** Generic feel-good messages about why someone should use product X instead of product Y don't generally have much of an impact. You can promise the moon and highlight flashy features, but these don't actually get people to think about _why_ they ought to use the proposed alternative. * **Value Proposition:** When it comes to offering a product to someone, it's important to understand what points are being made about the product, and what points of interest align with the person. With the Fediverse, one of our biggest mistakes has been to focus on _open source_ , _decentralization_ , _digital sovereignty_ , _privacy-respecting_ , and other similar terms. This is great for attracting nerds, but for the general population, it's useless. * **Onboarding:** A lot of people will tell you to switch to something by pointing you towards an app to download, an ISO to burn, or a project page with a link to sign up somewhere. In a lot of cases, that's the extent of the help you get! You made the first move, now you're on your own. That is, unless you have an additional person with expertise to help you. ## What Should We Do Instead? In a practical sense, advocacy takes shape in many different ways, not just in the grassroots method I described. I want to break down a few principles, and follow up with some case studies where I think some promising work is happening today. ### More specific messaging is better We've established that broad-brush messaging is generally not that effective in getting new people to check out the network. You know what does work remarkably well, though? Figuring out specific groups of people that would benefit. I'm not going to get super into the weeds here and say something corporate like "We need to design user stories that cater specifically to a bunch of demographics we've just imagined." Instead, I think we can look at the landscape of social media, and figure out a bunch of different groups of people that currently aren't having a great time on centralized social media. #### A few examples * Journalists, writers, and bloggers often find themselves struggling to stand out in an algorithmic timeline. Often, these timelines shut out smaller voices, and promote bigger ones that have a budget for promotion. * Activist groups want to find spaces to collaborate together on their shared causes, without feeling like they have to look over their shoulder to check if big corporate social media is spying on them. * Video makers want to find communities of people who are interested in watching what they have to put out into the world, without having to do A/B Testing or weird thumbnails of facial reactions. * Families with Discord group chats are currently feeling weird about Discord's impending ID Verification System. They just want to have a space to talk with one another throughout the day, on the subjects they care about most. ### Describe the problem and solution without jargon Building on the last concept: we need to find a way to explain the value proposition of the Fediverse without using complicated words. The solution is a good one, but the value proposition is not the technology itself. It's what the technology _does_ that counts. Here's a typical technical description of what the Fediverse is: > The Fediverse is a collaborative network powered by thousands of servers running many different kinds of applications that all talk to each other using a common protocol. While it's not wrong, you might as well be describing newsgroups. But, what if we reframed it to a more human-centric approach? > The Fediverse is a vision for the Web that takes away the hard barriers between websites and lets people communicate across them as if they were in the same place. That's a lot better...at least, it gives me some warm, fuzzy feelings. But I think we can do even better than that, by re-framing the current state of social media. > **What once started as social communication hubs for the entire world has degraded into a cesspool of advertisements, tracking, and censorship.** Companies have determined how to hijack your most valuable asset - your attention - and used it to keep you logged in and active on their sites and apps. But the Web doesn't have to be this way. Instead, we can use the Internet itself to do everything we need, and connect without a giant corporate middleman. The secret? We can use the World Wide Web as our social network. We don't even have to be on the same website for it to happen. Probably a bit too wordy, but you get the gist. Focus on a problem, talk about some user frustrations or concerns, and then explain _why_ the Fediverse could be a viable solution. Avoid buzzwords, and focus on the mental picture of a corporate silo vs a federated network, and what the second option offers people. The best part is this: there are myriads of complaints about mainstream social media platforms. You can create different messages for different people by tapping into other points of contention. ### Hold the user's hand gently This is where we stumble the most. We kind of assume that pointing someone to a project page like JoinMastodon.org will somehow provide people enough of what they need to jump in and get started. The thing is, onboarding is the most crucial part of user conversion, and it's not a great situation in the Fediverse. Here's some of the most common things new people ask when they join Mastodon: * Which instance should I join? * How do I find people to follow? * How do I connect with my friends? * Why won't this instance let me talk to my friend on this other instance? * Why is this post in my home timeline? * How do I look up a remote post to comment on it? * Does blocking someone prevent them from seeing my public posts? * How do I secure my account so just my friends see me? * What app should I use? And it goes on and on and on. Somewhere throughout this long line of questioning, a person might get exasperated and give up. It's a lot to comprehend right out the gate, and it takes a while to fine-tune your social experience to become comfortable. ### Idea #1 - Data Import and Contact Sync One thought that I've had over a number of years is that it's kind of a chore to move all of your stuff over from one network to the next. Facebook and Google at least have the courtesy to provide you with some kind of data archive of your entire social graph, but I rarely see any other systems make use of it. On top of that, it's really hard to find your friends in a new place. Source: A New Social Not too long ago, I was inspired by Bounce, which gives people a way to move from Bluesky to the Fediverse and vice versa. It's a great tool and does some really clever things in the backend to make sure you stay connected with your friends on the other network. This lead to me thinking...why don't we do something like this for Facebook, and every other network? We could create a tool that's an essential part of user onboarding: offer a continuous sync of contacts, posts, and interactions. Do you have interactions from Facebook that don't exist on the Fediverse yet? No worries, we can backfill those later, and reconstruct the conversations in your old social graph. We'll even tell you about your friends who have already moved over. Granted, not everyone is going to want to import their entire social archive over. However, being able to easily find your friends, or parallel accounts to Facebook pages you follow, would go a long way towards aiding discovery. ### Idea #2 - Professional Hand-holding Another way to tackle this problem would be to look at two very different places: at an organizational level, and at the individual level. This would require us to actually find people who are interested in alternatives to begin with. **For organizations** , we could offer trainings and support to help teams get moved on to a new platform, with clear-cut instructions on how to do things. In addition, we could help social media teams get set up with Fediverse-compatible tools. Did you know that Buffer can post to Mastodon? Or that teams can self-host an open alternative like Mixpost to manage their operations? Some organizations might even go as far as wanting to launch their own social instances. Or maybe they just like the idea of having a blog that federates. **For individuals** , we can do one better. Imagine if PeerTube or Loops had a strategy in place to reach out to prolific creators on YouTube or Tiktok, and were able to help those people get set up, import their media, and direct their existing followers towards these new platforms? Better yet, suppose we consulted these people on what they need out of a platform specifically? A fair amount of creators want their accounts to be set up for their own production teams. They want to focus on making videos and getting them out there to an interested community, and they want to direct people to donation links to help grow their channels. ## Case Studies I wanted to take a minute to focus on a few really interesting developments that I think play into what I'm describing. I'll try to keep it short and sweet. ### Newsmast Foundation – Creating Community Apps The first thing I really want to focus on is Newsmast, because I think they're solving a hard problem in a unique way. The organization has been developing special "white-label" Fediverse apps intended for specific community instances, such as toot.wales. Source: Newsmast Foundation By putting on a custom face and releasing it to app stores, Newsmast is solving a very specific discovery problem. Instead of saying "Connect with us on Mastodon", and making users join a new network and do that onboarding dance, they instead just reduce everything down to downloading an app and signing up. You're still joining the Fediverse, federation still works as advertised. You just get a sleek branded package. Source: Newsmast Foundation What's really crazy is that some of their integrations go way past just setting up a Mastodon server. Some of their apps actually integrate right into the provider's website itself, thanks to a little bit of magic with ActivityPub integrations and custom feeds. From the Bristol Cable App's Google Play page. Newsmast is currently looking to expand beyond just Mastodon, and I think their partnership with Bonfire is going to be a big deal. Bonfire's whole thing is to be extremely extensible, and easy to customize. Maybe in the near future, these apps will support activities like Events, Groups, and more? For intentional communities, this could be huge. ### A New Social – Bounce Migration Tool A New Social is the nonprofit organization behind Bridgy Fed. Bounce is their newer migration tool, and it builds on top of Bridgy Fed to make it easy for people to move from Bluesky to Mastodon and vice versa. While this might sound trivial on the surface, it's actually a really cool demonstration of how people can move their identities across different open federation protocols. There's a possibility for other protocols to gain support (both to Bridgy Fed and Bounce) in the future, but for now, they're working on making a robust product that's easy to use. ### Hard Fork / Search Engine - The Forkiverse The Forkiverse's official banner. I love it. A collaborative effort by two podcasts, _Hard Fork_ and _Search Engine_ , led to the launch of a new Mastodon instance called The Forkiverse, for fans and friends of both shows. Casey Newton, Kevin Roose, and PJ Vogt worked together to make this thing a reality, and have an active community that's part of the network. They told their audience about it, on a special episode. The Fediverse ExperimentOur present version of the internet is arguably the worst it’s ever been. Which means – any shot at changing things, even an unlikely one – is worth trying out. Thr…Search Engine What's crazy about this effort is that neither show is a small deal, when it comes to podcasts. Hard Fork is part of the _New York Times_ , and Search Engine is said to be downloaded over a million times per month. These guys saw the Fediverse, liked what it was about, leapt in with both feet, and started a community. ### Bonfire - Open Science The Bonfire project is a bold, ambitious effort to build a highly-customizable Fediverse platform that can do it all. One of their main pilot programs has focused on creating a space for scientists, which has a number of specialized needs. Source: Bonfire blog After consulting with members of the pilot program, the Bonfire team launched a dedicated instance with a number of special features. For example: researchers can log in with their ORCID identity, and automatically import their publications, which gets appended to a special section of their profiles. Published works can be easily previewed and accessed directly from within Bonfire. ### AltStore - Federated App Store Although it's currently only available in the EU, AltStore is an alternative App Store where developers self-host their own apps on dedicated servers. In a sense, the app store itself allows users to add sources from developers, and get represented as ActivityPub actors. Source: FediForum Demo, "The World's First Federated App Store" by Riley Testut What's really unique about this approach is that interactions on apps and updates can be seen by the wider Fediverse, and viewed inside of the AltStore app. While it remains to be seen as to what kind of impact AltStore might have in the future, this is a clear signal to developers that they can take part in the wider Fediverse ecosystem with very little effort. ### TilVids – Bringing Creators to PeerTube TilVids is kind of a big fish in a small pond. They have a number of YouTube creators mirroring their stuff directly onto PeerTube, with some of them even making exclusive videos just for the network. With a dedicated community of nearly 6,000 users, TilVids has made some pretty smart choices in reaching out to video creators across different popular niches, and have built a pretty thriving community around it. This has actually seen enough success that several creators are now hosting their own dedicated PeerTube servers, effectively creating affiliate networks. ## In Conclusion Advocacy for the Fediverse has to go beyond word-of-mouth, and grow past old ways of thinking about things. We need to attempt daring, bold new initiatives that focus on making the network accessible to newcomers, while finding new ways to serve communities. This requires us to think about a lot of different things, from messaging to presentation to distinct ways of solving problems. I think the future of the network looks bright.

**It's our view thatBonfire not only has the potential to revolutionize the Fediverse and Open Social Media but the internet as well.** Their motto is "Building blocks for communities". And they aim to: * create digital spaces we actually control * tolerate no billionaires, no algorithms, no enshittification * and empower citizens to shape our own open social web. We will be covering it extensively here on The Fulcrum. And as I mentioned in the first TPF of 2026, I personally have ambitious plans for it. But first a disclaimer, this article is based on my notes from reading the Bonfire documentation and blog articles. I did sign up for the playground instance yesterday and started exploring it as an user. Obviously, I am not an expert and as a newbie I am primarily paraphrasing. In fact, I have never used it as an admin and pulled the screenshots in this article from Bonfire's sites. Plus, Bonfire just released the stable version, 1.0. So, it's definitely a work in progress (which makes it exciting). You'll also see it's not easy for non-devs to get an instance going (yet). The platform is incredibly unique. It is unusually developed in an unusual way. Not just a generic federation framework, Bonfire is a modular, federated social platform for building digital communities. It’s nebulous by design. It's also: * decentralized * federated with ActivityPub * extremely modular * and community-first oriented with unique governance, moderation, and privacy models. It has a strong focus on maintenance and stability as well. And they do extensive user testing. Big tech it's not. ActivityPub lets it talk to the larger Fediverse. It's light but scalable. Extensions allow classic social networking, forums, project organizing, and more. Also, Bonfire instances can be invite-only or open. Also, I have linked to many of Bonfire's articles here so you can explore them **after** reading this article. In its entirety. 😈 ## Why it's different Bonfire stands apart from other Fediverse platforms due to its Circles, Boundaries, and upcoming Groups (more on those below). Designed for extensibility and experimentation, it focuses on local-first, community-driven goverance. It's also more privacy/security-focused than its peers. You can have four profiles per account which is unique. They show up as separate identities - personal, work, or a project/community one for examples. Consequently, you have both account and profile settings. And you can even create a personal blog with it. How cool is that? In fact, it might (just maybe) have the potential to be the everything app of the open web. In any event, it's very flexible, customizable, and even a little anarchic. It's messy but with unlimited potential. That's why we've fallen in love with the idea of Bonfire. And we are going to help in a small way to bring that philosophy to fruition and to you! * * * ## Development Stack Bonfire is implemented with its own dialect of the Elixir language. Elixir is similar to Ruby on Rails or Python. I am a PHP peep myself (and mainly a half-ass frontend developer at that), so I have a lot to learn. But at least I get the gist of it. It runs on the Erlang VM. And it's capably of web programming, embedding software, machine learning, data pipelines, and processing multimedia. So, it's mega flexible and functional. Phoenix is the web framework Bonfire uses. You build interactive web apps via Phoenix Livewire. The Model, Viewer, Controller pattern is used. And templates are built with HEEX which uses HTML and embedded Elixir to build components. Plus, Bonfire has its own Phoenix Livewire sync called Surface. It's designed to be familiar to frontend developers. Surface view components are compiled into Livewire code. A few extensions use the Absinthe GraphQL library to expose an API. The database is PostgreSQL. ### Hosting Deployment and management of Bonfire can be via: * Co-op Cloud * Docker Container * Bare Metal * or a Package Manager. Unfortunately, all of these are self-hosted at the moment or available via working with an agency like Autonomic or Bonfire itself. Among many others, Developer Setup, Elixir, and Hosting guides are available in the docs. Ok, we're stoked though slightly intimidated with the stack. * * * ## Administrators Bonfire's firekeepers (aka administrators) have extensive means to control how their communities work. This includes how they are federated. Admins can also: * sort other admins, moderators, and users into Circles (more on that below) * assign roles and permissions for each circle or user * and manage and import/export block lists. Instance monitoring is via a "LiveDashboard". It uses Oban and Orion to maintain, manage, and update data as well as a Web Observer to view it. ### Extensions Extensions control functionality and user experience within Bonfire. Developers can create new extensions for capabilities not provided "out of the box". They could include new features, integrations, or tools. In the box examples include Boundaries, posts, messages, maps, etc. Or you could battle misinformation. In fact, Bonfire’s Mozaic initiative is “leveraging the Bonfire modular framework, to offer like-minded organizations and communities the opportunity to build custom extensions that connect their homegrown or third-party applications to the Fediverse.” Hopefully, those that are FOSS and non-surveillance oriented. There's no need to do Techno Feudalists' evil deeds for them. ### Flavors Bonfire will eventually have six options for new installations. These apps are called Flavors and are based on use cases. For now the functional ones are: * Ember (which is basic and stable if you want to customize Bonfire) * Social (which is recommended and in beta) * Community (which is in Alpha) The Social flavor would be similar to other Fediverse apps with posts and follows. Again, Bonfire is unique with its Circles and Boundaries. It supports both microblogging and long-form formats. Posts can be public or private, include content warnings, privacy controls, etc. The Community flavor will have group spaces and collaborative moderation. Again these are features unique to Bonfire. And of course, you can switch flavors at any time. * * * ## Community / Users Bonfire users have extensive control over their experience as well. There is a strong focus on privacy and safety. This sets it apart from say Mastodon. And again, so do its Boundaries, Circles, and roles. A quick side note, the team is also working on native apps for Apple, Android, (and hopefully F-Droid) to complement the web format. ### Boundaries As you might expect, Boundaries are limits that you place on yourself or other users to control what you're comfortable with while using Bonfire. They control how others interact with individual users' content/posts/activities etc. As you can see in the image above there are many options. Bonfire succinctly notes: "Boundaries takes things to the next level by enabling you to combine one or more circles and then grant specific roles to each circle." And they are compatible with Mastodon quote authorizations and GoToSocial interaction controls. Interoperability rules. Speaking of, Bonfire proudly notes you can: interact "across Mastodon, PeerTube, Mobilizon, and the wider Fediverse. Protocol bridges also connect you with Bluesky and beyond, breaking down walls between social platforms." Good stuff. ### Circles Bonfire Circles are lists of users that individual users can create based on levels of trust and intimacy. And permissions control circle activities. Shared Circles are co-managed by users and can include other Fediverse users (interoperability). Everyone in the Circle can be followed. Circles can also be used as lists or to filter sidebar feeds. And they can be made into custom feeds. Great stuff. ### Roles As you might expect, roles assign a set of permissions to users or circles. This allows them to perform specific actions. Or prevents them from doing so. When you assign roles, you ensure that users or circles have levels of access and abilities based on their relationship with you or the purpose of the boundary, etc. ### Groups Bonfire’s dev team are currently working on adding group functionality. There is not anything in the docs about what is coming. But, these details are in the linked article above: “Shouting at the mythical "global town square" may be fine for chatter but it’s lousy for organizing. When you need specific people to see, act, and follow through, you need a group. Federated groups in Bonfire will be spaces where communities gather to organize, care, and coordinate across the Fediverse. They'll live next to your personal feed, but with each group having a specific purpose: a study circle, a lab team, an activist collective, a project team, etc. Inside you’ll find posts, conversations, calendars, shared resources, and more. Crucially, groups will be portable and interoperable, so communities can grow and thrive without lock‑in.” And there is more in this older one. Obviously, this is extremely unique within the Fediverse and something very much to look forward to. Fantastic stuff. ### Normal Fediverse Functionality Of course Bonfire has the features common across a variety of Fediverse platforms. Feeds include these presets: * following * local * remote (other platforms’ users) * explore * bookmarked * trending * and trending links There are many more optional ones. And some of these have RSS feeds. Nice. Users can create custom feeds for various contexts. A Circles feed would be an example. They can also control sort orders. You can filter and sort by content type, circle, date, engagement, source instance, etc. ### Messages Messages are private but not encrypted (yet). And they can be individual or group in nature. ### Blocking As noted earlier, Bonfire concentrates on privacy and security. So, it's extensive blocking options include: * hide * silence (you don't see individual users) * ghost (individual users can't see you) * block (combines silence and ghost) * and import block list ### Notificatons Optional notifications include: * follows * requests * mentions * boosts * likes * and events, polls, group activities, etc. ### Posting Posts allow mentions, hashtags, and attachments. Obviously, you can interact with other non-Bonfire ActivityPub accounts. Bonfire also has flagging/labeling capabilities. Its useful for flagging misinformation. And search works across the Fediverse which is nice. ### RSS Speaking of search and finding content, another unique and fantastic Bonfire feature are its RSS feeds. They are by profile and only feature public posts. Your follow feed presets are: * local * public * and custom ### Customization Bonfire also presents many customization options for users. Profiles can include widgets like weather reports. The usual ones like Appearance (16 themes) and Feeds are customizable. Widgets also help customize the dashboard. And users can configure extensions as well. Well-being controls include: * mark all uploads as sensitive * blur all media * enable infinite scrolling * and highlight notifications Privacy and Safety controls include: * enabling federation * limiting direct messages * controlling discoverability * and allowing search indexing Curated and trending topic controls include: * show or hide * and set amount of days and how many topics to show So, there is much more customization on offer for Bonfire users as compared to those on other Fediverse platforms. You can even add custom emojis. * * * ## Let's wrap it up for now We have covered a lot here and mostly on the frontend and users. This is just the part of the iceberg that's above water. There's tons more information on how Bonfire works on the backend in their documentation. So, there's much more to explore in the future. As you have seen, Bonfire has the potential to revolutionize the Fediverse and Open Social Media. I think it can revolutionize the entire internet as a formidable tool to support local communities. And we can leverage it to fight big tech, techno feudalism, fascism, surveillance capitalism, authoritarian governments, and other nasty things. Let’s wreck some Big Social ships (um silos). With it we can create digital spaces we fully control. There is no need to tolerate billionaires, algorithms, or enshittification. We, the individual citizens of the world can shape our own open social web. So, let’s support Bonfire and realize a revolution. Make a small financial donation like I do each month. Here's a second option for doing so. Or better yet, support it via your time and expertise. Or best of all, build a Bonfire instance for a community! If you're interested, learn more from Bonfire’s articles and documentation that we linked to throughout this article. And to close out, here's a video of the Bonfire playground instance. You can sign up here. It's of the social flavor and not federated. It's just for playing. Finally, be sure to let us know what you think on the Fediverse or via the comments below. As I said, I hope to write more articles on this revolutionary framework so we can continue our journey to unfuck the internet together. Let's start a big ass bonfire. ### Follow us on the Fediverse Share on Open Social Media

Their work is far from over, but lack of development and progress is leaving me wanting.

Sure, we have open source, federated replacements for Instagram, Tiktok, and YouTube. How do we get creators to use this stuff? One consideration involves the ability to pay for things.

What happens when you get a bunch of Fediverse people in a room together?

For our latest episode of The Decentered Podcast, we interviewed @rabble! It's an awesome interview that talks about Twitter, Secure Scuttlebutt, and the evolution of #Nostr. https://wedistribute.org/podcast/s2e3-rabble-from-nos-social/

FediForum: moving the Open Social Web forward

FediCon 2025: A Canadian conference for decentralized social networks, the Fediverse, and the Social Web. https://fedicon.ca/

Thinking through Tim Chambers' writeup on how to deal with the sometimes very spotty UX of Open Social Web platforms.

Nextcloud - a safe home for all your data