Identity Resolvers and 3Box

[Schwartz10]

Wanted to discuss specific UX + technical details regarding the identity resolvers and 3box.

Technical:

It’s pretty straightforward to resolve an ethereum address to a 3box identity, and it doesn’t require any changes in aragon.js. From the @openworklabs/aragon-profile node module, we can export our Profile class and use the profile.getPublic method. We can transform the name field from 3box to fit whatever vocabulary the Aragon Client uses. In the future, we could display a user’s verified socials (GitHub, twitter) in the label as well if available. There are a few other benefits to resolving 3box identities through the @openworklabs/aragon-profile node module (instead of directly through 3box) that I’m happy to go into more detail about if any one is interested.

In a future iteration we could even support editing your own 3box profile from within a label instance if we want, although this is more complicated.

UX:

There are several ways to manage the UX of resolving identities, esp when it comes to using local labels and 3box profiles. Our team's suggestion is to resolve an identity to a 3box (if the user has one), and if the user does not have a 3box, resolve to local label. This aligns with a previous conversation on the topic. @stellarmagnet designed a resolved 3box identity:

What do you think of this design? This UX? Would love any feedback!

[luisivan]

@dizzypaty can you take a look? Thx!

[sohkai]

@Schwartz10, @stellarmagnet, Javi, @dizzypaty and I had a discussion about this yesterday.

As opposed to the original identity provider spec, suggesting user-definable plugins, we will likely go with a simpler approach initially to support only the following resolvers in aragon.js:

• Custom labels
• 3box
• ENS
• AddressBook (eventually deprecated for org-synced custom labels)

Given this information, we at least know that the profile image can only be obtained via 3box. The more difficult question is what do we do with the name if multiple resolvers can resolve the address.

Another thing to be noted is that resolution may not be immediate (nor cheap) for all of these providers (especially 3box), and that we may need some form of background loading of these identities as well as designs for handling slow responses and network errors.

Again, the one I'm most worried about is 3box. @Schwartz10 is there a lightweight way to know if someone has a 3box profile to know if we should try and load their entire profile data?

[Schwartz10]

@sohkai right now we use this method to detect if a user has a box or not. Not sure if there is a lighter-weighted approach though.

Any thoughts on this @oed?

[oed]

I think that makes sense @Schwartz10

[Schwartz10]

Hi @sohkai ! Have there been any conclusions or concrete specs that came from our last video discussion about this? If I remember correctly, we were deciding between a generalized approach and an approach that is specific to 3box // local labels? Do we need updated designs? We're a bit confused about the desired implementation on our end.

If our goal is to get 3box identity resolution in the next aragon.js release, we'd love to get a better idea of what our obligation is for this portion of work, so we don't hold anything up. Please let us know.

thanks!

[dizzypaty]

Hey @Schwartz10 – on my side, I'll post the updated designs today/tomorrow so it can help stir the conversation!

[dizzypaty]

Identity providers management

These designs try to illustrate the concept that we discussed over the last call we had on this topic.

By adding an identity providers management screen, users would be able to choose which provider (locally created custom labels or any other available 3rd party identity provider) is used to resolve addresses on their Aragon organizations. (Note: we could discuss a bit more where this functionality should live, at a global or at the organization level).

Also, they can reorder their preferred data source and change this over time, for example, when more providers become available. If none of those 3rd party profiles exist, then we should default to the local custom label, and if there’s no custom label then we display the shortened ETH address.

Here you can have a look at the user flow that illustrates the above functionality: https://www.figma.com/file/di3NVrDoWWGYSYr7X7nqET/Identity-providers?node-id=0%3A1

AddressBadge & popover components

In the same Figma file you can also find the different variations of the AddressBadge and popover components populated when with different identity providers. (Note: the TokenBadge will be added shortly).

[Schwartz10]

Hey thanks @dizzypaty !

@sohkai brings up a good concern about resolving directly to 3box profiles - if there are, say, 200 addresses on the screen at once - this could be a bunch of requests on 3box and/or take a while. There are some optimizations to make there, but it might be a good chunk of work.

Another option, just thinking out loud here, is potentially to keep everything the same, and just add a little "view Profile" button on the Popover component. That way we don't need to fetch more than one profile at a time and we continue to stick with local labels for identity resolution for the time being. This should be really, really easy to build in to the client.

Although this would be a full integration, so we'd probably want to integrate your UI tweaks on the actual profiles themselves before implementing this.

Thoughts?

[oed]

@Schwartz10 What's the main concern with loading many 3box profiles? That there are many http requests, or something different?

[sohkai]

@oed Mostly that; it's a bit of a resource hog if we were to try and request 200+ profiles all at once in a naive fashion. We can build various mechanisms to optimize this (usually through caching or lazier loading), but those are more complex than the laziest of them all: only attempt to load on user interaction with a (potential) profile.

[Schwartz10]

Hey @sohkai @dizzypaty - wondering what your thoughts are on just adding a simple button to the Popover componeent to "view aragon profile" as mentioned in this comment above.

This would be super easy to implement (some small aragon client and aragon/ui changes) and not require us to change address resolution for the time being until we come up with a performant solution.

On the other side, @stellarmagnet brings up a good point that we're kind of "meshing" local labels with 3box // aragon profiles, which might have some UX consequences?

What are your thoughts?

[sohkai]

Closing for now; we can re-open this when there is renewed interest.