Make our Giveth.IO dApp more resilient before GivEconomy deploy

The Giveth Platform
1

It was a regular Sunday when I felt the incredible annoying spam on our discord of many donations of 1 xDAI to a project that was just created, around 50 new accounts logged in just to donate and like this project. All of this combined made the project go to our top 1 in matter of hours. Maybe they needed somewhere to allocate donations, or maybe they just expect a really cool airdrop from us in the future, either option is alright, the game and rules are set and they are just playing!

You can’t blame the player, you blame the system.

Then Monday morning happened and one of the top projects on our list was one talking trash about dappNode, it had zero donations but it was pretty easy to find. A little bit of scrolls down and you see the beautiful dappNode project being roasted on our own site, very rude, not nice. :frowning: :angry:

So this raised a question in me, how resilient is our app to these different strategies and “attacks” previous to our economy deploy?? With these I can tell it’s not ready, I can only imagine the fear of missing out from many degens, trolls and people to just get a bit of GIV or take advantage of our open ecosystem.

To keep it short, In my opinion we need to improve a lot on these:

  • Better curation on projects
  • More accurate and fair calculations on quality score
  • Optimize on security and stress test the dApp and Impact graph

I’d like to propose some solutions we can develop rather fast and evolve with time for each point:

  • Better curation on projects:

So far we have our project listing completely open and unregulated, anybody could upload indecent material, bully people or just troll in general and we could be unaware for long time. I came up with the idea to have 3 new filters [unlisted, listed, verified]

unlisted projects are accessible through the URL but are not shown on our page until some manual revision is made, the other two don’t need explanation. @willy mentioned on our call that we could do something like Uniswap where you can paste any contract and just use it in their platform. I think this flow have the same spirit, where you are able to donate and access only if you have the URL, but we won’t promote them by default. We can build a simple admin dashboard or a discord bot so anyone in the team can list new projects when desired, this internal flow can be up for discussion later. I would also like to ‘unlist’ some old project that raises doubts on its quality. I’d like to keep our feed as clean as possible, and maybe this could help us a lot.

  • More accurate and fair calculations on quality score

I’d like to consider a better score addition, considering probably a logarithmic function where there’s a point that you rate grows slower, we could consider time as a new parameter. We can also improve the project owner verification process and make use of it to make the quality score even more trustful. Besides the old social network verification, we can bring many other protocols like Proof of Humanity but the one that makes more sense as a first step is The Commons Stack trusted seed, every account that is trusted will be verified by default.

  • Optimize on security and stress test the dApp and Impact graph

Been talking with Carlos to increase reliability, quality and response time on queries and mutations during all the processes, I noticed some important issues when our app couldn’t handle large amount of donations. Many technical talk in here, no need to be addressed in this post but important to mention.

…

There are many easy first steps that we can take but I’d love feedback from all of you before starting any of them, specially on the first two points. Some we already discussed a while ago but just left for later, maybe now is the best time!

Shoutout to Hannah, Willy and Lauren, they inspired and helped with many of these ideas and proposal <3

3 Likes
2

Sounds awesome Mateo!! Thanks so much for putting the energy into generating ideas to make the DApp resilient <3

I like the idea of having listed and unlisted projects… the only thing I’d like to ensure is that we have an easy means for the projects to get listed. I’d hate for apathy, busy-ness, or overwhelm to cause the rate of flow from “listed” to “unlisted” to be low… Basically in the early days I think it would be great if we had like… a designated team or designated time slot in which our team pushed the projects to “listed”. And maybe we can figure out how to automate that better in the future.

100% agree on improving the quality score. I think also that we never did the “retroactive quality score”… updating old projects so that they are counted (I could be wrong… @mitch or @James would know). Creating a “trusted” list for members of the trusted seed is an interesting idea, but I’m not actually sure what our current parameters are for projects eligible to be verified… I think there is some piece about them needing to have a larger impact… not just be small individual projects (and these may be added by the trusted seed). Would love to hear from @WhyldWanderer on this

3 Likes
3

Thanks @mateodaza for the idea. I don’t support listed or unlisted concept, but instead we can invest on rating score. If we want to be standard, I think we have to have several views of projects beside having a homepage with algorithms to show desired projects on top.

So we may need 1-Projects Home Page 2- Success Stories 3- EXPLORE Projects

EXPLORE page with lots of searching and sorting tools for users, this page have these capabilities:
Sorting: (I prefer we have different views, not always cards, but it may be in rows)

  1. List of projects should gave this ability to users to sort projects in different time frames:
    1-1 most recent, latest (sort by creating date)
    1-2 most popular, (engagement params like number of donations, views + likes, replies, retweets)
    1-3 largest , (or richest, most fundraised projects: sort by total amounts)
    1-4 by topic (categories)
    1-5 by type (verified, traceable etc.)

Searching:
all related phrases ins all fields, even topics, types and location. user can sort after searching.

Projects Home Page: it will have several params on how to sort and view projects,
params should be:

  • Verified or traceable (proof of humanity is covered in this case)
  • Having rich media
  • updated
  • Have minimum amount of views/ likes
  • Have minimum amount of donations
  • Growth of donation amounts.
  • Admin manual score

Some of them has y/n but gain score for their attribute, and we can sort them in our hope page, there are lots of articles about how we can list, tile, provide media beside this projects to make them more attractive for users.

Success Stories
is a page about projects which are finished and raised needed funds, they should provide information about their impacts they had made. They can be sort manually by an admin score.

4

Thanks @mateodaza

I recall we briefly touched on this categorization of projects in the early days of new Giveth.io but it didn’t make it into the MVP, I guess now is the time.

I say yes to unlisted, listed, and verified. This solves few other open issues we have on Github, like previewing a project before publishing.

User side

  • Create a project and preview the listing
  • Show Unlisted badge (more info to explain internal review is in progress, time needed)
  • Notification when project get Listed (Email, in-app)
  • My Account filter projects by Listed, Unlisted, Verified
  • When a project is Unlisted (for some reason) show project page but with info that the project is Unlisted, CTA contact support or create a project or browse other projects etc.
  • Donating to an Unlisted project show notification like Uniswap (Important notice, you’re donating to an unlisted project at your own risk, checkbox I confirm)

Admin side

  • Ability to see all projects created and filtered by Unlisted, Listed, Verified, Pending Verification (or in progress) No Discord please, we should have an internal Dashboard for this
  • preview project Score (used only internally) and ability to Approve, Decline, Need improvement (Send message to project owner)
  • Approve automatically triggers a notification to User
  • Decline, option to write a reason/message that gets sent to the User

The reason I left out the Score from a Public view is that I want Giveth to be trustworthy by design, meaning all projects that are published on Giveth are worth donating and everyone should feel safe donating knowing the funds are going into the right hands and put to good use. I propose internal scoring system for admins to know when a project is worth Listing and Verified or not.

Next steps: Spec out the whole thing in Notion for Admins, Devs, Designers and Comms so that everyone knows exactly where to start. Create Epic, Issues and set timelines for implementation.

If I missed something please fill it in.

2 Likes
6

My only worry about this approach is that we are just making it “harder” for the user to find low quality projects. In our case it’s even worse given that we only have around 200 projects, that’s basically a 5 or 10 mins scroll to see them all. Filtering and putting more effort on searching would make more sense if we had larger amounts of projects.

7

About the trusted seed idea, it’s about verifying the user, not the projects. Whatever a verified user implies in the future, trusted seed accounts should have an instant checkmark

1 Like
8

I have nothing to add, pretty much what I was thinking and more.

If everyone agrees we can begin with the next steps, even making a simpler version to release asap and slowly add everything later. For example we can make this same flow without e-mails at first but being very explicit with the information for the users. Low complexity but big impact for the quality of the dApp.

About quality score I think that discussion will be a bit longer.

1 Like
9

I fully support the unlisted, listed and verified approach proposed by Mateo here.

Appreciating the open-minded alternative from MoeNick, and the rating score is a valiant attempt to make bad projects hard to find but I believe we have a responsibility to our donors and good project owners to have a built in screening process - we can see now what is on the horizon with the token launch and need to have stronger measures in place.

Marko’s recommendations for how to implement really clarify how a project can move from unlisted to listed, and I’m in agreement with the statement that projects listed on Giveth need to be worth donating to - that Giveth is trustworthy.

This also helps with projects that we are “unlisting” … we are just flipping the switch to make all projects start at unlisted and getting listed is a badge, that you can lose and be unlisted if you don’t keep a good rating score.

2 Likes
10

I love this whole discussion, thanks for raising this important issue!

I remember the conversation we had earlier this year about this same topic and the answer was to ‘kick the can down the road’ so it’s no surprise we’re here now having to flesh out a plan for these problems when they have already arrived.

I love the unlisted, listed, verified idea and we’ll have to find a system to reliably and punctually review and change the status of projects. My mind immediately falls to what Giveth TRACE already does with the bridge monitor - someone who’s job it is to check in on new, unlisted projects and decide whether to upgrade them to listed, leave them unlisted or remove them for more serious violations.

@karmaticacid The retroactive quality score update unfortunately has been a loose thread that I have tried many times to make happen but lacking the dev support to pull it off.

I agree that the concept of Quality Score should not be public info, better off for use in our internal decisions. For upgrading the metrics of quality score I think time is a great idea, leveraging a logarithimic function… I also think we will have a lot of community-driven solutions open up with the launch of the GIV economy.

3 Likes
11

Suggestion for
1-6 ‘I feel altruistic/generous’ or ‘Inspire/Surprise me’ (listing x number of random verified projects with no or low sorting stats needing some love)

3 Likes
12

Whilst the Unlisted and Listed terms work for the project owner, I feel a Listed/Unverified status could work also for the user and a CTA for the owner to get it verified.

2 Likes
13

Listed/Unlisted Guide (in progress): HackMD - Collaborative Markdown Knowledge Base

Please feel free to add comments/suggestions

14

Notes from our idea generation meeting:

Livestream of the discussion: Giveth livestream - Giveth.io Resilience on August 25, 2021 - YouTube

The plan is to move forward with creating the listed/unlisted layer on giveth.io next week. Comms team to work on imrpoving the guide, and write notification emails to projects that will remain unlisted (or will get cancelled).

15

Love the action and updates! PRAISE!

I am also a fan of unlisted, listed and verified… it also seems like there may be need for “censored” like the Malicious dappnode campaign…

I’m not happy about it but in the end I think we have to accept that people do stupid stuff on the internet and we can’t host it on our website… SHAME! SHAME!

How strict we are about it should be explicit with a terms of service, and i know Lauren and others are working on it… PRAISE! PRAISE!

Love this thread.

16

BOOM! That’s what we’re moving forward with.

17

And then we also will just censor projects as well right, if they violate the terms of service?

18

I think we must, when censored it should be removed from the public view and notification sent to user email informing them about the violation. Violation email should be a template we create that is sent automatically from server when master admin removes a project.

If there isn’t an issue open for this already then I suggest @MoeNick @mateodaza to create one. Copywriting do be done by someone from Comms team @karmaticacid

1 Like
19

Yeah! We talked about this with comms already… We’ll draft two emails

  • One to explain the project is going to stay unlisted and asking the owner to add info.
  • One to explain the project was cancelled because it violated the terms of conditions.

@MiA and @Danibelle are also working on updating our terms & conditions which will the ground for which we cancel projects.

Comms is also reviewing the listed/unlisted guide for project admins who are going through and doing the manual choosing work.

1 Like
20

Following the implementation of the unlisted/listed system we’ve encountered some discussion over whether the default status of newly created projects should be listed rather than unlisted.

These are some remarks I heard during the DEV call 18/10/2021. Please feel free to add.

  • If we choose to make projects unlisted by default we should add something into the front-end, immediately, that explains this new flow and new statuses.

  • We have a team that will be dedicated to checking projects as they are created, we have tools that will allow us to do this with minimal overhead

  • Project owners shouldn’t be penalized or disempowered until proven to not meet listed criteria

Also we can refer to this github issue for further context - https://github.com/Giveth/giveth-next/issues/303#issuecomment-945132365

I’m re-activating this thread to continue discussion on this particular topic of the default status being listed or unlisted upon project creation. In 1-2 days I will create a poll for soft-consensus and hopefully we can move forward with necessary technical changes resulting thereof.

2 Likes
21

I support: not having unlisted feature at all, however I know we implemented it, so let’s change the default to listed. It’s a natural behavior of an open platform.

And I do not support adding more status there: not reviewed, reviewed and listed, rejected and not listed, rejected but requested to review, reviewed but still unlisted, don’t have time to review so listed, listed from admin dashboard… See?

According to software architecture, we have to limit statuses and add them in standard way to prevent the spaghetti coding. The usual method is adding status with another field : “status reason”, like CRM systems.

Even if we add tags, we may also have further requirements how to change them and maybe someone set a business logic on them someday…

My friends, listing and un-listing is not a matter at all, we only can show 5 -10 projects in our home page, up to 20 in 1st projects page, it can easily be filled with good high score projects. we have to play with sorts and views instead on adding new statuses and operations…