Name of Project: Crystalizer
Proposer: hhff
Do you agree to open source all work you do on behalf of this RFP and dual-license under MIT and APACHE2 licenses?:
Yes, although we'd like to offer a paid plan to help us support infrastructure costs and provide ongoing maintenance, ie - something like how Sentry works. Given this is a CI style tool, we'd likely offer "parallelization" as a payment option (ie, paying for a "dedicated build queue" rather than waiting for the public queue).
Deploying and hosting static files with IPFS is not "beginner friendly" (in our humble opinion!). Developers need to understand a bunch of terminology (like "pinning", etc), and why they (probably) need pay for a pinning service, or spin up their own IPFS node. In addition, managing IPNS or DNSLink along with a DNS provider is confusing for folks who are new to regular DNS in the first place.
A CI style Github integrated pipeline that automates this complexity for the developer. This service would:
- Allow the developer to connect their Github account/org(s), and select project(s) for auto-deploys to IPFS
- Allow the developer to elect one or more git branches in a project as "pinned" (ie, integration, production, dev)
- Whenever a "pinned" git branch is updated, static assets would be built from the codebase, deployed, and pinned to an IPFS hash
- Allow the developer to debug build logs by surfacing them in a UI
- List all known "IPFS hashes" mapped to previous deploys in the UI
- Automatically manage IPNS/DNSLink on behalf of those pinned branches
- Allow for immediate "rollback" to a previous IPFS hash via IPNS/DNSLink via the UI
- Send a webhooks to another service on successful deploy
We originally built https://www.crystalizer.io as a way to preview PRs before they are merged, but we were beaten to market by https://featurepeek.com, which is ultimately a better product. As such, we already have in place:
- A fully integrated CI pipeline working against Github oAuth, written in Ruby on Rails
- A buildstep & background job queue for building and deploying static assets against multiple frontend frameworks on the fly (in docker containers via Kubernetes)
- A brand guideline, UI styles, and implemented component library for neat UI (screenshots below)
Changes we'd need to make to repurpose as a zero config IPFS deploy tool:
- Update all Design, Marketing & Documentation for IPFS concepts
- Redesign & reimplement build and deployment against IPFS
- Add IPNS/DNSLink management layer (for automatic + manual rollbacks)
- Under-the-hood move to using
Now.sh's open source builders (Apache 2.0) to support all of the frameworks listed here with zero config (currently we use our own logic here)
In recent years, the JAM (Javascript, APIs, Markup) Stack has become a really popular way of thinking about web apps and deployments. Services like Netlify & Now.sh have popularized these methodologies by adding a bunch of utility around this style of building and hosting. The JAM Stack is taught readily at developer bootcamps, and as such, is something new developers usually lean in to.
In addition, we've already written the core of the user facing app in Ruby on Rails, lowering the bar to external contributors to participate in improving the product.
We lower the bar (friction, person time, etc) to using IPFS as a viable deploy target for a really big and diverse group of developers (juniors, and everyone) - thereby increasing IPFS adoption! In addition, we'd simplify the concept of "rollback" deploys to these same developers, as permanent, immutable IPFS deployments are ideal for such a concept.
The main risk is that Netlify & Now.sh add IPFS as a hosting target in response to seeing how we do that (given our code would be open source). This doesn't strike me as likely, but who knows...!
However, in a lot of ways that would mean Crystalizer fulfills it's primary goal: increasing adoption of IPFS.
The main risk here is that when I last used IPNS, it was quite slow to resolve (upwards of 30 seconds). I understand that DNSLink is a faster way to achieve a similar thing.
In a worst case scenario, we could run an nginx proxy or Cloudfront Lambda function to improve usability by handling DNS routing to specific IPFS hashes on the fly.
A secondary risk is user acquisition - we are not experts in product promotion. The success of this software is dependent on people actually using it! More volume means more paying customers, and more paying customers means we can afford to dedicate time to maintenance.
- 3pts Rewrite content narrative
- 3pts Repurpose existing graphics
- 3pts Design new graphics and animations
~ 1 week of 1 designer's time
Deliverable: New designs for the Marketing homepage
- 5pts Redesign UI for for IPFS concepts
- 3pts Update ORM Schema to support IPFS hashes and such
- 5pts Update Projects#Index with IPFS details
- 5pts Update Projects#Build with IPFS details
~ 2 days of 1 designer's time ~ 1.5 weeks of a frontend developers time
Deliverable: New designs & a working UI repurposed to work with IPFS hosting concepts
- 3pts Implement Slack Integration
- 5pts Implement Sending External Webhook on Deploy Completion
~ 1 week of a backend developer's time
Deliverable: The ability to connect a Slack channel to notify users of new deployments, and the ability to post webhooks on this same event, for the sake of breaking caches and triggering other such services.
- 13pts Update Tooling & Build step to use Now.sh CLI
- 13pts Update Tooling & Deploy step to push to IPFS
- 8pts Handle Rollbacks and DNS Management (IPNS/DNSLink)
~ 3 weeks of a backend developer's time
Deliverable: The core technology. A zero-config, framework agnostic buildstep that deploys static assets to a unique IPFS hash, and optionally manages DNS routing, etc.
- 30% of total points
~ team effort, hopefully including the grant committee!
Deliverable: A ready-to-launch web application for users to connect their Github account, and start shipping static assets to IPFS!
If you'd like to read more about how we quote technology, we've detailed it here.
Please Note: The numbers here are indicative of "cost" to employ developers here in NYC (with health insurance, payroll taxes, etc). These numbers do not have a profit margin built in: we are fans of the IPFS ecosystem, and would love to be able to afford the time to build something great on top of it!
69 points * 1.3 (QA & Testing) / 13.5 (our burndown) = 6.6 person weeks
6.6 person weeks * $2800 (average cost to employ a person in NYC per week)
= $18,480
I plan to work on this (personally) roughly 2.5 days per week. Given the major timeline here is development (design timeline is short and can happen parallel).
As such, we'd expect a launchable application to be ready roughly 12 weeks from grant approval.
We'll be using it internally (instant rollbacks and cheap hosting is huge) so we'll ensure it's always in working order as a necessity.
However, we would like to grow this product into a profitable offering for hosting static assets. We'd love to eventually offer some additional services like free SSL via LetsEncrypt, on the fly serverside rendering, and perhaps some CDN integrations. In order to be able to do this work, we'd first need a profit generating product so that we can afford to commit development time to it.
- Hugh Francis
- Joshie Fishbein
- Christine Kim
- Alicia Willett
- Harrison Wideman
- Sebastian Odell
- Ellis Marte
- Sohee Lim
- Kay Mok
- Conor Davidson
https://www.sanctuary.computer
Our team works with the JAM Stack quite often, for client projects! We're very familiar with CI tools (we use CircleCI a lot, and I've used Travis in my open source work). We currently use CircleCI w/ Docker to build and push to S3, so we're familiar with the quirks of getting single page apps up and serving traffic.
In addition, we're experts in Rails, Docker, Kubernetes, and the like. The software stack we're working with here is a known quantity, through and through.
We're a product studio, so most of our client work is private, however we do open source a lot of things here, including non-code stuff like financials.
Screenshots of Existing Product
