-
Notifications
You must be signed in to change notification settings - Fork 6
Proposal
Adapted from a ridiculously long email to Jeremy -- here is a write-up of the revised Hacker Union mission (not adjusted to reflect last night’s discussion).
Please feel free to edit, annotate, and alter!
Create a git repository for "root". This is the generic form of a Hacker Union chapter. New chapters are created by forking this repo.
Create a git repository for "kernel". This implements the web interface to Hacker Union, the RESTful API, and various other odds and ends. For convenience, this is implemented in node.
Link the "root" repo to the "kernel" repo using whatever that magical git thing is that lets one repo reference another. This is how chapters associate themselves with a particular kernel. (I've never done this so I have no idea if this is valid). If I'm making things up, this can just be a git URL.
Provide a faculty for adding modules to the kernel: i.e., a convenient way to add extra optional functionality to a kernel. Modules are implemented in and are imported by the kernel dynamically.
Ideally, the kernel references external repositories containing the module code rather than hosting the code itself. This would allow chapters to fork the kernel and add custom modules that may not have been deemed suitable for global availability.
The kernel runs on a server managed by the chapter. For convenience, I'd like to use dotcloud as a simple built-in way to deploy a chapter server (we can probably negotiate a sponsorship and/or just raise money to pay for chapter's hosting).
Each chapter generates a secure public/private key pair. The private key is managed by chapter leaders. The key must be accessible to the server so that secret information can be decoded.
The kernel, once deployed, will -- via a git hook -- automatically pull the latest commits from the chapter git. This is safe as the only people with push rights are organizers; all others must submit pull requests. Additionally, chapter repos don't contain kernel code.
Deploying a kernel will require a small amount of bootstrap information including, at minimum, a chapter repository URL and a private key.
The chapter repository contains all data in a serialized JSON format, suitable for import into mongoDB. Private information is encoded in the public git repository by encrypting with the chapter's public key and embedding using a notation similar to: { 'type': 'encryption-scheme', 'value': '...' }.
Members are provided tools (potentially in the web interface / API) for encoding arbitrary data using the server's public key so that generating valid pull requests to [say] add a member, event, or other data is simple.
The encrypted values are embedded within the plaintext JSON to allow those interested in perusing the repo the ability to view the data's schema; we want to keep as little secret as possible.
Every chapter includes a .meta file that includes private confirmation information for that particular chapter. Data in this JSON file can be encoded or, using a notation, refer to a server environment variable. This file can be used to house API keys, preferences, and other kernel configuration options specific to that chapter.
The kernel is actually a simple node application. In addition to automating the process of pulling chapter data, decrypting, and storing the data in a database, the kernel provides a simple browser that is used to render data from the chapter repository as well as to expose key data and functionality via a straightforward API.
The rendering component is similar to Github Pages but simpler and driven entirely by simple conventions.
Entries in the chapter repository with a certain extension are interpreted as markdown documents. Others are interpreted as text documents. Still others are interpreted as embedded javascript modules.
Typically, the kernel will render each in a traditional -- and super cool -- old-school directory listing-type layout. This will both harken back to a simpler time, optimize the user experience for a developer user-base, and place all emphasis on data quality and functionality.
Again via convention, certain files and directories will be flagged private and will require a valid hacker union account to continue. Accounts are managed via the chapter (using the partially encrypted users data).
The "authorization required" dialog will provide essential information on local orientation sessions for those interested in joining as well as a field for logging in.
Once logged in, access and execution can continue as before.
Modules are included dynamically into the kernel and can therefore alter functionality in any way that doesn't directly modify the kernel source code. A convention will be established, however, to place references to modules in a navigation bar or other appropriate area.
Modules, generally, provide non-essential but still fairly "core" functionality (i.e., events listings, member search, wiki). These are initiatives that are likely to be useful to every chapter and that carry the endorsement of the maintainer of the corresponding kernel repository.
Non-essential functionality -- or apps that are hosted externally or that integrate via the API (or are not integrated but of value to chapter members) can be included as references. References also appear in the module navigation bar and allow chapter members to quickly access community initiatives.
References can also be included in the directory structure of the chapter repository similar to the way symbolic links work in UNIX environments.
References have two forms: privileged and unprivileged. Privileged references request access to the logged-in user's account and therefore the chapter's private data. Non-privileged is a simple link. User's are warned before a reference requiring access is executed.
The API provides programmatic access to chapter data. It may be sufficient to simply provide a key-based, managed interface to the data in the repository supporting standard query operations. If not, data-specific functionality can be integrated (i.e., an /events endpoint or a /users endpoint).
API access is granted on a per-chapter basis. Users in one chapter can't necessarily access the data of another chapter. However, it is possible (using the .meta file described earlier) to list chapters that are allowed or denied access; thus, the kernel will trust authentication decisions made by approved chapters' kernel.
The authentication API provides an oauth2-esque mechanism for granting third party hacks (i.e., "References") access to chapter data. A global "Connect with Hacker Union" mechanism will be included in the kernel that will allow a user to authenticate via a specific chapter. Chapters are free to override this but having a consistent Hacker Union connection process should be a goal.
With the above implemented, the Hacker Union becomes a "community incubator" for hackers. The Hacker Union's new mission is to provide necessary infrastructure to help local developer communities flourish.
This is achieved by providing common, useful tools such as events listings, member directory, newsletter alerts, venue directories, etc as core, shared modules. Importantly, none of these modules need exist prior to kernel launch.
Additionally, as a community infrastructure, Hacker Union gathers members together and provides a single, trusted directory of valuable tools, information, and resources for local hackers.
The framework also provides a common interface for hackers to plug into the local (and global) dev community and to work together to solve problems, share information, and build nifty tools.
The final piece is two-fold: in person meetings and concrete resources.
A weekly/semi-weekly hacknight is scheduled with the singular goal of "getting smart people together and building cool stuff, optionally for the mutual benefit of the community". This provides a time and space for members to socialize, hack, and support the chapter.
A monthly orientation is hosted to explain the Hacker Union framework (everything described in this email) and to manually approve each individual member. An organizer with push-rights will be present to add users to the chapter repository's data file. Additionally, we'll track down some super awesome retro printers to provide official membership cards with the member's username and the organizer's signature.
Last, Hacker Union will work to build a fund that can be allocated to members building projects that support the community -- including servers, meetups, venues, food for events, and anything else that might benefit from $100-$500 of funding.