Sean Tilley

Welcome to Prismo revived!

Welcome to Prismo revived!

Not so long ago, after a bit of encouraging from @dansup, I decided to revive this project using more modern stack. Apart from it being more modern, it is also way lighter than before and that's my main goal when working on it: everything should be as simple, light and independent as possible.

Technical stuff

New Prismo only depends on Ruby and sqlite. JS layer is minimal and based on importmaps so no heavy build step is needed anymore. CSS is being generated by native tailwind binary so produced stylesheet files are as small as possible and generation footprint is tiny.

When it comes to federation, old Prismo was based on a code extracted from Mastodon which was both messy and far from optimal to be used by such a small and simple website. Now we're using an excellent ruby library called Fedipub instead.

Why another link aggregator?

While other projects are focused on supporting multiple groups with massive amount of people in them, Prismo is more about small cozy federated single-topic instances. Being small and simple will let us perfect our feature set more easily.

What's next?

There is no any roadmap as of yet but, for starters, i will try to bring back original feature set (as you might feel like new Prismo is a downgrade from the old one - i just brought back the essentials for now). After that - we can discuss on what's needed and what would be good to have :)

There are obviously plenty of rough edges and issues but we will get there eventually. Let me know in the comments and, as usual, boosts highly welcome! :)

Let's talk!

• Mastodon
• Matrix

I'm tempted to move my whole social identity over to Ghost, but not being able to use Mastodon apps for the social part feels like a massive downgrade...

We Distribute's hosting provider is offline at the moment. Their team is working through it, but I basically can't access any of our subdomains or email for the time being.

Guess I'll just hang out here for now.

I don't think the follow buttons are supposed to look like that, but if they are, I applaud doing something different.

3D Game Development and Godot, Part I: Cameras

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.

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.

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!
• Body Movement: Weirdly, the player's body movement is actually controlled by a pivot attached to the body mesh. This secondary camera system fails to account for that, so movement is that much more difficult. You notice a lot of corrective motions that resemble shuffling, because the character can barely walk in a straight line correctly.

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.

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.

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.

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!

Reimagining Fediverse Advocacy

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.

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.

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.

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.

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

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.

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.

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.

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.

Aaand my instance is down again. It's honestly a struggle to keep a Pleroma / Akkoma instance going for the long term. JSON btree gets so bloated.

Ghost's ActivityPub Integration Feels Half-Baked

Before people start calling for pitchforks, let me say this: I love Ghost, and I think they've done some great work with embracing the Social Web. To see such a massive publishing platform do this is nothing short of impressive, and I'm grateful for the work the Ghost team has done.

It's been a little over a year and a half since the Ghost publishing platform adopted the ActivityPub protocol to enable federated subscriptions and interactions. While much fanfare was made about the release, subsequent development feels like it has stalled, with minimal visibility regarding future development.

As someone who bought-in to the platform after these promises were made, I've been dogfooding the Social Web integration daily, switching my personal site over to Ghost completely. While there's much to be happy about, I can't help but feel that there are still many, many feature gaps. Today, I want to talk about what I feel Ghost is still missing.

Social Integration

Social aspects for Ghost still feel lacking in some ways, which is more than a little bit ironic, considering that ActivityPub is really meant to add social capabilities to the mix. There are several areas where I feel this really breaks down still.

Federated Subscriptions

This was supposed to be a big selling point for Ghost, and was even part of their earlier product mockups. You could subscribe to a publication in the traditional way, through newsletter memberships, but you could also use federation to subscribe from your Ghost dashboard, as well as other parts of the Fediverse.

Technically, you can do that. However, discovery for this feature on the front end of any Ghost site is practically non-existent. I have ActivityPub turned on, and if you visit my site, there is no obvious way to figure out my handle and subscribe to me.

Of course, I can tell you my handle (@sean@deadsuperhero.com), but this limitation is bad UX. Even a subscription form that redirects you to your instance dashboard to subscribe would be an improvement. Which also leads to the question: why can't followers also be considered Subscribers / Members? It makes a lot of sense to put these things together.

Social Interactions

Another weird thing involves how social interactions work in Ghost: you can't see them on my site. The only way I can access them is through Ghost's dashboard, under the Social tab. If I click on any of my articles from there, they show up.

Here's a post on my site:

Here's the same post in the dashboard:

I actually reached out to the Ghost team a while back about the possibility of migrating We Distribute over to Ghost, and this was one of the main things I asked about. Is there an officially, supported way to embed interactions directly into the frontend, and possibly also integrate status updates as well?

It wouldn't be possible (yet) to bring in replies from the AP integration to the frontend of your site. However, if you can share more about what you're wanting to do, I can write up a feature request for our team!

They got back to me, and effectively said this wasn't supported. As someone that really appreciates being able to highlight community actions for everyone to take part in, this felt like a missed opportunity.

For comparison, this is something that's pretty well-supported in ActivityPub for WordPress. I just believe that social interactions should be front and center on publication sites, especially because it can encourage further interaction across the network, and help build online communities around sites that publish!

Social Features

In terms of the social features that Ghost currently offers, the landscape feels pretty barren. Compared to Mastodon, Ghost is currently offering only a fraction of the same features.

These are basic table stakes for interfacing with the Social Web:

• Mentions
• Hashtags
• Quote Posts
• Keyword / Tag Filtering
• Full-Text Search
• Content Warnings
• Polls
• Multiple Image Attachments on posts
• Video Thumbnails
• Privacy Scopes
• Lists
• Migration of User Accounts

Granted, I'm not expecting Ghost to copy each and every feature that every other Fediverse platform has. It's just that the lack of all of these things combined leaves for a very limited social experience, which could lead to the social feed being an afterthought, and therefore underutilized by people using Ghost. As someone that really wants an all-in-one place for my Fediverse identity, this is a bummer.

Mastodon API

At this point, this is more of a nitpick over a "nice to have" feature, but it's something I actually depend on. Admittedly, it depends on having the social features I just described.

To explain it briefly: the Mastodon client API is very, very popular in the Fediverse. So much so that a lot of Fediverse platforms have implemented it for themselves, allowing them to use a wide range of social clients on Web, desktop, and mobile. This is great, because it means I can just use my existing apps to post status updates, read notifications, and interact with people.

As an added bonus, I'm able to leverage Mixpost, which is like an open source, self-hosted version of Buffer. It supports the Mastodon API, so I can go through the process of scheduling posts of status updates without having to do it all on-the-fly. I can use it to post status updates to the Fediverse with WordPress, even.

I asked Johnathan O'Nolan, one of Ghost's founders, about the possibility of implementing something like this, and he countered with the idea that maybe Ghost should just have a dedicated mobile app for the social stuff. Now, I don't expect or demand anyone from Ghost to implement this, but it would seem like having this capability would only strengthen their story for social media teams to consider using that part of Ghost regularly.

Is Development Still Happening?

My biggest concern out of all of this is that the Building ActivityPub blog seems to have gone silent some months ago. It gives the impression that, once the feature was released, everyone just packed up and went to go work on other things. Which, y'know, is fair in a small independent startup.

The problem here is a lack of insight and transparency. There really isn't a way to get good information on what Ghost is currently working on, or what their current roadmap entails. From the outside looking in, one can get the impression that there's no further development happening in this area.

Where to Go From Here?

Despite everything, I'm still sticking with Ghost for my personal site. My hope is that maybe some of the Ghost team will see this, and take some of the feedback to heart. I still think it's a phenomenal publishing platform, and I want to see it succeed over alternatives such as Medium, SubStack, and even WordPress. I just think that their Social Web offering needs a lot of love.

For We Distribute, I'm still figuring out what I want to do. My long-term goal involves finding a Fediverse-first solution to migrate to, as the integration I have for WordPress sometimes feels like a far cry from what I'm dreaming of. It works, but WordPress itself can be very frustrating. I still maintain that a good publishing system for the Fediverse ought to be built for the network first and foremost, rather than bolted on to a CMS with an integration.

Even so, the ActivityPub for WordPress team is still doing astonishingly good work, and is updating their feature offerings through leaps and bounds. Maybe if I hang in there, it will get to where I want it to be.

I'm also looking at Bonfire, which has article capabilities, but would require a lot of custom development to make something even close to what I have with Ghost.

Is Ghost still developing new Fediverse features? They haven't updated their ActivityPub newsletter in a while now.

The Fediverse and Content Creation: Monetization

One thing that I've been thinking about for a while: the PeerTube platform is somewhat limited in providing tools for video-makers to receive financial support. At best, PeerTube offers a "Support" button on videos, but all this really does is provide a lightbox with links to various donation pages.

I actually think this is a bit of a problem when it comes to getting creators to use platforms such as PeerTube or Loops. A lot of people don't really see a point in joining a whole new ecosystem when they're well-established on YouTube or Tiktok to begin with, and a lack of financial incentives might make this seem like an exercise in futility.

The majority of this post is going to be focusing on financial support mechanisms specifically, but I want to be clear that this alone is not a silver bullet solution. It's just something that I think requires a lot of attention first. I'm going to talk about a few things the Fediverse ecosystem offers to mitigate this problem, with some thoughts on how we can better support video makers on federated platforms.

Payments, Access, and Friction

There are a few sticking points here that are worth thinking about. First and foremost is that, historically speaking, most Fediverse platforms don't offer good mechanisms for providing access to special paid content. From my limited understanding, there are two parts to think about:

• Payment Systems - payments in the Fediverse is still kind of a nascent, fledgling thing. A few systems offer the capability of buying or selling things through one or two major payment processing systems, and it's usually Stripe or PayPal. Part of the headache here is that this situation inherently props up a few monopolistic platforms, rather than allowing people to use whatever payment system is available in their own countries. Some of this can be worked around using cryptocurrencies – famously, the Mitra project leverages Monero for this very purpose, although I'm told it now can accept other forms of payment as well.
• Account Access - Historically speaking, the lion's share of Fediverse platforms lack a granular system for granting permissions to remote accounts. Most platforms in the Fediverse emulate Mastodon's privacy scopes, which don't do the best job of delegating which groups of people can see or interact with something. Either everybody can see a post, or just your mutuals can. Complicating things even further, there's not a great way to set something visible to a specific someone and let them know about it, unless you're specifically sending them a Private Message directly.

What's Available Today

There are a few cutting-edge attempts to solve this problem, and I think they might offer different pieces of the puzzle.

Premium Users

One PeerTube plugin I have a lot of admiration for is simply called Premium Users, and it does exactly what you'd expect. PeerTube channels that have this integration set up offer a special paid subscription button on their pages, and it does two things:

1. It takes a Stripe transaction to process payments.
2. It takes note of which Fediverse accounts made this transaction, and adds them to a special group that can see videos intended specifically for them.

On paper, this is great! We at least have a proof-of-concept to say that hey, this thing is in fact doable. Unfortunately, there are a few shortcomings:

• Limited Utility — people can only get this special access by clicking the button on PeerTube. If they tried to pay you out of band, through something like Patreon or Kofi, there isn't a way to easily set up their Fediverse account as Premium Subscribers. The payment system has no concept of what their Fediverse identity is, and the manual way for adding people is kind of messy and confusing.
• Rigid Scope — the plugin basically has to get set up by an admin, and use their Stripe account. Users then upgrade their own PeerTube accounts to add payment, and they get upgraded to a special user type. Anyone with that user type can see "Premium" videos from anybody on the instance, and the money only goes to the instance admin. This is less than ideal.
• Vendor Limitations — it only works with Stripe at the moment, which is not necessarily what other people are using to make simple donations. Trying to account for multiple vendors might be challenging, as it means that such an integration has to abstract away the specific vendors in another layer. This is not impossible, but can be somewhat cumbersome if you're trying to just offer a simple plugin that's easy to set up.

Unfortunately, this is kind of a deal-breaker if you wanted to create something similar to YouTube's "Channel Membership" feature for the Fediverse. It's less Patreon-like, and more like a way to see all the exclusive paywalled media in one place.

At the very least, we have a proof-of-concept on how to at least broker access to special content on PeerTube using payments. It's not perfect, but maybe it could be a foundation to build on?

Granular Permissions / Circles

Some of the most impressive development on this front comes from the Bonfire project, because their system actually lets people put their contacts into special collections.

Circles, which are Bonfire's concept for addressable groups, and Boundaries, which are the permission sets that can be assigned to them.

While it can be a little bit tedious to set up manually, the main thing to understand is that this works really, really well. You can have as many collections as you'd like, they can all have special rules applied to them, and you can decide which collections can see which things you post.

From a technical perspective, I see Bonfire as a shining example for what all Fediverse platforms should follow: we need to think about access, permissions, and addressing for posts, all at the same time. You can create special custom presets today, and scope it to a specific group of people.

While I think the UX behind this is still complicated, I think the concept is solid, and a simplified version could be a very powerful way to create special scopes of friends or followers.

Paid Circles

The Emissary project has been thinking long and hard about this problem by offering Circles, which are the very user collections we've been talking about up to this point. For their Bandwagon application, the lead dev has been thinking a lot about music sales, as well as different ways to support artists. As a result, the UX is very much simplified, and more user-friendly.

Examples of how different Circles can be set up as support tiers for artists.

Bandwagon does something neat by allowing musicians to turn membership of a specific Circle into a paid subscription. This allows artists to create special private things.posts, share events for secret shows, and even offer special tracks and albums to the people supporting them.

The lead dev, Ben Pate, has gone on the record in stating a desire to support many different payment providers in order to avoid monopolization of just one or two big vendors. He gave a really good presentation about the subject back in August for FediCon 2025, and it's worth watching.

CrowdBucks

CrowdBucks is still a relative newcomer to the space, and offers a few novel approaches that are worth thinking about. It's open source, and you can host it yourself, and the project acts as a wrapper around payment integrations to provide payment status, as well as subscriber information. That includes Fediverse handles!

A demo of a CrowdBucks fundraising page.

What really sets CrowdBucks apart is this: you don't actually create an account, in the traditional sense. Instead, you log in with your existing Fediverse identity, which then allows you to financially support whoever you want, while also allowing you to do fundraising for yourself.

One other benefit I see to having services like CrowdBucks is the benefit of decoupling payment infrastructure away from Fediverse instances. Rather than trying to get a bunch of different platforms and instances to try to juggle Stripe and PayPal API keys for admins and users, it would probably be way easier to just handle the actual payment action on a separate layer outside of the social platforms themselves. Instead of every creator trying to sign into a bunch of different services, they could just authenticate against their CrowdBucks payment server instead.

Honorable Mention: Mitra

Although the project isn't as well-known as some of the other efforts on here, it's important to acknowledge Mitra and what it has pioneered. In a nutshell, this is a simple, stylish Fediverse platform that has paid subscription capabilities built in.

Subscribing to an account results in a dialogue to determine how much you're supporting a creator per month.

In a lot of ways, Mitra predates almost all of the other attempts to incorporate payments into the Fediverse. The lead dev behind it, Silverpill, is very active in the Fediverse Enhancement Proposals community, which aims to help extend ActivityPub capabilities in a somewhat standardized, grassroots way.

Mitra has experienced some friction in being adopted by the wider Fediverse due to an ideological divide: historically, the platform has only supported Monero for payment, and the wider Fediverse itself doesn't generally hold a positive view on cryptocurrencies to begin with. A recent release no longer strictly requires Monero, but some glue code would still need to be written to support payment processors.

Putting It All Together

So, we have all of these different pieces. Can we use them together to accomplish what we want?

Let's say that we use CrowdBucks as the middleware that wraps around potentially many different payment solutions. It offers an API, can capture information about who is paying you for something, and can potentially even denote what thing they're paying for specifically. Great! Upon initial payment, a special follow request could get forwarded to the creator's account, which automatically gets approved upon proof of payment.

A plugin or integration could directly hook up to CrowdBucks, and then automatically put that paid subscriber into a dedicated Circle as a permission scope that can see stuff intended just for them. Additionally, this special follow request could also enable special notifications that tells the subscriber when new stuff is available to them.

A lapse in payment or cancellation could also be handled automatically through CrowdBucks, resulting in the Subscriber being automatically removed from the Circle after a set period of time.

Limitations

This concept is not without a few different headaches. Let's talk about them.

Currency Support

While a fair amount of payment processors are set up to handle international currency exchanges, the experience could be messier for platforms that aren't set up to handle it.

This is particularly glaring in situations where one person might want to pay with cryptocurrency, and the recipient doesn't actually accept that.

What might make sense is for CrowdBucks to allow people to plug in a multitude of different payment providers, defaulting to a "path of equilibrium" where the payee and recipient both go through whatever payment system they both have in common. The alternative is to basically establish some kind of escrow/transfer service for money in various forms, and that can get pretty complicated.

Fediverse Identity

Identity in the Fediverse is still somewhat flaky and non-standard. The secret sauce that CrowdBucks uses for Fediverse Login is really just a series of platform-specific integrations, such as "Sign in With Mastodon", "Sign in With Pixelfed", and "Sign in With PeerTube".

This isn't a great experience for anyone that's not using those specific platforms. Theoretically, we should all be using the ActivityPub Client-To-Server API for platform-agnostic Identity Login, but the biggest players such as Mastodon have yet to really embrace C2S in any way, shape, or form.

If we could all rally around C2S for at least this singular use-case, we might be able to have a universal login system for the entire network.

Ecosystem Support

Finally, the biggest headache here is buy-in. It's very challenging to get a bunch of different groups of people to align to a common set of goals, implementations, and methodologies.

My thinking here is simple: if we can get some level of integration working for PeerTube, Pixelfed, Loops, and any other federated platform where such a thing might be handy, we might be able to make major strides in solving this problem.

I'm Still Optimistic

While I think we still have a long way to go before we get to a place where there's a clear-cut "standard experience" on how these things should happen, it's evident that there are a lot of pieces being developed that could be made to work together.

I hold the view that commerce, understood through the lens of "the marketplace or bazaar at the center of town", could be extremely beneficial for the Fediverse. If we are to build this thing, it's going to require a lot of careful consideration, with different builders comparing notes on how they're currently doing it.

Anyway, thanks for reading!