Post · Bonfire Dinteg Labs

Maho Pacheco 🦝🍻

@mapache@hachyderm.io · 3 days ago

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.

Maho Pacheco 🦝🍻

@mapache@hachyderm.io replied · 3 days ago

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.

Maho Pacheco 🦝🍻

@mapache@hachyderm.io replied · 3 days ago

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.

Maho Pacheco 🦝🍻

@mapache@hachyderm.io replied · 3 days ago

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!)

Maho Pacheco 🦝🍻

@mapache@hachyderm.io replied · 3 days ago

@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).

Maho Pacheco 🦝🍻

@mapache@hachyderm.io replied · 3 days ago

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.

Bonfire Dinteg Labs

This is a bonfire demo instance for testing purposes. This is not a production site. There are no backups for now. Data, including profiles may be wiped without notice. No service or other guarantees expressed or implied.

Bonfire Dinteg Labs: About · Code of conduct · Privacy ·

Bonfire social · 1.0.0 no JS en

Automatic federation enabled