Thread by @sohkai

1/ I imagine most users of the Aragon client (mainnet.aragon.org) haven't fully grasped what they're interacting with.

It probably feels like it's just a web app (with some magic Ethereum spice).

That's great—we want it to. But there's so much more to this rabbit hole.

2/ Let's start with the magic Ethereum spice.

There are tens of deployed contracts compiled from thousands of lines in Solidity that act as infrastructure for each Aragon organization.

You can follow these contracts and their deployments in github.com/aragon/deploym….

3/ But beyond this infrastructure, each organization is deployed **by their creator** as a set of separate contracts that directly encode their own permissions and ownership structures.

There is no central root authority or contract tethered to these organizations.

4/ For end users, this means that, for the first time ever, you can have true ownership over the organizations you belong to, as well as any (digitally encodable) assets they may control.

5/ And yes, it does come at a cost.

You'll spend roughly 10 clicks, 15 keystrokes, five minutes, and between $2 to $10 to create an organization. You'll likely spend less than $1/month to interact with it.

For reference, a bank today quoted me $30/year to rent a plastic card.

6/ Last week we released Aragon 0.7, with an opt-in contract upgrade for existing users.

When was the last time your government asked you for consent to change the rules? When was the last time you could say "no thanks, I like how it works now, thank you very much"?

7/ (Small aside; I wrote this feature and am still impressed I did)

Letting alone how crazy it is that users can upgrade their own contracts, when they choose to do so, the Aragon client **hot swaps** their contracts' frontends for a completely seamless UI upgrade.

(End aside)

8/ To make this all possible we created our own on-chain package manager (aragonPM) that is itself constructed as an Aragon organization.

But here's the thing: anyone can deploy their own aragonPM instance, and any organization can install a package from any instance.

9/ Not sure what that means? Just contrast rinkeby.aragon.org/#/dune.aragoni… with rinkeby.aragon.org/#/pando-dao.ar….

Both are live demos showcasing how the term "organization" just became much more malleable in meaning with the applications published by @autarklabs and @AragonBlackTeam.

10/ And here's the kicker: the Aragon client is not just an app.

It's a platform.

While it's taken a while to get here, there are now three independent teams working on completely different visions of what an organization may mean to users. That's decentralized development.

11/ To this end, we provide extensive documentation (hack.aragon.org) complete with an SDK for building Aragon apps.

The Aragon Mesh team (headed by @0x6431346e) has steadily improved DX and @bpierre maintains aragonUI as the go-to React toolkit for building a frontend.

12/ Of course, we still have a lot of infrastructure, tooling, and incentives to figure out with being a platform.

This is obviously hard. Bear with us if it takes a while.

13/ If the base problem (be a successful app platform) wasn't hard enough as it is, we've made it even more difficult by valuing decentralization more than that other "dapp" you may use that serves a rigid, centralized experience on top of their onlyOwner "decentralized" network.

14/ Apology: for those of you who voted in ANV2 and had the uncomfortable experience of waiting 5-10min for the votes to load, this is why, and I'm sorry 🙇.

We know about it and we're working to improve it. UX and local caching enhancements look to be the lowest hanging fruit.

15/ (Aside)

But hey, at least you weren't forced to download a desktop app just so you could wait days for it to sync the entire chain. To its merit, it did have a much better loading indicator than our current one (none).

(End aside)

16/ Even though the client was most likely loaded onto your browser through our own content server and DNS (like any other web app), we've taken every measure to avoid as much centralized infrastructure as possible.

17/ At this point we're just waiting for browsers to catch up, so we don't have to shim a content-addressable link to DNS. Nearly everything else is already loaded through IPFS or fetched directly from Ethereum.

See blog.aragon.org/deploying-and-… for more details.

18/ Being content-addressed allows you to choose which version of the client, as well as your organization's installed apps, you want to use. Even if you're opted into frontend updates by default, you will always have the choice to roll back or fork from an earlier version.

19/ Finally, understand that the client itself is just one half of the dream. The other is the Network itself, allowing organizations to safely interact with one another, starting with the Court (github.com/aragon/aragon-…).

End/ We're essentially playing the same hand that Protocol Labs played with IPFS: build the underlying nodes first, then figure out how to incentivize interactions to build network effects.