Profiles in Aragon

[stellarmagnet]

Jonathan (@Schwartz10) and I want to propose the profile app that we have been developing (which integrates with 3box) be a “native” aragon application that is part of the Aragon client (aragon/aragon)

It doesn’t exactly make sense for a DAO to “install” the profile application, as it will likely be used by all DAOs. We both just got off a call with Brett (@sohkai) and he agreed that it makes more sense as a native app, part of the client.

A few other reasons why it will be important to include in the client:

1. OrbitDB (used by 3Box) needs access to indexedDB, which is not currently possible in a standalone Aragon app due to iframe sandboxing. We spoke about a few workarounds for this strategy, including “storage spaces” as being researched and discussed here. However, these solutions are all longer term, much larger architectural initiatives that need special security considerations. However, as a native app, profiles would have access to indexedDB, so they could work with 3Box without loosening or adjusting iframe sandboxing strategy.
2. 3Box asks for the window.web3.currentProvider, and uses it to request signatures via the JSON RPC sendAsync method. Neither the web3 provider nor the sendAsync method are exposed to aragon apps (seemingly on purpose), so in the short term, we’re using a very unsatisfying hack in order to make this work (we’re essentially imitating the web3 object with a single sendAsync method, that only accepts requests to the JSON RPC personal_sign method). The web3Wallet is available to the client, so we could use 3box and the current web3 provider properly.

Here are some standard profile designs below that make our work complementary with Aragon One’s identity initiative of ENS name claiming (subdomain of the global aragonid.eth). We wanted to show that the two concepts of a 3box profile and claiming an ENS username can intermingle.

We’d love to know what @luis and @Paty think about this. Do you think profiles are fit for the client? What concerns do you have? What more information would you like?

I’m totally open for collaboration on the designs as well (need to upload it to Figma…)

Designs

(click to enlarge the images below)

Legacy human (view mode)

Legacy human (edit mode)

(Pencil/trash icons displayed on hover)

Claiming an ENS username

Editing basic information

Pseudonymous future-human (alt design)

• Work history based on actual work you have completed/contributed (github / pando / etc history)
• Laptop sticker inspired cover region (nice to have )
  
  

[Thanks to @Schwartz10 for providing the technical aspect of this post]

[burrrata]

I’m conflicted… I really like the idea of making DAOs more social and interactive. On the other hand, this looks/feels a little “LinkedIn” ish. There’s a place for that in the world, but for building decentralized and diverse communities this might be a little limiting. For example: people often are biased by WHO is saying something rather than WHAT they are saying. A great place to see this is in /r/ethereum where people often don’t bother replying to new or unknown accounts even if they have legit questions/comments.

Another thing is that creating profiles where people show off their history/accomplishments makes it weird when people don’t. People who wish to remain anonymous are generally viewed as suspicious and treated with less respect than others. If you create a social graph that evaluates accounts based on their connection to other high value accounts, you can essentially create a “first class” and a “second class”. It’s an extreme example, but China is doing this with their Citizen Score and marketing/insurance/police companies are also doing this to segment populations. Since all blockchain data is public you don’t even need a Great Firewall or global ad network, you can just mine the data. Companies are doing this and offering it as a service to whoever wants it. I had a whole convo w Vitalik about the attack vectors for Charity Through Marginal Price Discrimination and it got very dystopian / black mirror very quick. Happy to explain how/why that might work, but it would take a min to describe. The TL;DR is that if you can differentiate between people, you can discriminate between them. Cultures and norms set the standards for how we discriminate (the technical sense of the word), but we’re looking at a global decentralized culture (often) driven by fear and profits so there’s no “norm”. I think the Aragon community is doing great with this via AGP-0 and the manifesto, but not everyone in the world shares those sentiments and the systems we create have no boundaries.

That being said, reputation and social connections are good and have served humanity well over the years. If you do great work you (often) want the world to know, and social connections are the foundation of humanity. These things are definitely important, but the way we go about them today can be improved. To empower those who have been left behind by the current system it’s important to think about how our designs reinforce or disrupt current biases/assumptions. Sadly, I don’t the best solution, but I see a few problems with the current design:

• Centralization: the whole thing implies a central profile. If I do different things with different accounts, I won’t get the credit for that. If I do everything with the same account though, then there’s a sunk social cost to switching. Furthermore, if I do switch, I have to move my tokens. Moving tokens is public. That means “switching” leaves a trail. Technically you can run them through mixers or in the future use zero-knowledge sidechains to eliminate correlations, but I doubt most people will. This is a problem for many reasons:
• Voting: if my votes are public like the last pic showed, then people who don’t like that might treat me differently in the future. For those with lots of opportunities, this is often not a problem, but for those with very few opportunities this is critical. A lot of the Aragon branding and promotional videos shows people in 2nd/3rd world countries accessing this stuff via consumer hardware. We’ve seen that people will put anything on the internet before thinking through (or even being aware of) the consequences. Putting things out there, permanently, esp if they are contentious, could get people killed. If people are organizing against something unpopular, don’t understand how these tools work, and make that data publicly available for their enemies… things are going to be sad. It’s an extreme example, but Aragon is all about empowering freedom and the people who aren’t free need this the most.
• Security: if my account goes down, I go down. There are projects like Dark Crystal that aim to help with social key restoration, but it’s not ready yet and most people are lazy. Having a central point of control for things that influence a persons voice (voting), capital (access to work), and reputation (resume and social connections) is very risky
• Location: straight up, if we’re building a decentralized system that allows anyone anywhere to do anything they want, adding a location is a legal snafu waiting to happen. Everything is public data, and it’s immutable. Most people don’t understand the laws in their own countries, and laws can change and be applied retroactively. Since laws are local to a chunk of dirt adding your location puts you in a jurisdictional bucket. That being said, some people feel like adding a location is a way they can express themselves. That’s cool, but then again… it creates the dichotomy between those who want to share and those who don’t. From a statistical data science stand point the more you can segment groups the more you can deanonymize them. This is a problem for a lot of people, but it takes a background in machine learning or data science to realize it. People will post and do things on the internet/blockchains that make their lives unnecessarily difficult in the future. Let’s not let them do that.

Ok that’s a bit of a rant, and for the most part these things are extreme examples, but if we’re serious about scaling I think they’re important to emphasize

Edit: to be more constructive, here’s my suggestions:

• Remove the option to add a location.
• Only allow social integration with platforms that are encrypted and/or allow users to sign up anonymously (This is hard right now, but I think it’s something to work towards. People often use the current networks because they’re the default, but if people are “nudged” towards other options via the UI/UX that can help greatly!)
• Integrate account recovery options (don’t only rely on Metamask).
• Rather than the traditional who’s who resume stats, create a process that forces people to show WHAT they did (code, projects, accomplishments) rather than WHO they are (titles and connections).
• Do not make votes or tx public. (This is currently hard/impossible on Ethereum, but it should be a design goal to work towards.)

Hope that helps

[Julian]

Nice layout - particularly like the Banksy page, really good.

[stellarmagnet]

@burrrata thanks for your deep analysis.

Context is important when thinking about profiles. I don’t think there’s a “one size fits all” solution here – but nobody is forcing anyone to populate a profile to interact with a DAO.

1. If one does choose to populate their profile, they are not required to populate all of the fields (like location, etc).
2. I don’t think Aragon is meant to be used only for organizations filled with anonymous people. Whenever you have an organization that is deploying billions of dollars of capital, you are going to need a bit of data to go off of to decide who is going to be paid for what they are doing.
3. It is possible to keep some of these details private and only provide access to certain aspects of your profile on a case by case basis.

So lets say there is a DAO that is trying to solve climate change and they are looking to hire a scientist. How should this scientist apply for that role? Do they actually send their Linkedin profile, a PDF, or alternatively an Ethereum profile that contains their work history?

Or even right now, when we are looking to hire people to join Autark, we still need a resume or something similar.

if my votes are public like the last pic showed, then people who don’t like that might treat me differently in the future

Right now if a person is voting with an Ethereum address that is linked to a public identity, then your vote is public. If you don’t want your vote to be public or don’t want people to know who you are… then you do not populate your profile.

This current profiles solution is not meant to solve one losing their keys, or the ability to share an identity across multiple Ethereum addresses, but i think those types of things will sort themselves out over time via “universal logins” type approach. That’s outside of our scope of work.

What I am presenting here are some ideas that were outlined in Autark’s Flock proposal, and the purpose of the profile here is to help DAOs decide who to assign a task when there is greater than one applicant – that’s why it’s LinkedIn-like, as it’s work-specific.

[burrrata]

Are these profiles for people, that they then connect to DAOs, or would each DAO set the permissions for what types of data users/members can enter into their profile for that org?

Also, just giving people the option to fill stuff in or not implies that they are aware of all the implications that their data has and that there isn’t social pressure to add data. People choose the default, and historically that has not been a win for users at scale. I’m saying that it would be wise to design the defaults in a way that protects users and sets new norms.

[stellarmagnet]

Are these profiles for people, that they then connect to DAOs, or would each DAO set the permissions for what types of data users/members can enter into their profile for that org?

These are profiles that are global to Ethereum. One profile can be shared across all DAOs. There is private profile information that you can only give access to specific people (or DAOs too? @Schwartz10)

Also, just giving people the option to fill stuff in or not implies that they are aware of all the implications that their data has and that there isn’t social pressure to add data. People choose the default, and historically that has not been a win for users at scale. I’m saying that it would be wise to design the defaults in a way that protects users and sets new norms.

I was just trying to describe that there are so many use cases for Aragon organizations and DAOs, and there are some DAOs where profiles wont be important, others where it will be important. There are some cases where you want your votes to be public, others where you may hodl your tokens in a more private account not attached to a public identity.

So if a person wants to interact with one DAO without any kind of identity, and another DAO with an identity; or to have multiple identities across multiple DAOs – that all works. You change your metamask address and you change characters. Nobody is forcing anyone to do (or not do) any one thing…

There just may be some DAOs where you need a profile to participate. There may be other DAOs where it’s not recommended to have a profile. That’s why I don’t necessarily agree with removing features (like location) just because it doesn’t fit within the context of one specific vision of what a DAO is or what a DAO can be.

[stellarmagnet]

But i think this specific feature (removing Location) can be a good thing to do a signaling vote on! I personally have never been bothered by this feature, and live in the “universe” on many social platforms and haven’t been judged for it…

[burrrata]

Ok that makes more sense. So you’re making an thing that lets people create a profile on Ethereum, but is not specific to any DAO or organization. Then it’s up to each DAO to decide how to interact with that data. It could be that the DAO only allows certain info to be populated, but that’s really up to the discretion of that organization/community?

I still feel strongly that the defaults are super important and going to set expectations for users and orgs, but I see where you’re coming from that restricting the design space isn’t a good move for “layer 1” of the project. Better to create possibilities and then let context specific applications (“layer 2”) make decisions as to how to implement those possibilities (protocol vs application). I guess it’s inevitable that people will do what they want with their data and norms will form around that. It’s just that when data get big, it can be combined to create insights that would otherwise not be possible, and most people don’t realize this until it’s too late. The struggle is real lol

[stellarmagnet]

@burrrata

Ok that makes more sense. So you’re making an thing that lets people create a profile on Ethereum, but is not specific to any DAO or organization. Then it’s up to each DAO to decide how to interact with that data. It could be that the DAO only allows certain info to be populated, but that’s really up to the discretion of that organization/community?

Yeah we are integrating with 3box, and that lets people create profiles on Ethereum. We are essentially exposing some of the edit functionality within Aragon and also extending it to support other fields that aren’t in their default set (location is in their default set).

Shared backend for Web3 | 3Box

This forum post describes the profile being part of the Aragon client and it would be DAO agnostic. It seems you may prefer that profiles should be DAO-specific so a DAO can have the choice to hide the location field in Aragon?

I still feel strongly that the defaults are super important and going to set expectations for users and orgs, but I see where you’re coming from that restricting the design space isn’t a good move for “layer 1” of the project.

It seems like the main data point you have a problem with though is location?

From a statistical data science stand point the more you can segment groups the more you can deanonymize them. This is a problem for a lot of people, but it takes a background in machine learning or data science to realize it. People will post and do things on the internet/blockchains that make their lives unnecessarily difficult in the future. Let’s not let them do that.

I think if one populates their name and image (with true data), the people who are determined to know where you live can probably figure that out. I’m sure one’s home address can be found without having the “location” data on your Ethereum profile, as it can be stitched together from other social profiles. Hence I am having a hard time being convinced that exposing a location field makes much a difference in this use case – as far as trying to set new privacy norms – especially once you have already given up your image/name.

I think what you mention for how one should describe their work history based on accomplishments instead of titles is good advice too – that’s why I have an alt design with Banksy whose work history is based on open source projects and actual data. I think there will still be multiple use cases to design around / support, but I am still not seeing the harm in listing jobs by titles or harm in listing one’s education. One can’t just break hiring norms by designing a new UI and saying “use this, it’s better for the world if we hired in this manner”.

I think trying to reinvent many things in parallel will stand in the way of adoption. Let’s just get people being part of DAOs first?

The current design pattern does support one describing a project instead of a company. If you have a project-focused work history, you use the fields in a different way than people who don’t have project-focused work histories. Not everyone is a developer, and not everyone can link to some portfolio work etc.

[burrrata]

@stellarmagnet

It seems you may prefer that profiles should be DAO-specific so a DAO can have the choice to hide the location field in Aragon?

It would be awesome if each DAO could have settings that determine which personal data fields the DAO interacts with or accepts. Then communities could set their own norms and policies around data disclosure.

@stellarmagnet

It seems like the main data point you have a problem with though is location?

That’s the most obvious and concrete one, but it’s really more of a general concern for people who could potentially be negatively impacted by the data they disclose. Learning the hard way isn’t fun

Regarding “true data” vs “alternative data”, sure with enough digging anything is possible. Often I think it’s more like the story of the bear chasing 2 hikers: one hiker stops to put on his running shoes and the other asks why. He simply replies that he doesn’t have to outrun the bear, he just has to outrun the other person. Security through obscurity isn’t a solid defense, but from a big data standpoint the less correlations the better.

And yeah I like the Bansky one. Showing work done via PRs (or the year graph on GitHub) is cool. Anything that helps people see and understand work being done is awesome. I imagine this could also include blog posts or user created items (for example what you might put on a resume saying you worked on x problem with y people and z happened). 1 size doesn’t fit everyone though, so options are good. If it’s coming from a 3rd party that provides lots of options anyways, and the DAOs themselves can set rules around what data they do and don’t accept, then I think it’s all good. I just don’t want people to get in a scenario where they blindly fill everything out and then regret that later.

And yeah there’s always a balance between UX and ABC other thing. I’m not designing the app so it’s not my call. I just wanted to voice some thoughts/concerns so that they would be taken into consideration with all the other things

@stellarmagnet

The current design pattern does support one describing a project instead of a company. If you have a project-focused work history, you use the fields in a different way than people who don’t have project-focused work histories. Not everyone is a developer, and not everyone can link to some portfolio work etc.

That’s also cool. Again, 1 size doesn’t fit all and I’m seeing this more and more as I better understand how this would work. If people have options on what they want to share that’s great. If DAOs can set parameters on what personal info they want to interact with, that’s great. Then people and communities can self organize, which I think is the goal of the whole thing

[luis]

This is very cool! Information-aside, I think that just visualizing whatever 3Box gives us is a good way. We may even want to just include their webapp with an Aragon theming, that may be easier implementation-wise.

As for the possible issues, I only see one: how do you see this interfacing with the tagging system?

[burrrata]

@stellarmagnet
Just wanted to circle back and say that with more data and experience my views are changing. Helping to build out 1Hive it’s becoming obvious that having a way to see who’s who in the DAO, what their interests are, and what experience they have would improve community engagement and onboarding dramatically. Essentially, I can totally see the need for profiles in Aragon and would love to have that feature available to the 1Hive community

Also, regarding my suggestion for DAOs to selectively configure what data fields they want to include from profiles in their org, that actually doesn’t seem practical now that I’m thinking about it more. If the profile is global and not tied to a specific DAO each profile would have to have an API that the DAO connects to. The DAO would then selectively pull profile data from each member and display it in a member profile within the DAO rather than linking to the member’s global profile. This is kind of silly though because if a member wanted to be anonymous they would create a new profile to use with that DAO, and if a member did not want to be anonymous you could easily look up their global profile, so all in all it was a terrible idea on my part. My bad lol

[stellarmagnet]

@luis

As for the possible issues, I only see one: how do you see this interfacing with the tagging system?

Hey @luis, first, glad you like the direction! As far as how it interfaces with the tagging system — we have always thought it would work as Brett has proposed here: Identity Providers: Resolving Addresses to Identities in Aragon

Hence, the badge should also be able to render the name/avatar based on the 3box profile data. The difference would be in the data we display in the popover. Instead of “Edit custom label” button we can have a “View profile” button for addresses that actually have a 3box setup. For addresses without a 3box, it can show “Add custom label”. This then doesn’t break the current design pattern too much and allows both features to coexist. Since with 3box we will also have access to much more data, we may want to include more data in the popover, as Brett suggests in his forum topic as well.

So the ultimate changes to support this would be:

1. Including Profiles as part of the client
2. Enhance IdentityBadge to support an additional data source (3box) and add conditional rendering logic

You may ask: “what if I assign a custom label to Alice, and then two weeks later she sets up her profile?” I think the best way to handle this is either:

A) We ask the user to opt-in to using 3box as an identity provider when we roll out the client upgrade. We tell them that if you opt-in, your user generated labels will be disregarded if that Ethereum address has a 3box setup.
or
B) Alternatively, we don’t give the users the ability to opt-in, and instead we market the change on social media or as a new feature when they first access the app after the upgrade.

For both cases, the custom labels can still coexist (the 3box data would not be overwriting the json file), and if we really really wanted – we can display the local label set by the user in the popover and still expose editing features – just takes a bit more UX thoughts so it’s not over complicated.

I lean towards Option B, because I’m having a hard time believing that a user would have a problem with utilizing a name that comes straight from the source. Custom labels can then still be useful for people who don’t have 3boxes or non-user entities. I prefer to “keep it simple” and then add extra features if there is demand (good to have that Help Scout now ) .

Either way, I think the priority order of data rendering should be:

1. First, render badge based on 3box data
2. If 3box data does not exist, render the badge based on custom labels.

Let me know what your thoughts are — we are hoping to begin the client development items soon. I’d also like to understand your thoughts on the top navigation in relation to profile data and ENS to make sure we are aligned / marching down the same path.

@burrrata

Just wanted to circle back and say that with more data and experience my views are changing. Helping to build out 1Hive it’s becoming obvious that having a way to see who’s who in the DAO, what their interests are, and what experience they have would improve community engagement and onboarding dramatically. Essentially, I can totally see the need for profiles in Aragon and would love to have that feature available to the 1Hive community

@burrrata glad you have turned around your views on this

[luis]

A) We ask the user to opt-in to using 3box as an identity provider when we roll out the client upgrade. We tell them that if you opt-in, your user generated labels will be disregarded if that Ethereum address has a 3box setup.

Yeah, I think this makes sense.

• First, render badge based on 3box data
• If 3box data does not exist, render the badge based on custom labels.

Makes sense too. Maybe some users will still want to provide a custom label to override 3box, but I think that is an edge case and we shouldn’t worry about it now.

[burrrata]

Just discovered the Aragon/Keybase identity project, but it looks like it was archived.

• https://blog.aragon.org/how-aragon-approaches-identity-and-the-ethereum-keybase-resolver-d548133e4a26/
• https://github.com/aragon/KeybaseRegistry

@stellarmagnet Will it be possible to integrate Keybase profiles/identities with this profile app?