High Level Goals and Requirements

[chances]

(Copied from the README)

The Citybound Modstore

A webapp to discover, rate and publish mods for Citybound.

Goals

• CRUD for Mods
  • Augmented: Submit, publish, unpublish, update, and delete mods
• Browse Mods
• Mod API
• User Management
• Moderation/Curation of Mods
• Security

Others TBD?

Tooling

• Backend
  • node.js? Express?
  • DB? (See citybound/modstore#3)
• Frontend:
  • React?

Functional Requirements

CRUD for Mods

CRUD operations performed by users to submit, publish, unpublish, update, and delete mods.

• Only authenticated users may submit mods
• Mod data and metadata

Questions

• What is mod data and metadata? (See citybound/modstore#3)
• How are mods submitted?
• How are mods updated?
• What kind of version management should the modstore maintain, if at all?
• Should mods be able to be deleted on a whim?

Browse Mods

• Search for mods by:
  • Name
  • Keywords
  • Author/Creator (Contributors?)
  • Popularity
  • Date
  • Etc?
• Discover mods curated by moderators
• Rate mods

Questions

• What kind of rating system should be maintained? (See citybound/modstore#3)

Mod API

An interface to the modstore's Browsing features.

Questions

• How much of the modstore's features will the Game Client make use of?
  • Limited to simply Search, Update, and Install?

User Management

• Registration
• Login/Logout
• Change password/password reset
• Profile?
  • Gravatar photo?
  • Biography?
  • Location?
  • Age?

Questions

• Login integrations with popular services like Google, Facebook, GitHub, etc?

Moderation

• Manual review of submitted mods?
• Curate individual and lists of mods
• Promote featured mods
• Manage and respond to report of abuse and policy violations

Questions

• Different roles for moderators? (e.g Editor/Curator vs. Maintainer/Abuse Mitigation)
• What are the modstore's policies?
  • Terms of Service?
  • Abuse Resolution Policy?

Security

• Mod archive checksums?
• TLS/HTTPS
• Follow OWASP Recommendations

Questions

• Assuming malicious intent, what content should be allowed?

Others TBD

Nonfunctional Requirements

• Reliable availability/uptime
• Terms of Service?
• Privacy Policy?
• Cookie Policy?
• Abuse/Conflict Policy?

Others TBD

Questions

• What are the main goals of the Modstore?
• What kinds of guarantees does the Modstore make for its clients?
• How should the the name be stylized? modstore, Modstore, or ModStore?
• Is the name final? (Should we spawn a new issue?)
• How will the webapp be required to scale?
• Other requirements?

[chances]

@n1313 In response to your citybound/modstore#3 comment:

I've added your suggestions in draft form to the list of goals and requirements.

The game client should ... not attempt to display any potentially dangerous media such as screenshots, HTML markup and so on.

How can screenshots be dangerous?

I agree with the crux of your statement regarding data integrity. However, safe mechanisms exist for displaying rich text even with HTML. We could keep a restrictive white list of tags or even only allow a subset of the Markdown spec, for example.

The modstore should only do basic validation of archives (for file corruption?). No compatibility or security checks are to be made, since this is a responsibility of the game client itself.

I think it might be a good and reasonable idea for the modstore to maintain checksums of mod archives that the game client can then validate after it has transferred a mod to a client. This could help protect against man-in-the-middle attacks. To further enhance security, the modstore should be delivered over TLS/https.

The modstore should store old versions of the mods along the most recent versions, as long as there is a published dependent of that particular version, or until the mod author decides to delete it.

Ooh, I smell creeping dependency hell...

There's another question: Should the modstore keep copies of all applicable versions? Should the modstore do all this bookkeeping to keep track of the interconnected graph of mods?

[chances]

Another interesting question:

Should mods be able to be deleted on a whim?

We don't want our own leftpad incident. 😜 What kind of retainment policy will the modstore have? (This leads to bigger Terms of Service, Privacy Policy, and whatnot balls of wax...)

[n1313]

How can screenshots be dangerous?

The modstore consumers will be 1. people on modern browsers, which are fast, secure, and are maintained by dedicated teams of professionals, and 2. the Citybound game client, abilities of which in the context of displaying arbitrary content from the internet are... unclear at the moment.

The game will be talking to the modstore and displaying mod info, right? I think it would be better to limit its potential exposure surface right from the start. I don't know how good the standard library in Rust is, and if there is a good library to render HTML and images and stuff. Rendering plain text is simple(-ish? Non-ASCII? Right-to-left? Emojis? Zalgo?) and it is unlikely that a malicious modmaker will be able to do bad things using just plain text. JPEGs on the other hand are difficult, and I think Anselm and contributors would rather focus on game features, rather than worrying about displaying JPEGs securely.

When it comes to the web-facing part of the modstore, then yes, it should be much less restrictive.

[n1313]

As for dependencies and versions, it's going to be difficult anyway. My (somewhat limited) experience with game mods shows that games tend to break mods with every release, and that mods that are hosted on Dropbox eventually disappear. So what I would like to have is a system that allows me to play my favorite mod even if it is old and is not updated to the most recent version of the game. It should not be a problem if this mod depends on certain versions of other mods (which may or may have a more recent versions themselves). And I don't see a way to achieve this goal without storing old versions of mods (in the modstore) if they have dependents.