Identity & DAO Membership

research

#21

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.


#22

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.


#23

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.


#24

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.


#25

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.


#26

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.


#27

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.


#28

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 (https://rinkeby.aragon.org/#/) 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.


#29

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.


#30

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.


#31

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