Post #2661027

2026-03-15 02:46 UTC

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

Replies (1)

@mapache@hachyderm.io 2026-03-15 02:48

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@mastodon.social 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.

Open ##2661028