<div> <img src="https://i.imgur.com/B2BfZIk.png" alt="openregistry-logo" width=400/> </div> <br> We started OpenRegistry as a fun project when we [saw Greg Osuri(CEO at Akash Network) mention](https://youtu.be/4xlOVeUXd90?t=2763) they’d reward anyone who’d build a container registry on Akash Network and Skynet. We started putting a few hours everyday in building what is now OpenRegistry. After a short while, there came a [Sovrython Hackathon sponsored by Akash](https://akash.network/blog/akash-network-provides-decentralized-cloud-and-100k-in-akt-prizes-for-sovrython-hackathon) which motivated us even more to accelerate the work and present it for the Hackathon. We (Gunjan and Jasdeep) joined forces and started working on it together and submitted our first working prototype in Hackathon and [we WON!](https://akash.network/blog/everyone-s-a-winner-in-the-sovrynthon-hackathon-sponsored-by-akash) yayy!! We continued to work on OpenRegistry because at this point it was more than just rewards or a Hackathon to win. We believe that building in Open and maintaining a high bar for privacy is a must. We realized that in order to be completely decentralized, we need to work harder to problems related to infrastructure. Since containers are such an integral part our modern infrastructure development and deployment lifecycle, we must continue to build OpenRegistry and make it more reliable. ## Technical Details ### Backend The OpenRegistry backend is written in [Golang with Echo framework](https://github.com/labstack/echo) which is high-performance, extensible and minimalist Golang web framework. Golang is simple and among **top 5 languages** used for blockchain development. The list includes [Ethereum](https://github.com/ethereum/go-ethereum), [Polygon](https://github.com/polygon-io/client-go), [Cheqd](https://github.com/cheqd/cheqd-node), [Storj](https://github.com/storj/storj), [Akash](https://github.com/ovrclk/akash), [Tendermint](https://github.com/tendermint/tendermint) and many more. Another factor for Golang’s popularity in blockchain projects is the [Cosmos SDK](https://cosmos.network/). Golang is the default implementation and [over 250 projects are built using the Cosmos SDK](https://cosmos.network/ecosystem/apps). We use PostgreSQL for indexing data, mapping content hashes to user-friendly names, access control among other things. We do not collect any Personally Identifiable information (PII), except a username/email combination, which only helps the end user to operate OpenRegistry better. In addition to that, we use [Plausible](https://plausible.io/) to monitor user engagement. Plausible is a lightweight and open source web analytics fully compliant with GDPR, CCPA and PECR. ![OpenRegistry-push-layer-architecture](https://i.imgur.com/x46TKda.png) #### Push Layer Explained: 1. From Docker CLI, user tries to push an image to OpenRegistry 2. A container image is comprised of layer(s) depending on various factors, read more about how layers in an image are decided 3. The layers are further chunked into blobs for efficiency resons( read about multipart upload) which are then sequentially uploaded to user defined storage backend (skynet/IPFS). 4. Please note unlike blobs, the layers are uploaded concurrently which means at any point there can be multiple layers being uploaded to OpenRegistry without waiting for one another 5. The binary blob component hashes the contents of blobs and sends the contents of the blob to the resolver one at a time while keeping the hashes in the DB to be resolved later 6. The resolver uploads the blob to skynet or IPFS and brings back the content hash which is mapped to a container image or a container image tag in a human readable format or SHA256 fromat 7. With a blob recieved and processed by Openregistry, Docker is then notified about the successful upload of blob and to send the next blob to process. 8. Onec all the blobs for a layer hasve been recieved, OR combines them to calculate the digest of the layer and is stored along with the content hash supplied by skynet/IPFS 9. When a user, at some later point requests to retrive an image manifest from OpenRegsitry, they are given the Content hash along with the layer Digest which they can then use to download the layer directly from Skynet/IPFS As of Q1 2022, we have the following features available in OpenRegistry: - OCI Distribution Spec APIs (push, pull, content discovery, content management) - Authorization with JSON Web Token (JWT). We'll be replacing these with Platform Agnostic Security Tokens (PASETO), which provides a better layer of security for long or short term credentials. - Finegrained control over Access Control Lists (ACLs), so that users can configure how and what could be shared with others. - HTTP Basic Authentication - GitHub Token Authentication - Login to Web Console with Username/Password combination - Login to Web Console using Github - Container image catalog API (with few extensions) ### Web Interface The WebApp was previously written with React and JavaScript and is now being replaced with SvelteKit and TypeScript which will definitely make it faster and more efficient. We are also using a large amount of Tailwind CSS components which are lightweight. The new WebApp contains a beautiful series of illustrations by [flexiple](https://flexiple.com/), fresh color palette and a brand new Logo. The features Web interface has to offer are as follows: - Home page with container image search, overview and high level architecture diagram - Explore page that connects with catalog API from backend and displays all the available container images - Container image search with auto completion - Repositories page to display user's own repositories - FAQ section and a ticket window for additional help - User profile and settings page - About page with team data ### Database The Database layer was previously written with Badger which is simple to use key value store and fast like a cache. However for scaling and data organization, we have migrated to PostgreSQL database. We are planning to keep using badger for operations that are very frequent. Alongside this, we have tried to make an effort for future DB migrations to be simple, quick and with minimal code changes. This can be achieved by abstracting the database operations in OpenRegistry to an interface. Any new database like MongoDB could be implemented and used by just satisfying the storage interface with ease and no changes in existing code. ### Hosting and Storage OpenRegistry uses Akash Network as its compute layer and IPFS via Filebase as Storage layer. Both of these platforms are significantly more cost efficient when compared to their centralised alternatives. OpenRegistry database only stores the content hashes and maps them to human-readable names thus ensuring complete privacy. We're also planning to integrate with [iExec](https://iex.ec) for Continuous Integration of container image builds. ## What’s Next for OpenRegistry? There are great many thing we would want to introduce in and around OpenRegistry to build a complete ecosystem for public goods. We want to be more involved in community projects aside from our daily jobs and provide high quality service content as our contribution to community. Our goal is to make OpenRegistry as cheap as possible for everyone, which can be achieved with higher adoption by community projects and open source developers. With our current estimate, it would roughly cost us $250 USD monthly to handle 100 active users. ### WebAuthn Web Authentication or WebAuthn for short is relatively a newer standard for authenticating users in your applications. It’s a W3C standard and is supported in all latest versions of popular browsers. It is as simple as logging into your computer with Windows Hello or Apple’s [Passkeys](https://support.apple.com/en-us/HT213305). It works much like Public Key Authentication. Users simply process a cryptographic signature, and on success they prove to be the owners of a particular account/identity. Read more about [WebAuthn here](https://webauthn.io/) ### Integration with IPFS [Inter Planetary File System or IPFS](https://ipfs.io) for short, is a peer-to-peer hypermedia protocol designed to preserve and grow humanity's knowledge by making the web upgradeable, resilient, and more open. IPFS is one of the most popular projects in the storage and routing ecosystem. This means users of OpenRegistry will get to select the storage backend of their preference. Once you upload a file to the IPFS Network, it can be retrieved across the globe using any machine that can use internet. In addition to this, any file can be pinned, making that file available forever (or as long as it's not unpinned). This contributes strongly towards our data reliability goals. ### Integration with iExec [iExec](https://iex.ec) is an all in one platform for secure dapps, confidential compute, governance and oracles. With iExec you can build Web3 apps, run short lived tasks in secure environment, trade computing assets all while preserving ownership and privacy. iExec's task based compute system is a perfect fit for our new Continuous Integration feature. With this feature, you can connect your GitHub repository to OpenRegistry, which will use iExec behind the scenes to spin up small tasks to build and publish your container images automatically. ### Vulnerability Scanning for Container Images To detect and eliminate any malicious program in a container image, it can be scanned before a push/pull to make sure you get clean and safe to use code. To integrate vulnerability scanning with OpenRegsitry, we are exploring two methods at the moment: 1. Container image vulnerability scanning with [grype](https://github.com/anchore/grype) 2. Hosted vulnerability scanning as a service bundled with user subscription ### SPIFEE based resource access SPIFFE, the Secure Production Identity Framework for Everyone, is a set of open-source standards for securely identifying software systems in dynamic and heterogeneous environments. Systems that adopt SPIFFE can easily and reliably mutually authenticate wherever they are running. This will become very useful for orchestrating access at Organization level. ### Encrypted & Private Container Images Private container images are one of the most sought after features of a Container Registry. OpenRegistry does provide consistent hashing system for validating the contents of a container image but with encryption, this can be taken to the next level. One of the major advantages of encrypted container images is that you can control the accessibility to be limited to a particular group or organization. This means you can ship private code bases, propertied software or patented work within container images without having to think about it being stolen or misused. Even if such a container image comes in hand of malicious user, they will not be able to read or decrypt the contents of the container image. OpenRegistry will support popular cryptographic methods like Rivest-Shamir-Adleman (RSA), Elliptic Curve, and Advanced Encryption Standard (AES) and the encryption keys (private keys) will never leave the user (at least they won’t be shared with OpenRegistry). There are tools available in the market to encrypt container images on client-side and upload them to container registries. <br><br><br> ### Platform Agnostic Security Tokens Platform Agnostic Security Tokens or PASETO are a safe alternative to JSON Web Tokens (JWTs). JWT’s were never meant to be used as long-term credentials. Using JWTs as short-lived (5-10 mins) credentials is ideal but with a Container Registry, it makes sense to have long lived credentials in some cases. They’re very limited in scope and are used under secure contexts. Learn more about [PASETO here](https://paseto.io/) ### Org Mode Org mode will enable you to create and manage organizations within OpenRegistry. You can think of Org Mode as Github Organizations. This will let you manage a team or teams easily through org wide scopes, permissions and ACLs. Initially, Org Mode will include the following features: - Create & manage organizations - User Management within the Org - Fine grained scopes and permissions <br><br><br><br> ## Development Roadmap > ◻︎ To Do | ⚙️ In Progress | ✅ Done | ### Milestone 1 - (Completed in Q4 2021) > After successful completion of this **Milestone**, a user should be able to: Push, Pull, Search and Manage their container images on OpenRegistry. Any container engines (like nerdctl or docker cli) should also be able to use HTTP Basic and JWT Authentication. A basic form of Web Interface will also be ready to use. In addition to this, We should have received Certification from Open Containers Initiative Organization for implementing Distribution Spec. |OCI Disttribution Spec Implementation|AuthN & AuthZ|APIs, Web Interface, & Integration| |----|----|---| |✅ Push Container Images|✅ Implement Registry Spec Compliant Authentication Protocol|✅ Catalog API for Listing Container Images| |✅ Push Container Manifests|✅ Server Side Network and bandwidth Optimization|✅ System Wide Logging| |✅ Pull Contianer Images |✅ Migrate KV Store to PostgreSQL|✅ List Tags API| |✅ Pull Container Image Manifests|✅ JWT Support|✅ Basic Web Interface| |✅ Content Discovery & Management|✅ HTTPS - Basic Authentication|✅ Release Closed Beta Program| |✅ OCI Conformance Ceritification||| <br><br> ### Milestone 2 - (Completed in Q1 2022) > After successful completion of this **Milestone**, we'll have a brand new designs implemented. A state-of-the-art Web Interface will be released along with personalised blog posts, Login With Github, Autocompletion for searching container images and an Uptime status page to monitor OpenRegistry's uptime. |Web App Development|Workflows & Developer Experience|New Release and the way forward| |----------|--------|----------| |✅ Design Logo & Web Interface |✅ Logs & Metrics collection \w FluentBit and Grafana|◻︎ Cut a new release| |✅ New Home Page for OpenRegistry|✅ Uptime Status Page|✅ Integrate Email Service with OpenRegistry| |✅ OpenRegistry Dashboard View|✅ OAuth2.0 /w GitHub|✅ Enable Sign In & Sign up on Web Interface| |✅ Settings & Profile Page|✅ New Blogs about OpenRegistry & collaborations|◻︎ Load & Performance Testing| |✅ Search With Autocomplete|✅ Documentations|| ### Milestone 3 - (on-going) > Upon successful completion of this **Milestone**, OpenRegistry will have multiple storage backends, thorough collaborations with IPFS and Filebase. These backends will be configurable by the end user. We're looking forward to bring WebAuthN to OpenRegistry as it will eliminate any need to collect PII. Along with this, we're also expecting Vulnerability scanning, Bring your own encryption keys and more. > Automated deployments are going to be a huge USP for OpenRegistry. With this feature, a user will be able to connect their GitHub account and enable automated builds for their container images on Pull Requests/Merges. |Web3 integrations|New Features & Enhancements|Ecosystem Building| |------|--------|-------| |✅ Collaborate with IPFS|⚙️ WebAuthn - Passwordless Access|◻︎ Run Freemium for 2022| |✅ Collaboration With Filebase|◻︎ Bring your own Encryption Key (BYOK)|◻︎ Contribute back to iExec, IPFS, Akash Network| |◻︎ Collaboration with iExec|⚙️ Automated Container Image builds| <br><br><br><br><br> ### Milestone 4 (Timeline TBD, estimated early next year) |OpenRegistry Core|Enhancements|Web App| |------|------|---------| |◻︎ gRPC APIs for OCI Distribution Spec APIs|◻︎ Add iExec RLC as a payment method |◻︎ Cut a new release| |◻︎ Container Image Analytics|◻︎ Platform Agnostic Security Tokens (PASETO)|◻︎ Design Origin Illustrations| |◻︎ Private & Encrypted Container Images|◻︎ OCI Distrbution Spec Extensions support |◻︎ Subscription plan | ### Milestone 5 (Timeline TBD, estimated mid next year) |OpenRegistry Core|Enhancements|Web App| |------|------|---------| |◻︎ Organization Mode|◻︎ SPIFEE based resource access|◻︎ Animations for Web App and Blog| |◻︎ P2P Container Image Distribution| ◻︎ SPIFEE based resource access |◻︎ Vulnerability Scanning for Container Images| ## Maintenance and Upgrade Plans We've already laid out our plan for next 2 quarters but it doesn't end there. We want to build a complete ecosystem around OpenRegistry and add a bunch of complimentry features and products. We're currently running a Open Beta Program to join and check OpenRegistry out. We're soon to release OpenRegistry for Public use and once OpenRegistry is stable enough, We'd like to shift focus towards building a Desktop App along the lines of Docker Desktop and Rancher Desktop. With this product, we'll be able to make real use-case of P2P container image distribution, with fine grained ACLs. ## Code repositories - OpenRegistry - https://github.com/containerish/OpenRegistry.git - OpenRegistry Web - https://github.com/containerish/openregistry-web.git <br><br><br><br><br><br><br><br><br><br><br><br><br><br> ## Additional Information We're part of Akash Community Awards Board (CAB). CAB helps promising projects get funding upto $100k USD in AKT, in the form of grants. A grant funding proposal for $100k USD in AKT has already been approved and paid out for OpenRegistry. > Note: Due to the dip in market value, the amount was equivalent to about $35,000 USD at the time of funds disbursement. ### Details: | Organization | Amount | Received | | ---- | ---- | ------ | | Akash Network - Open Cloud Hackathon Winners | $10k USD in AKT | ✅ | | Akash Network - CAB Funding Round 1 | $1k USD in AKT| ✅ | | Akash Network - CAB Funding Round 2 | $10k USD in AKT| ✅ | | Akash Network - CAB Funding Round 3 | $100k USD in AKT| ✅| ### Helpful Links: - **Web Interface - https://app.openregistry.dev** - **Blog - https://blog.openregistry.dev**