The internet is built upon hidden layers. Shared protocols that abstract complexity and get everyone singing off the same songsheet. Take TCP/IP, the foundational communication model of the internet that makes for standardized, interoperable communication and which is the groundwork of the internet we know today. Most developers don’t interact with TCP/IP, but nevertheless everything depends on it. A near-invisible substrate woven into the fabric of the internet itself.

It’s one of many hidden layers that have stacked over time to create the internet we know today. DNS as the phonebook. HTTP for browsers. Physical infrastructure like submarine cables and data centers used by thousands of entities to deliver their applications, but the end user almost never hears about them. Sometimes even the core developers can’t name every service upon which their utility depends. These invisible substrates are the results of decades of shared endeavour and research, born of a collective and communal vision to build the internet we know today. It was built by universities, researchers, idealists (and the military) who embraced a decentralized future - before we forgot how important it was.

Commercial Layers

Not all “invisible” layers are communal resources though. Many are commercial. Commercial infrastructure has replaced many open protocols, and are now embedded into nearly every app. Database infra like Postgres are quietly packed in. Content Delivery Networks like Cloudflare distribute our videos and images, for a price. Over the decades since the early internet, the commercialization of ostensibly necessary protocols has exerted a more vice-like grip on developers. Commercial layers aren’t inherently bad, but when reliance on them becomes default - and when default becomes dependency - then that is when the problems begin to creep in.

The AWSification of our digital realms means crucial hidden layers like payments (Stripe), storage (AWS S3) and data infra (Snowflake) have become monopolised, restricting innovation and raising costs while centralizing risk and reducing resilience. At the price of increased efficiency, we created a monoculture of invisible dependencies. Devs need to ship their product and need to stay on deadline, so the stack begins to ossify around these critical dependencies.

Systemic Fragility

This landgrab to control key functionalities has led to the shared layer cake beginning to teeter and threatening to topple. Devs often don’t know what their applications depend on under the hood, or found that they had one choice only, and it’s a choice they have to pay for. They become vendor-locked, their applications become subservient, and their bills become unpayable. And, when a core service like Snowflake goes down - sometimes the entire product stack goes down with it. A brutal systemic fragility with very real consequences.

Nowhere is this brittleness more acute than the data layer, which is now fragmented, insecure, centralized and overly complex. Developers are forced to reinvent how to store, sync and permission data for each new project, sometimes multiple times. ETL pipelines become fragile and infra-bloated, with developer time spent fixing sync processes and maintaining compliance. Developers wishing to control their data lifecycles o and let users own their data - who want to reclaim full sovereignty of their application - thus find themselves stuck, and are forced to marzipan the top of a cake they never had a hand in baking.

The Need for a Shared Data Layer

It is the data layer that is missing from the invisible, shared stack - the stack under the stack. A data layer that behaves like a protocol, not a product. A new default on which any dev can build without restricting their integration to the services they already use and have already spent time, money and energy building on. Data management infra that means developers can eschew the use of the cloud if they choose to. 

It’s not about competing with or outmoding existing infrastructure, but about building an interoperable resource and shared protocol for data management that anyone can use, whether their project has just published its first repo or has been delivering utility to users for twenty years. It’s not about deleting the cloud, it’s about reimagining it as the ultimate peer in a network of peers. Not a single centralized point of failure, but a powerful pillar of strength in a more widely distributed network. 

Source Network is building a data layer that sits at the base of any current stack and is fully interoperable with it. Just as TCP/IP is an invisible root at the base of the communications tree, so Source Network will be an invisible root at the base of the data layer cake. A distributed, verifiable data infrastructure that developers can rely on. A way to keep their software data sovereign even as they utilize cloud services. Composing a backend, rather than building one. The hidden data layer that powers every application. A developer building a mobile game can use DefraDB to sync player data across devices. One building inventory systems for a factory floor can ensure those devices continue to update if a central server goes offline.

Foundational Layers

Nothing about Source Network’s stack - DefraDB, LensVM, SourceHub and Orbis - precludes integration with other services. The stack is modular and developers can pick and choose. DefraDB is a peer-to-peer database that lets devices perform operations on data and sync with others in the network. LensVM ensures that data can be understood across devices with different schemas and of different manufacturers. SourceHub creates a cryptographic audit layer for operations performed by DefraDB, while the Orbis Secrets Management Engine helps manage permissions and issue access keys. 

All of these tools can be used in conjunction with a standard cloud provider in order to deliver application utility. Source Network’s tools are about building a better internet by embracing edge-native design and understanding that distributed systems are resilient systems - something corporate juggernauts are all too aware of, and why they are pushing edge-native systems themselves. Source Network’s tools sit underneath an existing stack, and work fluently with it.

It’s not about smashing the cake we’ve so lovingly (if inexpertly) crafted to pieces, but about creating a better base layer for what we already have. Making all internet functionality better, not cutting off our noses to spite our face. The protocols we rely on today weren’t obvious at the time, they became essential over time. Source Network will be that next invisible layer, a sovereign data management infra that reduces latency, increases resilience and restores control to developers - and ultimately users. A local-first cryptographically secure layer for data that ‘just works’, and something that ultimately becomes as invisible to developers and users as TCP/IP, but no less essential.