Do you have an idea in mind of what this might look like?
Here’s my thinking:
Pro: Better UI so that Initiatives and Artifacts are less beurocratic and Cred flows are more precise.
Con: If users are split between platforms that can create breaks in UX. A lot of Ethereum communities have this problem where 90% of all engagement happens on web2 platforms, but then they have to leave the experience to use a separate web3 app for voting or payments or something. As a result, they don’t.
Having the entire UX of the SourceCred game all in one place could be great for engagement. Have we already fully exhausted the possibilities of using Discourse for Boosting, Initiatives, and Artifacts?
Agree that we want the whole UX in one place. Let’s consider the different UI pieces we want:
An interface for interactively diving into Cred (how much cred does this Initiative have? Where does that cred come from? Where does it flow to?)
An interface for exploring one’s own Cred and how it’s changed over time
An interface for seeing how much Grain one has and how it’s changed over time
An interface for boosting things (requires that the backend know how much Grain you have, and a way to commit the changes)
An interface for editing and creating artifacts/initiatives
I posit that many of these are basically impossible to build into Discourse. Therefore, as we build out the game, most of the key functionality will be outside of Discourse. Once that happens, since we will want the whole UX in one place, we’ll want to move the initiatives and artifacts out of Discourse and into our dedicated UI.
This will also be easier for beta users, who may not all be using Discourse.
I’m not an expert here, but my initial assumption is that a lot of this could be done via regular checkpoints that are put on IPFS. There would be a server that takes in data from the Discourse/GitHub API, then runs the SourceCred algorithm on it, then creates checkpoints on that data in regular intervals. Then a “Cred Explorer” front-end could be built for end users to find data they want. It would be like a block explorer for a blockchain, but for SourceCred - and instead of data coming from a blockchain it would come from Discourse, GitHub, etc…
The “backend” here could be the “Cred Explorer.” It could track the history of any SourceCred instance over time (in this case SourceCred core) and send compute relevant data. When users boost a Thread, Initiative, or Artifact that data would get fed to the Cred Explorer. Boosting could be accomplished via a special emoji (like this one ) and that could even be made possible as a reaction (like likes, but with other symbols) via the Retort plugin. We can currently edit Initiatives and Artifacts via Discourse wikis and the Initiatives plugin is being made to support that.
Seems like for an MVP we could have a Cred Explorer to run the SourceCred protocol and provide a nice UI to view the graph, but the game itself could be played via channels like GitHub, Discourse, and whatever else we integrate. This way we can focus on designing, testing, and validating the core game mechanics before anything else.
Also might be incorrect here as to what is and is not technically possible, but this is my initial impression.
This is quite similar to how the prototype works, except we use GitHub Pages for hosting rather than IPFS. @wchargin looked into using IPFS back in the day, but the performance and reliability were nowhere near the quality we’d get from using web hosting (e.g. GitHub pages).
Features that Boosting needs:
You need to know your Grain balance
You need to know how much the node has already been boosted (will affect how much of the future cred you get from your boost)
You need to choose how much of your Grain balance you want to “spend” on a boost (50? 100? 1000?)
You need feedback on whether your boost was successful (-> your Grain balance goes down) or if it failed (you didn’t have enough Grain)
I don’t think we can do this without having our own dedicated UI.
Good point. I was thinking that the SourceCred protocol could figure out all that stuff, but since boosting happens via Grain the user would want to specify how much to boost, and before they make that decision they would want to know who else had boosted and how much. They’d also want to see what’s boosted so that they engage with the highest leverage content. That’s not possible currently via Discourse.
So would we have to fork Discourse and create our own version that has Boosting, or would we just have a separate website people go to that lists things that are boosted? If the later, would people then have like a dashboard of their current open boosts that are in play as well as other boosts that they could participate in? Also, the most important part about Boosting is what is being boosted. It’s very important that the experience of boosting is closely tied to the experience of engaging with content. How would we do this if Boosting is siloed in a separate app? Would it maybe be like a browser extension or something that overlays more information onto the core experience?
Forking Discourse and trying to build within it would impose a lot of cost/complexity for the system, and make SourceCred less usable for projects that don’t use Discourse. So we’ll want to build our own UI for it.
The SourceCred UI will include first-class support for Initiatives and Artifacts; those will no longer be canonically represented by Discourse threads. However, we could have @credbot automatically create a Discourse thread for each initiative if we want to have a place to discuss it, if we find that valuable. The SourceCred UI will also import data from GitHub, Discourse, etc; this is necessary so artifacts/initiatives can link to activity there. This also means we’ll be able to search for pull requests, threads, etc, in the SourceCred UI, and boost them there.
We could then build a browser extension for GitHub / Discourse which makes it easy to navigate from a post on GitHub/Discourse directly to the matching node in the SourceCred UI.
Cool. So raw data would get fed from various channels like Discourse, GitHub, Twitter, etc… to the SourceCred server, then that server would process the data according to the SoruceCred protocol and layer on the Cred/Grain boosting, voting, etc… and then a client would display all that data in a UI that has UX optimized for SourceCred gameplay?
) and that could even be made possible as a reaction (like likes, but with other symbols) via the