Upstream published 8.2.3 on July 20, 2026. It is a patch release, but the changelog opens with four security changes before moving through fixes for live streaming, embedded players, background jobs, object storage, and federation.
P.LU was already running PeerTube 8.2.2, so this was a direct patch upgrade with no intermediate releases to account for.
The PeerTube 8.2.3 release notes place four changes under the security heading:
The release note does not assign severity ratings, CVE or GHSA identifiers, or a separate affected-version range to these four changes. Without that information, we are treating them as upstream security hardening and avoiding claims about exploitability that PeerTube has not made.
Several fixes address the paths viewers are most likely to notice:
Invalid width to find appropriate image errorThese fixes cover both ordinary playback and the less visible state transitions around a live session. That combination matters on a public video service: a stream can look healthy in the player while cleanup or quota bookkeeping is already going wrong behind it.
PeerTube 8.2.3 fixes an infinite loop in S3 pagination and cleans up several background-job problems. Refreshes of remote objects are deduplicated correctly, scheduled jobs should no longer run more often than needed, and file-move jobs now consume their configured attempts before the error handler takes over.
Runner jobs also clean up their temporary directories correctly. For instances using object storage or remote runners, these are operational fixes rather than cosmetic ones: they reduce duplicate work and prevent failed jobs from leaving avoidable state behind.
The release also tightens several edges around remote data and long-running requests:
youtube-dl returns no dateOther user-facing fixes include the channel link on iOS, clearer feedback when the backend returns HTTP 502, removal of a private video linked to an abuse, and a set of right-to-left layout corrections.
The 8.2.3 release notes do not announce a new database migration, configuration change, or runtime requirement for this patch. P.LU moved directly from 8.2.2 to 8.2.3.
The useful post-deployment checks are correspondingly focused: confirm that the running server reports 8.2.3, test a restricted embed and a password-protected live stream, and watch scheduled jobs, remote-object refreshes, and object-storage moves for unexpected retries.
P.LU is now on PeerTube 8.2.3. This patch is mostly about enforcing checks correctly and making failure paths terminate cleanly—the sort of maintenance work that keeps a federated video service predictable under real traffic.
]]>Every donation this month was made for C.IM. These contributions go directly toward server costs, storage and bandwidth, and the company overhead that keeps our platforms running independently.
| Item | Amount |
|---|---|
| C.IM servers | €200 |
| P.LU servers | €100 |
| R.NF servers | €20 |
| Image.Hosting servers | €10 |
| Estonian company maintenance | €159 |
| Item | Amount |
|---|---|
| Cloudflare CDN & R2 (S3-like) usage | $229.73 ≈ €197.57 |
| Stripe processing fees | €3.44 |
As always, we publish these numbers so you can see exactly where donations go and what it costs to run the platforms.
If C.IM is part of your daily routine and you’d like to help close the gap, you can donate here.
Recurring donations are especially helpful — they let us plan infrastructure spending with more confidence each month.
]]>relay.c.im will shut down permanently on October 31, 2026.
If your instance is already subscribed, you do not need to disconnect it by hand. When the relay stops, delivery stops with it. Admins who rely on relays should add another one before October 31, 2026.
New subscriptions are closed as of today.
relay.c.im has been our free public ActivityPub relay for small Fediverse instances that want more posts in their federated timelines and hashtag results.
A relay sits between subscribed servers. Servers publish public posts to it, and it sends those posts back out to the other subscribed servers. As relay.toot.io explains, this can help new or smaller servers see more of the Fediverse. It also costs storage, CPU, and moderation time.
The upstream software we use, ActivityRelay, has been quiet for too long. When we checked on July 6, 2026, the public repository showed April 22, 2025 as the latest visible commit. Running federation software with that little maintenance is a security and compatibility risk.
relay.c.im also does not do much for our own network anymore. C.IM already federates with more than enough instances. A relay helped more in the early days, when discovery and federation reach were thinner.
The subscriber list has collected a lot of dead or unreachable instances. Cleaning that up one domain at a time is busywork, and we have better things to spend admin time on.
There are also better-maintained public relays already doing this job. Keeping our own relay alive just to duplicate that work does not make sense.
From July 6, 2026, relay.c.im no longer accepts new subscriptions.
On October 31, 2026, the relay will stop delivering activities permanently. We plan to return 410 Gone from the relay inbox for a while after shutdown so subscribed servers can fail cleanly instead of retrying forever. After that, the domain may stop resolving.
If your instance does not rely on relays, no action is needed.
If your instance does rely on relay.c.im, add another relay before October 31, 2026. Two public options to check are relay.toot.io and relay.intahnet.co.uk. relay.toot.io lists https://relay.toot.io/inbox for Mastodon, Misskey, and forks. relay.intahnet.co.uk lists https://relay.intahnet.co.uk/inbox for Mastodon and Misskey. Pleroma-family software, including Akkoma, should use the relay’s /actor endpoint instead.
For a broader directory, use Relay List. It tracks public ActivityPub relays, registration status, online status, and participating server counts. Read the warnings there before adding a relay. Relays increase storage, compute, and moderation load.
For Mastodon, go to Preferences → Administration → Relays, choose Add new relay, paste the new relay inbox URL, and save. After the new relay is connected, remove relay.c.im from the same page.
Thank you to the admins who used relay.c.im over the years. It did its job.
This change affects only the public relay. Our other Owl Owl services, including C.IM, P.LU, R.NF, and Image.Hosting, are not affected.
]]>The joke worked because the speaker had no need to bluff. Prodromou is one of the five authors listed on the W3C ActivityPub Recommendation and the author of O’Reilly’s ActivityPub book. The self-deprecating frame covered an honest architecture talk about why the Fediverse works at all.
His running gag was that every term could be treated as a portmanteau. Fediverse is federated plus universe. ActivityPub is activity plus publishing. RESTful, in his groaner version, is rest plus full. Fine. Protocol people deserve hobbies too.
Behind the jokes was a serious claim: ActivityPub works because its core is intentionally ordinary. It is impressive in the way a good loading dock is impressive. Trucks arrive. Boxes move. Nobody writes a poem about the forklift.
Any competent Web engineer from the mid-2010s could look at ActivityPub and think, yes, this is roughly how I would have done it.
If you want the primer before the argument, start with What Is ActivityPub?. This piece is about why those familiar parts mattered.
Federation starts with a modest agreement. Independent networks agree to exchange activity data. They do not agree on a database, a moderation model, an admission policy, a user interface, a ranking system, or a product category.
That minimum agreement is the important part. Mastodon, PeerTube, Lemmy, WriteFreely, Pixelfed, WordPress, and small single-user servers keep their own shape. It is why our Mastodon service on C.IM, PeerTube service on P.LU, and Lemmy service on R.NF can share a social graph without becoming one product.
The ActivityPub specification describes two layers: a client-to-server API and a server-to-server federation protocol. In practice, the server-to-server part is where most Fediverse operators feel the machinery. Actors have inboxes and outboxes. Servers deliver activities to remote inboxes. Other servers fetch actor documents, objects, and collections by URL.
The model is almost aggressively plain. An activity is a sentence: subject, verb, object. Alice liked the article. Bob followed Alice. A server created a note. Someone announced a post. The thing crossing the wire is often the sentence about the content, not merely the content itself.
That distinction makes ActivityPub social. A content-sync protocol can move articles and images. A social protocol also has to move reactions, follows, blocks, shares, undo operations, and the context that makes those actions meaningful.
Prodromou’s funniest historical aside was that the activity concept traces back to 1930s Soviet activity theory, associated with psychologist Alexei Leontiev, and then wandered through user-experience research before landing in Activity Streams. The Fediverse running on repurposed Marxist psychology sounds like satire written by committee. Protocol concepts rarely arrive cleanly from first principles; they get dragged in from wherever the previous generation left useful tools.
The transport is even less exotic. ActivityPub uses HTTP. Fetch an actor’s URL to learn about the actor. POST an activity to an inbox to deliver it. The spec’s overview says the quiet part directly: inboxes and outboxes are URLs, and federation usually happens by servers posting messages to other servers’ inboxes.
Even the familiar user@domain handle is not fundamental to ActivityPub. It comes through WebFinger, a modernization of older Internet identity lookup habits. The protocol needs identifiers. Humans like handles because @alice@example.org fits in a search box better than a full actor URL.
This is why ActivityPub spread. JSON-ish objects, HTTP GET, HTTP POST, URLs, collections, actors, inboxes, outboxes. None of this is dazzling. Boring is implementable.
Boring protocols still accumulate weird debt. ActivityPub has a good example sitting in authentication.
The Fediverse commonly uses HTTP Signatures for server-to-server request authentication. The awkward part is which HTTP Signatures. The deployed Fediverse grew around the older draft-cavage-http-signatures-12, an Internet-Draft that is now expired and archived. The IETF work later produced RFC 9421, HTTP Message Signatures, published in February 2024, with a different design.
Minimum-consensus evolution looks like this in practice: a draft is useful enough, implementers ship, the network grows, and the official standard arrives later with a different shape. Nobody can fix that by saying “the spec says” loudly at a server log.
Security has another blunt edge. ActivityPub has addressing. A to field can say which actor or collection an activity is intended for. Servers can deliver only to addressed recipients, and they can check authorization when someone fetches a private object. The ActivityPub spec explicitly allows servers to require authorization and return 403 or 404 when a request should not see a target object.
That gives the Fediverse an access-control model. It does not give it end-to-end encryption.
Content usually sits in cleartext on the instance that hosts it. Admins with database or filesystem access can read what their server stores. Backups, object storage, logs, full-text indexes, and search pipelines can widen the practical trust surface if an operator is careless.
For instance admins and self-hosters, this is the operational truth worth writing on the wall: the instance is the trust boundary.
Running your own server can shrink that boundary to infrastructure you control. Choosing someone else’s server means choosing an operator, their security practices, their backup habits, their incident response, and their judgment. That is the direct consequence of a federated publishing system without built-in end-to-end encryption.
Open by default sounds clean until abuse arrives with a working DNS record.
ActivityPub lets anyone put a compatible server on the network. There is no department of the Fediverse where a new instance asks for a license. That openness is essential. It is also why defederation exists.
Defederation is the rough defense mechanism for a rough world: one server blocks another server. There is no president of the Fediverse. Blocks happen locally, sometimes coordinated through shared blocklists, public warnings, private admin channels, and community memory. Obvious abuse can trigger a fast cascade. Ambiguous cases become slow, political, and deeply human.
This is where the minimum viable agreement stops being enough. A protocol can define how to deliver a Create activity. It cannot decide which community should accept a server that has weak moderation, hostile users, a spam problem, or a different theory of speech.
The standards process has its own version of this tension. W3C consensus moves slowly because it is supposed to move together. That works when the goal is interoperability rather than speed. It becomes harder once the installed base is real.
Prodromou framed the problem clearly in the Q&A. ActivityPub still has room to be invented, but it already has more than a hundred implementations and tens of millions of users whose social graph should not be broken by a clean-sheet rewrite. Every improvement has to negotiate with existing software.
Even the language around the network carries governance history. “Social web” and “Fediverse” are technically close relatives, sometimes near-synonyms. “Fediverse” also carries the identity of the 2017 to 2022 wave: free software, open standards, LGBTQ communities, safety-conscious communities, left politics, anarchist politics, and a strong sense of “us” developed against large platforms that had already failed them.
That cultural memory affects protocol adoption. Bluesky can be bridged through Bridgy Fed. From one side, bridged Bluesky accounts may look like part of the Fediverse. From the other, the same bridge may look like ActivityPub accounts appearing in the Atmosphere.
Prodromou’s answer to “when has ActivityPub won?” was intentionally uncomfortable for some parts of the Fediverse.
Victory is not merely a thousand cozy instances, each with good local norms and a donation page that almost covers the object-storage bill. That world is valuable, but it does not change the default assumptions of the Internet.
His win condition was two or more hundred-million-user commercial networks federating over ActivityPub. Think Threads plus another large network such as LinkedIn or Snap. At that point, small independent servers could still participate as peers in the same network as the giants.
A huge commercial platform joining ActivityPub is both a validation of the standard and a threat to the culture that kept the standard alive. If the open protocol is strong enough, large platforms become participants. If it is weak, they become gravity wells.
Prodromou also pointed to large Chinese social networks as an opportunity: hundreds of millions of users, mostly disconnected from the global social web, potentially able to interconnect on their own terms through an open protocol. ActivityPub’s ambition is not to be a nicer microblogging club. It is connective tissue for social software.
The historical warning came from the late 1990s web. Dynamic web content could have gone through Java applets, controlled by Sun, or ActiveX, controlled by Microsoft. The boring outsider path was JavaScript. It took years, a lot of pain, and standards work for the open option to become the default.
The Fediverse should not assume it gets the same happy ending automatically. Large platforms can arrive with proprietary “solutions” for identity, portability, search, ranking, payments, moderation, trust, or quote posts, then try to turn deployment scale into standards authority. The open answers have to ship first.
On January 15, 2026, W3C chartered a new Social Web Working Group chaired by Darius Kazemi. The active charter runs through January 31, 2028 and covers maintenance for ActivityPub, Activity Streams, Activity Vocabulary, WebSub, Micropub, Linked Data Notifications, Webmention, and related notes.
For ActivityPub operators, the most immediate milestones are deliberately modest. The charter lists expected completion in Q3 2026 for updated ActivityPub, Activity Streams, and Activity Vocabulary documents. Prodromou described the ActivityPub work as backward-compatible and largely editorial: clarify underspecified areas, document what existing implementations already depend on, and make the standard easier to implement without breaking the network that exists.
The current ActivityPub Recommendation is stable, but it is also a 2018 document carrying the assumptions and omissions of that moment. Common Fediverse content types and behaviors often live across ActivityStreams vocabulary, implementation practice, FEPs, project-specific extensions, and admin folklore. A maintenance revision that turns some of that into clearer text is exactly the sort of work operators notice only after fewer things fail strangely.
The same charter names LOLA as a tentative deliverable that the Working Group may adopt as a Recommendation-track specification, depending on incubation progress, implementer interest, and group consensus. LOLA is a proposal for live online account portability between ActivityPub servers at a user’s request. Its draft covers copying content, moving following relationships, notifying followers, redirects, and the trust decisions involved when one server asks another for a user’s account data.
Portability is where the boring protocol has to protect users from boring lock-in. If leaving a server means losing posts, followers, reactions, media, and social context, the Fediverse has recreated the trap with more domains in it.
After the maintenance revision, the conversation can move toward an eventual ActivityPub 2. The right model may look less like a flag day and more like HTTP evolution: old versions keep working while capable peers negotiate better behavior. Backward compatibility is how a social network avoids cutting its own graph in half.
The hard engineering ahead is not making ActivityPub cleverer. Clever protocols are easy to admire and hard to deploy. ActivityPub won because it made federation feel like ordinary Web plumbing. Now the network is growing into the parts that are less ordinary: signatures, privacy, moderation, portability, commercial scale, and standards governance under load.
The next phase should keep the machinery boring while the politics, economics, and user counts stop being small.
The FediForum recording is worth watching because the jokes make the architecture easier to remember.
]]>PeerTube 8.2.2, published on July 2, 2026, is the kind of release admins should not leave sitting in the queue. Upstream’s note is short: administrators should upgrade immediately, and the affected range is PeerTube 8.2.1 and earlier.
The PeerTube 8.2.2 release notes say this release fixes vulnerabilities ranging from medium to high severity in PeerTube <= 8.2.1. It also includes security hardening.
Upstream has not published CVE identifiers, affected endpoints, exploit details, or a technical write-up yet. The same release note says those details will be added in a few weeks. Until then, the useful admin fact is the version boundary.
For P.LU, that was enough. We were on PeerTube 8.2.1, inside the affected range, so we patched before the disclosure window instead of waiting for more detail.
Security is the reason to update. The release also fixes a few rough edges:
loadByIdOrUUID and loadByIdOrUUIDWithFiles now accept short UUIDsThese are small fixes, but small fixes are where public instances lose time. Embeds, captions, plugin helpers, and move jobs are the sort of things people notice after they have already broken.
P.LU moved directly from PeerTube 8.2.1 to 8.2.2, so there were no intermediate PeerTube releases to fold in.
Upstream does not list new runtime requirements or configuration changes for 8.2.2. After deploying the new tag, the checks are plain: confirm the running version, restart the PeerTube services, and keep an eye on captions, embeds, and move jobs during normal use.
That is the whole update. P.LU is on 8.2.2, and we will revisit the changelog if upstream publishes more security detail later.
]]>C.IM was previously on Mastodon v4.6.1. This upgrade brings in the v4.6.2 security release and Mastodon’s v4.6.3 patch set from July 3, 2026.
Mastodon lists dependency updates under the v4.6.3 security section.
v4.6.2 matters here too. Upstream shipped that tag solely to rebuild the official Mastodon Docker container images with a fixed FFmpeg for CVE-2026-8461, which the release notes classify as critical severity.
For instances that do not use the official Mastodon container images, the application tag is only part of the check. FFmpeg still has to come from a fixed package or local image. Upstream lists the fixed versions as 8.1.2, 7.1.5, 6.1.6, or 5.1.10.
Mastodon v4.6.3 adds an “Update available” item to the navigation when a newer Mastodon version exists. Small thing, useful thing. Update visibility should not depend on someone remembering to check GitHub.
Post images now render in emails as well. Since Mastodon 4.6 introduced public-post email subscriptions, emails with attached media should now look closer to the posts they came from.
Most of v4.6.3 is cleanup around the 4.6 web interface and background jobs:
tootctl media lookup failure on some setupsNone of these are large features. They are the sort of fixes that make the 4.6 series less noisy on a public instance.
External dependency requirements have not changed since Mastodon 4.6.0:
The v4.6.3 upstream notes mark this release as requiring asset recompilation for non-Docker installs. The published update steps are to install dependencies, precompile frontend assets, and restart all Mastodon processes. Docker-based deployments need to restart all Mastodon processes after pulling the new image.
C.IM was on v4.6.1 before this update, so the v4.6.2 notes were part of the upgrade window. The extra check is FFmpeg, especially for anyone using upstream container images or managing FFmpeg as a system package.
C.IM is now running Mastodon v4.6.3. Users should mostly notice fewer rough edges in the 4.6 web UI and better email rendering when posts include images.
On the admin side, the boring part is the important part: keep FFmpeg patched, rebuild frontend assets where required, and restart all Mastodon processes after the update.
Source code for our instance is available at:
]]>The official project site is joinmastodon.org, but the Mastodon network itself is not one domain with one global database behind it. Mastodon is open-source social networking software that many independent servers can run. Those servers can connect to each other, so an account on one server can follow, mention, reply to, and be followed by accounts on other servers.
Mastodon takes the social network apart into smaller pieces: operators, communities, rules, and software that agree on a shared protocol.
The Mastodon project describes the software as a free, open-source social network server based on ActivityPub. A server can publish text, links, images, audio, video, polls, and other social objects. Users can follow friends and find new accounts much like they would on a familiar microblogging service.
The familiar interface hides the main difference. Mastodon’s own server directory says plainly that Mastodon is not a single website. To use it, you make an account with a provider, and Mastodon calls those providers servers. Older posts and admins often call them “instances”. The words usually mean the same thing in casual Fediverse conversation.
An account name has two parts: the username and the server. @alice@example.org identifies Alice’s account on example.org, in the same way an email address belongs to a domain.
That domain matters. The server stores the account, serves the profile, receives posts from other servers, applies local moderation policy, queues background work, stores media, and handles the boring parts users only notice when they break.
From a user’s side, Mastodon looks familiar. You create a profile, post updates, attach media, follow people, reply, boost, favorite, mute, block, and report. Mastodon’s posting documentation says the default character limit is 500 characters, with media attachment support for images, video, audio, and polls. Individual servers and forks can change limits; on July 3, 2026, C.IM’s public instance API reported a 5,000 character post limit.
The home feed feels different from the ranked timelines people are used to elsewhere. Mastodon’s homepage describes a feed with no algorithms or ads and chronological posts from followed accounts. Servers still have arguments, bad posts, and moderation mistakes. The default product is not built around selling ranked attention to advertisers.
For operators, that design choice is not a slogan. A Mastodon server still has costs: compute, object storage, email delivery, moderation time, backups, upgrades, abuse handling, and the occasional weekend spent reading Sidekiq queues while pretending this is a hobby. Removing advertising does not remove the bill. Someone still pays it, usually much closer to the community using the server.
Mastodon federation uses ActivityPub. The W3C ActivityPub Recommendation was published on January 23, 2018, and defines both a client-to-server API and a server-to-server federation protocol for delivering content and notifications.
Email is the easiest comparison. Gmail, Fastmail, Proton Mail, and a self-hosted mail server can exchange messages because they agree on mail protocols. They do not need the same owner, UI, spam filter, storage system, or business model.
Mastodon servers work similarly for social actions. Your account has an ActivityPub actor document with endpoints such as an inbox and an outbox. When you follow someone on another server, your server sends a Follow activity. When that remote account posts, the remote server can deliver a Create activity to your server. Your client then shows the result in your timeline.
Plenty of other software speaks ActivityPub too. PeerTube, Pixelfed, Lemmy, WriteFreely, and other Fediverse projects use the same general protocol family. That is why a Mastodon account can follow a PeerTube channel or interact with posts from non-Mastodon software when both sides support the needed ActivityPub behavior.
Federation is real interoperability, with rough edges. Different software can interpret objects differently. Replies can look incomplete from one server and fuller from another. Some servers block each other. Some servers disappear. The protocol gives the network a common language; operators still have to run the network.
Centralized social networks usually have one top-level policy system. Mastodon pushes more of those choices to servers.
Every server is operated by an independent person or organization, and Mastodon’s server directory warns that providers may differ in moderation policies. A small art community, a public institution, a language-specific server, and a personal single-user server do not need the same rules.
Moderation is local by design. Mastodon’s admin documentation says moderation actions are applied locally as seen from a particular server. An admin on one server cannot directly delete a user from another server; they can limit, suspend, or reject that remote account’s local presence. For whole-server problems, Mastodon supports domain blocks with levels such as rejecting media, limiting a server, suspending a server, and importing blocklists.
People often read “decentralized” as “unmoderated”. Mastodon is closer to distributed moderation. Communities get more control, and users get more homework. Choosing a server is closer to choosing an email provider, a neighborhood, and a sysadmin at the same time.
Mastodon’s own promoted server list adds a baseline. Servers listed there commit to the Mastodon Server Covenant, including active moderation against racism, sexism, homophobia and transphobia, daily backups, emergency admin access, and at least three months’ notice before shutdown. That covenant applies to servers Mastodon promotes, not every server on the internet.
The video script says Mastodon instances are usually crowdfunded. Many are, but the claim is too broad as written.
Mastodon’s documentation is more precise: the software itself does not implement monetization strategies, while server operators may use paid accounts, existing company infrastructure, crowdfunding, or personal funds. The same page says Mastodon development is crowdfunded through Patreon and OpenCollective, and that no venture capital is involved.
Mastodon is not financed by one ad business that owns the whole network. It is also not cost-free. Every server has to solve its own funding, capacity, legal, and moderation problems. Some do that well. Some do it for a while. Some close.
As of July 2, 2026, Mastodon’s public statistics API reported 7,877 servers, 10,357,373 registered users, and 722,073 monthly active users.
The same API shows a modest one-month trend: server count drifted down from roughly 8,030 at the start of June 2026 to 7,877 on July 2, registered accounts rose slightly, and monthly active users moved from the mid-730,000s to 722,073.
There is no single central database of every account on every server, so those figures need careful wording. They are useful, but they are not the same kind of number a centralized platform can produce from one internal analytics database. Public Fediverse statistics depend on reachable servers, reporting behavior, crawling, software compatibility, and duplicate or abandoned accounts. Treat them as a measured public snapshot, not a census.
The older “over a million registered users” line from early Mastodon explainers was true for its time. In 2026, it undersells the registered-account count and overstates our ability to produce one perfect live total.
Mastodon is harder to capture than a single corporate platform because no one company owns every server, account, timeline, and moderation queue. A company can buy one server. It cannot buy the whole protocol with one acquisition contract.
Your account still depends on your home server. That server can close. A government or network provider can block a domain. An admin can change policy. A storage failure can hurt if backups are bad. A community can split over moderation decisions because communities do that, usually with spreadsheets.
Decentralization changes the failure mode. Instead of one global platform outage, sale, policy change, or API shutdown, the network has many smaller points of failure and many paths around them. Healthier, often. Maintenance-free, no.
For users, the practical rule is simple: choose a server whose policies, funding model, jurisdiction, and admins you can live with. For operators, the rule is less poetic: publish clear rules, patch quickly, keep backups, monitor federation queues, document shutdown policy, and do not pretend moderation is an optional plugin.
C.IM is our Mastodon server. P.LU runs PeerTube for video. R.NF runs Lemmy for discussions. They are separate services, but ActivityPub lets them sit on the same Fediverse map.
A C.IM user can follow people on other Mastodon servers. In many cases, they can also follow compatible accounts or channels from other ActivityPub software. Every app keeps its own shape. The social relationship can still cross the server boundary.
So, what is Mastodon?
It is a social network, but that answer is too small. Mastodon is open-source microblogging software for a federated social web: many servers, many communities, one shared protocol, and no single owner of the whole conversation.
]]>Pause there. A Twitter account cannot follow a YouTube channel in the same native way. You can paste links between the two, of course. You can embed, cross-post, and automate a few things if both sides allow it. But the follow relationship itself belongs to each company’s platform.
The Fediverse takes a different route. Mastodon, PeerTube, Lemmy, Pixelfed, WriteFreely, and a long list of smaller projects speak ActivityPub. Think of it like SMTP for social software. Gmail, Outlook, and a self-hosted mail server do not need the same owner or the same interface to exchange email. They need a shared delivery format.
ActivityPub gives social apps that shared format.
ActivityPub became a W3C Recommendation on January 23, 2018. W3C is the standards body behind many web specifications, so the recommendation gave implementers something stable to target.
The ActivityPub specification covers two jobs. One is client-to-server: an app talks to your home server to create, update, or delete content. The other is server-to-server: your server delivers activities to other servers and receives activities from them.
Most people notice the server-to-server part first. You follow someone on another domain. Your server stores that relationship. When the remote account posts, your server receives the activity and puts it where your client can show it.
ActivityPub was already running in the wild before the W3C date. W3C’s announcement said it was deployed across thousands of Mastodon instances with more than one million registered users. Mastodon had also moved early: the v1.6.0 release notes, published on September 10, 2017, called ActivityPub Mastodon’s primary protocol while keeping OStatus compatibility during the transition.
The older federated social web had OStatus. It worked, and it deserves credit for that. It also asked developers to assemble several pieces at once: Atom, Activity Streams, WebSub, Salmon, and WebFinger. The OStatus history reads like a pile of reasonable standards that became awkward when every new server had to implement the whole bundle.
OStatus also came from a microblogging world. A short status update fit naturally. A video platform or forum could use the same network, but the fit was less comfortable.
ActivityPub did not remove all complexity. Anyone who has debugged federation queues knows better. It did give developers a cleaner set of concepts: actors, inboxes, outboxes, and activities such as Follow, Create, Like, Announce, and Delete.
Dry, yes. Good protocols usually are.
For a deeper look at why that plainness matters, see ActivityPub Won by Being Boring.
An Actor is the account, channel, group, or service that does something. In Mastodon it is usually a person account. In PeerTube it might be a channel. The ActivityStreams vocabulary includes actor types such as Person, Group, Organization, and Service, and ActivityPub actors expose endpoints such as an inbox and outbox.
The mailbox metaphor is useful enough here. The outbox is where an actor publishes activities. The inbox is where another actor receives them. The ActivityPub overview describes that shape directly: clients can post to an actor’s outbox, and federated servers can post to a remote actor’s inbox.
The verbs say what happened. Follow asks for updates from another actor. Create wraps new content. Like records a favorite or approval. Announce is the activity behind a boost or share. Delete tells other servers that an object should go away. The server-to-server section is where those delivery rules become federation behavior rather than just JSON vocabulary.
Then there is lookup. People type handles such as @alice@example.org; servers need actor URLs and inbox URLs. Mastodon’s WebFinger documentation describes the lookup from user@domain to actor profile URI, and the underlying WebFinger protocol is RFC 7033.
WebFinger is not DNS. The comparison is still useful: DNS helps software find a host; WebFinger helps Fediverse software find the actor behind a handle.
Mastodon, PeerTube, and Lemmy do not become the same app because they use ActivityPub. They only agree on enough grammar to pass messages.
Mastodon usually publishes a short post as a Note. PeerTube can publish video objects. Lemmy deals in communities, posts, links, and comments. The ActivityStreams vocabulary has room for object types such as Note, Video, Page, Article, Image, and Audio, so a server can describe both the object and the activity around it.
The receiving software still has work to do. Mastodon may show a PeerTube upload as a status with a video preview. PeerTube may show a Mastodon reply as a comment. Lemmy may display a remote account inside a thread. Some of this is smooth; some of it is awkward. Federation is real, but presentation is still software-specific.
Email is the closest everyday analogy. Gmail and a self-hosted mail server do not share a UI, storage engine, spam filter, or business model. They can still exchange messages because they agree on delivery.
ActivityPub applies that idea to follows, posts, replies, boosts, and related social actions.
In practice, the P.LU and C.IM flow is not mysterious.
Log into C.IM with a Mastodon client. Copy the address or profile URL of a PeerTube channel on P.LU. Paste it into Mastodon’s search box. If you pasted a Fediverse handle, C.IM uses WebFinger to resolve it. Then C.IM fetches the actor document and learns where that actor receives activities.
When you click Follow, C.IM sends a Follow activity to the P.LU actor. After the relationship is accepted, future uploads can be delivered as ActivityPub activities. A new video on P.LU becomes a Create activity containing the video object, and C.IM receives it in the relevant inbox.
From the user’s side, the result is simple: a PeerTube upload appears in a Mastodon timeline. From the operator’s side, the useful part is even simpler. We do not need a private C.IM-to-P.LU bridge for this. Both services already speak the same protocol.
R.NF uses the same general idea through Lemmy. Lemmy is built around communities and threads rather than timelines and channels, so the interface feels different, but the federation model is still ActivityPub.
ActivityPub is no longer a lab demo. W3C’s 2018 announcement already mentioned more than one million registered Mastodon users across thousands of instances. After Elon Musk’s October 2022 Twitter acquisition, public statistics summarized by ThinkImpact describe Mastodon monthly active users jumping from the hundreds of thousands to more than 2.5 million by late 2022.
The network did not stay at that peak, which is worth saying plainly. A May 2026 snapshot from The World Data puts Mastodon monthly active users around 750,000 to 1 million, with more than 10.5 million registered accounts, 10,475 active instances, and more than 1.18 billion posts. The same page estimates more than 11 million registered accounts across the wider Fediverse.
These numbers are not exact. Fediverse statistics come from crawlers, opt-in reporting, and public instance data. Servers appear, disappear, block crawlers, misreport, or simply stop publishing useful counts.
Federated Works makes that caveat explicit while summarizing data from Fediverse Observer and related sources. Its January 17, 2024 snapshot listed about 13.7 million users, 3.5 million active users, 1.2 billion posts, and 22,456 reporting servers.
The rough order of magnitude matters more than the exact row in a table. ActivityPub is big enough that operators run into real caching, moderation, queue, and compatibility issues. It is also visible enough that larger platforms have had to respond. Threads began limited ActivityPub federation work in 2024, and 2025 reporting still described that work as expanding but incomplete. Standards tooling is still moving too; the public ActivityPub summary records Germany’s Sovereign Tech Fund supporting a compliance test suite with EUR 152,000 in 2023.
ActivityPub gives servers a common language. It does not make every Fediverse product feel perfectly joined up.
Account migration is the obvious example. Mastodon’s account moving documentation says a profile move can transfer followers if the remote software supports the Move activity. Posts do not move. Follows, blocks, mutes, and bookmarks need separate export and import steps. Moving followers is useful, but it is not a full account clone.
Remote conversations can also look incomplete. In a Mastodon discussion about missing replies, a maintainer explained that Mastodon does not guarantee it has every reply to every remote post. Fetching every possible conversation would create a lot of extra traffic. The user-facing version of that tradeoff is familiar: stale counts, missing replies, or a thread that looks fuller on one instance than another.
Usually, that points to implementation and synchronization rather than a protocol that cannot carry the data. Users do not care much which layer is at fault when a reply is missing.
The standards process has its own friction. A W3C Recommendation is stable, which operators like. Changing it is slow, which developers notice. Much of the Fediverse advances through extensions, implementation practice, and community convention before it feels standard.
ActivityPub lowers the cost of leaving a single company’s social graph. It does not remove trust from the system.
Your home instance still matters. Its admins set moderation policy. Its infrastructure handles your account, media, queues, backups, and abuse reports. Its jurisdiction and operating model matter too, especially if you care about privacy and long-term access to your own social identity.
For Owl Owl OÜ, C.IM, P.LU, and R.NF belong in the same story. They are not one giant app. They are separate services for microblogging, video, and discussion, hosted in the EU and built around open-source software that can participate in the same network.
The practical point is modest, which is probably the best way to state it. A post, a video, and a discussion thread do not have to live inside one corporate product to be connected. ActivityPub is the boring machinery that makes that possible.
]]>That second release was not a feature release. It did not redesign the web UI, add a federation feature, or change how users post. The Mastodon 4.6.2 release notes say the release was made solely to update FFmpeg in the official Docker container images to fix CVE-2026-8461. If you were not using those Docker images, the instruction was still blunt: make sure the system FFmpeg is updated to a fixed version, such as 8.1.2, 7.1.5, 6.1.6, or 5.1.10.
The corresponding Mastodon commit is almost comically small, which is usually how serious infrastructure work looks when it is done correctly. b90dcd0 changes one file, with one line added and one line removed: ARG FFMPEG_VERSION=8.1.1 becomes ARG FFMPEG_VERSION=8.1.2 in the Dockerfile.
Mastodon did not become a media decoder project overnight. It processes media, FFmpeg handles the dangerous part, and when FFmpeg shipped a fix, Mastodon had to move.
People keep calling this an “AI vulnerability” problem. The better description is speed. AI is shortening the gap between code, discovery, reports, patches, releases, and the awkward final step: proving the fixed binary is the one actually running.
CVE-2026-8461 is an out-of-bounds write in FFmpeg’s libavcodec, specifically the MagicYUV decoder. NVD lists it as affecting FFmpeg before 8.1.2, with denial-of-service impact and possible remote code execution in some cases. The CNA score from JFrog is CVSS 3.1 8.8 High.
JFrog Security Research, which discovered and disclosed the issue, named it PixelSmash. Their write-up is useful because it shows the supply-chain shape: the bug sat in a foundational media library that Mastodon, Jellyfin, Nextcloud, and plenty of other projects either link, bundle, or invoke.
JFrog demonstrated crashes across projects such as Kodi, mpv, Jellyfin, Nextcloud, Immich, PhotoPrism, and OBS Studio, and showed remote code execution in Jellyfin and Nextcloud scenarios using a crafted 50 KB AVI file. JFrog’s caveat is worth keeping: the reliable RCE demonstration depended on conditions such as ASLR being disabled, while the out-of-bounds write alone was enough for reliable denial of service across tested targets. Keep that distinction. “Potential RCE” and “drop-in internet worm” are not the same thing, even if both make admins reach for coffee.
For a Mastodon operator, the question is simple: can an attacker get your instance to process a media file through a vulnerable FFmpeg path? If yes, the patch clock is running.
Mastodon 4.6.2 exposes something unglamorous and real: application versions are not the same as runtime security state.
If you run the official Docker image, Mastodon’s one-line Dockerfile change matters directly. If you run your own build, your risk depends on the FFmpeg binary your media workers actually call. If you use a distro package, your risk depends on the package branch, the security repository, and whether you have applied the update. If some part of your stack carries a static FFmpeg binary, congratulations, you have a small archaeology project.
On June 28, 2026, the Debian Security Tracker entry for CVE-2026-8461 showed exactly why this gets messy. trixie-security was fixed at 7:7.1.5-0+deb13u1, and forky/sid were fixed at 7:8.1.2-2, while bullseye, bookworm, and the listed bookworm-security package were still marked vulnerable. That does not mean “Debian did nothing”. It means different branches, security repositories, upstream releases, container images, and downstream applications do not move as one object.
In practice, open-source security lands at different times in different places.
Software production is speeding up. GitHub’s 2025 Octoverse reported more than 180 million developers on GitHub, more than 1.12 billion public and open-source contributions, and a record 518.7 million merged pull requests. It also reported more than 1.1 million public repositories using an LLM SDK, with 693,867 of those created in the previous 12 months.
That volume changes what maintainers and operators have to absorb: more code, more configuration, more Dockerfiles, more package locks, more generated examples, more test scaffolding, and more half-finished prototypes entering the ecosystem.
AI-assisted coding is risky because it is useful. Veracode’s Spring 2026 GenAI Code Security Update found that AI coding models now exceed 95% syntax correctness in their tests, but only about 55% of generation tasks resulted in secure code. The code increasingly runs, which is nice. It still often carries known security flaws, which is less nice.
Banning AI-assisted coding would be theater. The real mistake is treating runnable output as reviewed output. A pull request that compiles is not the same thing as a threat model. A generated Dockerfile is not a supply-chain policy. A suggested package is not provenance.
AI also makes bug discovery cheaper.
Google Project Zero and Google DeepMind’s Big Sleep work is a useful early signal. In 2024, the Big Sleep team reported that an AI agent found a previously unknown exploitable memory-safety issue in SQLite, and that SQLite fixed it the same day, before it reached an official release. Clean outcome: bug found, fixed the same day, gone before most users ever touch it.
Anthropic’s Project Glasswing update shows the harder version. Anthropic said that it and roughly 50 partners used Claude Mythos Preview to find more than 10,000 high- or critical-severity vulnerabilities. In open source specifically, Anthropic said Mythos Preview scanned more than 1,000 projects and estimated 6,202 high- or critical-severity findings. Of the 1,752 assessed by security firms or Anthropic, 90.6% were valid true positives, and 62.4% were confirmed high or critical.
The painful number is further down the pipeline: Anthropic said it had disclosed an estimated 530 high- or critical-severity bugs to maintainers, and 75 had been patched at the time of the update.
Those numbers explain the pressure. Discovery is getting cheaper; verification and patch deployment are not. The bottleneck moved from “can we find enough real issues?” to “can humans process the queue before the queue becomes operational risk?”
curl maintainer Daniel Stenberg wrote in 2025 that about 20% of curl’s security submissions so far that year looked like AI slop, while only about 5% of submissions had turned out to be genuine vulnerabilities by early July. He also explained the cost: every report pulls multiple curl security team members into triage, even when the report is nonsense. The current curl vulnerability disclosure policy now says there is no bug bounty and explicitly asks contributors not to paste large AI-generated explanations.
That consumes maintainer attention in exactly the place open source has the least slack: careful review by people who understand the code.
OpenSSF made the same point when announcing $12.5 million in open-source security grants in March 2026. Their announcement says AI is dramatically increasing the speed and scale of vulnerability discovery, while maintainers face a flood of findings without enough resources or tooling to triage and remediate them.
Bad reports are not harmless because they are wrong. They are expensive because they look plausible long enough to steal time from people who could be reviewing a real patch.
The useful response is closure.
OpenAI’s Patch the Planet announcement gets this part right: the program is framed around maintainer consultation, human review, validation, patch development, testing, CI/CD improvements, and disclosure coordination. The initial participants include cURL, NATS Server, pyca/cryptography, Sigstore, aiohttp, Go, freenginx, Python, and python.org.
Trail of Bits’ first-week report is even more concrete. Their Patch the Planet write-up says the first week produced 64 pull requests and 51 issues across 19 projects, with 37 patches already merged. The useful output went beyond bug tickets: fuzzing harnesses, CI security scanning, supply-chain tooling, tests, correctness fixes, and release-pipeline improvements.
For open source, this is the useful version of AI security: fewer theatrical “critical” reports, more reproducible evidence, better severity calls, patches maintainers can actually merge, and tests that make the same class of bug less likely next time.
AI also changes dependency selection. A developer asking an assistant to “add file upload support”, “wire in video previews”, or “make this run in Docker” is asking it to choose libraries, package versions, base images, environment variables, and examples from the internet’s memory.
The supply chain is already huge. Sonatype’s 2026 State of the Software Supply Chain announcement reported 9.8 trillion open-source downloads across the four largest registries, up 67% year over year, and more than 1.233 million malicious packages. It also said GPT-5 hallucinated 27.8% of component versions and even suggested real malware packages when operating without real-time supply-chain intelligence.
Vibe coding has an unromantic side. The assistant may scaffold the app in an evening. The operator inherits the dependency tree for years.
And AI applications add their own surfaces. OWASP’s LLM01:2025 Prompt Injection guidance is clear that prompt injection can lead to sensitive information disclosure, unauthorized access to functions available to the LLM, command execution in connected systems, and manipulation of decisions. Once an LLM is connected to files, web retrieval, MCP servers, internal tools, or deployment workflows, natural language becomes part of the system boundary.
Traditional CVEs remain. LLM-specific risks sit beside them, usually with worse logging and more ambiguity.
For our Mastodon node, CVE-2026-8461 is an FFmpeg incident moving through a Mastodon-shaped dependency path.
We have upgraded the FFmpeg used by our Mastodon deployment to a fixed version. The check that counts is what the running media workers call when they generate thumbnails, previews, and transcodes.
The operational checklist is deliberately boring:
ffmpeg -version inside the actual runtime environmentA one-line Dockerfile change upstream still has to become a running binary downstream. Operators do not get credit until that part is done.
At this point, “does this software have vulnerabilities?” is the wrong question. All serious software does.
Ask a more useful one: how long is the delay between discovery and a patched runtime?
Track mean time to patch, mean time to deploy, dependency freshness, and image rebuild frequency. For this case, the practical question is whether an operator can prove which FFmpeg binary the media workers call. On the intake side, vulnerability reports need a reproduction, affected-version analysis, and enough detail for a maintainer to act.
AI did not create the FFmpeg MagicYUV bug. The public trail names JFrog Security Research as the source for CVE-2026-8461. It does not name an AI system. The case still belongs in the AI-era security conversation because it shows what the new tempo feels like: upstream library, CVE, security research, distro tracker, Dockerfile, downstream release, running service.
Panic-upgrading everything forever breaks production and then pretends the wreckage was security.
The patch race is about knowing which dependencies are reachable, which fixes are real, which reports are noise, which patches are merged, which releases contain them, and whether the running system has actually crossed the line from vulnerable to fixed.
AI is making that race faster. Operators who watch only application version numbers will miss half of it.
]]>You can try it here:
BlorpUI is a playful, quirky way to browse Lemmy. It does not replace the default R.NF interface; it is another option for people who prefer a different reading and browsing experience.
The source code for BlorpUI is available here:
https://github.com/Blorp-Labs/blorp
R.NF now offers several web interfaces, each with a different feel:
Lemmy’s open ecosystem makes it possible to use different frontends with the same communities, accounts, posts, and comments.
Some people want a compact layout. Some prefer a brighter interface. Some mostly browse from a phone. Others just want something with a different personality. By hosting several interfaces, R.NF can support more preferences without forcing everyone into the same UI.
BlorpUI is now available at b.r.nf.
If the default interface is not quite your style, try one of the alternatives and use whichever one feels best for how you read and participate on R.NF.
]]>This is a security-focused maintenance release. It does not introduce breaking changes, but it includes several important fixes that are worth applying promptly on public Lemmy instances.
Lemmy 0.19.19 addresses multiple security issues:
X-Forwarded-For headerslemmy-ui HTML embedsThe X-Forwarded-For issue is especially important for instance operators. Lemmy’s default NGINX configuration previously used $proxy_add_x_forwarded_for, which can preserve client-supplied values. The recommended fix is to use $remote_addr so client-provided forwarded headers are overwritten instead of trusted.
There are no breaking changes in this release.
Admins using Lemmy’s Ansible setup should get the NGINX configuration change automatically during upgrade. Other deployments should check their reverse proxy configuration and make sure client-supplied X-Forwarded-For headers cannot be used to bypass rate limits.
For R.NF, this update keeps our Lemmy instance on the latest 0.19 security release and ensures the service remains stable for link-sharing and community discussion.
For the official release notes, see:
R.NF is now running Lemmy 0.19.19.
This update focuses on security and operational correctness, especially around rate limiting, login behavior, moderation over federation, private messages, and safe rendering in the web UI.
]]>This update includes an important security fix from 8.2.1, along with the improvements introduced across the 8.1 and 8.2 releases.
PeerTube 8.2.1 fixes an XSS issue involving JSON-LD data injected by the server on video watch pages.
Because this is a security release, upgrading promptly was the right call for P.LU.
PeerTube now allows a video channel to be transferred to another user on the same instance. This makes it easier to reorganize ownership when projects change hands or when a channel outgrows its original account setup.
Live streams now support DVR behavior, so viewers can pause a live stream and seek within the live window.
PeerTube Studio can now remove segments from a video. This is useful for quick cleanups without having to re-edit and re-upload the full source video.
Admins can configure download rate limits globally and per IP. This helps protect instances from instability when large numbers of downloads happen at once, including abusive or automated download traffic.
PeerTube 8.2 improves several admin workflows:
PeerTube 8.1 brought several changes that also land on P.LU with this update:
png and webp video thumbnailsAcross 8.1, 8.2, and 8.2.1, PeerTube also fixes a long list of practical issues, including:
PeerTube 8.2 removes Node.js 20 support. PeerTube now requires Node.js 22, specifically version 22.12 or newer.
Instances upgrading from 8.0.x should also follow the PeerTube 8.1 migration notes, including the post-upgrade migration script and the recommended thumbnail/storage maintenance steps.
The 8.2 release also includes an NGINX configuration fix for video downloads, so admins should review and update their NGINX configuration when upgrading.
For the full changelog, see the official releases:
P.LU is now on the latest PeerTube 8.2 patch release.
]]>This is a bigger update than the version number suggests for us, because C.IM is moving from the 4.5 series to the 4.6 series. It includes the main Mastodon 4.6 changes, plus the fixes released in 4.6.1.
Profiles have been redesigned with a cleaner layout and a better editing flow. You can now update more of your own profile directly from the web interface, without going through the preferences panel.
Mastodon 4.6 also adds support for alt text on profile pictures and headers, which is a useful accessibility improvement for profile pages.
Mastodon now supports Collections, a way to group and share up to 25 accounts. This is based on the Fediverse’s Featured Collections work, so it is designed for interoperability rather than being a Mastodon-only feature.
Mastodon 4.6 introduces email subscriptions for public posts. When enabled by an administrator and then enabled by a user, visitors can subscribe to that user’s public posts by email.
We will keep an eye on this feature because it can increase outgoing email volume and operating costs.
This release adds several useful controls for admins and users:
Mastodon 4.6 includes many interface refinements, including better accessibility, support for vertical-language posts, improved keyboard shortcuts, and clearer wording in several settings pages.
It also changes the theme system to use design tokens and CSS variables. This is good for the long-term frontend direction, but it means custom themes need updates to work properly with the 4.6 series.
The 4.6.1 patch release focuses on dependency updates and fixes for the new 4.6 experience:
Mastodon 4.6 changes several infrastructure requirements:
libvips is now required; ImageMagick support has been removedThe upgrade also requires database migrations, asset recompilation, and restarting the streaming server.
Mastodon v4.6.2 was released after this update, but it only updates FFmpeg inside the official Docker container images. We do not use those images for C.IM, so there is no application source update for us to apply here. We will skip 4.6.2 and plan to update again when Mastodon v4.6.3 is available.
For the full release notes, see:
C.IM is now on the Mastodon 4.6 series, with the 4.6.1 patch applied.
This update improves profiles, introduces collections, adds new account and admin tools, and brings a large set of fixes across the web UI, ActivityPub handling, accessibility, and backend behavior.
Source code for our instance is available at:
]]>All donations received this month were for C.IM. They help us maintain a stable Mastodon instance, pay for the surrounding infrastructure, and keep our platforms independent.
| Item | Amount |
|---|---|
| C.IM servers | €200 |
| P.LU servers | €100 |
| R.NF servers | €20 |
| Image.Hosting servers | €10 |
| Estonian company maintenance | €159 |
| Item | Amount |
|---|---|
| Cloudflare CDN & R2 (S3-like) usage | $225.28 ≈ €190.61 |
| Stripe processing fees | €2.93 |
Thank you for continuing to support independent, user-focused social infrastructure.
If you value C.IM and want to help keep it sustainable, please consider donating here.
Monthly support, even in small amounts, makes it easier for us to plan ahead and keep improving the service.
]]>This month, every donation we received went to C.IM. Even when the total is modest, these contributions help offset the ongoing costs of servers, storage, networking, and company operations.
| Item | Amount |
|---|---|
| C.IM servers | €200 |
| P.LU servers | €100 |
| R.NF servers | €20 |
| Image.Hosting servers | €10 |
| Estonian company maintenance | €159 |
| Item | Amount |
|---|---|
| Cloudflare CDN & R2 (S3-like) usage | $233.80 ≈ €197.82 |
| Stripe processing fees | €2.20 |
We continue to share these reports because transparency matters, especially for community-supported services.
If you can, please consider making a donation to support C.IM and help us reduce the monthly deficit.
Your support helps us keep the service independent, privacy-focused, and available to the people who rely on it.
]]>All donations received this month were for C.IM. These contributions directly support the infrastructure behind our Mastodon community and help us continue operating without ads or tracking.
| Item | Amount |
|---|---|
| C.IM servers | €200 |
| P.LU servers | €100 |
| R.NF servers | €20 |
| Image.Hosting servers | €10 |
| Estonian company maintenance | €159 |
| Item | Amount |
|---|---|
| Cloudflare CDN & R2 (S3-like) usage | $211.65 ≈ €179.08 |
| Stripe processing fees | €3.44 |
Running federated infrastructure has steady monthly costs, and community support makes a meaningful difference.
If you want to help keep C.IM sustainable, you can donate here.
Thank you for helping us build and maintain independent social infrastructure for the Fediverse.
]]>This month, all donations we received were directed to C.IM. Your support helps cover the cost of running the Mastodon server and the infrastructure around it.
| Item | Amount |
|---|---|
| C.IM servers | €200 |
| P.LU servers | €100 |
| R.NF servers | €20 |
| Image.Hosting servers | €10 |
| Estonian company maintenance | €159 |
| Item | Amount |
|---|---|
| Cloudflare CDN & R2 (S3-like) usage | $225.95 ≈ €191.18 |
| Stripe processing fees | €3.27 |
We publish these reports so our community can see what it costs to keep these services running.
If C.IM is useful to you, please consider donating here to help cover the monthly infrastructure and operations costs.
Every donation helps reduce the gap between community support and the real cost of keeping independent, federated services online.
]]>This moves P.LU from the 7.x series to PeerTube 8. It includes new channel collaboration tools, player changes, and the 8.0.2 patch fixes.
Channel owners can now invite other users on the same instance to become editors. Editors can manage videos, playlists, and comments on behalf of the channel — and all actions are tracked in a new Activity page.
PeerTube 8.0 ships with two player themes: a new modern Lucide design and the renamed Galaxy theme (the original look). Admins and channel owners can set default themes, and individual videos can use different themes. The Galaxy theme also adds vertical volume controls.
Video imports now show an explicit “Import failed” state, making it easier to spot and fix issues. Import status is visible on both the manage and watch pages, with retry functionality built in.
yarn to pnpm for faster installs and upgradespackage.json files no longer block plugin updatesIf you’re upgrading from PeerTube 7.x, check the v8.0.0 release notes for breaking changes, including deprecated REST API fields and updated Node.js requirements (≥20.19 or ≥22.12).
For the full changelog, see the official releases:
]]>This release includes a security fix for ActivityPub collection caching, improvements to quote post handling, and several bug fixes for relationship caching, notifications, and connection management.
Full changelog:
https://github.com/mastodon/mastodon/releases/tag/v4.5.6
This update patches a security issue in how Mastodon handles cached ActivityPub collections, and fixes several bugs around quote posts, notifications, and database connections.
C.IM now runs the latest patch release for the 4.5 series.
Source code for our instance is available at:
]]>The first report of the year covers C.IM donations and the monthly costs for our infrastructure.
| Item | Amount |
|---|---|
| C.IM servers | €200 |
| P.LU servers | €100 |
| R.NF servers | €20 |
| Image.Hosting servers | €10 |
| Estonian company maintenance | €159 |
| Item | Amount |
|---|---|
| Cloudflare CDN & R2 (S3-like) usage | $229.05 ≈ €193.80 |
| Stripe processing fees | €4.96 |
We publish these numbers each month so the community can see both the support we receive and the costs we still need to cover.
If you value the services we run, please consider donating here.
Small donations add up, and recurring donations make planning much easier.
]]>