How To Curate DApps Simply

Browser
1

The Problem

We need a way (many ways, actually) of curating the list of DApps displayed in Status now that we’re on mainnet. Currently, we curate these manually based on which ones actually work well on mobile, but this is not a long-term, nor scalable, solution.

A Proposed Solution - Version 0.0.1

At first, we use a simple game involving a bonded curve: rank is based purely on which DApp has staked the most SNT, but the more SNT staked, the cheaper it is for the community to create “downvotes” which decrease the DApp’s ranking.

This is an elegant game-theoretic solution with an incredibly simple UI.

Features

  1. DApps/developers pay to rank. This is no different than current SEO practices, except developers know exactly the algorithm used and what is required to rank highly. Importantly, they are not paying a company: they are staking SNT in a registry. They do not need to trust Google, PageRank, FB etc. AND they stand the chance to earn ~60% of what they staked back if users vote on their ranking.
  2. Users pay to vote, a fee which goes directly back to the DApp they are voting on. This means there is no explicit incentive for users, and it actually costs them to participate. Far from an error, this is key to the design of the whole system.

Listen to Alice

I don’t want to have to think about which links appear first in my searches. I certainly don’t want to have to manage many different tokens with different governance rights and requirements just so that I can “trust” the content I’m looking at.

All I want is to know that the links which appear first are relevant to me, I want to be able to see easily how that “relevance” was calculated, and I want to be able to tweak things, but only when I feel really strongly about it. #DeleteFacebook.

Importantly, DApps that rank highly ought to be providing the most value to the community as a whole.

Designing for Reality

Participation in any structure that requires votes and multiple stages, be it a DAO or a TCR, is always low. This is not just because of poor interfaces and unstable technology, it is because getting people to track votes and tokens actively is almost always a bridge too far. So, let’s design with that in mind.

There is no incentive for users to participate precisely because - even with “incentives” in other schemes - they have not been doing so. However, users still benefit as a side-effect of the system: the more SNT is locked up in the DAppStore, the less there is in circulation and the more valuable the SNT any given user is holding.

In this way, even without assuming any user participation, we achieve the key design goal of the system-as-a-whole without requiring any central authority whatsoever: DApps which rank highly contribute - literally - the most value to the community.

Some Scenarios

1. I build a really bad/hurtful/illegal app and stake a lot of SNT to rank highly. What then? If I receive back the SNT it costs the community to downvote me (supposing they’re even willing to do so), then I can just keep doing this endlessly.

a. Remember, due to the setup of the curve, you only receive back ~60% of what you staked. So, it’ll cost you signficantly to keep that up over long periods of time.
b. Also, there is contractual reality and the Status UI. The two do not need to be completely bound. If there is a DApp violating App or Play Store policies - for instance - we may need to remove it from the UI. Anyone else is still more than welcome to implement another UI with different rules for the same contract.
c. There is another (free) option when downvoting for users to report DApps to Status that they think should not be in the UI.

2. I am well-resourced actor who wants to ensure an upstart young DApp never ranks as highly as my own product. I’m just gonna downvote them out the registry.

a. Remember, again, that the cost to do this goes back to that developer. Though they only receive ~60% back, it’s going to take some time to achieve your goals - time in which the community can organise.
b. It may even be more optimal from your perspective just to stake that SNT to your own DApp, though this is complicated by the fact that doing this results in it being cheaper for the community in general to downvote you. Even this simple game has a complex, emergent, multi-sided market nature i.t.o. the cryptoeconomics.
c. Either way, any corporate bidding war, trolling, or other kind of underhanded tactic only ever has the net result of more SNT entering the DAppStore, which is still benefitting the community as a whole.
d. Radical Markets can be tough environments - we just need make sure that inevitable competition ends up benefitting people, rather than putting them at an even greater disadvantage.

3. I am a poor DApp developer who is really excited by the idea of permissionless participation. Now you’re telling me I have to pay another fee? That’s BS!

a. Yes, I know. This is what programs like Incubate and “Optimised for Status” (when we create that) are intended for. Remember that the “fee” you’re paying doesn’t go to Status, and that you can earn a lot of it back by building an engaged community that cares enough to donate to or vote on your product (oh yeah, this system also has the nice side-effect of being a sort of Patreon for DApps).
b. Also, free markets are the most efficient means we have ever discovered of optimising allocative efficiency. Though it can seem callous, this really is the best way I could think of to organise the system long-term.

Show Me the UI

Barebones UI
Barebones UI1226×1042 161 KB

Obviously, this is very bare-bones. We’d probably need at least one other intermediate screen to explain a little, at least when a user first votes. However, it does illustrate how simple we can make Version 0.0.1.

No tracking different tokens in your wallet and wondering when on-chain transactions are required. No reviews, or governance needs, or anything “extra” for you to do. Yet you can easily see why each DApp ranks where they do, and can influence that should you really want to.

Also note the tab with Status Store, Trending, and Discover at the top of the first screen. This simple game with staked SNT does not answer the “relevant to me” part of Alice’s complaint very well, but there are other solutions to this: discovery and network topolgy-based solutions to find popular/relevant/trending topics, and various approaches being experimented with at StateOfTheDApps, OpenSea or Dappist etc. We could have separate tabs/filters for them as they are implemented and then allow users to curate their own searches by setting the filters to what they think - at a glance - is the most interesting to them.

The Mechanism - Simply

  1. A DApp stakes SNT to rank.
  2. Votes are minted based on how much is staked, using an exponential curve.
  3. The cost to vote = total cost / number votes available. Less votes available = higher cost.
  4. The cost to vote, paid by the user, is sent directly back to DApp when voting occurs (if ever).
  5. The trick is here: total cost == amountAvailable of the SNT that DApp staked when the DApp’s effectiveBalance (what it is ranked by in the UI) == 0 as a DApp must earn back the amountAvailable from what they staked by the time they have been voted down to 0.
  6. A DApp’s effectiveBalance = totalStaked - (number negative votes * (rate * (amountAvailable / number votes available))).
  7. amountAvailable = 62.5% because I set the amountAvailable = 1 / exponent and then played with the numbers until they seemed optimal (there is a bounty for this too, though).

Other Links

  1. Tech Talk
  2. GitHub Repo
  3. Previous Discuss post
4 Likes
2

Short of a formal proof if you were to use an optimization library like Optimization and root finding (scipy.optimize) — SciPy v1.11.3 Manual to find some global optimum, what are the conditions that would tell us we found the optimal or improved parameters?

3

I’m not familiar with the library, unfortunately. The problem with a formal proof is that there is the arbitrary bound of contractual reality vs the Status UI, which is not quantifiable.

My sense, however, is that we can still optimise by looking at the totalStaked in SNT as a percentage of the Total SNT in circulation (~3.4B) and use that as a means of figuring out after what % votes should be essentially ‘free’. After say, 3% of the total in circulation is staked by one DApp, we can be sure it is a well-resourced actor, and it should be really easy for the community to influence their position.

So, we use a specific exponential curve to produce “votes”. Then, we set the amountAvailable for staking == 1 / exponent of the curve, and we try to figure out what curve we should use to achieve the above condition of % staked after which it is pretty much free to vote.

4

I wanna try a demo!

Something with simulated SNT perhaps, as well as attack guides w/ advice about how to spend your money to get in what place with what conditions.

ie: stake x on yourself for position y with precarity z, or spend x% of your budget on staking, y% on downvoting your opponents and z% on upvoting yourself.

bounty that ish

5

How much would you need on a bounty to buidl that demo @okwme? Tell me and I will make it happen :wink:

1 Like
6

To my mind a great first step would be to decentralize inclusion/exclusion, without introducing ranking mechanisms (although SNT utility is stronger in such a model).

Is there a simpler version where…

  • DApp developers stake some amount of SNT to be listed
  • Status establishes some guidelines as to what is not allowed (to accommodate App Store policies)
  • Other DApp developers approve/challenge DApps based on these guidelines
  • DApps that don’t comply are delisted or rejected?

This does less to mitigate problem #3, but perhaps there are other incentives Status can offer approved DApps.

Apart from low overall participation, two of the key takeaways from AdChain’s mainnet TCR launch was that participants lacked the desired background experience to make informed decisions about publishers. They also failed to take initiative in defining standards for voting publishers in or out.

So it seems that establishing guidelines is necessary to grease the wheels.

It’s also a very relevant point that rankings wouldn’t be personalized to an individual level. Subjective, economically motivated rankings sounds like a recipe for irrelevance. I’d advocate for a less complex MVP that aims solely to decentralize ownership of the list.

The more actions a user can take in a system built on unfamiliar concepts, the harder it will be to learn and use.

I think any option should also go through UXR testing early on.

As a baby, baby step toward DApp decentralization, I will re-write the Submit your DApp to Status docs this week to move back to a PR model, so that developers can get listed without depending on us to do anything but approve their PR.

7

  1. Thank you for re-writing the docs and changing the flow, I agree that is necessary.

  2. There is no simpler model than this: find me one and we can implement it.

  3. I think having Status set up any kind of “guidelines” (beyond technical ones to do with what simply doesn’t work on mobile) is the exact opposite of what we’re trying to achieve. The key takeaways you list are exactly what led me to simplify massively in the proposal above. Everyone knows how to “upvote” and “downvote”, this is not an unfamiliar concept at all, it’s just that the exact mechanics are a little more involved than on Reddit etc, for which we have that intermediate screen.

  4. I agree that UXR testing is very much required.

  5. To reiterate, we will have to create some guidelines on what sorts of things could get banned from the UI (likely just whatever would get us pulled from the stores while we still require them). However, requiring people to “vote based on those guidelines” is how to do cryptoeconomics wrong 101: it’s not about what “policy” you put in place, it’s about the underlying incentives of your system.

For some further context, the ENS contracts we use has 776 lines of code and the voting contract is 319 lines of code, both with many supporting contracts. This proposal will end up being just 1 contract with around 100 lines of code… Why is it more complicated, and why do we shy away from smart contracts in favour of our “own guidelines”? Guidelines are not decentralized, they’re not scalable, and I have no idea how we would “enforce” them, if at all. It would, in other words, actually end up being far more complicated.

8

Guidelines or no guidelines is a detail relevant specifically to a context in which DApps are simply being voted in or out of the list. In that scenario, there would be no upvoting/downvoting.

9

I’m sorry if I came across as short earlier @rachel - was not the intention - have edited the above for a clearer response.

The other problem with having any kind of guidelines on how to vote (i.e. anything that is not strictly objective like store guidelines) is that you then have to somehow incentivise Dapps or developers or whoever you want voting to actually take part. This is always a mess, both from a game-theoretic and UI perspective, which is one of the reasons why I really think this is the simplest possible solution.

10

No stress.

I don’t present that as a fully baked concept, and haven’t given it nearly enough thought.

Just wanted to advocate for reducing complexity wherever possible and breaking this ultimate vision into smaller steps.

11

I have no ultimate vision.
I’m just a random walker.

:heart:

1 Like
12

As an overview and assuming the mechanics you suggest work as expected I believe it to be a very noble game to crowd-source a curated list.

Regarding the mechanics, how do you deal with Sybil attacks? What disincentivizes a developer to pay users (through external channels) for upvoting her dapp? And the opposite. What if she pays users to down-vote dapp competitors? Wouldn’t a wealthy enough attacker always win the game?

My main train of thought, was regarding if these mechanics would be enough for a decentralized dapp store, sorry if I’m going far beyond the initial intentions of the original post… ^^"

It seems an elegant solution to curate a list ranked by a single attribute, but this is not enough to provide Alice with the ultimate list for what she’s looking for.

What the mechanism is doing is to create a global list sorted by a metric about how the participant users in the store think the dapp matches their initial expectations.

This is a highly valuable metric that Alice could use to calculate the dapp relevance based on her perspective. But probably should be treated just like another one.

We could easily include other metrics such as if is trending, categories, text matching score. We can even replicate the suggested mechanism to allow users to rate other metrics that require consensus. I believe the key element here is that Alice ultimately has the option to change the relevance equation to full-fill her needs.

As a side note, and undestanding that we’re still far from it… what I would really love to have is a way to use my own subjective metrics. The most important one being the score I give to other players regarding a specific subject. If we could include these metrics into the equation we could filter-in/out the view of those players.
That way, we may not even need incentive mechanisms, I could see the list based on the views of the people I trust, whatever is by whitelisting them, or by blacklisting others, and Sybil attacks become pretty much irrelevant.

1 Like
13

Thanks for the feedback @xavivives! Yeah, Sybil attacks pose a problem and Dark DAOs or very well-resourced actors do seem to win this game if they’re malicious enough. There are some ways to protect against this, but none that are very elegant imo. Rate-limiting votes from the Status UI is one (it would make it easier to see manipulative votes); or completely decoupling upvotes from the calculations so that they’re a fixed price and only serve as donations/protection are two possibilities.

@jarradhope and @ricardo3 both think quite differently about this problem, though. We incur possible censorship vulnerabilities in a system like this and discovery, in general, seems to be a better way of handling curation/search:

"In legacy social networks, ranking of information is typically done by the platform owner, often with the intent of driving up profits. In this model, content discovery algorithms are opaque, prone to censorship, monopolistic in nature, and possess high switching costs should users of the network become dissatisfied with the quality of content discovery.

Within the Status Network, stakeholders will be able to opt-in to curate the content that is displayed by producing signatures on events (i.e. by upvoting or downvoting content or ideas), referred to as signals, in which the stakeholders’ token backing is weighted in ranking.

The aggregate signals generated from stakeholders form an open graph that content rankers can use. Should a stakeholder be dissatisfied with the content ranking by their current provider, they can choose between a market of search algorithm providers, keeping algorithm providers honest and removing the monopoly web 2.0 solutions have on the way we consume information.

SNT Utility

SNT is required to opt-in for curation mechanisms.

Example use-cases

  • Stakeholder A, an early adopter, has moderate stake in the network, and has an economic incentive to see the content ranking remain high, and opts in for Community Curation.
  • Stakeholder B, a data scientist, believes he can improve upon a content algorithm and thus the value of the network, so purchases a larger stake in the Network and submits a new algorithm."
1 Like
14

It seems like in terms of freedom, anyone should be able to list any dapp, no? After all, this isn’t the Status dapp store, it’s the world’s dapp store, being filtered through a blue window.

The opinion of the blue window should probably be dictated by the community surrounding it. It seems like anyone should be able to submit any dapp but every community could do its own filtering based on its own rules.

Status’s rules might be based on the core principles. Since you presumably signed them, and as a result have a stake in upholding them, you could have a 10 point checklist that you rate dapps on how well they fulfill each core value. The dapps that score highest rise to the top based on some set of “values” some community has for what they want in dapps.

15

I am developing a smart contract that does this, and this is also interesting for Sticker Market packs, which now the first registered will be the first loaded.

CurationMarket.sol

For now is very simple, and I didnt gone further yet because i still unsure on the best and correct way to implement the exact requirements.

  • the cost of down-voting is 60% of points decreased
  • the cost of down-voting goes all to author
  • the points slashed goes all to “burn address” (SNTPlaceHolder(SNT.controller())
  • the cost of increasing is 100%
  • the cost of increased is kept locked in the smart contract.

This will be improved, this sketch will help to understand the basic behavior, as next step would be to use bonded curves in the decrease cost, if possible on-the-fly (as a function of current balance and the down votes).

It aggregates the ranking and keep the tokens locked, which can be easily migrated to a completely new contract.

Ranking.sol

The ranking is a linked list, that can only be read from “top” to bottom. So the high ranked entries are benefited from being processed first, which makes the pagination of UI a lot more efficient.

the increase and decrease functions require user providin “oldPrevious” and “newPrevious”, which would be calculated by UI, being that the old link (in old points) and the new link (with changed points). If the value is exactly the same, then they are ranked by timestamp, being registered first would be first.

This is not exactly a normal linked list, because:

  1. It don’t track tail
  2. cannot resolve backwards
  3. its ordered based on element data

The importance of a linked list is:

  • Arrays are not flexible to reordering
  • Unordered arrays needs to be loaded first (almost) all to be able to render whats the first position.