Federation #

Over the course of the project, we've explored maybe different architectures for Underlay. At the core of this consideration is a tension between the simplicity and accessibility of a system, and the eventual power dynamics and restrictions that such a system imposes. Centralized systems are cheaper, more efficient, and quickly to develop, but they risk placing too much power in the hands of the central hosting entity.

Purely distributed systems offer technical assurances against such risks, but in practice are difficult to use, grow, and develop. In the most extreme case, they play into a fallacy of trustless systems based on technical proofs. We do not advocate for trustless systems, as we simply don't believe such things are possible once you enter the realm of social structures and culture.

We do believe in trusted institutions playing an important role, and our eventual vision is towards one of federation.

Our initial ask is not to host a node though, but to help us iterate on the core offering. We're throwing one party to start, and once we know how to throw that party and what's included in it, we intend to have multiple parties facilitated by a common protocol and set of expectations.

As such, we are beginning by building out underlay.org. Technical considerations will be made to ensure we aren't locking the system into a centralized model, but we are not yet putting resources towards facilitating self-hosted versions that are interoperable and stable.