Hi there, if you read this blog it’s probably for one of three things,

1) my investigation of the life of Isham Randolph, the chief engineer of the Chicago Sanitary and Ship canal.
2) you know me and you want to see what I’m doing but you haven’t discovered Twitter or Facebook yet.
3) Open Badges.

This is a quick update for everyone in that third group, the Open Badges crew. I have some news.

When I joined the Open Badges project nearly three years ago, I knew this was something that once I joined, I wouldn’t leave. The idea of Open Badges hits me exactly where I live, at the corner of ‘life long learning’ and ‘appreciating people for who they are’. I’ve been fortunate that my love of life long learning and self-teaching led me down a path where I get to do what I love as my career. Not everyone is that fortunate. I see Open Badges as a way to make my very lucky career path the norm instead of the exception. I believe in the project, I believe in the goals and I’m never going to not work toward bringing that kind of opportunity to everyone regardless of the university they attended or the degree hanging on their wall.

This summer has been very exciting for me. I joined the Badge Alliance, chaired the BA standard working group and helped organize the first BA Technology Council. At the same time, I was a mentor for Chicago’s Tech Stars program and served as an advisor to a few startups in different stages of growth. The Badge Alliance work has been tremendously satisfying, the standard working group is about to release the first cycle report, and it’s been great to see our accomplishments all written in one place. We’ve made a lot of progress in a short amount of time. That said, my role at the Alliance has been focused on standards growth, some evangelism and guiding a small prototyping project. As much as I loved my summer, the projects and work don’t fit the path I was on. I’ve managed engineering teams for a while now, building products and big technology architectures. The process of guiding a standard is something I’m very interested in, but it doesn’t feel like a full-time job now. I like getting my hands dirty (in Emacs), I want to write code and direct some serious engineer workflow.

Let’s cut to the chase – after a bunch of discussions with Sunny Lee and Erin Knight, two of my favorite people in the whole world, I’ve decided to join Earshot, a Chicago big data / realtime geotargeted social media company, as their CTO. I’m not leaving the Badge Alliance. I’ll continue to serve as the BA director of technology, but as a volunteer. Earshot is a fantastic company with a great team. They understand the Open Badges project and want me to continue to support the Badge Alliance. The Badge Alliance is a great team, they understand that I want to build as much as I want to guide. I’m so grateful to everyone involved for being supportive of me here, I can think of dozens of ways this wouldn’t have worked out. Just a bit of life lesson – as much as you can, work with people who really care about you, it leads to situations like this, where everyone gets what they really need.

The demands of a company moving as fast as Earshot will mean that I’ll be less available, but no less involved in the growth of the Badge Alliance and the Open Badges project. From a tactical perspective, Sunny Lee will be taking over as chair of the standard working group. I’ll still be an active member. I’ll also continue to represent the BA (along with Sunny) in the W3C credentials community group.

If you have any questions, please reach out to me! I’ll still have my chris@badgealliance.org email address…use it!

Earning an Open Badge is easy, there’s plenty of places that offer them, with more issuers signing up every day. Once you’ve earned an open badge, you can push it to your backpack, but what if you want to include the badge on your blog, or your artisanal hand crafted web page?

You could download the baked open badge and host it on your site. You could tell people it’s a baked badge, but using that information isn’t super easy. Last year, Mike Larsson had a great idea to build a JS library that would discover open badges on a page, and make them dynamic so that a visitor to the page would know what they were, not just a simple graphic, but a full-blown recognition for a skill or achievement.

Since his original prototype, the process of baking a badge has changed, plus Atul Varma built a library to allow baking and unbaking in the browser. This summer, Joe Curlee and I took all these pieces, prototypes and ideas and pulled them together into a single JS library you can include in a page to make the open badges on that page more dynamic.

There’s a demo of the library in action on Curlee’s Github. It shows a baked badge on the page, when you click the unbake button, it takes the baked information from the image and makes the badge dynamic and clickable. We added the button to make it clear what was happening on the page, but in a normal scenario, you’d just let the library do it’s thing and transform the badges on the page automatically. You can grab the source for the library on Github, or download the compiled / minified library directly.

There’s lot’s more we can do with the library, I’ll be writing more about it soon.

First things first, what do we mean when we say “Open Badges Infrastructure?” Infrastructure is a bit of a loaded term, you can interpret it as servers, you could interpret it as software, or both hardware, software, internet…all the things. We’ll make this easy and say that the Open Badges technical Infrastructure is all the things that make it possible to earn or issue an Open Badge.

“All the things” is an easy answer to the question, “what is the open badges infrastructure?” but it doesn’t help much when we’re trying to push the infrastructure forward, when we’re trying to grow the ecosystem. Given a technical infrastructure need, how does the Badge Alliance, and the Open Badges community, figure out the best way to address the need? If the OBI is “all the things,” who could support it without turning the OBI into a silo’d badge system?

When we asked what role the Badge Alliance would play in the OBI, we knew that the OBI needed a shepherd organization that could help the members of the OB community coordinate their efforts maintaining the long-term health of the OBI. So how do we decide what actions fit into that model? What parts of the OBI are fair game for the BA to directly touch, which parts can we influence, which parts should we stay away from entirely?

We built a three-tier model that represents all the pieces of the OBI,

The first layer of the tier is the Open Badges standard. If you’re issuing an Open Badge, you’re relying on the standard to make the badge interoperable, transportable and verifiable. It’s the layer that all the other layers of the OBI rely on.

The second layer is libraries and tools that interact with the standard. Badge issuing libraries, validation libraries, badge bakers, tools that you download and install on your machine, or use as a dependency to build a bigger tool, fit in this layer.

Lastly, the top layer is userland. The marketplace. All the hosted services that interact with badge earners, with badge issuers and with badge consumers. It relies on the layers below it, and covers them up. A student earning a badge never knows that layers one and two exist, they just know that they received a badge and are storing it in their backpack.

Given the three layer model of the OBI, the Badge Alliance realized that it’s absolutely vital that we take a very active role in the maintenance of the first layer – the OB Standard, a less active role in the library layer, and a purely advisory role in the top userland layer.

Like all frameworks, it’s possible to find edge cases that break the model, but for most cases, it’s a solid way to judge what actions the BA should take in the maintenance of the OBI. Sunny and I will write more over the next couple of weeks about exactly how the BA will play in the three tiers.

The BA standard working group has had adding extensions to the OB assertion specification high on its roadmap this summer. We agreed that before we could add an extension to an assertion or Badge Class, we needed to add machine readable schema definitions for the 1.0 standard.

We experimented with JSON-Schema, then JSON-LD. JSON-LD isn’t a schema validator, it’s much more. It builds linked data semantics on the JSON specification. JSON-LD adds several key features to JSON, most of which you can play around with in the JSON-LD node module.

Add semantic data to a JSON structure, link the serialized object to an object type definition.

Extend the object by linking to multiple object type definitions.

A standard way to flatten and compress the data.

Express the object in RDF.

Treat the objects like a weighted graph.

All of which are features that support the concept behind the Open Badges standard very well. At its core, the OB standard is a way for one party (the issuer) to assert facts about another party (the earner). The assertion (the badge) becomes portable and displayable at the discretion of the owner of the badge.

JSON-LD is also quickly becoming the standard method of including semantic markup on html pages for large indexers like Google. Schema.org now lists JSON-LD examples alongside RDFa and Microdata. Google recommends using JSON-LD for inclusion in their rich snippet listings.

We’ve been talking about JSON-LD on the OB standard working group calls for a while now. It’s starting to feel like consensus is forming around inclusion of JSON-LD markup in the standard. This Tuesday, September 2nd 2014, we’ll meet again to collectively build a list of arguments for and against the move. We’ll also discuss a conditional rollout plan (conditional in that it will only be executed if we get the thumbs up from the community) and identify any gaps we need to cover with commitments from the community.

It’s going to be a great meeting, if you’re at all interested in JSON-LD and Open Badges, please join us!

We’ve had “Backpack Federation” on the Open Badges roadmap for a long time. It’s always been the next thing we’re going to work on, but it continually gets pushed down the list by other high priority items. My goal in this post is to remove the “Federation” project from our roadmap entirely and focus on the features we mean when we say federation. Those features are absolutely within our reach, some of them are being worked on now, some of them are complete and in production.

What does “Federation” mean?

“Federation” just means distributed, with no central service that’s solely responsible for the maintenance or governance of the service. The internet is arguably the greatest example of a federated network. There’s minimal central authority; anyone can add a node to the network. Facebook is the opposite, a single entity controlling a large network of users and services. Facebook allowing users to post Tweets to their timeline counts as federation under some definitions of the word, but for our purposes, we’re talking about distributed systems without a central authority.

What do we mean by “Federation?”

We pack a lot of meaning into open badges federation, what we really mean is “distributed badge storage that gives users choice and opportunity to be discovered for their achievements.” Federation means more backpacks, more user choice and more user benefit. I’ve written more about federation in past blog posts, and even more about a world with more backpacks.

Some brief user stories help illustrate what we mean by federation,

I earn a badge at my local public library and can put it into the Mozilla Open Badges Backpack, or onto my school’s backpack, or my backpack on my phone.

I make a badge for Javascript programming public in my backpack. A week later, an employer finds my badge through a search for JS skills and I’m asked for an interview.

A researcher gathers anonymous data through the distributed network of backpacks about the amount of time it takes to learn skills equal to an undergraduate math degree via free online courses.

I want to learn how to research my genealogy, I find resources and badges online through a search in my backpack.

A teacher can see the badges her students have earned over the summer, and associate them with common core standards she needs to teach this year.

A teacher can find content and badges for his classroom that maps to common core standards.

A teacher can associate a badge they didn’t create with a common core standard; letting her colleagues know that it’s a great alternative to the canon curriculum.

Let’s stop saying Federation

Let’s break down the scenarios above and give a rough idea of what needs to be built to satisfy the need.

I earn a badge at my local public library and can put it into the Mozilla Open Badges Backpack, or into my school’s backpack, or my backpack on my phone.

Our first pass at this feature was a prototype of a issuer api shim that stored your backpack of choice in the browser. It’s still viable, but we’re also thinking a lot about badge baking. A badge that includes metadata about what the badge represents inside the badge graphic, a “baked badge”, is a super portable badge. The current backpack concept requires that the earner “push” their badges into a backpack. By contrast, for years we’ve had an idea for a backpack that ‘pulls’ badges from an issuer; let’s pursue that. With a “pull backpack”, a lot of the burden of the Issuer API is taken from the Issuer. If they give a baked badge on their site, a “pull backpack” can suck it right up. Pinterest for badges!

I make a badge for Javascript programming public in my backpack. A week later, an employer finds my badge through a search for JS skills and I’m asked for an interview.

We’re working on a prototype of a badge directory which focuses on indexing BadgeClasses (the definition of an earnable badge, instead of the BadgeAssertion, which defines an earned badge). If we extend the directory to allow for indexing of BadgeAssertions, backpacks could report earned badges to directory services. The directory services could share feeds of their indexed objects, acting as supernodes in a network of badge indexers.

A researcher gathers anonymous data through the distributed network of backpacks about the amount of time it takes to learn skills equal to an undergraduate math degree via free online courses.

Also solved by a network of badge directories.

I want to learn how to research my genealogy, I find resources and badges online through a search in my backpack.

The Mozilla Discover prototype demonstrates how we can use a directory service that includes explicit machine readable learning pathways to make it easy for learners to create their own learning opportunities. Just like the idea of indexing BadgeAssertions in addition to BadgeClasses, we should create a specification for a BadgePathway and index it in the network of Badge Directories. That specification work will happen in the Badge Alliance Open Badge Standard Working Group.

A teacher can see the badges her students have earned over the summer, and associate them with common core standards she needs to teach this year.

By creating “pull backpacks” (backpacks that gather badges instead of waiting for issuers to push them to them) we’re opening the door for specialized backpacks that cater to specific users – like school age children that need additional checks on their internet usage from guardians and school officials. Allowing a school to host a backpack makes it easier to tie out of classroom achievements with in classroom learning.

A teacher can find content and badges for his classroom that maps to common core standards.

The Badge Alliance Endorsement Working Group is considering methods to allow third parties to add information to a badge, without needing the badge issuer to change their BadgeClass definition or a badge earner to change the issued BadgeAssertion. Badge directories will play a key role here too, indexing these kinds of endorsements and making them available to badge consumers.

A teacher can associate a badge they didn’t create with a common core standard; letting her colleagues know that it’s a great alternative to the canon curriculum.

While it’s great to create an endorsement for a broad audience, we shouldn’t lose site of instances where metadata could be added a badge and shared inside a private group for a specific purpose. Directory services need to scale big, but there are use cases that need small specialized private directories as well.

So, what’s this all mean?

Kind of like the parable of the boiling frog or less gruesomely, my parable of getting a full meal out of a bunch of small plate appetizers, we’re going to meet the goals of federation without a specific project named “federation”. Federation is dead, baked badges, backpacks that pull badges, badge directories, pathways discovery and endorsement are the new distributed federation.

Lot’s of input for this post came from John and Carla. Thanks! Feel free to comment on this post below, or get involved with a Badge Alliance Working Group to keep the conversation going!

The specifications that make up the Open Badges Standard form the basis for the Open Badges Infrastructure; the collection of platforms and tools that make Open Badges possible. While the infrastructure has continued to grow, the standard has remained pretty stable over the last year. That’s not necessarily a bad thing, standards are standards because they’re stable. Despite its growth and reach, Open Badges is still a young project, there’s plenty of work to be done, so it’s time to start looking at the standard with a critical eye. Is it complete? What does it need?

Badge Alliance Standard Working Group is made up of organizations and individuals that ask those questions. We’ve worked together to evaluate the existing specifications and look for opportunities to improve and extend their reach.

Paperwork

The first issue we tackled was largely administrative. How do we function as a group? The Alliance built each working group with a chairperson, an Alliance liaison, and a cabinet the chair and liaison assemble. The Standard WG is a bit different, because we’re maintaining technical standards, we also decided we needed a more formal charter that explained how changes to the standard would be proposed, evaluated and accepted or rejected. We based the first draft on similar charters written by the W3C, and the Python Enhancement Proposal process the Python community created. The first draft of the BA-Standard WG charter is here.

Workwork

It was pretty clear that the number one addition we all wanted to see added to the specification was a formal way to extend the assertion, both as a way to add information and as a way to experiment with future ideas.

We posted draft proposal to the openbadges-discussion, discussed, updated, discussed, iterated, and discussed some more.

We found that it was difficult to extend the schema if we couldn’t describe the schema in a machine readable way. We’ve put the extension specification on hold until we have a full json-schema representation of the 1.0 specification. After that, we’ll represent schema extensions in json-schema, most likely taking advantage of the json-schema ability to extend json-schema.

What’s next?

We expect the json-schema-fication of the 1.0 specification / schema by June 24th, and the extension specification by July 8th. After that, we need to sync up with the Endorsement Working Group and ask the difficult question, “After you issue a badge, is it mutable? Can we add information to it?”

How to get involved

If you’re an organization that relies on the Open Badges Standard, or if you’re just interested in schemas and specifications, we’d love your comments on all the above! Join the discussion on the BA-Standard WG Mailing List or join one of our bi-weekly calls.

This is the second post in a two part series on BadgeKit, in the first part, I wrote about BadgeKit Now, looking at how you can set up a version of BadgeKit on your own servers now.

BadgeKit is coming! Like I wrote last time, it’s already here. You can pull a handful of Mozilla Open Badges projects together, host them on your servers and build a complete badge platform for your project. All that’s easy to say, but not easy to do. BadgeKit will streamline launching an open badge system so that just about anybody can issue open badges with an open platform that grows with them.

Sunny and Jess wrote an overview of where we want to get to by March, a MVP Beta release for the Digital Media & Learning conference. The release will give users two ways to work with BadgeKit,

SaaS – define your badge system on the fully hosted site (or your self-hosted site), integrate the system with your existing web applications through our API’s.

Self hosted – the full experience outlined above, but hosted on your own servers.

In both cases, the issuers build a website that interacts with our API’s to offer the badges to their communities.

The project divides easily into two big buckets – first building out the API’s we created in Open Badger, Aestimia and the Backpack, second building a solid administrative toolkit to define badges and assemble them into larger badge systems. Issuers use the toolkit (which will live at badgekit.org) to design and launch their badge systems, then they’ll integrate the community facing portions of the system into their own site (which preserves their custom look and feel) with our API’s. Here’s a quick sketch of what it all will look like,

Lot’s of API’s

More Flexibility

Last week we talked about a few services in the BadgeKit Now post, OpenBadger, Aestimia, Badge Studio, a ‘badging site’ and the backpack. None of those pieces are going away, but they are all going to get a makeover – each is stripped down to the roots and rebuilt with an emphasis on their web API interfaces. We’re going to standardize on MySQL as a datastore, explore Node.js’ streaming API’s for database access and output and rebuild the account authentication model to allow the services to support more than a single ‘badge system’.

Data Model

The current data model uses a three-tier ownership chain to define a single badge – a badge belongs to a program, a program belongs to a issuer, a issuer is part of a badge system by being defined in the instance of Open Badger. There’s a one to one mapping of a ‘badge system’ like Chicago Summer of Learning to an instance of Open Badger. Adding an extra layer, so that a badge belongs to a program, a program belongs to an issuer, an issuer is part of a badge system, which sits beside other badge systems in the single instance of Open Badger will open us up to hosting several large systems per ‘cluster’ of Open Badger servers. We’re breaking the one to many relationship of a badge to a program and a program to an issuer and allow for badges to belong to multiple programs, or programs to multiple issuers, issuers to multiple systems, providing more of a graph-like collection of objects.

Authentication and Authorization

This collection of applications authenticates the identity of each piece in the chain by signing API calls with JSON Web Tokens. The key used in each app is configured as an environment variable, as long as each app knows the key, they can read and write to other applications with the same key. When we build badge systems that are co-hosted, but span multiple applications (Open Badger talking to the badge site, the badge site passing messages to Aestimia) we’ll have to change the way the distribution of keys between the applications. The client site API keys will allow them access to the hosted API’s.

What’s Next?

You can follow the development of all these pieces on Github and read more about the system as it develops on Planet Badges.

This is the first in a two part series on Badgekit, the new badge issuing platform from the Mozilla Open Badges team. This post talks about the current suite of issuing tools we’ve built, the next post will talk about where we’re headed.

This post will explain how you can cobble together your own version of what will become Badgekit now. A follow-up post will explain the improvements we have planned, which will make Badgekit different from the collection of tools we have today.

Conventions

There’s a few things in common in the apps that I’m going to write about here, in no particular order –

Node.js – everything we build is in Javascript with Node.js on the server.

12 factor – We’re bought into Heroku’s 12 factor application architecture. We follow it pretty closely. That means that most of these apps use environment variables for configuration and don’t write to the filesystem for anything.

Heroku – for most of our production applications, we run in custom AWS EC2 instances, but given the above 12 factor point, it’s entirely possible to run a complete Badgekit-now system in Heroku.

Datastores – there isn’t much consistency in datastores, we use MySQL in some places, MongoDB in others, Memecache here and there, Redis. There’s very little consistency (which will change as we move towards real-Badgekit).

Lot’s of API’s and Webhooks – the apps all have big healthy API’s and do lot’s of inter-app communication by Webhook callback.

One instance per ‘client’ – every client of Badgekit runs their own instance of all the tools. That made it easy for us to punt on serious user authorization. If you can log in, chances are you can do just about everything.

Open Badger is the biggest application in the current Badgekit implementation. It handles the core functionality of a badging system, defining badges, issuing them, tracking whether someone has accepted an issued badge, creating claim codes for in-real-life badging, it’s a big collection of tools that accumulated over time. Almost everything is available via the API. A single instance of Open Badger will manage a full badge system with multiple issuers. The model fit the Chicago Summer of Learning, which had issuers, who had programs, which had badges.

You can build a badge inside of Open Badger, define criteria to earn the badge using a bulleted list of yes / no questions the assessment tool uses to evaluate the application, and upload a badge image. You can’t design the visual image for the badge, which we realized was a limitation on CSOL. So we built Badge-Studio (try it out here) to visually design the badge. (Badge Studio is another tool that will be greatly improved for the release of Badgekit).

The best thing to come out of Open Badger is the API. It’s full featured, makes it easy to list badges, easy to issue, and served us well in several installations. It proved to us that a solid API is worth the effort (I mean, we were already pretty bought in, but it reinforced the idea). You can see an example API call here – a list of badges available for MozFest 2013.

First of all – it’s Latin for “assessment.” I named it, for better or for worse, in a fit of Latin nostalgia (does that exist?). Aestimia is the thinnest possible assessment platform. When a user applies for a badge, the client site sends a package to Aestimia that includes the learners submitted evidence and a criteria listing it grabs from Open Badger. Aestimia returns an application id, then calls a webhook url the client site defines with any updates to the application. When an evaluator evaluates the application, Aestimia tells the client site about the changed state. The client site then chooses what to do with that information, either issuing a badge and emailing the learner about their new badge, or emailing the learner that the badge wasn’t awarded.

Because Aestimia only cares about criteria and evidence, it doesn’t necessarily need to end in the awarding of a badge, it could be used for assessment for any sort of situation. It’s entirely possible to build a system on top of Aestimia and Open Badger where a user does several assessed activities before a badge is awarded. Open Badger doesn’t understand an activity outside of a badge, so you’d have to hack it a bit to store criteria, and you’d need to build in some logic (maybe with tags?) to define a ‘path’ but – you could do it. Hacking aside, all those things will be key features of Badgekit, we have lots of plans!

One interesting sidenote from CSOL – because the Open Badges infrastructure doesn’t yet support federated backpacks, and because the current Mozilla Backpack can’t host badges for under 13 year olds, we ‘faked’ backpack functionality by creating an Open Badger API authenticated endpoint that provided a list of badges issued to a particular email id. In installations where users under 13 aren’t an audience, we push the badges to the Mozilla Backpack as a way of ‘accepting’ the badge.

All badge issuers need a place to store badges, I’ll write more about our plans here in the next Badgekit post, but for now – federation will fundamentally change how we think about backpacks.

Client sites

The CSOL client site was heavy compared to Connected Educators Month and Open Badges Badges. Largely because it had to handle user accounts and parent / guardian approval workflow for learners under 13. Subsequent sites were stateless with limited server code, feeding off the Open Badger and Aestimia API’s. That architecture works well for us, we expect continuing with it as much as possible as Badgekit develops.

How it all flows together

Phew, that was a lot of words. Let’s make some (low tech ASCII) pictures explain how all these pieces fit together.

The user picks a badge, and submits evidence that they’ve completed the badge. The evidence, plus the evaluation criteria for the badge (from Open Badger) are sent to Aestimia. After the evaluator evaluates the evidence, Aestimia calls back to the badging site to let them know they finished the evaluation. (see all the new arrows?)

Let’s say the learner got the badge! Hurray for learning! The client site then calls to Open Badger to issue the badge, most likely by asking Open Badger for a claim code embedded url that the site can email to the user. Once the site has that link, it sends it to the user via the email service.

And that’s it! Easy, right? Not really. It’s actually pretty complicated. There are multiple variations to the above flow, and it’s not even clear that we want to make the learner jump through the claim code acceptance flow – most learners just want their badge! Plus, each of those boxes is a separate piece of hosted software. This isn’t a setup for the feint of heart.

Which is really the point of Badgekit – all those services make sense. They’re the right thing, so what can we do to make it easy to use them? Plus – we’re not the only tool provider, maybe there’s a better assessment tool out there, maybe an issuer uses another issuing platform, but wants to use Aestimia. Badgekit will make hosting all these things seamless, without having to know the difference between Open Badger, Aestimia and whatever else, and give an issuer choice in how the pieces of their program work together. To paraphrase some advertising campaign somewhere – issuers should worry about teaching and making cool badges, not about how their badge system moves bits of data around.

The Open Badges team had its first tech panel way back on September 26th. The tech team met with active Open Badges community members to talk through the heavy tech-bits of Backpack Federation (which I wrote a bit about in “Let’s Make More Backpacks.” The raw notes from the meeting are here and video is here. It’s been a while since the meeting, but I wanted to summarize what we talked about there, and add some thoughts on where we’re headed next with Backpack Federation.

Federation is the Pipes

Backpack Federation in its minimum viable form is about moving badges around between the users backpack of choice. That was our target for the tech-panel demo, and our target for the first release of the feature. The result looks a bit like this,

Federation System Flow diagram by Jess Klein and Brian Brennan

It’s a simple goal, we’re confident we can roll it out in a couple of weeks, given it’s prioritization against other projects. However – that’s the Open Badges core team’s goal – the community wants more, and weren’t shy about saying it.

Federation should be about mobility

One of the themes from the discussion was that backpack federation is about more than just moving the badges around, it’s about creating more value in the badge – adding evidence directly to the baked badge, making the badges portable without relying on an issuer’s site, making the badges less about pushing them places, and more about pulling them.

Where do we go from here?

To start with, we’re absolutely going to have more tech-panels. It was a useful conversation and influenced our thinking, which I think you can see in some of the projects that came out of the Mozfest hack-sessions – the full assertion baked in the badge, and the start of the directory service. The former starts to address the issue of true portability of open badges and the latter starts to move us toward a pull-model of badge discovery.

We’re still committed to basic “push your badge to the backpack you want to” functionality as the MVP for Federated Backpacks. It’s a key part of the Badgekit project we launched at Mozfest and opens up the world of customized backpacks in a way that we’re convinced will change learners use of open badges.

Thanks to all that attended the first Open Badges tech-panel! The next one is tentatively scheduled for early November (fill out this Doodle Poll if you’d like to influence the timing). We’ll be talking about the 1.0 changes to the assertion specification and all the possibilities it enables.

Following up on a post on the Mozfest blog, I wanted to give a big shout of thanks to the folks that came out to support Open Badges in our hack-track. We had around 8 hours of time built into the schedule for building new things on top of the Open Badges infrastructure and the Badgekit stack. I’m thrilled with what we accomplished, some highlights…

Open Badges Crawler / Indexer

Andrew from DIY built a service on top of the backpack that indexes all the badge classes loaded and marked public. It uses our database to bootstrap a crawling process that finds and indexes badges. It’s a first big step towards building a service that makes it easier for learners to find badges they want to earn. We’ll get it deployed live soon, in the meantime the code is up on github/thisandagain/badgecrawler.

Bake Everything!

In the current baking spec, we only specify that the link to the hosted assertion file be ‘baked’ into the badge png. It’s a good thing, because it pushes validation back to the issuer, but it makes very lightweight issuing difficult. Any issued badge requires a server to host the assertion, or a public key to validate a signed assertion. For a huge swath of badges, we’re less concerned about validation, and more concerned about attaching metadata that describes an accomplishment. Mozilla’s own Potch submitted a pull request to the bakery service that bakes the entire assertion into the badge, a huge leap forward for anyone that’s ever wanted to just quickly bake and email someone a badge without worrying about hosting.

Badge Everywhere!

The fine DigitalMe folks posted a map where people could put physical push pins that represented a commitment to launching a badge program in the place under the pin. The ever-resourceful and recent OpenBadges full-timer, Erik Christensen, built it as a real web site – Badge the World!

Badgekit and Appmaker, PB&J

We announced Badgekit (more on that from Erin, Sunny and Jess) at the festival, launched Open Badges Badges and MozFest badges on the platform and then started playing around with it. A few people came to the hack sessions wanting to mobile-ize issuing. Jess led several sessions on tools for disaster relief that included badges (which she writes more about on her blog), Telefonica and Unicef joined Mozilla to work on a mobile donation platform that included badges and bunch of us wanted an app to issue badges in a game of werewolf (excuse me, WereFOX).

When we realized we were in a room full of people that wanted to make mobile badging apps, we decided it would make more sense to build a series of Appmaker components. All in all, David, Laila and I built three key components, an issuer (which interacts with OpenBadger via claim codes and the API), a badge lister (fed by the OpenBadger feed) and a Twilio SMS’er. Given those ingredients, it’s possible to build a whole bunch of interesting things. The Appmaker team is working hard on getting external component libraries includable from the main Appmaker site – as soon as that happens we’ll be able to unleash a hoard of custom mobile badging apps!

Appmaker is really pretty cool to work with, and matches the goals we have for Badgekit – make hard things easy, build a community around a product. We’ve known the Appmaker squad for a while, and we’re super thrilled how easy it was to smoosh Badgekit tools into Appmaker containers. Really excited to keep that going.

Doug caught a great picture of the Erin / Jess plenary demo of the Appmaker / Badgekit super-combo,

@willowbloo just posted (Nov 3) a video summary of the disaster relief badge project she and others worked on, more on Youtube.

Learning Pathways

Chloe and Mike built this amazing demo of where we could head with Learning Pathways. The process of linking badges together into a pathway that other learners can duplicate and follow.