Identity & DAO Membership

From OP:

In the first release of the new Aragon client (v0.5) we decided to implement a very simple identity system building on ENS, that currently allows users (there is no UI for this yet, but it is doable at the EVM level) and DAOs to claim a name (a subdomain of aragonid.eth ) that can be used as an alias for an Ethereum address (but just as a one way mapping: name → address).

What’s the user experience like for a user to get the ENS name? This solution makes technical sense, but I’m afraid the UI would be a lot more complicated than for setting a simple nickname in a mapping stored by the DAO. It’s certainly doable, but I’d be worried that refining the UX on this, and programming the more complicated process will lead to more delays on getting nicknames at all.

Along that train of thought, is there some simple interface defined for the Aragon frontend code to look up a mapping on chain or in ipfs and populate nicknames? We could have it look at our mapping and this would solve the problem. This would be a good interface to standardize no matter the underlying system.

@jtremback this is the Address Book app that Luke mentioned which is in the works. Hoping to have it done in our Github in the next few days or so. Would love to chat more in our session tomorrow to see if it meets your needs. For the mappings to reflect in all of the Aragon apps, I assume they would have to be forked. This isn’t exactly for managing an individual identity, but technically any person should be able to add themselves to the address book. And indeed since it’s an Aragon app, the Voting app can control modifications, additions, etc.

We built it so we can have an “Address” dropdown in our apps, and it would pull in the list of entries from the Address Book. This is useful for when you are sending transactions to the same people/entities/projects over and over again (I know the Identity app would solve this for individuals, but it won’t solve it for some external person or entity not in the DAO)


Yeah, the main limitation right now is that any UI you want to leverage the Address Book needs to know the address of the app. Our current solution is to just initialize the app contract with that address for any app that needs the name->address mapping accessible in the UI.

Thanks, that looks like a great interface for setting nicknames. My concern is getting those nicknames into the main Aragon interface, in the built-in apps like voting and finance.

Not sure what the status of this is:

But I think it would be helpful to understand (separate) from the larger issue of profiles/identity architecture what a MVP would look like to get to the point where addresses can be assigned a human readable identifier and then swapped out in the UI if the identifier exists?

Is that something that can be delivered independently (without creating a ton of technical debt)? If so what are the blockers?

Yes, please! This issue is a pretty big blocker for us at Althea. I mean, imagine if a normal web app had everyone’s user names and avatars replaced by database ids. This would be considered a critical bug and fixing it would be an emergency.

We can just barely get by with this issue in one of our test deployments, because the users there are ready for some jank and are being personally guided by my co-founder @DSimpier. There’s no way we can deploy it with the 0xstrings instead of nicknames in our other test deployment.

1 Like

My vote for a short term fix would be to give the rest of the interface the ability to pull an address->nickname mapping from an app (for example that address book app), and use that to populate the interface.

As long as those nicknames can only be changed by a vote or other authorization, this would seem to be as secure as we need.

1 Like

Speaking only as a user and not to the technical details of the proposal, these are my thoughts about what I want for “identity and membership” in Aragon:


I want my org to have an ENS name, and I want Aragon to recognize my ENS name if the address I’m using to interact with it has a name. If I don’t have a name yet, perhaps the app could offer me a way to register one (either a subdomain of aragonid.eth or a fully-qualified domain name - for the latter it would probably refer me to a dedicated ENS registrar app). I also want to be able to use an ENS name instead of an 0x address in every place possible i.e. “first-class” ENS support.

I agree with @jtremback that first-class ENS support is likely the most urgent need usability-wise. I specifically say ENS because creating our own name system seems like an unnecessary detour.

Aside: Regarding the address book app, I wonder if it wouldn’t be better to store this locally rather than on-chain. This has the benefit of 1) not taking up scarce and expensive blockchain storage 2) not requiring a transaction each time it’s updated and 3) not requiring consensus over the name -> address mapping, since each user gets to create their own address book.

I have a desktop wallet app that has an address book but the labels are stored locally, not on the blockchain. This seems to work well enough. See my idea below about a “roll call” app that might make more sense to do on chain since it isn’t storing any extra data on chain or introducing a new shared resource to govern.


It might be interesting for orgs and individual org members to also have a profile that can be seen when you click on the address or ENS name, so you can quickly get more context about who/what you are interacting with. A simple solution could be Ethereum Profiles; storing (relatively) large amounts of data off-chain is a mostly unsolved problem that is currently being punted to centralized hosts like IPFS gateways or AWS. (Swarm incentives when?) Outsourcing this feature to Ethereum Profiles is probably the best solution vs rolling our own (another unnecessary detour imo).

Aside: maybe in the future Ethereum Profiles can also support a standard like ERC-725 so users can make and receive claims, and these claims can be stored in the profile. I imagine this working like an OpenBadges backpack, if not actually using that standard just in a blockchain context (related). This would be a universally beneficial feature for all “social” or “multiplayer” dapps, not just Aragon.


I think the current way that “membership” can be defined in Aragon works great today and is already intuitive. How do you add someone to your organization? You assign a token to them if you want them to have governance rights, you add them to the payroll if you want to give them a salary, and you assign a permission to them if you want them to have direct power over an action. Seems straightforward to me - I see no need for the membership naming scheme described in the OP.

Maybe a “membership” or “roll call” type app could exist that just pulls from the Token Manager and Payroll apps installed in the org and shows who is a “member” and what apps they’re plugged into e.g. “johndoe.eth - Token Manager, Payroll” similar to the way the Permissions app shows which apps are installed and what permissions each entity has in the org.


IMO, it shouldn’t be looked at as “creating our own name system”. Technically it’s just a mapping of Eth addresses to nicknames. Both us and @stellarmagnet have implemented it in our apps. What’s really neccessary is just the interface between whatever record will be used (be it ENS, or the address book), and the frontend.

ENS could be the most theoretically elegant solution, but I’m concerned that it will add more steps for the user and implementation complexity. Sounds like a lot of work has been done on it already though.

But ultimately, whatever gets some form of usernames implemented most quickly would be great, and I wish we had flagged up this issue months ago.

Speaking again only as a user, I would rather have one name that I can use for every org I’m part of and every dapp I use rather than have to get a new name for each org I join and each dapp I use. ENS is a nice, already built out solution for this.

A bespoke system where each org has its own nickname app is a short term fix but will result in long-term headaches if it becomes widely used and users end up with a bunch of nicknames to manage and remember, plus it adds governance overhead to each org as its one more resource to collectively manage.

Add to all this the dev resources that are diverted to building this bespoke nickname system vs working on an objectively superior solution (full ENS support) and I still come to the same conclusion: it seems like an unnecessary detour.


The Address Book is a DAO’s address book, not an individual’s address book. It’s important to have some shared understanding of what a particular address maps to (e.g. adding the address for an external contractor’s gnosis multsig wallet via the Address Book that routes it to the Voting app before the mapping can be created), otherwise the system can be gamed when these nicknames are being used for financial transfers.

ENS requires another party to take an action for it to be useful. Not everyone is going to adopt ENS right away. Not everyone you’re going to send money to is going to use Aragon either.

That doesn’t mean we should suffer through a suboptimal UX of managing an external spreadsheet for the mappings. That means when transfers are proposed, as a member of the DAO you have to check an external spreadsheet/doc and trust the validity of it? How do you control who updates the spreadsheet – would it be like a Github file where you need to do pull requests etc?

If two teams have found a need for such a service, I don’t see that as an “unnecessary detour”. In building this Web3 world I think there are going to be things we have to do in the near-term, which actually don’t take that much effort at all. Because it may take years until ENS becomes much more commonplace. For example, if all of the multisigs or all of the wallet apps started to require an ENS or suggest you register one on the spot, then maybe we won’t need “Address Book” type apps anymore. Until that happens, this is no detour. It’s just building tools that help us navigate this Web3 jungle, a jungle that doesn’t have any clear, direct roads.

1 Like

Thanks for all the comments.

I admit to agreeing with almost everything that @light is arguing. Building a custom ‘Address Book’ app with name to address mappings is definitely not really hard from a technical point of view, but adding 1st party support for a particular address book implementation (every address input in any app would use this information) feels like adding technical debt right off the bat.

In terms of technical complexity, doing profiles on top of ENS like in the OP is not more than 2x more complex and I feel that we will be able to enjoy much greater network effects by doing so. Rather than adding the custom address book that we will never be able to deprecate without a hairy migration.

My proposal for the Membership app would basically be an ‘Address Book’ app plus the ability to grant everyone in the group permissions to do something (e.g. contractors can vote on some issues), but I am also not sure of how useful it really is if something like the ‘roll call’ were to be implemented as it definitely feels redundant and less powerful than just using tokens or special relationships like being in the Payroll.

I tend to align closer to @jtremback and @stellarmagnet position on this, avoiding technical debt and redundant effort is desirable, but it feels like the major pain point is dealing with non-human readable names right now (not necessarily full identity/profiles or membership management). Obviously, it’s hard to make a judgement without perfect information about both real impact to users in the short term and the time delta associated with two or more different solutions–but based on this thread and other conversations it feels like a full membership/identity solution is still very much in a concept stage, whereas providing human readable name translation is very concrete and addresses a specifiissue that has been pointed out as significant concern of one of our early adopters. I would really like to see how we can come up with an incremental approach which prioritizes getting a solution for the immediate problem of human readable address transaltion while minimizing the technical debt going into a more robust identity/membership solution.

I think it is worth pointing out that from a user perspective, acquiring an ENS (subdomain) is not difficult (and anyone using Aragon already has one as it is part of the onboarding process). So if we want human readable names to use ENS, I don’t think this has to have a huge impact on the user experience.

I’m quite confused how a Membership application will cover managing address mappings to entities that aren’t in Aragon?

Let’s call this pattern a “translator”. A translator translates an Ethereum address (0x…) into a human-readable name.

Why not allow the system to be flexible enough to sync up with multiple translators [translation providers]? Then it will cover the broader use case of translating addresses that aren’t individuals or Organizations that are using the Membership app? Instead of trying to tie everything to one elegantly designed translator, let a few of them co-exist (especially since the elegant design doesn’t cover all translation use cases)

If there are multiple translation providers you enable for your DAO, you can also rank them, so if the translation exists in two or more providers, then it will display the translation from the highest-ranked provider.

Does this solution really add that much technical debt? Like if someone doesn’t want to have two translators, then they don’t have to have it. If someone does, then it just does something different when loading the front-end?

I think the greater technical debt can come with designing a system that is not flexible and is tied to a single application to provide such a service. As seen on this thread, organizations have different needs, so how can the aragon architecture be designed in such a way that it can more easily cater toward those needs, instead of assuming there is a silver bullet solution to this use case that goes way beyond membership/identity ?

Note: this translation provider topic is a bit of a “fork” from the original thread, not sure if another thread is necessary to have more focused discussion on the topic, so it’s not confused with the solution presented here.


Just an aside, I’m wondering what will the process be to get an ENS name with a subdomain or whatever? I have to admit I am not familiar enough.

The reason I ask, is that I strongly disagree with the idea that having a different username for each DAO a user is on is a big problem.

  1. Most users will only be on one DAO, especially at first
  2. Slack has a username per org. Is this slightly inconvenient? Sure. Has it stopped their hundreds of millions of users from making great use of their service? No.

If getting an ENS username is anything more than a few clicks, smoothly integrated into onboarding like an address book based system would be, then it’s a net negative.

I think the issue of ENS is not necessarily related to the issue of whether a user should have a single name/login. I think the big benefit of having a single login is that its clear that when you participate in multiple organizations with the same ethereum address there is a public link between the two “accounts” which may not otherwise be intuitive. I agree though that early on this probably won’t be a huge issue.

With regard to how the process to get an ENS subdomain might feel, If you go through the Organization creation process ( you will claim an ENS subdomain (x.aragonid.eth) in the processes. This is used in the URL to access the organization in the future.

The thing that I have been most worried about with this proposal is that it might break backwards compatibility. Using a dedicated app, or using ENS won’t do that, so I would be happy to see those options happen. It also might be useful for the ‘Address Book’ app to instead be two apps - one to handle giving names to apps, and one to handle giving everyone in a group the same permissions to do something. The implementation would look similar to that of a token, but being an Aragon App makes it deployable in a kit, upgradable, and reduces the deployment costs to that of a proxy contract.

All of this is really great feedback, tons of good ideas. Will go back to the drawing board next week and polish my proposal for the first iteration of Identity that we should be able to ship in a few months.

1 Like

Just a final note from me: I would be very happy with this type of solution.