hummHive's Technical Principles
This blog was generated by hummHive, which is an app and ecosystem for creating and sharing content in highly secure and adaptable ways. It's as ambitious as it is necessary in the modern world and its architecture is agent-centric and inherently resilient.
hummHive follows three simple technical principles:
1. separate data from service providers
2. put content creators in the driver's seat
3. create a shared community of creators and readers
When looking at the existing social/media landscape, it's clear that there are a number of issues that need attention. Below, the guiding principles, designed to address these issues, are explored in more detail.
Separation of Data from Service Providers
The first problem is that every major content platform deliberately captures user data as part of their business model. The news headlines focus on legitimate privacy and safety concerns, however there's another problem with captured data. Content creators are effectively locked-in to the platforms they use unless they proactively take steps to protect themselves and their data. This can also happen unintentionally - by default, every system that needs a database is generally incompatible with every other system. With hummHive, all content is kept separate, in a simple format that can be easily published (publicly or privately) on your website or (ultimately) any platform of your choosing.
hummHive treats your devices as the source of truth for all your data. Different platform providers are only ever sent a copy of the data in order to provide a service (like streaming video on a website). There is no monolithic "hummHive Cloud" to lock in your data, and never will be. Your data can be synced or migrated to different devices and services at any time. hummHive can't stop third party providers putting walls around data that originates in their system but it can keep original copies of everything you produce locally, offline in the hummHive app so that you can deploy that content elsewhere.
In the future there will be a marketplace of connections that you can use, however they will be purely services like web hosting, data backups, identity management, etc. that can work with only a copy of your data. The hummHive ecosystem won't require you to rent a database or capture your original content behind a proprietary graphical user interface.
Wherever possible hummHive provides minimal or zero knowledge of your data to providers. For example, the first provider for data sync and backups is Keybase, which already implements encryption for all data sent to their servers. Another provider will be Holochain, which is a p2p platform that natively supports invite-only private networks to share data between devices in a way similar to bittorrent.
Think of the hummHive app like an offline backup of your valuable content PLUS a "meta" content management system (CMS) that can move instantly between other platforms or content management systems. In fact, it is relatively straightforward to build an adapter between hummHive and any major open source CMS like Ghost, Wordpress or Drupal. If something happens to your CMS hosting provider, social media platform (or maybe you just want to migrate from a clunky old website to a shiny new one), you can click a button and humm will republish all your content to any compatible system.
Content Creators in the Driver's Seat
The second problem is that content creators typically have little stewardship over anything that happens on the major platforms - including over their own content. This can be simply due to the technical bar being too high to encourage experimentation, or due to politically motivated moderation. It's hard to argue against the importance of free thought and empowered invididuals in a healthy society.
What if undesirable content is published via hummHive? Ultimately individuals are responsible and accountable for their own agency. hummHive puts everything back on the content creator, philosophically, technically and legally. When you download hummHive you are downloading an empty shell (or canvas!) that pulls in dependencies on-demand as you connect to service providers. Want to host a website? That's fine - you just need to login to your Amazon account. Want to take credit card payments? Sure, just copy in your Stripe merchant key. hummHive can't censor, track, or save you from the consequences of your own actions either. The relationship between you, your service providers, and your readers is up to you to shepherd. This is grand departure from how contemporary social media and content companies operate.
The final problem is one of social co-ordination. It is a two sided problem for publishers. On one hand content creators should be able to collaborate offline, outside of any particular platform (or maybe across several), without worrying about syncing, permissions or copyright issues. On the other - content creators should be able to have public and private readerships and persistent member lists, without relying on any particular platform handling logins.
hummHive can't replace the raw traffic and eyeballs that big brands can funnel to you but hummHive can help your core readership find you and your content if you need to migrate to a new world.
On the content creation side hummHive cryptographically signs every version of every piece of content you create with a device-specific key, a key from an identity provider, and several secure timestamps from different servers. This proof can be validated by anyone who trusts the same identity provider and timestamping servers that you used to create the proof. The proof generation and tooling is all open source. This proof then moves alongside your content to every system that can ingest it, for example it can be included in the validation logic for a holochain application to allow you to move content in and out at any time. If someone else tries to plagiarise or steal your content, or pass it off as their own, you can provide an older proof than their's to show that you created the content first and even what device you created it on.
In terms of your readers, we push the canonical list of members all the way to your device. If a member tries to access your content they always need their login credentials to be provided directly from you (e.g. a mail blast) or from a copy of your list (e.g. from a backup). In the future you will be able to choose other hummHive content creators that you trust and their readers will be able to automatically become your members publications.
So where is hummHive today? The current version of hummHive has a website deployment pattern built on Gatsby and Keybase . You can go to hummHive's website to join the waitlist to download the hummHive app as a content creator, create your hive, and start creating content in the app. All your content will be offline by default but as soon as you connect your Keybase account you will start syncing your public and private content to the keybase filesystem.You can invite other people to your hive to collaborate on content, make drafts and publish them when you are ready. Published content can be wrapped into a website using Gatsby and deployed live to the public using the Keybase website hosting or S3.
Roadmap - what is next?
As one of the guiding principles is putting content creators in the driver's seat, we need people to kick the tires. Early adopters are welcomed to register on our website for access and provide feedback.
Improved Support for Private Content
hummHive supports private content behind an optional paywall for your users. If you login to Amazon and Stripe through the hummHive app then your private Keybase content can be served through a free-tier AWS Lambda for all your readers that buy a subscription in Stripe.
An Extensible, Open-Source API
The file syncing API is the first clear extension point for back end connections. The goal is to have a range of pluggable service providers for:
- website generation, hosting and DNS including .crypto unstoppable domains
- logins and identity
- file syncing and backups
- verifying content proofs and timestamps
and more, including the front-end to allow for new functionality such as photo galleries, video streaming, etc. to be built in parallel along the text editor that we call the hummPublisher.
Holochain Support and More Connections
Keybase is nice because they provide a lot of the needed functionality, yet we can't over-rely on their services. While we are willing to trust that their encryption works the way they claim (we have generally reviewed enough of their code that it seems legit), there is nothing stopping them from simply turning off their servers or charging for access. For example, all the cryptographic key algorithms are hard coded in their software to use their own server to forward messages between all your devices. It's not so easy to write your own software that integrates with the official client unless you also use their servers. To embody our principle of decoupling data from service providers, we need to accept that keybase could change or stop of their services at any time. We are working to add more connections in parallel to the API audit. For example, we will launch a Holochain connection that handles file syncing and backups as soon as the Holochain p2p network is ready to handle them. Holochain is perfectly aligned with our vision because it supports private networks and avoids centralised servers, but it is not as mature as Keybase, so this is a work in progress! We will also add more centralised connections such as Amazon and other cloud services to provide many options for each of the pluggable components.
And that's it for this post! Thanks for reading, being, and humming!
Be sure to join our waitlist at https://humm.earth.
Until next time!