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!

--

This is actually very similar to how a Mastodon post works when you post a image.

Imagine:

β€’ the image = the badge
β€’ the post = the description of the recognition

Once published, anyone in the #Fediverse can interact with it:
reply, comment, like, boost, quote, or follow (and block) the issuer.

Badges become social objects.

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.

--

In the future, Fediprofile will support OAuth sign-in from platforms like:

β€’ LinkedIn
β€’ GitHub
β€’ Google
β€’ others (not instagram but is open-source and you can implement it ...)

This allows people to easily create a profile while still participating in the #Fediverse. (In a limited 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.

@mapache

Yes pls sign me up!!!!

Question: can we authenticate with other Activity Pub credentials (Bonfire, for example), or are we limited to Mastodon?

Here's my aim for the near future:
1. AP fediverse platform possibly a stack of a few bespoke apps (Bonfire, Vernissage, Emissary/Atlas, maybe Peertube...)
2. If not SSO, then one login for all our sandbox spaces.
3. One (pseudonymous permitted) profile for community members (I was pondering this when FediProfile popped up on the TL!!!)

@johannab @mapache can you give me an example of a community or group using this?

@theraccoonbytes @mapache

Oh I don't know - I'm aiming to start one. 🀣

Here's the high-level current motivation: @samnabi and the https://onemillionneighbours.ca project have put together a project aiming to address something I've been observing for years, that local civic engagement efforts suffer because *online* connectivity scatters people and their connections to the global similar-but-walled-off tech giant "social Media" spaces.

I want a way for local citizens to engage *locally* and in 3D.

One Million Neighbours Waterloo Region

One Million Neighbours Waterloo Region

@theraccoonbytes @mapache @samnabi

a large part of the point I'm trying to make is that we can do this within borders, with a commitment to local hosting and local support, but with access to the global base of fediverse software and collaborative reach globally.

But my vision for "verification" is more like the financial industry's "KYC" - an identifyable org and/or certified professional vouches for someone by an auditable process. Badgefed + Fediprofile seems a great digital schema for it