Skip to content

Instantly share code, notes, and snippets.

@garbados
Created January 22, 2020 06:53
Show Gist options
  • Star 3 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save garbados/cd3d5b382834e73645513df24e08d5ec to your computer and use it in GitHub Desktop.
Save garbados/cd3d5b382834e73645513df24e08d5ec to your computer and use it in GitHub Desktop.
Comparative Considerations Regarding Distributed Software Architectures

Comparative Considerations Regarding Distributed Software Architectures

Together we are strong. Knowing this, how can we write good software?

Software is post-scarcity tooling. Strip the paywalls; underneath they have always been a new order of labor-saving device, one that can be infinitely copied and infinitely shared. Rich promises live in its possibility; promises the rich have betrayed, possibilities they have squandered.

We can fulfill those promises for each other because together we are strong.

This is an ominous time. Napster is long dead. Aaron Swartz, too. Software is bad, but it doesn't have to be. From BitTorrent to Mastodon, distributed systems leverage the power of many to astonishing effect. Among archivists, pirates reign.

There are many ways to build distributed applications. A monolithic stack can employ distributed components -- clustered databases, high-availability caches and proxies -- but the most powerful architectures weave together untrusted elements, stitching distant neighbors into resilient networks. I do not have to know you. I do not have to trust you. Still we are stronger together.

Application developers learn the hard way over and over that cleverness is fool's gold, that every problem is old and all shine is marketing. They bet too much labor on too little proving and so their vigorous advances disintegrate. But we try again, and again, and again.

Here are some considerations:

Fedi vs Chain: Fedi

A blockchain is a form of world-writable append-only database. It can be encoded with rules that actors share, and through a mysticism those rules can be monetized, but it remains no more or less than a database.

A system with a single database has a single point of failure. Trust fails like any component, and actors will find themselves unwilling to associate. No mysticism can bind them.

Federation is the superior technique. Actors must be free to form networks within networks, protocols within protocols, and they must have the tools to moderate those connections on a continuing basis. Communities must be empowered to define and defend themselves as it is the only way they can exist.

People outlive their tools. Federation is interactive syndication, and it does not intrude uninvited into the realm of datatypes. Applications must dream bigger than a single backend, for it shall wither before the lifetimes of users. Remain humble enough not to insist upon your own conception of data.

Open vs Closed: Open

Should you publish source? What if corpers steal it? Of course you should publish source. Property is theft.

The tactical advantage of FOSS lies in aftermarket engineering. Take what has been excruciatingly bought and paid for and prove it in a distributed model: self-hosted, federated, peer-to-peer. It all has its place. Knowing you cannot compete on price, give it away for free. The only ones the thieving capitalists will compete with then are each other, and we will not need them. Our doors will always be open and they will choose to walk by.

The fate of a tool is to be used. Should the carpenter abdicate their craft because some fascists sit in wooden chairs? The carpenter can choose who to deal with, as developers can use license cooperatives to collectively elect into issuing commercial licenses, but fascists will still sit in wooden chairs. Best then to ensure they do not sit near anyone; indeed, that they do not sit at all.

Fighting the Browser

The web wears a terrible crown and we will mourn its passing. Righteous litanies recount the sins our cleverness has accumulated, and still through it we find each other. Should you build a browser? Maintain a Chromium fork? Develop infrastructure on hidden subnets, or obscure protocols? I don't know.

The earth shifts beneath us. Can you taste the ash in the air, or the plastic in the water? The police are outside. The police are inside. The misery in your money and the meager choices it affords arrive from one spirit, our foe whose name is the kyriarchy, and it mutters of a wretched future. We will face it together. Together we are strong.

Do not build a browser. It is too much work. Instead write server applications with server-agnostic clients, and connect them with HTTP and P2P protocols that use established neutral infrastructure layers, like torrents. People use browsers, and your works must be usable through them as much as without them to be meaningfully accessible.

Someday the web will be gone.

Auth

I wish auth tooling were better, but for now there are two auth models to consider:

  • Self-hosted, including any application where one device corresponds to one user identity.
  • Group-hosted, where one application supports many users.

Self-hosting makes a decent demo but in the production case an application must support many users, even when many users are one person or one user is many persons, for some of us are not sysadmins but inevitably some of us must be. For that we require auth{n,z}.

Here is a common and durable authn model:

  • Users sign up with an email and password.
  • Users confirm their account with a link or token sent to their email. Tell them to check their spam.
  • Use bcrypt to encrypt and check passwords, and NEVER store plaintext passwords.
  • 2FA is bonus points.

There are no easy authz models but it is unwise to confuse a user with an identity. So, here is an authz model I have yet to regret:

  • Users can create identities which have an associated keypair, token, or other credential.
  • Identities perform actions, and may authorize other identities or list of identities for certain actions. For example, content may be encrypted so only members of a certain set of identities may decrypt it. These sets may be explicitly enumerated or an application may support dynamic lists, such as followers.
  • Identities can create and delegate authority to identities, such as to grant permissions to secondary applications acting on a user's behalf.

Someday, perhaps, we will have good tools. Until then we at least have each other, and the wisdom and anguish of all who came before.

Conclusion

There is a humane future that software helped build, and we must build it for each other piece by laborious piece. Save your energy. Ration your effort. Life can be long if you let it go on. Together we are strong, so stand by who stands by you. Stand by each other.

Stay alive out there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment