I think it's a good time to explain how we see @badgefed and @fediprofile, how they work together, and how #badges can use #ActivityPub and the #Fediverse.

I think it's a good time to explain how we see @badgefed and @fediprofile, how they work together, and how #badges can use #ActivityPub and the #Fediverse.

Also how this can help communities outside the fediverse!

This is a quick overview of the architecture and ideas behind it. 🧵 1/

(thanks @johannab for the ask ...)

@badgefed is an open-source project that generates digital recognition in the form of #OpenBadges.

OpenBadges is a specification based on JSON. BadgeFed currently uses version 2 of the spec.

The main difference with v3 is verification.

In OpenBadges v3, the badge can be verified by itself because the verification information is embedded in the credential.

In OpenBadges v2, verification requires retrieving information from the issuer and badge endpoints.

For our use case, issuing recognition on the internet, this is not a problem.

In fact, we actually WANT that external verification step.

It allows badges to reference issuer endpoints and remain connected to the systems that created them.

Badges themselves are very simple files.

Often the badge information is encoded inside an image, usually a PNG.

So the image contains both:
• the visual badge
• the structured metadata describing the credential

One file, both human-friendly and machine-readable.

Other times these are simple json files.

--

Where things get interesting is with #ActivityPub.

@badgefed uses ActivityPub as a transport layer for decentralization, and also as a way to add social features.

BadgeFed issues credentials, but it wraps the OpenBadge inside an ActivityPub Note.

The actor creating that note is the badge issuer. <-- important!

ActivityPub is also used for federation.

Badge issuers (ActivityPub actors) can follow other issuers.

When a badge is issued, a Create activity is federated.

Other servers receive that activity and can store a local copy of the badge.

This works very similarly to how Mastodon servers cache posts.

Because of that, badges can also be:

• revoked using the Delete activity
• updated using the Update activity

Again, this reuses existing ActivityPub verbs instead of inventing a new protocol or new spec.

Simple primitives, (I love how simple it is), powerful results.

--

Verification is also straightforward.

The #OpenBadge issuer URL points to the ActivityPub actor URL.

That means the same actor who published the badge also owns the public/private key pair used in ActivityPub.

So the actor identity and the badge issuer identity match.

Now let’s talk about Fediprofile.

@badgefed issues recognition to recipients identified by a profile URL.

It intentionally does not allow email addresses (even hashed ones).

This avoids security issues and allows recipients to be identified using public profiles. Privacy at it's best.

Any URL can be used as a profile:

• LinkedIn
• Mastodon
• GitHub
• personal websites
• Instagram (ugh, eww)
• etc...

If that URL also happens to be an ActivityPub actor (for example a Mastodon or PixelFed profile), the user will also receive a mention or notification when a badge is issued.

--

Many people already receive badges across different identities.

For example, I personally have badges tied to:

• my LinkedIn
• my personal website
• gaming profiles

This is where the concept of a badge wallet or badge backpack becomes useful.

A place to collect them all. (POKEMON!)

@fediprofile is designed to be that wallet.

Because Fediprofile itself is an ActivityPub actor, it can follow badge issuers (again simplicity wins!).

When it detects a badge issued to one of the verified profile URLs connected to the account, it automatically stores it (and optionally boost it).

Users can then choose which badges to display. Users OWN their badges.

This creates a low-friction identity layer.

People who don’t want to run their own site can still have a public profile where they show:

• their social links
• their activity
• their badges

All in a decentralized way.

This is where the model becomes powerful.

People who don’t know about the Fediverse can still participate indirectly.

They receive badges, create profiles, and interact with issuers, WITHOut needing to understand federation.

It’s a gentle on-ramp.

(And I am making sure to add extra friction if they don't have a fediverse account, and encouraging them to create one).

--

There are interesting possibilities here.

Imagine a Fediprofile plugin that lets someone cross-post to Instagram and Pixelfed.

Or automatically creates a Pixelfed account for an illustrator.

Fediprofile becomes an entry point into the Fediverse.

And all of this to answer @johannab question.

--

For communities, this becomes even more powerful.

A community can run its own Fediprofile hub.

Profiles can include:

• social links
• badges
• gamification
• streaks
• recognitions

All tied to the community.

--

Example: a hiking community.

Imagine a fediprofile hub for mountain hikers where members can:

• show their trail badges
• track hiking streaks
• share gear links
• display summit achievements

Combine that with a badge issuer and maybe a #Mastodon and/or #PixelFed server for the community.

Now you have a decentralized ecosystem.

I’m also exploring ideas like:

• leaderboards
• activity points
• community challenges

Possibly as a component integrated with BadgeFed + Fediprofile, or maybe as a separate project.

Still experimenting.

--

In short:

BadgeFed issues decentralized recognitions.
Fediprofile helps people collect and display them.

Both use #ActivityPub as the backbone.

Badges become portable, social, and decentralized.

And communities can build on top of that.

--

P.S. I decided to NEVER add a wallet into BadgeFed, keeping it simple and extensible by default. So Fediprofile is the default wallet. But anyone can build and use their own. No new specs, no new protocols.