Account and wallet address relation

The Giveth Platform
1

As we had discussions in reviewing ux flow of our dapp, we need to review user persona to make the decisions better for UX, so in my understanding we have 3 type of users.

User Type 1 - Viewers (web2+web3)
Not connected a wallet, not having an account

USE CASES: See projects pages, search, see profile pages, and see the all pages

User type 2- Donors

2-2 web2 users
Not connected a wallet, not having an account
USE CASES: do all above + donate to a project through Transack.
{How we can give the givebacks?}

2-3 Web3 users
Connected wallet, not having any account
USE CASES: do all above + donate to a project with their address

User Type 3- Project Owners who want to collect or give
Having an account, wallet is connected

3-1 Donors with accounts
USE CASES:

  • do all above
  • giving hearts
  • donate

3-2 Project Owners
USE CASES:

  • do all above
  • giving heart
  • sign up
    (for web2 users Torus is mandatory - for Web3 users: they just need to sign with an existing wallet address)
  • sign in
    (for web2 users Torus is mandatory - for Web3 users: they just need to sign with an existing wallet address)
  • sign out (once they signed in / we go ahead the the previous token )
  • create project
  • see my projects
  • active/de-active projects
  • edit projects,
  • Add/remove project updates
  • receive email notifications {I’m not sure about this}

So we do not need an account and stuff like “sign in / sign out” for type 1 and 2 users. and it’s like other blockchain platforms. and the suggested header that @markop designed is good for these type of users unless we should remove logout part because there is not any account there.

But for project owners we need account based design, we may have different header letting the user know that he is still signed in with the specific account name and a given connected wallet. So even I change my wallet address Im still logged-in but when it comes to donation, I have to get aware by the dapp that I have to donate with that currently signed wallet.

We may add a feature in backlog for completing this with adding more addresses as secondary addresses to the user profile.

6 Likes
2

Thanks Moenick, Here is what I think :slight_smile:

  • I think Viewer should not be able to give hearts, cause if so then the project owner can do it mill times him/her self as a viewer (it effects quality score). viewer cannot do any action except SHARING A PROJECT, asking for support (in the footer), partnership, vacancies,… and maybe anonymous donation (WITHOUT SIGN IN WITH WALLET ADDRESS)? what if the viewer would like to donate anonymously without logging/signing in. Shouldn’t he/she be able to do so? with both a wallet address or transac.

  • donate with wallet address he/she can receive GIVbacks but with Transac she/he does not recieve GIVbacks, Right? should we mention that in the UX?

  • If he wants to do any action except create project, he/she should create a profile (gmail, name ,…) Wallet address is optional (it is optional to sign in via wallet, it can be web2 services like twitter, gmail,… ). But if a signed in user wants to create a project he/she should has to have a wallet address, if web2 then Torus (the way we have now), if web3 can choose from Metamask or all other bunch of options depending on the browser he/she is in.
    Once signed in and entered his/her wallet address, he/she can see stuff on my account and do all of the actions: my projects, edit project, deactivate/activate project, verify project, view and edit project.
    User have one primary address which, for now, we improve it using messages for better communication and make him/her aware that he is donating with the Connected Wallet address.

  • Based on what Griff and Mateo said, it doesn’t matter if a user has multiple profiles, for now we keep the one to one monogamous user-wallet relationship and I think with some confirmation messages to the user or some other simple UX tricks we can handle the bad experience we have now when changing the address or looking to copy other wallet addresses which kicks the user out and he has to sign in again.
    Later we keep the primary and secondary addresses in one profile.

1 Like
3

If the viewer donates then they become a donor (category 2) so I’m not sure how that would make sense otherwise. by the nature of Ethereum a user cannot make an anonymous donation without being logged into some sort of wallet extension (i.e metamask, Torus) so I don’t see how this could really change from what Moenick has described.

Donna makes a good point about giving hearts, since it does affect quality score we shouldn’t make it exploitable. Ideally only users who have connected to a wallet and/or have an account should be able to like projects.

@MoeNick What is the idea behind not including a third type for Donors - Walleted connected, has account. Is it because we want to keep it clearly defined from project owners? Shouldn’t one of the goals of our UX be to have users create accounts? The more that users interact and integrate with the platform will help us communicate with users and analyze their behaviour.

Also some additional use cases would be:

  • Add/remove project updates
  • receive email notifications (this is especially important for the proposed third type of donor)
3 Likes
4

1- Donors who “Walleted connected, has account” might be the project owners who would like to donate.

2- GREAT POINT : “one of the goals of our UX be to have users create accounts?”
In my opinion: No, we just have to try to make it smoother as possible.
Appreciate if @markop , @Griff can give comments on it. If the answer was yes, we have to make create account a mandatory before making donation.

3- I also agree with Giving Hearts not to be open service, so It needs creating an account, I will change it.

4- I missed them I will add:

  • Add/remove project updates
  • receive email notifications (this is especially important for the proposed third type of donor)

Thanks for your comment buddie.

5

I updated the post …

6

We have a new type of user… the smart contract user… someone using a gnosis multisig that is trying to donate (rainbow rolls did this) We might want to test this use case too and figure out how to handle it…

In general i don’t think we should try to combine addresses and user accounts… lets let people donate with multiple accounts and each account has a unique user name… this will be better.

But we should integrate with ENS… if they have a Reverse ENS address, that should automatically show up instead of their address.

3 Likes
7

To clarify we specified a while ago that contracts could not be project owners - so in this case only smart contract users should be donors, right?

8

We prompt them prior to donating to sign up / register or connect wallet making it clear the benefits of doing that (get GIVbacks), regardless if they are donating to a project that is verified or not.

In this case we simply ask user to sign the message with the new wallet they just changed and want to donate with, and we append that wallet to their account. The first wallet ever connected can be Primary wallet flagged in our db. (no need to allow user to change their primary wallet in their account, at least not at this stage).

I agree. Most sites these days prompt you to sign in if you want to like something. Sharing is fine.

This is the most important question of this topic. I believe this is something we’re deciding not just for Giveth but for the most part of the Web3 space in general.

Previously we had implemented the one wallet one account feature and here’s why I think this is not a good practice:

1. User activity (not only the on-chain data) is associated with their wallet address and is logged in their account.
2. Changing the wallet (this became a routine user behaviour in Web3) creates a fresh account which is empty and all the previous activity that user is expecting to see in their account, is now missing.

What users believe they know about something strongly impacts how they use it. Mismatched mental models are common, especially with designs that try something new.

In Web3 (DeFi in general) most dapps operate as one wallet one account because of the nature of those services. Although, some DeFi dapps now support multiple wallets nested under a single account (even allowing even watch addresses), but this isn’t the use case here.
Most DeFi dapps do not deal with personal user data other than what is associated with the wallet (on-chain activity).

Web2 user mental is based on belief that they have an account associated with all their activity, history and other data collected by the service. We’re trying to bridge the Web2 and Web3 worlds allowing anyone to interact with the Web3 (donating and fundraising with/in crypto) without prior experience, and we do that in a most seamless way possible.

Disclaimer: Onboarding users to Web3 is not our main focus, it’s just part of the flow and we do our best to make it frictionless.

Web2 users who eventually advance and become more experienced interacting with Web3 will find themselves in the same situation as Web3 natives who are very familiar with wallet interactions and “non existing user accounts”.

It’s a two-way bridge and we have to address it from both directions: Web2 and Web3 use cases.

Users base their predictions about the system on their mental models and thus plan their future actions based on how that model predicts the appropriate course.

The system should always provide feedback to the user on what is happening and what is going to happen if taking some actions.

In this case, if user is switching the wallet (or provider) one possible solution could be to prompt and ask them if they want to continue by associating the new wallet with existing account or they want to create a new account with that wallet.

Here is a draft diagram of the flow discussed. Editing and commenting is open to everyone.

I definitely want to give this more thought and discuss with fellow Web3 designers because I believe that this isn’t only a Giveth issue but something applicable to many Web3 projects and dapps which will be built in the future.

I’d love to hear your thoughts and opinion as both Web2 and Web3 users, how you think, feel and decide when faced with situations like this.

2 Likes
9

One Hundred and Twenty Three Percent Agree with Marko’s positions stated.

Yes and Yes.

Please.

Torus gives users sooo many ways to sign up. And each one creates a new wallet! I feel very strongly we have to give users an account identifier that allows them to link multiple wallets if they manage multiple projects. This is important future think, that affects current development decisions. And we can’t make it in a vacuum - thank you @markop for looking to the ecosystem for how we can leverage design decisions that keep us relevant and easily relatable to the Web3 space as we move rapidly towards cross-chain interoperability as well.

10

I think in some ways this might be okay. However some of the unique features and risks of the GIVeconomy may require us to implement some sort of identity or proof of uniqueness feature. The problem lies in the gamification of GIVbacks, we kind of kicked the can down the road on this one but the recent issue with RIP medical debt @mateodaza resurfaced an important problem.

How do we prevent verified projects from cycling funds from donations back into themselves and draining GIVbacks?

I really think that at certain levels of participation we’ll need to require some sort of account/identity relation with a wallet address.

11

There is a conversation in the DEV channel on Discord about one wallet / one project, that I would like to draw into this discussion, beginning with @MoeNick 's question here.

I feel strongly that decisions about core functionality in the platform like this are governance matters and really need input from donors, project owners, designers, AND developers… this forum is our best shot at soliciting that input.

IF from a development perspective, we need to have one wallet per project - then we really, really need to have multiple wallets per account for amongst others, the reason I share here.

Quoting @karmaticacid :
“## Lauren — 11/23/2021
The reason we have it this way is because we want it to be clear to donors… so they can see that their money is going to that account that is for x purpose. it’s for “ease of accounting”. the donors can see how those funds are being spent too… from the account they donated to, and see if it checks out. it’s also nice to be able to use that as a unique identifier for each project.”

IMO, this is where the difference between G.io and TRACE become essential - an org needs to be able to have multiple projects, and to see them in the same place, in order to provide donors the level of transparency they desire. G.io does not provide any transparency with just one level, and it makes a non-profits administration a nightmare instead of easing it which is a value, mission and intention.

With the utmost respect I feel a lot of contradiction with @Griff 's response here, both in the reality of how Blockchain and banking functions right now for orgs doing good, and in the idea of enforcing trust by making it more difficult and expensive to be transparent. There is an assumption here that nonprofits will commit fraud if it’s too easy to do so, and that we have to regulate them instead of building them a tool that makes it easy to give, AND receive.

G.io simply cannot be clear to donors in the basic form it is now no matter how much we engineer wallet limitations etc. If you want to just give, and trust, use G.io. If you want transparency and accountability, you need the 3 layers of TRACE with DAC Campaign and Traces to deliver that. And if we want to enforce accountability on G.io for verification then I posit that we need to add Traces at minimum, and all three levels to actually achieve that.

1 Like
12

Thank you @Danibelle for drawing it into this discussion because it also matters a lot!

From the perspective of a Project Owner (Non-profit/Org), I’d expect to have one address tied to many projects that I’m listing on Giveth.io.
Since the Project Owner persona can also be a Donor persona and would be allowed to switch wallet
when donating, we should just take this into count informing them the same way I proposed earlier.

Changin the primary wallet address in My Account/Settings (I assume we would have this option down the road) would either be disabled for Project Owners, since it has a larger effect on transparency mentioned above, or we would inform them about the consequences of such actions.

Anyhow, we can map out the flow and all implications for each persona when we decide on technical implementation, plan and build this into our roadmap.

Additionally, we’re talking about individuals and orgs here, and right now we don’t have a clear distinction (correct me if I’m wrong) between those accounts. We would eventually need Org account type and the ability to invite team members. This opens up another question on how we want to structure that, how flexible we want this to be, and what is the development effort to accomplish it.

2 Likes
13

The challenge here is we have Donors with needs/expectations and Projects with very different needs/expectations

I can speak to the donors needs…

Dani can speak well to the Project’s needs…

Can we separate the flows COMPLETELY

Donors do not want to automatically link all their addresses together and bundle… this causes issues around anon donations and is against the normal web3 flow (as mentioned above)

Projects want to have multiple addresses managed under 1 account and are used to that flow from other expectations…

I think all of our challenges would evaporate id we make a very clear distinction at the get go from Donors and Projects and give them different UXs.

5 Likes
14

In my view, we should separate two requirements

  1. Donor/Viewer account management or Profile<–>Wallet Address relation
  2. Projects management or Project <–>Wallet Address relation

Donor/Viewer account management

To focus only on Donor/Viewer account management I believe we should make web2 login mandatory for off-chain interactions, here giving hearts and receiving emails. Signing a message by the user doesn’t suffice as we can be attacked easily by someone who authenticates by random private keys and then sends give heart requests or set invalid emails. Of course, the user doesn’t need to log in for donate scenarios and can create tx or user transak but he will miss notifications like GIVBack receive emails.

I believe only web2 login is the valid way to create a profile. In case we go for it (web2 login), we can then think about wallets management as the user can connect wallets to its profile. Resources of connected wallets will be shown in the user menu/dashboard and the user will receive notifications related to them.

Project management

I agree with the idea of one project can have multiple addresses. But it should be one unique address per network! In case we support multiple networks (e.g. Mainnet, xDAI, BSC, etc.), a project owner needs to define one address per each network he/she likes to receive donations on.
Again, I don’t understand why a single address can be used for multiple projects but it can be implemented. The only concern is successfully keeping track of donations in our backend since the user should successfully push his donation information to our backend. Otherwise we would lost the track and don’t know which project was aimed by the user.

As a technical person I wish I have included all the requirements, otherwise please let me know

2 Likes
15

I can find this very similar with what @amin is saying.

What do you think @markop ?

16

Absolutely! Yes.

BUT BUT BUT … we need to go back to the drawing board and CAREFULLY plan out and architect both backend and frontend and UX. This has many implications on the current system and it isn’t a one sprint job.

4 Likes
17

I’m a bit confused by the terminology here - what do you mean a project can have multiple addresses? do you mean a project owner?

A project can only have one address, the address that receives crypto donations to their project.

2 Likes
18

Yes Project Owners, thx for the clarification

1 Like
19

As we are going through the first GIVbacks round… I want to leave some comments here for consideration.

I would like to advocate for a donor profile/account and a project owner profile/account. We can have different functionality for each.

Project owner account

  • can have multiple projects and manage them from one profile
  • cannot donate to any project from this account
  • manage updates, edit projects, etc etc.

Donor account

  • donors need complete a profile in order to donate - info can be minimal as long as it attaches all donations made from that address to their account (having the ability to view donation history of a users wallet is very useful when reviewing GIVbacks data for fraud)… keep in mind that they can always choose to donate anonymously in which case their username will not be shown in the donation history of a project.
  • donor accounts should be one wallet… one account unlike the project owner use case.

I imagine we could do something like this:
When the user creates their profile they choose whether they are a donor or a project owner
project owner accounts wouldn’t be able to donate to any projects from their project addresses and addresses that are attached to projects wouldn’t be able to create a donor account - this keeps users from donating to their own projects to get GIVbacks and makes it very clear to the user that one profile type is for donating and the other for funding their project… I’m sure there is more to be thought about and spec’d out but these are my initial thoughts.

Please see this issue: https://github.com/Giveth/giveth-next/issues/642

2 Likes
20

I would say that we could create a system where people need to make a profile to get GIVbacks… but we should not put any barriers to donating… We can make a pop-up AFTER they donate to tell them they will get GIVbacks IF they fill out a profile… but even that… i would want to know why we need that when we have their ETH address already… Requiring a profile makes it hard to make GIVbacks a composable Public Goods Lego that stacks well with other solutions… Maybe we give them EXTRA GIVbacks for making a profile?

Remember:
Screen Shot 2022-01-14 at 3.23.58 PM

1 Like