Tech journalists treat Mastodon like a corporate competitor, not a protocol. They’re so conditioned by the “5 corps in a trench coat” internet, they can’t grasp a decentralized web. The fediverse breaks their brain. 😆

https://techcrunch.com/2025/08/29/mastodon-says-it-doesnt-have-the-means-to-comply-with-age-verification-laws/

#mastodon #federation #technology

We are VERY excited about all the features landing in the next release! However, we’re also introducing one big breaking change—and that’s the purpose of this post. WE ENCOURAGE EVERYONE USING BADGEFED TO CREATE A DATABASE BACKUP BEFORE UPGRADING.

(GO, do it now, we will wait for you and then continue reading this post.)

Don’t worry: if you forget, chances are you won’t lose data, but recovery may be trickier. If you can, please back up first.

Summary (read before upgrading)

• Database filenames now match your domain, for example: mydomain.db. The previous single default filename is no longer used by default.
• Back up your existing SQLite file NOW. You can also download a backup from the admin portal: Admin > Database > Download Backup.
• After upgrading to 0.1.1, the app uses a per-domain database. Use the import utility to migrate from your backup—or copy your backup into the data directory and rename it to the domain-based filename.
• Prefer one shared database? Set the environment variable SQLITE_DB_PATH to your desired (or current) filename (for example, badgefed.db).

If you already upgraded without preparing

• Your previous database was not replaced or deleted. Locate your old badgefed.db (or backup), copy it to the data directory, and rename it to the new domain-based filename.

The 0.1.1 release and full release notes are coming soon!

Badge up!

You can read the article "BadgeFed 0.1.1 — Breaking change: per-domain database filenames" by @mapachehere as well.

Hey Fediverse! 👋

We’ve been quiet… but not idle. Forget waiting for long blog posts, time for micro updates.

Today’s news:

We’ve got a few BadgeFed instances live and federating! 🏅

To make it happen, we did a hardcore backend rewrite to support multiple domains on a single machine.
For most, it’s a niche cost-saving move, but it might be useful for others too. Under the hood: each domain runs its own SQLite DB, with backups in place.

But this isn’t just about the tech, the fun part is seeing multiple BadgeFed servers talking to each other (!!). Follow them, check the thread, boost it, and watch for more as they come online!

You can read the article "BadgeFed Update: Multiple Instances Online!" by @mapachehere as well.

Hey Fediverse! 👋

We’ve been quiet… but not idle. Forget waiting for long blog posts, time for micro updates.

Today’s news:

We’ve got a few BadgeFed instances live and federating! 🏅

To make it happen, we did a hardcore backend rewrite to support multiple domains on a single machine.
For most, it’s a niche cost-saving move, but it might be useful for others too. Under the hood: each domain runs its own SQLite DB, with backups in place.

But this isn’t just about the tech, the fun part is seeing multiple BadgeFed servers talking to each other (!!). Follow them, check the thread, boost it, and watch for more as they come online!

You can read the article "BadgeFed Update: Multiple Instances Online!" by @mapachehere as well.

This post sent me down an enjoyable rabbit hole of thinking about #federation for #git forges, thank you!

Good news! You can now find @Defector on Flipboard and in the fediverse, thanks to their federated account. Follow them for coverage of sports, pop culture, and more.

https://flipboard.com/@defector

#Flipboard#Federation#ActivityPub#Sports#Media#Journalism#Fediverse

Good news! You can now find @Defector on Flipboard and in the fediverse, thanks to their federated account. Follow them for coverage of sports, pop culture, and more.

https://flipboard.com/@defector

#Flipboard#Federation#ActivityPub#Sports#Media#Journalism#Fediverse

The iPad. Rainbow Looms. "Inception." They all arrived on the scene in 2010 — and so did we. In 2025, we're celebrating Flipboard's 15th birthday. Here's to the next 15 and more! Check out the spreadsheet here to discover all the Magazines you can find in the fediverse — and comment below if there's a publication you'd love us to federate.

https://about.flipboard.com/inside-flipboard/15-years-of-flipboard/

https://docs.google.com/spreadsheets/d/1iUFTo6rPvhqzCReLaM1c6-xUKRuBVqlZVStZl9Al-EU/edit?gid=1764807022#gid=1764807022

#Flipboard#FlipboardMagazines#ActivityPub#Federation#Fediverse#OpenSocial#OpenSocialWeb

The iPad. Rainbow Looms. "Inception." They all arrived on the scene in 2010 — and so did we. In 2025, we're celebrating Flipboard's 15th birthday. Here's to the next 15 and more! Check out the spreadsheet here to discover all the Magazines you can find in the fediverse — and comment below if there's a publication you'd love us to federate.

https://about.flipboard.com/inside-flipboard/15-years-of-flipboard/

https://docs.google.com/spreadsheets/d/1iUFTo6rPvhqzCReLaM1c6-xUKRuBVqlZVStZl9Al-EU/edit?gid=1764807022#gid=1764807022

#Flipboard#FlipboardMagazines#ActivityPub#Federation#Fediverse#OpenSocial#OpenSocialWeb

Concept for discussion: Replacing HTTP Signatures with Bearer Tokens for ActivityPub Federation

Curious what other people think about this idea. What if federation security was re-worked to use target-assigned bearer tokens to authenticate GET/POST requests? This would remove the need for complicated signing schemes and reduce system load under heavy traffic bursts (as no cryptography is required).

A basic implementation could look like this:

1. When instance A (a.example.com) first attempts to federate with instance B (b.example.com), a POST request is made to a dedicated registration endpoint. (for discussion, we'll say it's https://b.example.com/activity-pub/register-instance). This request includes fields necessary for verification, including the source domain name, target domain name, and a securely-generated verification token. Other metadata could be included to allow instance B to selectively allow/prohibit federation based on other criteria, but this is optional.
2. Instance B makes a POST request back to a dedicated verification endpoint on instance A (for discussion, we'll say it's https://a.example.com/activity-pub/verify-registration). This request must include the target domain name and verification token provided in step 2.
3. Instance A checks the verification token (and verify that it matches the target domain name) and return a successful value. The verification code must be invalidated after this call!
4. Instance B, after verifying instance A's request, returns a securely-generated federation key back to instance A. This federation key is a bearer token used to authenticate all requests from instance A to instance B. This key must be unique to instance A!
5. Instance A completes the original request with the Authorization header set to Bearer {federation_key}.
6. Instance B receives the request, detects the federation key, and checks it against the list of registered instances.
7. If the key does not exist or A has been defederated, then a 403 Forbidden error is returned.
8. If the key is expired or revoked, then 401 Unauthorized error is returned. Upon receiving a 401 error, instance A should start over from step 1 to re-authenticate and complete the request with a new token. This process should not be repeated for recursive failures!
9. If the key is approved, then a 200 OK response or 202 Accepted response is returned, and A can consider the request as successful.

Advantages versus HTTP Signatures:

• No cryptography requirements.
• Simple logic, no edge cases around HTTP query parameters or header order.
• Equally effective for all request types.
• Keys can be easily revoked or rotated.
• Supports authorized fetch and defederation use cases "by default".

Disadvantages versus HTTP Signatures:

• Breaks the actor model - instances are required as a first-class concept. (but really, the actor model is basically dead already. you can't even federate reliably without a WebFinger server, at minimum.)
• Requires multi-request "handshake" before communication. (but this is already required in practice, since a signature can't be validated without first requesting the signing actor.)
• Out-of-band protocol - communication can't happen over ActivityPub / ActivityStreams because this is a prerequisite to authenticate any request. (but again, we already require WebFinger and some software requires NodeInfo for full support.)

So, what are your thoughts? Good idea? Bad idea? Did I miss something? Please let me know, I welcome replies here!

#ActivityPub #AP #Federation

Concept for discussion: Replacing HTTP Signatures with Bearer Tokens for ActivityPub Federation

Curious what other people think about this idea. What if federation security was re-worked to use target-assigned bearer tokens to authenticate GET/POST requests? This would remove the need for complicated signing schemes and reduce system load under heavy traffic bursts (as no cryptography is required).

A basic implementation could look like this:

1. When instance A (a.example.com) first attempts to federate with instance B (b.example.com), a POST request is made to a dedicated registration endpoint. (for discussion, we'll say it's https://b.example.com/activity-pub/register-instance). This request includes fields necessary for verification, including the source domain name, target domain name, and a securely-generated verification token. Other metadata could be included to allow instance B to selectively allow/prohibit federation based on other criteria, but this is optional.
2. Instance B makes a POST request back to a dedicated verification endpoint on instance A (for discussion, we'll say it's https://a.example.com/activity-pub/verify-registration). This request must include the target domain name and verification token provided in step 2.
3. Instance A checks the verification token (and verify that it matches the target domain name) and return a successful value. The verification code must be invalidated after this call!
4. Instance B, after verifying instance A's request, returns a securely-generated federation key back to instance A. This federation key is a bearer token used to authenticate all requests from instance A to instance B. This key must be unique to instance A!
5. Instance A completes the original request with the Authorization header set to Bearer {federation_key}.
6. Instance B receives the request, detects the federation key, and checks it against the list of registered instances.
7. If the key does not exist or A has been defederated, then a 403 Forbidden error is returned.
8. If the key is expired or revoked, then 401 Unauthorized error is returned. Upon receiving a 401 error, instance A should start over from step 1 to re-authenticate and complete the request with a new token. This process should not be repeated for recursive failures!
9. If the key is approved, then a 200 OK response or 202 Accepted response is returned, and A can consider the request as successful.

Advantages versus HTTP Signatures:

• No cryptography requirements.
• Simple logic, no edge cases around HTTP query parameters or header order.
• Equally effective for all request types.
• Keys can be easily revoked or rotated.
• Supports authorized fetch and defederation use cases "by default".

Disadvantages versus HTTP Signatures:

• Breaks the actor model - instances are required as a first-class concept. (but really, the actor model is basically dead already. you can't even federate reliably without a WebFinger server, at minimum.)
• Requires multi-request "handshake" before communication. (but this is already required in practice, since a signature can't be validated without first requesting the signing actor.)
• Out-of-band protocol - communication can't happen over ActivityPub / ActivityStreams because this is a prerequisite to authenticate any request. (but again, we already require WebFinger and some software requires NodeInfo for full support.)

So, what are your thoughts? Good idea? Bad idea? Did I miss something? Please let me know, I welcome replies here!

#ActivityPub #AP #Federation

Socialhome v0.22.0 released, with a completely new UI!

This is a massive milestone for the #Socialhome project, one that could not have been possible without the hard work of @alain@jase.social. If you have followed the Socialhome project, you'll know that Alain has been responsible for most of the development of project in the recent years. This includes rewriting the #federation library to ensure #ActivityPub support is first class. More recently Alain has taken the challenge of rewriting the frontend, which has fallen into a rather poor state over the years.

The new UI work is actually a coordination of two people working many years apart. Way back years ago @lightone@mastodon.xyz made some UI designs for a new Socialhome UI (thank you! <3). While the designs were not implemented for years, they were not forgotten. In 2023 Alain jumped to the challenge and started the full UI rewrite of the Socialhome frontend. This UI has now matured into a state that it is good for daily usage - which is the main focus of this release!

Currently, a Socialhome installation will still default to the old UI. If you do want to try out the new UI for example on socialhome.network, go to the account settings and toggle the "New UI" flag. Going back is also easy, should the new UI cause unforeseen issues (please do report!).

If you are a server admin, see the new UI installation instructions for how to add the new UI to your instance.

This is not all! The releases of v0.21.0 and v0.22.0 also contain a bunch of other changes and fixes. Most notably;

• ActivityPub profiles are now richer, including bio and a larger picture, in addition to an avatar.
• Many new API's to support the new UI, including session authentication, search, media upload, content fetching over uuid, profile organize and profile settings.
• Whoosh has been replaced with Xapian as a search index backend.

See the full changelogs. Additionally, the federation library has received a ton of changes and fixes which can be found here.

Also, last but not least, we moved from GitLab to Codeberg. Check out the new repositories.

Installing and updating

We recommend using the Docker images (amd64/arm64).

Notes on how to use the Docker images can be found in the docs.

What is Socialhome?

Socialhome is best described as a federated personal profile with social networking functionality. Users can create rich content using Markdown. All content can be pinned to the user profile and all content will federate to contacts in the federated social web. Federation happens using the ActivityPub and Diaspora protocols.

Please check the official site for more information about features. Naturally, the official site is a Socialhome profile itself.

• Official site
• Documentation (for admins)
• Code repository (GitHub mirror)
• Chat room on Matrix

Try Socialhome?

If you want to try Socialhome first before trying to install it, register at https://socialhome.network and then ping us with a comment on the user name chosen to get the account approved. You can also request account approval in the chat room. This unfortunately approval step is due to spammers.

Contribute

Do you want to work on a Django and VueJS powered social network server? Join in the fun! We have easy to follow development environment setup documentation and a friendly chat room for questions.

#socialhome #federation #fediverse #activitypub #diaspora #django #vuejs

Socialhome v0.22.0 released, with a completely new UI!

This is a massive milestone for the #Socialhome project, one that could not have been possible without the hard work of @alain@jase.social. If you have followed the Socialhome project, you'll know that Alain has been responsible for most of the development of project in the recent years. This includes rewriting the #federation library to ensure #ActivityPub support is first class. More recently Alain has taken the challenge of rewriting the frontend, which has fallen into a rather poor state over the years.

The new UI work is actually a coordination of two people working many years apart. Way back years ago @lightone@mastodon.xyz made some UI designs for a new Socialhome UI (thank you! <3). While the designs were not implemented for years, they were not forgotten. In 2023 Alain jumped to the challenge and started the full UI rewrite of the Socialhome frontend. This UI has now matured into a state that it is good for daily usage - which is the main focus of this release!

Currently, a Socialhome installation will still default to the old UI. If you do want to try out the new UI for example on socialhome.network, go to the account settings and toggle the "New UI" flag. Going back is also easy, should the new UI cause unforeseen issues (please do report!).

If you are a server admin, see the new UI installation instructions for how to add the new UI to your instance.

This is not all! The releases of v0.21.0 and v0.22.0 also contain a bunch of other changes and fixes. Most notably;

• ActivityPub profiles are now richer, including bio and a larger picture, in addition to an avatar.
• Many new API's to support the new UI, including session authentication, search, media upload, content fetching over uuid, profile organize and profile settings.
• Whoosh has been replaced with Xapian as a search index backend.

See the full changelogs. Additionally, the federation library has received a ton of changes and fixes which can be found here.

Also, last but not least, we moved from GitLab to Codeberg. Check out the new repositories.

Installing and updating

We recommend using the Docker images (amd64/arm64).

Notes on how to use the Docker images can be found in the docs.

What is Socialhome?

Socialhome is best described as a federated personal profile with social networking functionality. Users can create rich content using Markdown. All content can be pinned to the user profile and all content will federate to contacts in the federated social web. Federation happens using the ActivityPub and Diaspora protocols.

Please check the official site for more information about features. Naturally, the official site is a Socialhome profile itself.

• Official site
• Documentation (for admins)
• Code repository (GitHub mirror)
• Chat room on Matrix

Try Socialhome?

If you want to try Socialhome first before trying to install it, register at https://socialhome.network and then ping us with a comment on the user name chosen to get the account approved. You can also request account approval in the chat room. This unfortunately approval step is due to spammers.

Contribute

Do you want to work on a Django and VueJS powered social network server? Join in the fun! We have easy to follow development environment setup documentation and a friendly chat room for questions.

#socialhome #federation #fediverse #activitypub #diaspora #django #vuejs

From: blenderdumbass . org

This article is published on a website which is powered by BDServer. And I'm trying to make this website support ActivityPub, so you could for example, subscribe to me from your Mastodon account. Yet it is easier said than done.

If you have any experience with ActivityPub, web-development or Python, please consider helping me. We have BDServ...

Read: https://blenderdumbass.org/articles/please_help_me_with_activity_pub

#activitypub #fediverse #mastodon #bdserver #python #programming #webdev #federation #API

My activitypub enabled blog enables me to respond to comments made by those on the fediverse. However, the link says 'Reply with federation', and I keep thinking that I need permission from @georgetakei before I can do that. 🤣

#ActivityPub#StarTrek#Federation