Over the last year I’ve been playing with how to use the master branch for some projects, as a private content and data storage. Github repositories are cool like that, where you can make the gh-pages branch public, and the master branch private. If I don’t want some content, JSON data, or files public, I just put it in the master branch for the research project.
All of this is possible because of Github, the social coding platform. Github provides a cloud platform on top of the open source software management solution Git. Using Github I can create repositories that act as storage solutions for each of my research projects. I count 78 repositories currently making up the API evangelist network, but I see over 100+ repositories in my Github profile. Most of my repositories are publicly available which is free with Github, but a growing number are private, and my monthly bill for Github has increased each year.
Jekyll is a simple, blog-aware, static site generator perfect for personal, project, or organization sites. Jekyll gives you the ability to manage the look and feel of your site, along with simple management of pages, and a blog. The rest is up to you. There are plenty of folks who are pushing the boundaries of what Jekyll can do, comparable to the evolution of the WordPress platform, but in a much more static way–Jekyll is the hollywood front for all of my public website.
Along with Git repositories, Github Pages, and the other social features, Github provides an API which gives you access to users, repositories, files, and pretty much every other aspect of the Github platform. This means that each one of my research projects, and their public web sites have an API. I use the Github API to publish all of the blog posts, pages, and JSON data files that support my research, across 78+ projects.
In the header of my websites, I add a little handler that keeps an eye out for the incoming oAuth_Token–Github and oauth.io handle everything else.
Using Github.js I try to grab the contents of a file in the private, master repository, and if the authenticated Github user is added as a collaborator on the repository, the call is successful, if not I deny the user access to any content, data or files in the projects master repo. This is the line between public and private, or front-end and back-end on my websites. Using Github identity as authentication to my private world, I am able control who has access, using the standard Github organization, and user management.
Currently I’m using this layer to decide whether or not to access and display data from JSON files, and access to PDF files located in the master branch. You can see this in action via my messaging research of email, SMS, or MMS. If you are listed on each of the projects repos as a collaborator, and logged in via Github, you can see the building blocks for each research area, and the current PDF version of the research report–otherwise you just get the default information.
As with all of my work, this is a work in progress. This step in my evolution is all about using as a paywall for my research, where other tools I’ve built like my CSV Converter, and Data On Github applications are using the master branch as application store, even if you aren’t logged in the app will still run, you just can’t save anything. Next I’m going to play with this approach as part of my API broker research, exploring different ways of aggregating APIs, and managing key access using the private master branch for each repository.