On Aragon naming

On Aragon naming

Aragon naming can be confusing. Aragon was the original name for the dapp, and now Aragon means the project in general. We need to clarify naming and keep it consistent, since we do have a lot of components, and it can make people unclear about their relationship.

Ecosystem projects

Those are projects that are horizontal to the whole ecosystem and not tied to only Aragon. Therefore it shouldn’t follow any Aragon naming scheme, although I’d incline to name them after birds.
Those right now are: Radspec and Lorikeet.

For devs

The naming scheme for developer tools would be aragon + acronym. So aragonXXX.


Currently there is not a name for all the dev tools we have built. aragonSDK would be their umbrella, and the primary brand for Aragon developers. It’s tagline would be everything you need to build apps that run on Aragon Core.


Makes sense to be called that way, because it’s the kernel + framework that all the Aragon ecosystem uses to work and inter-operate.

DAO Kits to Aragon templates

A kit is a set of tools. What DAO Kits do resembles a template more, so we should just call them Aragon Core templates, or templates.

aragon.js to aragonAPI

aragon.js has a dot, which isn’t used anywhere else in our naming, and also has an extension, which locks it down to a single programming language and isn’t used anywhere else in our naming neither.

aragonAPI describes better what this component does, and adheres to our naming scheme. Of course, this would be for the aragon.js client. For the server (or the wrapper as we call it) it could just be split off as part of Aragon Core, and it would have some internal name not exposed to the public so much.

There may be multiple implementations of aragonAPI, such as a Javascript one, called aragonJS.

APM to aragonPM

We don’t use acronyms anywhere else, so I feel bad about this one. Going on with our dev tool naming scheme, I’d say aragonPM would be the right one. Since there’s immediate interest in maybe working on this with other teams, I’d leave it as it is, not to rename twice.


aragonUI would be the thin layer on top of Lorikeet that is Aragon-focused and opinionated.

Aragon CLI to aragonCLI

With our dev tool naming scheme, I’d rename to aragonCLI. aragonCLI would be the command line tool developers use to build Aragon apps.


It’d be a good idea to split aragonCLI into two components: the CLI for developers, and the CLI to interact with DAOs (the dao subcommand in the CLI right now). Unsure about the name yet, but it could just be the DAO CLI.

For users

Aragon Core to Aragon

Aragon Core it’s confusing and breaks in the following scenarios:

He is an Aragon core contributor . Does that refer to a core contributor to Aragon, or a contributor to Aragon Core?

Aragon App could work, but it has flaws:

  • Aragon Core acts as a platform for Aragon apps, so calling the platform Aragon App would mean that it’s an app that runs apps (?)

  • I like That Planning Tab, I use the Aragon app . Does that refer to TPT’s Aragon app, or to the Aragon App?

Not a lot of people know what Aragon Core anyway, everyone calls it just Aragon. If there is confusion or more context needed, one could always specify the Aragon project or the Aragon client, when referring to one of them.

Aragon Network

Feels like the name is understandable. I’d leave it as it is. It’s a DAO that conforms a network of DAOs.


I like the renaming. About Aragon Core, I was thinking that naming it Aragon Interface is straight forward.

I think “Aragon Interface” is a bit technical for a user-facing brand name.

My first choice would be to go back to just calling the dapp “Aragon”, or when discussing it in a broader context, “the Aragon client”. The dapp is the first thing that comes to mind when people I know hear the name “Aragon”. And naming it Aragon does not exclude other people from building alternative clients with different names. “X client, powered by aragonOS” or “Y app, powered by aragonOS” (“powered by aragonOS” will likely only be mentioned as a technical detail for those interested).

My second choice would be to take a similar approach that Mozilla has with Firefox. Where Aragon is the “org” brand name and Firefox is the “product” brand name. I’ve been thinking about it since we first floated the idea of rebranding Aragon Core and I haven’t thought of a name yet that has a “wow” factor that makes it worth changing to.

I think regardless of what we do with the Aragon Core brand, I would reconsider use of the phrase “Aragon core contributor” so long as it doesn’t have a clear definition. The “core contributor” term raises the following questions:

  • What makes someone a “core contributor” vs just “contributor” without the “core” label?
    • Do they have to be on an Aragon team? Or just get a pull request merged?
    • Are reviewers “core contributors” even if they don’t get any code merged?
    • Is it only people who contribute to aragonOS, the “core” of the whole Aragon system?

Hey everyone,

I’m happy to see this being discussed here. As someone who’s new to the Aragon ecosystem, I can confirm that the current naming doesn’t contribute to the already super complex system in a positive way.

On the other hand I’m very aware that naming things (especially in Software Development) is very very hard (iPhone Xs Max anyone)?

With that in mind, here are some additional thoughts starting from the consumer perspective:

  • There’s already Aragon and Aragon.One which are two different things and I assume that most of the people out there already wouldn’t expect. Not because it’s unnatural that a company develops and supports a certain product and therefore have a clear separation, but rather because these two names are too very similar. Now the reason I bring this up is not because I propose to change the name of Aragon.One, but just to raise awareness that I don’t expect people to talk about “Aragon by Aragon.One”. They’ll most likely refer to it as just “Aragon”, the project, the team, the company, the app.

  • Considering the comment above, when it comes to “Aragon Core”, I’d probably vote for just calling it “Aragon App” - the whole thing. The reason being is that it’s very likely that most of the users of the app are either not technical, or even if they are, they probably don’t know or maybe don’t even care what’s going on behind the scenes. The app may run other smaller apps in it, but from a user perspective, you really don’t know unless you go and inspect the code. However, people probably still want to refer to particular apps within Aragon. They’ll prolly call it “Voting app in Aragon” or “Aragon’s Voting app”. Again, chances are very high that people refer to the whole thing as just “Aragon”, so I think “Aragon App” would the most straight forward. What about the apps within Aragon App then?

  • Apps running inside Aragon are fully featured apps by themselves. From a user perspective however, they are probably not. I would probably just call them what they are: “Sandboxed Apps”. Oh funny, guess what - as I’m writing this there’s another idea coming to my mind:

  • If we consider that there might be a lot of apps for Aragon some day and people will actually go ahead to some “marketplace” or “apps” section to install new apps, then the thing that I just called “Aragon App” could actually be considered the operating system then runs apps. So here I’m proposing to call the Aragon app “Aragon OS”. Funny world.

Let’s look at the developer perspective.

  • I have to say that calling the project that “just” has the smart contracts that power the whole thing “aragonOS” threw me a bit off in the beginning, because, well we know operating systems as things like Mac OS, Linux and Windows. I assume many people expect that terminology this way. So if we assume for a moment thart we call the app “Aragon OS” as described above, than the contracts project could be called “Aragon OS Core” or “Aragon Core” (haha… I know). The reason I go with “core” is because it makes very clear that it’s the core of the project, and at the same time it’s not tied to “Contract”. Who knows maybe someday Aragon will run on a plattform that doesn’t have contracts. Or maybe contracts are just called differently. (btw, the repositories on Github I’d call aragon-something-something). This would also free up the namespace to call Aragon Sandboxed Apps just “Aragon Apps”. Oh and you get your Aragon Core contributors as well! :smiley:

  • re:aragonAPI: I think it’s a little bit vague because at the end of the day, everything is an API to some extend. What is it really for? It’s to make sandboxed apps talk to the contracts, through the thing I just call "host for now. It basically enables developers to connect their apps to the whole thing, so how about “Aragon DevKit”?

  • re: Lorikeet: I’m not sure I follow what this exactly is for in that proposal. Also, it doesn’t sound like anything that I could imagine people talking about.

  • The package manager can just be called “Aragon Package Manager” and ppl will call it “APM” by themselves because it’s easier to say.

  • Aragon CLI makes perfect sense.

Let me remind you that all of the proposals above are names for communication and branding not the repository names.


Lorikeet is the new name for Aragon UI. I don’t think the rebranding is official or announced yet.

Ah got it. If you go for that name, I suggest providing some information how to pronounce it as well :smiley:

I just tried 5 different variations and they all sound weird. I’m sure I just don’t know how to say it right.

Should we also rename AraGen to aragonENV ?


It’d be the logical name for our new naming convention, thoughts @jorge?

Off of a recent conversation, spurred by the confusion around aragonAPI, is a new proposal for how we organize the aragon.js repo.

“aragonAPI” sounds like a web2.0 API server you’d run / call to get or post information. It’s also not very descriptive as to what it’s really for.

The new proposal makes aragon.js the home for any JavaScript-related libraries we may write. It’s already a mono-repo, but we’ll consolidate and move more packages into aragon.js.

The changes:

  • Keep the aragon.js repo name
  • Move apm.js as a managed repo under aragon.js, and rename published package to @aragon/aragonpm.js
  • Move apm-serve as a managed repo under aragon.js, and rename to aragonpm-server
  • Rename the current @aragon/client package to @aragon/api or @aragon/app, as this will be library consumed by app developers
  • Rename the current @aragon/messenger package to @aragon/rpc-messenger
  • Rename the current @aragon/wrapper package (not quite sure what); this is less important as it will only be used by someone implementing a full blown client (e.g. aragon/aragon or aragon/aragon-cli)

In the future, we will add more packages to aragon.js, for utilities and other JS libraries. This naming scheme would also scale well in the event we ever start writing more than just JS clients, where different environments could have different extensions.


We could get rid of the .js in @aragon/aragonpm.js as it’s implied by the repo (aragon.js) or npm, it would also feel more consistent with the other packages.

I want to also add that we aim to keep aragonAPI as the marketing name for the frameworks/libraries devs will use to interact with aragonOS and the Aragon client. But aragonAPI may be a set of multiple libraries in multiple programming languages or platforms, and one of them would be aragon.js.

Having just recently delved into all of the different packages I find this topic of utmost importance.

My humble opinion is that naming should generally follow responsibility. Sticking to the single responsibility principle in library implementations can both alleviate confusion and ease integration between different modules/components.

  • @aragon/client is the core package developers interact with. Its responsibility is clear.
  • @aragon/messenger has very clear boundaries and responsibilities. Renaming to @aragon/rpc-messenger is sensible.
  • @aragon/wrapper is the least clear in terms of its responsibilities. It does a lot of different things. Perhaps by defining more clearly what we want this module to explicitly do, we’ll know better how to name it, or the submodules we might want to break it to. Hence, I would recommend developing a better shared understanding of its the responsibility before renaming.

Example of confusion

Currently, when clicking on aragonAPI in the developer portal, one is redirected to the aragonJS root page. The first package mentioned is @aragon/client, all the while the repository is aragon.js.

on @aragon/wrapper

aragon/aragon adds and builds on top of @aragon/wrapper a fair bit and there are probably good reasons for that. At the same time, it’s where the boundaries between the the two packages become loose.

A quick look at aragonCLI to understand how @aragon/wrapper is used reveals some duplication of that initialisation code.

I don’t know enough yet to say much beyond. But I’m confident a better name can arise from a clearer scope/responsibility definition.


Having just recently delved into all of the different packages I find this topic of utmost importance.

A quick look at aragonCLI to understand how @aragon/wrapper is used reveals some duplication of that initialisation code.

Definitely agree!

I think part of the confusion comes from naming packages based on the relationship between them, and a lot of them have a client <-> server type of relationship.

For @aragon/wrapper, since it has the responsibility to create DAOs, find information about them (its apps and permissions), as well as easing the interaction with a DAO by calculating the tx pathing, it might make sense to name it manager, admin, super, sudo or something among those lines.

For @aragon/client I still very much like @aragon/app.

And perhaps only call aragon/aragon and aragon-cli a client, although we could be more specific and say CLI and GUI.

1 Like

Totally agree Daniel. Those are packages that don’t follow the name convention agreed upon here, so they should be renamed (@aragon/wrapper and aragon.js).
Also I like renaming @aragon/messenger to @aragon/rpc-messenger.

Hmm yes, this should definitely be fixed so that it’s more clear the relationships between “aragonAPI” and aragon.js.

Agreed on this; this is the terminology I’ve been striving for (I usually use @aragon/client to avoid confusion between that package and actual user-facing clients).

@Daniel and I were having a conversation about if it made more sense to use @aragon/api or @aragon/app for (what is currently) @aragon/client.

We ended up deciding that @aragon/api made the most sense:

  • @aragon/app is too confusing, since you could mistake an Aragon app for this package, especially when spoken
  • @aragon/api fulfills the original intent for that library to be the JS implementation of aragonAPI

I was worried @aragon/api would be confused for aragonAPI, but I think it’s OK if most users make this connection. To JS developers, @aragon/api should be the aragonAPI they care about.


Yes! Nothing to add :slight_smile:

To clarify, do you mean calling the client @aragon/api?

Yes, renaming the current @aragon/client to @aragon/api.

Oh, I understood you meant renaming the Aragon client and I was very confused. Now I see, you mean renaming the package. I think that makes a lot of sense

1 Like