Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Create a node for each Discourse like #1587
Let's use the syntax
In the past, for every like, we would create the following graph
As of this commit, we instead create:
We make this change because we want to mint cred for likes. Arguably,
Create a node for each like is a somewhat hacky way to do it--in
Obviously, this is not robust to Sibyll attacks. If we decide to adopt
If we merge this, we should simultaneously explicitly set the weight to
I'm not sure this:
And doing a node contraction instead to be sure they are equivalent seems like needless extra work.
So I would have a strong preference for bringing the community consensus forward. Discussing the proposed changes before merging. Perhaps including a prototype to show the new behavior with example weights.
Beanow left a comment
Gave this some thought.
Suppose we increase the like edge weights instead to make likes more important. The main difference I can think of is, it matters a lot who gave you a like. It's better to be liked by a "Cred whale" than someone fairly new. This could be the sibyll proofing we need, because existing cred works as the filtering logic here. But the linear scaling might make it biased in comparison towards circlejerking and favoring the whales.
Perhaps this "heuristic which increases the cred weight of a post" should be like quadratic voting.
Given that we're interested in allowing plugins to set weights with their own logic (WeightedGraph).
That said. I think it may be worth having a discussion about temporary solutions for experimentation.
For those that need a refresher on Sybil Attacks.
I'd want to ask what is the current standard for the entities that make up nodes. Intuitively it would be (somewhat) tangible things like people, topics, pull requests, etc. Adding a like as a full fledged entity first makes me think about how this fits into a long term graph. If we think of many different kinds of reactions to posts, there are many different ones, and so representing just a "like" doesn't do the future landscape of reactions full justice. An alternative could be to have a "reaction" node that then has an attribute to describe the kind (does the graph support nodes with attributes?).
My gut reaction is that it would be more appropriate to adjust the weight on the link, or some attribute that determines the weight of the link. The links are relationships, the nodes are entities, and to model a relationship as a node seems off.
Don't know how much sense this makes for SC nodes, but here's a way of thinking about it from DDD.
Entities are not defined by their attributes.
Value objects are defined by their attributes.
The commit may be in a grey area, but all other nodes so far are entities.
I would argue a like is a value object.
If you change the source or destination.
Source: - Beanow likes Post-123 + Dandelion likes Post-123 Destination: - Beanow likes Post-123 + Beanow likes Post-555
It's not the same like.
This is a good point. If we set the node weight of the like nodes to
Yeah, it definitely is a temporary solution. It's actually motivated less by SC's own use case than by something we saw on another project's Discourse instance. Basically, there was a user who had made a very large number of relatively low-effort (and low-like) posts, and was receiving a disproportionate share of the cred, while other higher-signal users had low cred. On a hunch, I explored the forum data, and found that the higher signal posters had fewer posts, but far more likes received.
This gave me the idea that we could mint cred based on likes (which represent implicit review of activity) rather than on raw activity. Since we're in active dialogue with that other project, I wanted to prototype something super quickly to show them. The feedback from that project was that this version seems better than the original.
I sent a PR for this branch mostly to prompt discussion -- I don't feel it's super important that it merges in it's current form, esp. since we are pretty close (via WeightedGraph) to being able to implement it much more cleanly.
I've done an analysis of the new behavior. I'm going to post it on Discourse instead of here, so that everyone in the community can take a look and chime in.
I would go with a minimalist description of a node, and say: "a node is anything which should accumulate cred". (One will note that this is somewhat subjective, which is fine.) I think it's clear that contributors, pull requests, etc, should accumulate cred. Likes probably should not. So I agree that likes should not be nodes.
On the GitHub side, we have distinct edge types for each positive reaction (we ignore the
Not really. You can see the types here:
Update: I've posted an analysis of how this changes the Discourse cred here: https://discourse.sourcecred.io/t/minting-discourse-cred-on-likes-not-posts/603
I've come to believe we should merge this change as-is. By having likes and posts be separate nodes (which both mint cred), we can express cred minting formulae like
If we don't make likes correspond to nodes, we could still set custom weights on each post based on the number of likes... but we're constrained to expressing things like
Because for any individual post, right now we can mint it
However, without this change, then the minted cred would be
Feel free to ask questions if this is unclear; hopefully as we start to document the algorithm more cleanly it will be easier to communicate this.
As for why this makes sense conceptually: it basically means that Likes are contributions. It's counter-intuitive, but it makes sense if you think about it. People are doing some work by reading posts, and expressing which posts they found valuable. That information is itself valuable (which is why we are consuming it in the algorithm). Right now the amount of cred we mint per like is definitely in excess of the like's intrinsic value, which is a (temporary, acceptable) hack since we're still in an alpha state.
(thanks to an offline convo with @wchargin)
wchargin left a comment
@decentralion and I discussed this a bit, and we actually think that
Note: If we were using semver to signify cred-changing changes, we would need to bump version numbers here. We're not doing that right now, but it's interesting to think about.
(Even if the client set the weights on likes to an explicit 0, this would still be a breaking change, due to the alpha decay matter brought up by @Beanow.)
Beanow left a comment
Based on https://discourse.sourcecred.io/t/minting-discourse-cred-on-likes-not-posts/603
*Let's use the syntax `(node)` to represent some node, and `> edge >` to represent some edge.* In the past, for every like, we would create the following graph structure: `(user) > likes > (post)` As of this commit, we instead create: `(user) > createsLike > (like) > likes > (post)` We make this change because we want to mint cred for likes. Arguably, this is more robust than minting cred for activity: something being liked signals that at least one person in the community found a post valuable, so you can think of moving cred minting away from raw activity and towards likes as a sort of implicit "cred review". Create a node for each like is a somewhat hacky way to do it--in principle, we should have a heuristic which increases the cred weight of a post based on the number of likes it has received--but it is expedient so we can prototype this quickly. Obviously, this is not robust to Sibyll attacks. If we decide to adopt this, in the medium term we can add some filtering logic so that e.g. a user must be whitelisted for their likes to mint cred. (And, in a nice recursive step, the whitelist can be auto-generated from the last week's cred scores, so that e.g. every user with at least 50 cred can mint more cred.) I think it's OK to put in a Sibyll-vulnerable mechanism here because SourceCred is still being designed for high trust-level communities, and the existing system of minting cred for raw activity is also vulnerable to Sibyll and spam attacks. Test plan: Unit tests updated; also @s-ben can report back on whether this is useful to him in demo-ing SourceCred [on MakerDAO]. If we merge this, we should simultaneously explicitly set the weight to like nodes to 0 in our cred instance, so that we can separate merging this feature from actually changing our own cred (which should go through a separate review). : https://forum.makerdao.com/t/possible-data-source-for-determining-compensation