RFC: Content ratings - #66
LaurensDeV wants to merge 3 commits into
Conversation
|
Hey @LaurensDeV, thanks for pushing this forward! But I’m not sure if the thumbs up and thumbs down is the main mechanism that we should use for this. In the original design, the main signals that I was expecting to use were “n of download, frequency of update” for positive signal, and a report action (that we never fully specified if it was a serious flow or a quick action). if everyone prefers to go with the thumbs up and down, fine for me. But I just wanted to express my opinion that this isn’t something that I would do if it was up to me. |
MrJeranimo
left a comment
MrJeranimo
left a comment
There was a problem hiding this comment.
I'm not sure if I agree with this RFC, but I will not outright reject this RFC as I want to see what the other maintainers want to say.
| The index will list content of varying quality, including abandoned listings, listings broken by a game update, and the occasional deliberate junk entry. | ||
| Nothing in the design so far gives a user any way to tell these apart before installing, and nothing gives index maintainers a way to notice them at all short of someone complaining in Discord. |
There was a problem hiding this comment.
[Info]
There is manual yanking and reviews by the owners of the content, but you are right that the only other way is to complain to the maintainers.
| ``` | ||
|
|
||
| `vote` is `1`, `-1`, or `0` to withdraw. | ||
| `version` is the release the voter had installed at the time, recorded verbatim as the `version` of that release, which RFC 0031 normalizes to SemVer 2.0.0, and is used as described under "Versions" below. |
There was a problem hiding this comment.
[Must Fix]
On line 103 when you talk about the published format, version is not listed there, nor is there any labeled way for storing which version got X amount of votes in that format.
| A random opaque token is generated on first launch and persisted by the client. | ||
| It is not an account, it is not tied to anything, and a user who clears it can vote again. | ||
|
|
||
| This is friction, not authentication, and the RFC states that plainly rather than implying a guarantee it cannot make. | ||
| The mitigations are per-identity deduplication, a rate limit per source address, and ignoring votes from tokens first seen less than 48 hours ago. | ||
|
|
||
| For this to be a privacy-respecting design rather than a tracking one, the token must not be sent anywhere except the vote endpoint, and the aggregate job must not retain source addresses beyond the rate-limiting window. |
There was a problem hiding this comment.
[Personal Opinion]
I am not sure if I agree with this idea. As you say, it doesn't fully prevent spamming or vote manipulation, just delays it/makes it annoying. Personally I feel that since the main two ideas behind why we should have the voter system are
- Have some form of content control (mainly due to bad content and deprecation)
- Know what content is good.
For the Good Content we already have some stuff implemented and planed,
- Download count: This is just attention and may not always work, but usually attention = good/useful.
- Instance sharing: This is essentially just a Mod Pack. want to share your instance, make it a mod pack and all the Mods, Vehicles, and Saves, will be shared with the user. Everything else isn't needed. This can be a great way for people to find content they like.
- Social Media: If KSA gets big enough, social media will probably handle sharing info on what content is good. Also not the best as it is usually attention based, but at least it is less for us to maintain.
For the content control side a built in reporting system might be better,
- We can have authentication, the reporting can be done through GitHub or some other platform, which may prevent spam.
- It gives the users an area to write what is wrong.
- We don't have to store and upkeep the data.
I know there are drawbacks to the reporting system like manual moderation, but the same would happen with the rating system (manually seeing why content is downvoted so much) and we already planned to have some form of reporting.
Ratings now follow the RFC 0052 pattern: the indexer copies the endpoint's public aggregate into ratings.json in the generated repository, and the snapshot attaches it as an optional rating field, so clients keep the one-fetch contract of RFC 0033. Ids and version ordering cite RFC 0031, per-game-version ratings cite RFC 0017, download counts cite RFC 0052, and the RFC 0025 section answers the places the non-goal was already applied and cites RFC 0048 as the precedent for amending without superseding. The reference implementation moves from Workers KV, whose free plan allows 1,000 writes a day to different keys, to D1.
a0147dd to
dba1d8d
Compare
3 participants
What
An RFC for a thumbs up / thumbs down rating per listing.
A small write endpoint collects votes and aggregates them, the indexer copies the public aggregate into
ratings.jsonin the generated repository, and the snapshot attaches it as an optionalratingfield with a rounded score and a vote count bucket, the way RFC 0052 handles download counts.Ratings fail open and never affect installing, dependency resolution or any other automated decision.
It came up in Discord, and there is no Pre-RFC thread for it.
RFC checklist
rfc:field in the front matterDECISIONS.mdupdated,status: Accepted, and any superseded RFC markedNotes for reviewers
The real decision is the RFC 0025 non-goal.
A write endpoint is a service somebody has to keep running, so this RFC proposes narrowing that non-goal to "anything whose failure degrades installing, updating, or resolving dependencies".
If the stewards would rather keep the non-goal absolute, the RFC says it should be rejected, not implemented in a weaker form.
Feedback wanted on: the narrowing itself, and whether it needs a
supersedesentry or only aDECISIONS.mdrow; a random client token as the voter identity; and the requirement that the endpoint runs on an org-owned account with at least two people holding credentials.