This document is still mostly accurate, but mildly outdated in some particulars:
- SourceCred now has “timeline cred”, which shows how much cred each individual earned every week, rather than a single lifetime score. Much better for doing things like ongoing payments (of cash or tokens). You can read a bit more about it in the Timeline Cred announcement post and in this thread about attacks / cred farming.
- Timeline cred has a new UI, which doesn’t (yet) support recursively exploring where a node’s cred came from. However, there is still a ‘legacy’ mode that shows the UI depicted
- Node weights can be set manually for individual nodes, not just on type
- The way that node weights work has changed, so they now affect how much cred “resets” to the node with high weights, rather than tweaking how cred flows from adjacent nodes.
The SourceCred implementation is a JS-based program that anyone can run. In principle, you could write an implementation that runs on a blockchain; however, this would have two problems. First, calculating cred is both compute and data intensive, and I don’t know of any blockchains that scale well enough to support calculating cred on-chain. Second, much of the data “lives” off chain (e.g. GitHub history), so at the moment there is no way to avoid having an oracle.
However, SourceCred is decentralized in that anyone can run an instance on a project, and using the same config, they should get the same results. So a project could appoint a set of semi-trusted validators to run cred off-chain and then report the results on-chain, and it would be easy for everyone in the community to check that the work is being done faithfully.
Let me know if that doesn’t answer your question.