Community Mod Repository and The Majiir Challenge

[Greys]

You both make good points. Version indication and notification seems to be an important differentiating feature. Without even that, the site is just a file repository. With it, the site can resolve an often-requested community wish list item.

I've argued before that the current inoperable state of spaceport and how it has failed to effect us at all prove that we do not need a repository at all, and that remains true. However, none of this is about need.

I think that's a really great thing; we do not need spaceport, we do not need spaceport 2, we do not need replaceport. We want to have a neat and useful service for easily hosting mods that is conducive to people finding both new mods they may enjoy and the specific mods they know they want. We want, therefore we do. And we do whatever we want and everybody has been invited to take a crack at it and I really have no investment in who wins. If I'm happy with one of them, I will use it; if I'm not happy with the winner, I have four release threads, dropbox, mediafire, my github repos. I'm not wildly successful, Replaceport won't change that, and I'm totally content. I want to see something cool happen.

So we've had seven pages of ideas, normal bickering, and the obligatory anger vent phase, which went swimmingly. Maybe it's time to get technical?

Majiir, what is the software environment you are prepared to offer, languages you'd like to see used, you keep saying things about Node with a capital N and I don't know what that is. I believe you said that you can run anything free but I'm sure you have opinions, positive and negative.

[Majiir]

Majiir, what is the software environment you are prepared to offer, languages you'd like to see used, you keep saying things about Node with a capital N and I don't know what that is. I believe you said that you can run anything free but I'm sure you have opinions, positive and negative.

I do have opinions. Remember, that's what these are. If you disagree, great: build an awesome site to prove me wrong. While most of this is negotiable, it's probably easier for everyone if the technologies used are ones the host likes.

• As I wrote in the OP: Linux, please. It's free and can be more conservative with system resources. It also greatly simplifies deployment, setup and maintenance if all VMs run the same OS. All new VMs on my server get CentOS 6, and there's one currently on CentOS 5. This will be hard to negotiate; if your website is so tightly connected to a particular operating system, it's probably not a very good website.
  
• I like nginx. Other high-performance web servers can be considered, but I don't think there's yet a performance concern that justifies another choice. I will have objections to Apache, again based on experience. Note: For server platforms like Node.js that include HTTP servers, I'll still ask that a proxy server like nginx sit in front. This is to make configuration easier down the road, to avoid running the server as root, et cetera.
  
• I have a lot of experience with PHP, and accordingly I am not a fan. It's slow, it's constantly playing catch-up on technology support (radical things like "unicode") and it's a pain to get anything done without slotting your code into a framework with dozens of files that you'll need to tweak because configuration isn't flexible enough. There are many developers with some PHP experience, but there's a dearth of real talent. If someone builds a really excellent PHP-based site, I can roll with it, but I'll certainly be looking out for something else.
  
• I have vague philosophical and practical objections to Ruby and, to a lesser extent, Python. (That probably means Rails and Django in the context of this discussion.) This is a step up from PHP, but I'll roll my eyes a lot and take the time to refine my arguments against.
  
• C# is great! We love C# in the KSP modding community, right? Thing is, something like ASP MVC is really quite heavyweight, and it's probably overkill for a simple site like this. Setup and configuration will be substantially more complex. I could be convinced, but prepare for a very raised eyebrow.
  
• I like Node.js. This is weird, since Javascript is a highly dynamic language, and that's not usually my style. However, having spent some time developing with Node.js, I've come to really appreciate the ecosystem that's grown around the platform. Building a high-performance, data-oriented web service with Node.js is really easy. This opinion is controversial to some, and I am prepared to defend it. (In #kspmodders, please, not here.)
  
• MySQL is alright. I think it shines in more complex applications where data needs to be highly structured. For this site, I think we could benefit from the relative simplicity and easier-to-obtain performance of a NoSQL database. MongoDB is a good go-to choice, and there are plenty of other good options.

Here's an example site architecture (overly simplified) using the bolded technologies:

In this setup, nginx handles all HTTP requests. Static content like images and file downloads are served directly by nginx. Requests for dynamic content are proxied to Node.js. To track download statistics, nginx writes access logs for Node.js to parse. User file uploads are processed by Node.js and written to the filesystem to be served by nginx.

I stress that this is just an example. Alternative suggestions are encouraged.

[psyper]

[*]I have a lot of experience with PHP, and accordingly I am not a fan. It's slow, it's constantly playing catch-up on technology support (radical things like "unicode") and it's a pain to get anything done without slotting your code into a framework with dozens of files that you'll need to tweak because configuration isn't flexible enough. There are many developers with some PHP experience, but there's a dearth of real talent. If someone builds a really excellent PHP-based site, I can roll with it, but I'll certainly be looking out for something else.

[*]MySQL is alright. I think it shines in more complex applications where data needs to be highly structured. For this site, I think we could benefit from the relative simplicity and easier-to-obtain performance of a NoSQL database. MongoDB is a good go-to choice, and there are plenty of other good options.

I stress that this is just an example. Alternative suggestions are encouraged.

ah. I'm one of those 'with some PHP experience, but a dearth of real talent' lol. I also tie it in with mysql. I can create the site using these but I don't want to go through all the work and for my site to suddenly be ditched in favour of someone elses - I will try and fulfil everyones desires from this thread as much as possible - theres a few ideas running in my head as a result of these and every step of the way I would request input from everyone on this thread. I think you're right Majiir from your response to Spaceport2 - I think Squad should just concentrate on making an awesome game that much more better - they have enough on their plate and should just let spaceport and spaceport2 die - we are the modders we know what we want in a mod repository - lets start building this thing. I have my own server with unlimited space and bandwidth but I'm not 100% sure what unlimited means in this context (I've been screwed over before with my ISP saying they have unlimited bandwidth then throttle my account when I stream too much - this was before they had to put their 'fair usage' terms in the small print).

I'll make it if you guys come?

[GavinZac]

ah. I'm one of those 'with some PHP experience, but a dearth of real talent' lol. I also tie it in with mysql. I can create the site using these but I don't want to go through all the work and for my site to suddenly be ditched in favour of someone elses

Words from my mouth. I built a mental health support website some time ago, built up a useful community and felt like I was making a difference. Then the local government made their own half-arsed version of it, had all the marketing and budget of a full-time setup, and the site was a ghosttown within the week. That tastes bitter. People might be skeptical of Squad's intent for "SP2" but if it's the one that has an ingame link or browser, it will be the one that people use, justified or not. Any third-party repository should be done before that, and done to a level of excellence or built with a featureset that sets it apart.

I'll make it if you guys come?

I'm stuck in a PHP project right now but I am happy to bugfix and dip in here and there. If PHP is not to people's taste my actually training is in C# for the web, though I always find myself coming back to PHP as it's so quick to set up.

[Cilph]

No objections to Node.js and NoSQL. The database system won't be that complicated, so it suits it.

I wouldn't mind a C# or Java-based MVC system though. Possibly a REST back-end and have the front-end be all javascript. REST services are ridiculously easy to create, and the front-end could use Ember.js.

Edited March 5, 2014 by Cilph

[sharpspoonful]

One file per mod or several?

One ZIP file will do, and files should be packaged with some uniformity. File> KSP Gamedata/README.txt./Source.exe/Other misc. folders not associated.

What kind of files are allowed?

ZIP files for uniformity and ease of unpackaging across different OS platforms.

Can people download from the site, from an external link or both?

Depends on bandwidth from Majiir's server. Preferably from his sever alone.

Who gets to upload files?

Those with verified logins.

What else you got Majiir. I'm here all night.

[K3-Chris]

A replacement to spaceport would be nice, I don't use spaceport anymore because it's high hot-mess points, but on the forum it can at times be hard to find a specific mod, or tell an updated mod from a mod that just got a recent reply, though the IRC is bandying about the idea of building it completely from scratch, which seems pretty overkill, though if you have the time and skill to do it go for it, seems more sensible to skin/adapt an already existing CMS though at least imo, and no, WP isn't a CMS

[mys_721tx]

A package manager should be on the schedule so the mod dependency can be resolved by some metadata instead of packaging everything into a zip file.

[kitoban]

Can say I like the idea of where this is going will definitely be keeping an eye on it.

One thing that comes to mind on this (not sure if it has been mentioned already) is for the ability to transfer ownership of a mod. There has been a number of cases where someone has picked things up off another modder and I would imagine all the statistics that go with the mod management would be useful to the new owner.

[Majiir]

I wouldn't mind a C# or Java-based MVC system though. Possibly a REST back-end and have the front-end be all javascript. REST services are ridiculously easy to create, and the front-end could use Ember.js.

I've conspicuously avoided front-end. It will become clear when the server's mostly done what sort of front-end capabilities are needed. Something like Ember could be quite heavyweight, although I have no qualms about requiring Javascript support.

One file per mod or several?

One ZIP file will do, and files should be packaged with some uniformity. File> KSP Gamedata/README.txt./Source.exe/Other misc. folders not associated.

This conflicts with the versioning feature. Fully agreed on the rest.

A package manager should be on the schedule so the mod dependency can be resolved by some metadata instead of packaging everything into a zip file.

A full-blown package manager is a project in and of itself, but a site could definitely support package managers by exposing a machine-readable API. That's minimal effort to accomplish.

One thing that comes to mind on this (not sure if it has been mentioned already) is for the ability to transfer ownership of a mod. There has been a number of cases where someone has picked things up off another modder and I would imagine all the statistics that go with the mod management would be useful to the new owner.

I've had to deal with this on Spaceport and it's not fun. This is a great second-round feature.

[Trueborn]

I do like the idea of the package manager, although I do agree that that would be a total project in and of itself. An alternative might be allowing specified dependencies that would trigger the automated download of the dependant mod.

That would let someone downloading a mod that's mabe two months old to hook into yesterday's toolbar update.

Unfortunately, it does interfere with the "big red button" concept.

Ownership transfer (probably at the admin level) is an excellent second tier feature.

[sharpspoonful]

This conflicts with the versioning feature. Fully agreed on the rest.

So long as it is not a part of the file name why does it has to be? We could even modify the downloaded file to look like MOD.ZIP>KSP Gamedata/x.xx.xREADME.txt./Source.exe/Other misc. folders not associated. Anything involved with the download portal could easily have the title changed by the author to reflect the latest update, much like you can in a forum. Again, not a programmer in the least, but where ever the stated versioning is place should also allow the author edit it.

[Johnley]

Hi guys, I'm primarily a PHP/SQL developer, with enough javascript experience to muddle my way through Ajax stuff. I would love to help with this project, but the current discussion might be aided by a central document that outlines what we have decided on so far (maybe Majiir could edit the OP, or put up a quick dokuwiki/google doc).

my 2 cents on the versioning stuff: using a tag system, you could tag a mod as 0.23, and then have the mods version in the metadata part. tags and categories would really help with an "advanced search" feature. Also, would this site be open source? once we all agree on a technology to use, it would make actually creating the site much easier if everyone can help, even if its just adding in another method/api call/css layout.

[rhoark]

In the spirit of simplicity, I'll distill this down to one feature: rich description field. A simple text formatter like Markdown can be extended to support video embeds.

I think a one line synopsis, license statement, and forum link need to be independent fields so they

a) can be made mandatory

are placed in a consistent easily-locatable place at the top of the page

Across a variety of games/download services modders in aggregate have shown themselves to be very bad at giving these pieces of information their due prominence.

[novafire08]

A couple suggestions for the development of this idea.

1. Community moderation. Rather than a rating system based on stars or whatever, my idea is a binary yes/no system of "Is this the mod you were looking for?" that would help categorize searches. So if the results spit out 50 results for "kethane", but the official Kethane mod has the highest ranking for searches of "kethane", then that mod gets put at the first result, and so on.

2. Future planned features. The first iteration of ReplacementPort will probably not be the final version. Deciding what goes in version 0.1 while allowing for additional features that will come with version 0.7 is important.

3. Purpose of the site. Also fits with future features, but I noticed that Majiir specifically referred to this as a mod repository, while Spaceport also allows for .crafts. If .crafts will be allowed on the site should be decided upon very quickly, and if they are, there should be a completely separate section for them. It should be very clear what section you're in, with no crossover in the search functions, so .crafts with Kethane parts don't get thrown into the results when you're looking for the Kethane mod.

[Trueborn]

I think so far we have determined that version 0.1 will be for mods only. The architecture would almost surely support .craft files as well. Maybe a later version could offer a walled-off .craft area, but I don't think that's high on this group's priority list.

I'm assuming everyone will balk at this, but here is a link to the document I built for my earlier post (updated with Majiir's architecture diagram and two additional requirements) as a public document. So if you find OneDrive a terrible collaboration tool, feel free to copy it to google or wherever you want.

[arrdem]

For this particular application a NoSQL family database like MongoDB is probably OK becuase most DB accesses will be file reads by ID or mod lookup by ID. Big sequential scans of the mods list would be better suited to a SQL derivitive for a number of database implementation reasons. I would caution you to steer clear of MongoDB itself however. Mongo is a primarily in-memory store, which is awesome for reads and writes since Mongo escapes a memory to filesystem synchronization on write most of the time. However this introduces obvious issues with data reliability. If your "real" datastore is a RAM cache that may or may not get synchronized to disk, what happens if the server looses power? Kiss your data goodby... Furthermore despite having a sharding system setting up sharding with Mongo is a total pain in my experience, limiting Mongo to applications for which a single monolithic server will suffice.

I contend that while MongoDB may serve as a sufficient datastore for getting this project started, it is a poor choice in the long run and other datastores, especially RethinkDB offer the same features list with much stronger consistency gurantees and frankly a better management system. Just my $0.02.

[krenshala]

This is probably getting a bit ahead of things, as a rating system is at best a second pass item in my opinion (have to get the site hosting things to rate before you bother actually rating them) but I wanted to share my thoughts.

I think my suggestion works best if everyone has to log in to download, however, that does require a bit of extra back end work as well as adding a (low) barrier to entry for folks that "just want to download <mod>". It should be able to mostly work based on GET data, though one point requires a login, and another two would (in my opinion) work best if login was required. Anyway, to the meat of the post.

A simple additive system for (mostly) auto-magically rating hosted mods they look at with minimal effort by site users. Basically, site use drives the majority of the ratings.

* If a connection/user views the mod, +1 star

* If a connection/user dowloads the mod, +1 star

* If a connection/user (possibly user only) recommends the mod (via checkbox), +1 star [mutually exclusive with the below line]

* If a connection/user (possibly user only) indicates the mod has a problem (via checkbox), -1 star [mutually exclusive with the above line]

* If a user marks the mod to notify on updates, +1 star

This leads to an automatic rating from zero (0) to four (4) stars, where the end user has, at most, two mutually exclusive checkboxes ("I recommend this!" and "This has problems!") with the rest of the ratings coming from how they use the site itself.

Examples: If you view a mod but don't download it, this feature marks it as a "1 Star" mod for you. If you download the mod and mark it to notify you of updates, it would be marked as a "3 Star" mod (1 view, 1 download, 1 watching).

Combining the above with metadata about views of the mod entry and a mods relative worth is pretty clear. "300 views, 2 Stars" means a decent group of people have looked at it, but not many are watching and/or recommending it. "2 views, 4 Stars" means its new; it might be good, it might not. "2300 views, 3.5 Stars" mean lots of folks are downloading it and most are watching and/or recommending it; probably a good thing to look into.

This should be a relatively simple system to implement: views of the mod page, download links on the page clicked, and whether or not zero or one of the two user checkboxes are selected summed, then stored to generate an average rating. Not having worked on a site this large, I'm not sure if the results should be cached and updated in the background, or calculated "live", but even cached it should still be useful and relatively low in system resource costs.

Obviously, this isn't a perfect system. Spiders could taint the data (lots of 1 Star "reviews" added as they spider through the individual mod pages), but this can be worked around in at least a couple of ways. It may only work if everyone has to log in, which may turn enough users away to make it worthless, but I'm really not sure if that would be the case. There are probably at least two other things I've overlooked, but if I don't throw it out there it could just as easily have been the Ultimate Method nobody else thought of.

Feel free to (constructively) critize, comment or stick on the back burner for ReplacePort 0.5 or whatever.

By the way, I'm partial to the name DeepSpacePort, though ReplacePort is catchy.

[OffByNone]

So, this happened.

Here's my two cents: while we are still going through a number of options for a next step on a new iteration of Spaceport, if Majiir or any other capable personalities from the community want to step up and try to make an alternative from the ground up, it's welcomed.

[Mishkin_007]

I had started my own alternate spaceport that was pretty promising about 6 months ago, I tested the market and everyone told me that there was no need for an alternate website so I abandoned the project. And personally, I think you guys are drastically over thinking this.

Edited March 6, 2014 by Mishkin_007

[Majiir]

Regarding craft files: My hosting offer is for a mod repository. While we can certainly have that discussion, I'm not really a fan of supporting craft files, and it's definitely not a core feature.

I'm assuming everyone will balk at this, but here is a link to the document I built for my earlier post (updated with Majiir's architecture diagram and two additional requirements) as a public document. So if you find OneDrive a terrible collaboration tool, feel free to copy it to google or wherever you want.

I think it's worth simplifying your document a bit. It's wordy in some places, vague in others, and even overly specific in a few. Any place where you say "by this I mean two things" or "this has two parts" you should split those into discrete parts. (You even say this yourself at one point.) The document also contains a lot of open questions, and I think those should be resolved rather than documented.

Specific comments:

• Update notifications are mentioned in the "major features" list, but subscriptions are not. My impression from discussion in this thread is that these ideas are linked, and that subscriptions may also play into mod rankings somehow (even if it's just a visual indicator).
  
• Search might not belong in the required features list. (Either that, or things like versioning and download metrics also need to be required.) A repository that allows modders to create listings and then link to them from a forum thread would still be quite useful. I'd go so far as to say download metrics are more important, at least from an adoption perspective.
  
• Mod metadata could be split into a few categories for requirements levels. Name, author and description are undoubtedly core features. Mod version is probably up there. The rest might not be; the thread has yielded varying opinions there. A document doesn't necessarily have to iron all that out right away, but it could help to categorize how certain we are about each feature.
  
• Regarding the description field: I haven't seen any objections to rich text. I like Markdown. Might as well just specify it and be done with it.
  
• The search feature needs a lot of work (in this thread, not just in the document). We've said we want it to be better, but exactly how it accomplishes that is something to discuss. My personal thoughts: full-text searches are cleaner than tagging systems, and it would help to use download and subscription counts to weight results.
  
• Requiring users to log in to download is a show-stopper, so it's fine if the update notification system only works for people who are logged in. We should think about what situations could cause the site's perception of a user's installed mods to differ from reality. A user might download a newer version without actually installing it, or they might download the latest version from a different location (e.g. an auto-updater packaged with the mod). What facilities should be available for users to correct their download history?
  
• I'm not completely convinced that mod versions need to have some discernible ordering. Is there some way we can save ourselves the headache while giving mod owners flexibility to decide which versions come before others?
  
• I think I agree with your second paragraph about mod versioning, but we need to be clear that this means we're dealing with two kinds of objects, mods and uploads, where each mod may have many uploads. It is thus not mods that have versions, but uploads; and not mods that have download statistics, but uploads. I think mods should certainly have a description, but perhaps uploads should too (for release notes and the like). As an alternative to uploads, we could call these "files" or "versions".
  
• I don't think the dichotomy you present in download metrics is necessary. The server collects and records statistics on things like downloads and subscriptions. Users can view some of these statistics. Perhaps we say that mod owners can view more detailed statistics while normal users can only see summaries, but that's a lot more clear than slicing and dicing it.
  
• I would move the first section in administration tools elsewhere. Administration tools are for administrators. If mod owners need some privileged controls over their own mods, we should enumerate exactly what they can do.
  
• On that note, something is missing: user accounts. They need to be created, authenticated and probably modified. What properties comprise a user, and how they can be changed, should be specified. Authentication can get really complicated, so for now I suggest we stick with simple password authentication and consider social media and third-party authentication later.
  
• I think it's okay to allow users to transfer mods without admin intervention so long as there's a big scary warning about it.
  
• I have a minor amendment to make to the proposed system architecture: nginx can handle file uploads and pass just the metadata onto Node.js for processing. It doesn't need to go into the document, but I thought it was neat.

Overall, I quite like it. Documents are good.

I would caution you to steer clear of MongoDB itself however. Mongo is a primarily in-memory store, which is awesome for reads and writes since Mongo escapes a memory to filesystem synchronization on write most of the time. However this introduces obvious issues with data reliability. If your "real" datastore is a RAM cache that may or may not get synchronized to disk, what happens if the server looses power? Kiss your data goodby... Furthermore despite having a sharding system setting up sharding with Mongo is a total pain in my experience, limiting Mongo to applications for which a single monolithic server will suffice.

MongoDB allows you to configure write concern so you can trade performance for safety. That said, my server has been online for four years or so, and it's located in a datacenter with redundant battery and generator units. MongoDB can be made to dump data to disk regularly, and I doubt losing a few seconds of data in the rare event of power loss will be a problem. We're not dealing with financial transactions here. (Even if we were, it could be made to work.)

This is probably getting a bit ahead of things, as a rating system is at best a second pass item in my opinion (have to get the site hosting things to rate before you bother actually rating them) but I wanted to share my thoughts.

It's not too hard to implement, but I think it's overly complex and you've already pointed out some problems. We can tell spiders to ignore the relevant endpoints, but consider that you could reduce the rating of a competitor's mod by simply downloading it a lot! Additionally, a mod's rating might sink as it becomes more popular because less invested users don't take the time to do anything more than view or download. Being linked on Reddit (generating a lot of view-only entries) could kill a mod's rating.

[EDIT]

So, this happened.

I have offered my response. If we had some official announcement or support upon release, that would be grand. If not, I'm not sure what "it's welcomed" really means.

Edited March 6, 2014 by Majiir

[arrdem]

MongoDB allows you to configure write concern so you can trade performance for safety. That said, my server has been online for four years or so, and it's located in a datacenter with redundant battery and generator units. MongoDB can be made to dump data to disk regularly, and I doubt losing a few seconds of data in the rare event of power loss will be a problem. We're not dealing with financial transactions here. (Even if we were, it could be made to work.)

Delighted to hear that you have more experience working with this toolset than I do. Yay confidence! Known limitations! Rational choice of toolkit!

[blizzy78]

I think a one line synopsis, license statement, and forum link need to be independent fields so they

a) can be made mandatory

are placed in a consistent easily-locatable place at the top of the page

Exactly this. We need to differentiate fields into categories like "must have", "will be displayed in fixed locations", and "nice to have (ie. optional)".

FWIW, I really love how the Google Play Store looks. Each app's page looks exactly the same, and you always know where to find information. No scrolling around to find stuff, and only if you're lucky that the programmer has actually added it.

[Streetwind]

I wholeheartedly agree with rhoark and blizzy78 here. Documentation is important, especially from the perspective of a player looking for mods.

I started exploring KSP mods in my second save, after playing in a completely stock one for a few weeks. And the first mod I tried out was Kethane. The main reason for choosing it: I could see even without downloading what it was about, what parts it added, and how those parts were supposed to be used. That it's even organized in its own small wiki is a bonus on top. I immediately knew what I was in for, and even more importantly, I knew that I wanted to have it.

In contrast, during more recent forays into the big wide modding community, I come across mod after mod after mod (both on spaceport and on the forums) that utilize their access to a freeform textfield mostly thus: a cryptic changelog or author musing about future versions, sometimes an outdated imgur gallery of misc rockets in flight or on the launchpad that could really be anything (or sometimes even use other mods in addition to the one in question), and a big bold download link forwarding to spaceport where you find a carbon copy of the forum post, except not quite as up to date. The problem with this goes beyond merely having to figure out how stuff works (that would not be much of an issue). Rather, as a player, I often find myself looking at a thread and thinking "this mod has a really awesome title that drew my mouse to click on the forum topic like a magnet, but for the life of me I cannot actually figure out what it even does or why I would want to download it". This immediately triggers in me the subconscious feeling of "I wonder if the mod itself is just as half-assed". Which likely ends up being unfair towards the work the author has put into making it.

As such, I'd consider it extremely important to give mod authors the tools to show off exactly those things - to tell the browsing player what they do and why that player should want to download it. I personally even feel that it should be mandatory, but then I am just a consumer and only see my side of the medal.

Edited March 6, 2014 by Streetwind

[Trueborn]

I think it's worth simplifying your document a bit. It's wordy in some places, vague in others, and even overly specific in a few. Any place where you say "by this I mean two things" or "this has two parts" you should split those into discrete parts. (You even say this yourself at one point.) The document also contains a lot of open questions, and I think those should be resolved rather than documented.

Specific comments:

• Update notifications are mentioned in the "major features" list, but subscriptions are not. My impression from discussion in this thread is that these ideas are linked, and that subscriptions may also play into mod rankings somehow (even if it's just a visual indicator).
  
• Search might not belong in the required features list. (Either that, or things like versioning and download metrics also need to be required.) A repository that allows modders to create listings and then link to them from a forum thread would still be quite useful. I'd go so far as to say download metrics are more important, at least from an adoption perspective.
  
• Mod metadata could be split into a few categories for requirements levels. Name, author and description are undoubtedly core features. Mod version is probably up there. The rest might not be; the thread has yielded varying opinions there. A document doesn't necessarily have to iron all that out right away, but it could help to categorize how certain we are about each feature.
  
• Regarding the description field: I haven't seen any objections to rich text. I like Markdown. Might as well just specify it and be done with it.
  
• The search feature needs a lot of work (in this thread, not just in the document). We've said we want it to be better, but exactly how it accomplishes that is something to discuss. My personal thoughts: full-text searches are cleaner than tagging systems, and it would help to use download and subscription counts to weight results.
  
• Requiring users to log in to download is a show-stopper, so it's fine if the update notification system only works for people who are logged in. We should think about what situations could cause the site's perception of a user's installed mods to differ from reality. A user might download a newer version without actually installing it, or they might download the latest version from a different location (e.g. an auto-updater packaged with the mod). What facilities should be available for users to correct their download history?
  
• I'm not completely convinced that mod versions need to have some discernible ordering. Is there some way we can save ourselves the headache while giving mod owners flexibility to decide which versions come before others?
  
• I think I agree with your second paragraph about mod versioning, but we need to be clear that this means we're dealing with two kinds of objects, mods and uploads, where each mod may have many uploads. It is thus not mods that have versions, but uploads; and not mods that have download statistics, but uploads. I think mods should certainly have a description, but perhaps uploads should too (for release notes and the like). As an alternative to uploads, we could call these "files" or "versions".
  
• I don't think the dichotomy you present in download metrics is necessary. The server collects and records statistics on things like downloads and subscriptions. Users can view some of these statistics. Perhaps we say that mod owners can view more detailed statistics while normal users can only see summaries, but that's a lot more clear than slicing and dicing it.
  
• I would move the first section in administration tools elsewhere. Administration tools are for administrators. If mod owners need some privileged controls over their own mods, we should enumerate exactly what they can do.
  
• On that note, something is missing: user accounts. They need to be created, authenticated and probably modified. What properties comprise a user, and how they can be changed, should be specified. Authentication can get really complicated, so for now I suggest we stick with simple password authentication and consider social media and third-party authentication later.
  
• I think it's okay to allow users to transfer mods without admin intervention so long as there's a big scary warning about it.
  
• I have a minor amendment to make to the proposed system architecture: nginx can handle file uploads and pass just the metadata onto Node.js for processing. It doesn't need to go into the document, but I thought it was neat.
  

Overall, I quite like it. Documents are good.

I've made some changes based on your comments. Its probably still often too wordy, but can be edited down.

• I think my "opt-in" and your "subscription" are meant to be the same thing. Users subscribe to a mod in order to receive update notifications.
  
• I believe a simple search function is a functional requirement. Otherwise users would only be able to find content via a direct link or some global index? Now, a lot of traffic does come from the forums so it might actually be usable without it. I just think it would throw a lot of users off if they couldn't search for mods. Of course, if its worth doing its worth doing well.
  
• I split metadata into "required", "optional", and automated categories and specified Markdown.
  
• In general I like the idea of full-text search, but I also understand why keywording is useful. This may need the most discussion in this forum.
  
• I edited the update notification section a bit. Honestly, I think the email notification is the most useful. Few people are going to want to log on to a mod site just to see if they need to update anything. But options to limit a digest to daily, weekly, or monthly would probably be required as well. The email could provide a direct download link to the updated mods. On the other hand, I also see the utility of a list on a user's homepage with links to updated mods. A simple "x" next to each notification could serve to dismiss it if they were not interested in downloading at that time.
  
• I agree that an ordering system probably isn't required. As we are capturing upload timestamps, ordering of the versions is already taken care of.
  
• I really like using the term "mod" to refer to a set of .zip files, which retains a continuity over time. Each separate .zip file that is uploaded will be referred to as a new "version" of the mod. The server can retain past versions for download by users if they so desire.
  
• I specified a possible download log entry. I don't go into much detail with subscriptions, but I don't think that needs a log so much as just a sum.
  
• Moved administration stuff around a bit, though it isn't heavily specified.
  
• User Accounts are now represented, with some specification.
  
• Non-moderated ownership transfer comes in two steps, I believe. The first is the owner selecting a target mod and target user to assign ownership to. This then generates some sort of message to the targeted user (email?). The targeted user then either chooses to accept ownership, decline ownership, or ignore the message. This implies some time limit may be appropriate, and a results message should be sent back to the original owner.
  

The file is in the same place, and should be editable by you guys if you have something you want to add.

I've done some reading about MongoDB, and it seems pretty interesting (to one who's only dealt with relational DBs). I can certainly see how some of its traits would work well in this application.