openuserjs/openuserjs.org

The home of FOSS user scripts.

openuserjs.org's Issues

Graceful failure

When we encounter an error almost anywhere, we should handle it and fail gracefully.

Firefox Accounts webhook

When Greasemonkey integrates Firefox Accounts as their sync service, make a connection with that to import all synced scripts.

https://blog.mozilla.org/blog/2014/02/07/introducing-mozilla-firefox-accounts/
https://wiki.mozilla.org/Identity/Firefox_Accounts

Site Mascot

We need something like GitHub's Octocat to use as a mascot for the site. My idea is called the Magical Mechanical Userjs Bird (or M2UB). It's based on one of my father's works and is a blue bird with visible gears in its chest and a wind-up handle on it's back. We can use him on our error pages and maybe his wind-up handle as our favicon. I'll create him, release it under creative commons, and see what you guys think.

HTTPS

We will need this for GM updates and a few of the authentication services require it. I already shelled out the money for an http certificate on the openuserjs.org domain and it seems pretty simple to set up. And redirection of http to https is also simple. I'm just making this issue as a reminder to me. I'll do this after #1.

Script Issue Tracker

Basically a less robust version of GH Issues. Open/close, comments, labels.

Create .editorconfig

i18n: String internationalization

Down the line we should make sure the site is easily translatable with some small UI in the footer to change language. Language selection should ideally be included in a user preferences or something.

Beggar's Corner

Some place for regular users to ask for a script they would like someone to write. The name is pretty self-explanatory.

Create a mailing list

We need a place were we can argu... discuss shit and flood our inboxes. For Greasemonkey development, things are usually discussed on list before opening an issue or, god forbid, actually writing code. So far most of us have advocated for a Google Group.

Implement markdown on user input

We should implement markdown on almost all input (that are blocks at least) that displays out somewhere (posts, issue tracker, script descriptions, user bios, etc.).

Ideally, headers should automatically turn into anchors where the front-end will be able to create links--sans github style.

Get our site listed in Greasemonkey as a place to find scripts

We need to see if we can get Greasemonkey to replace it's direct links to UserScripts.org with a splash page that lists both sites (with probably a temporary label on us that we're new). We should definitely create the splash page first (we can reuse the one shown to new users of GM), and do all the GM code changes for it before we ask so it's just a matter of to pull or not to pull.

This should be that last issue closed on the 0.1 milestone. We should should have a functioning site (lacking many planned features of course) before we even think about asking GM to link to us.

The Garage

A place for script writers to ask for help from others. The name is a nod to Greasemonkey, and what people usually call an auto repair shop (where you'd find greasemonkeys).

GitHub Authentication

Users should be able to link their GH account (and potentially create a new account if one doesn't exist) to the site using OAuth.

User script grouping

US.o tried tags for this, but people can create any tag (leading to very similar but separate tags) and you can add any number of tags to an individual script. The result is a total clusterfuck that makes it mostly useless.

I believe they did unintentionally get it right when they implemented groups. You create a group for a specific purpose and people can add scripts to that group. The only problem is that it's completely buried and not even visible to users that aren't logged in.

I think we should allow scripts to be easily grouped (with auto-completion to suggest an existing group in real-time) and only allow the script to belong to one group that doesn't exist yet (creating a new group). Then when a user visits a page with a group of scripts (we could probably show links to the groups with the most scripts, or most popular using some formula, on the home page) we sort based on a formula that combines number of installs and positive reviews (with reviews having more weight).

.meta.js

There needs to be a corresponding .meta.js file for every .user.js file.

Edit User Settings

We need a page (/user/edit) where a user can edit the "about" section of their profile and manage what authenticators are attached to their account. We can reuse the login/registration form on the home page (minus the username of course). They should be able to add and remove authenticators to their account, and choose their preferred method of authentication (by default it's the last method you tied to your account/username).

Script Uploading

A user needs to be able upload a script directly to the site. If a user wants to edit or create a script on the site, provide them with a sexy js web editor (syntax highlighting and line numbers). Keep the script header in the database for the .meta.js service.

The Toolbox

A place where user script libraries like GM_config or jsl can be posted (not installed) so that script writers can look around for an existing tool that might help them in their development before writing their own solution. These will basically be scripts (which means they can be reviewed and flagged) that can't be installed on their own and an install button will be replaced with input containing the url of the library so that it can be easily copied. The install count will be replaced with the number of scripts on the site that are @requireing the library, that is linked to the list of scripts using the library.

Finish Implementing Passport Strategies

Left over from #1. There is an admin page to enter these authorization keys in: /admin/api

Right now I can't signup at all. I run in to a different error with each strategy I try. Anyway, plain OpenID needs some special work (an extra input so we know who to authenticate with).

Refactor existing code to conform to style guide

In my haste to get authentication working, I wrote some sloppy code. Time to go back and clean it up and fill it full of useful comments.

User Profile

A page (/user/ for the person logged in and /users/username for the world) to show the users "about" string (which can be changed via #44) and their user role. Eventually it will show more stuff like scripts they've written (#2 and #3).

Create Mockups

Create a click-through mockup using Balsamiq Mockups and submit it to the wiki as a PDF.

The Graveyard

Moderators and admins are fallible and sometimes they make mistakes when removing things (as demonstrated by Marti's account on US.o recently getting accidentally deleted). Instead of actually deleting accounts, we should disable them (removing them from visibility on the site) and make them visible in a moderator section of the site (called the Graveyard) where mistakes can be undone. Scripts and posts belonging to the user get disabled/re-enabled by proxy.

Use environment listening port number.

Use process.env.PORT for environment listening port number.

User Script Sandbox for detection of potentially malicious scripts

One of the things I've been toying with is the idea of running scripts when they're uploaded inside a sandbox on the server that would replicate the Tampermonkey environment (since Node.js uses V8 it would be trivial for a malicious author to detect the difference between V8 and Spidermokey, e.g. if (typeof [] === 'object') return;) in order to detect potentially malicious code. Here's my logic to do this:

• get the source of a page matching a random @include rule of the of the script using Google search api. For a @include *, just use http://google.com
• use jsdom with the most advance options to provide a DOM for the page. I might need to make some modifications to make it more believable, like setting request headers that jsdom uses when fetching remote scripts and images in the page to look like Google Chrome requests.
• replicate GM_* apis and metadata behavior (@require and @resource) that Tampermonkey supports
• run the script in a sandbox with the window from jsdom as its global object and detect potentially malicious function calls using defineGetter for eval and document.cookies
• provide warnings for scripts that use these risky functions and suggest safer alternatives

Note: I'm also doing this because it fills one of my requirements to get this project accepted by my professor as my capstone project.

Edit (4/10): Fleshed things out a little more.

Make scripts forkable

Related to collaborative scripts (#10) and in the same vein as GitHub, scripts should be forkable. Forking would give the original author proper attribution, but OpenUserJS.org isn't GitHub so there would be no pushing, pulling, or merging. This is the old school style fork where you take an existing script and do your own thing. If users want more they can put the script on GitHub and get those features.

A script that is just copied and upload as the user's own would be cause for flagging and removal.

User account creation and login

This is probably the first feature we need to implement. I'd focus on getting OpenID to work first (we basically become an OpenID provider for those who don't already have one: node library). We'll keep user information in the DB, and each user will have a userRole which will be a number that corresponds to a textual value in a userRoles.json file. Here's the values I suggest (higher userRole values have all the privileges of lesser values):

• 1 - User: Anyone who can sign up. This user can use all the basic features of the site, like open issue, write reviews, flag spam, etc.
• 2 - Script Writer: This is a user who either has an OpenID or GH account, and has posted script(s) on the site.
• 3 - Moderator: This user active on the site and actively flags spam. They can remove content that has been flagged as spam using some set threshold.
• 4 - Admin: This user has been a moderator for awhile, and has actively contributed to the source code of the site. An admin can remove any content posted on the site by a user with a lesser userRole. An admin can make any user a moderator or take away moderator privileges, and nominate a moderator to be an admin. Another admin must confirm the nomination before the nominee becomes an admin.
• 5 - Founding Father: Anyone who actively participated in the initial development of the site. This user can appoint and remove any user as an admin, and remove any content posted on the site by a user with a lesser userRole.

Login with Facebook

User should be able to login (a create an account if one doesn't exist) with Facebook.

Swap out Mustache rendering engines

I wrote my own Mustache template rendering engine for Node.js awhile back. It is much faster and more memory efficient than Mu. Instead of building a parse tree in memory and then evaluating it to render (waking the parse tree and figuring out context.. ew), my engine transforms a template into a node module and then requires it. To render, it just passes the options to the module. The code is much simpler (so easier to optimize) and because it's a module, V8 can actually preform optimizations on the rendering code. I still need to implement Mustache partial syntax before it becomes a drop-in replacement for us. Template rendering speed and efficiency is important for us because we do it for essentially every request, and templates are just going to get more large and complex going forward.

Create style guide

We need consistent formatting of code and we should define it very explicitly. We can always do cleanup commits, or even have someone specifically assigned to do code cleanup.

Private Messaging

If this ever exists, it has to be a threaded discussion. None of this re: re: re: re: re: re: nonsense
Just give me your email so I can use Gmail already!

Build Guide

Building this thing is starting to get complex with the addition of S3. We should put together a step by step guide of how to build and run the site locally so that developers don't have to try and figure it out on their own.

GitHub WebHook

A user needs to be able set up a WebHook on a GitHub repo and have all the .user.js files pulled to the site. Also the site needs to be able to receive info from these hooks and pull the scripts that have been changed (parse the payload). I have some PHP code that I used to post commit info for GM_config to a thread on US.o using a WebHook. Eventually, we'll to try to get OpenUserJS listed as an official service hook (#16).

List user scripts on the homepage

This is obvious, but I'm adding this to make the 0.1 milestone a complete unit. This will probably just be a simple list with the most recently updated scripts at the top and continuation on additional pages.

Collaborative Scripts

A script author should be able to allow other users to update a script. This can be either manually or the collaborative author can point to some GH repo that contains the script (we just take the latest, they can handle collisions on their own).

Usable when screen width is small

It's important that the site is usable when view on a display that has a small width (like a phone). The best way to do this is to check the page width and inject a different stylesheet that is adapted for a small screen width if it goes below some threshold. This should be dynamic, meaning that changing your window width will toggle this style off/on.

Also, if a comment box is floating, make it optional (with the default off) and save the preference for the user. Commenting on US.o is near impossible on my android phone for this very reason.

Rework Find GH Scripts Feature to prevent hanging

Related to #2. Nodejitsu is apparently much slower than my machine so it has a real problem trying to look through every GH user repo for user scripts. I guess the best solution would be just to list the repos first (meaning a list of repos would always appear on /user/edit/scripts with the find scripts button below it) and let the user select which ones we search through for user scripts. Then provide the same import list as we do now for all repos, but only for the ones the user selected. Surely they at least know which repos have user scripts, right?

Flag Spam

You should be able to flag almost any user generated content as spam and once enough people flag it, it collapses (if it's a script, it becomes unlisted too) but it can still be manually expanded and you can vouch for it as not being spam. There should be some type of spam dashboard (sorted by content type, i.e. issue, comment, script, etc.) that shows moderators what has hit the threshold and can be removed.

We could leave the flagging ambiguous (literally just a red flag icon) so that it could also apply to malicious scripts, or we could have a specific flag for that.

Users can also be flagged, in which case, everything the do (like commenting) is automatically collapsed/unlisted. Of course this would require a higher threshold to prevent people from silencing a user they just don't like.

Flagging is disabled on a users who hold a role of moderator or greater (see #1).

Create .gitignore file

An initial .gitignore file needs to be created. I suggest using the template file from Github: https://github.com/github/gitignore/blob/master/Node.gitignore

use of for..in in the source

I've seen various uses of for..in in the source tree to check for objects, but this includes __proto__. Node.js doesn't have harmony enabled by default yet, so we can't do things like for..of, the easiest way I can think of is to use the underscore module:

The buggy method

//doesn't ignore things like __proto__
for(var key in obj){
  do_something(key)
}

becomes

_.each(key,function(key){
    do_something(key)
}

What do you guys think?

OpenID Authentication

All the authentication strategies listed on the login page work (I've tested all of them myself), except OpenID because it requires getting a special identifier. If a user selects OpenID from the dropdown they will be taken to /login/openid (which will use the same login.html template) where they can enter this identifier.

Scripts Must Be Released Under an Open Source License

To reduce the level of legal bullshit and in the spirit of the "open" in the site's name, users must choose to release their user script under one of the following open source licenses to upload it to the site:

• GNU General Public License
• GNU Lesser General Public License
• MIT License
• BSD 2-Clause License
• BSD 3-Clause License
• Creative Commons Attribution 3.0 Unported
• Creative Commons Attribution-ShareAlike 3.0 Unported
• Creative Commons Attribution-NonCommercial 3.0 Unported
• Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported
• Apache License, Version 2.0
• Mozilla Public License 2.0

Human readable install links

Since we're using Express we can easily turn http://openuserjs.org/scripts/id.user.js into http://openuserjs.org/scripts/username/scriptname.user.js where scriptname is the @name of the script. We can probably use the same code Greasemonkey uses to create file names when it saves userscripts to make it url compatible. We can use the user's name and not some number id because we're using mongoose.

Script search

Just a basic search functionality for scripts. To get even better results, we could probably parse all the metadata of script and add it to what is searchable.

Promise vs Custom Library when waiting for multiple async calls to finish

Currently we're using a library called Promise (bluebird package) to wait for several async calls to finish before we do something (in this case, a redirect).

Originally, I wrote a very small library to do the same thing. I think my library is simple to use and results in cleaner code, so I'd like to go back to using it.

Which one we choose is important because we will run into this situation all the time in the future: any time you need to run multiple async calls and know when they're all done before you can do something.

Manage Authenicators

From #44:

a page where a user can... manage what authenticators are attached to their account. We can reuse the login/registration form on the home page (minus the username of course). They should be able to add and remove authenticators to their account, and choose their preferred method of authentication (by default it's the last method you tied to your account/username).

Add admin nomination page

Was in #1, but I felt it was large enough to get its own issue.

Create good MVC base for app

We need a good MVC base for the app, with folder structure looking something like so:

root
    controllers
    models
    node_modules
    views
    public
        js
        css
        images
    app.js
    package.json

Controllers: Handles all logic, db calls, etc and is used directly by our routes using something like app.controllers.[category].[specific route] (e.g. app.controllers.scripts.raw to handle the .user.js and .meta.js routines).

Models: Complete schema data and db-specific logic here, which would most likely use mongoose to make it easier.

Views: All templates. Hook into using express's view engine and views so that we can easily call res.render([viewname], [data]).

Public: All the frontend publicly visible stuff.

---

Opinion needed

What extension should we use for templates (which will be Mustache)? Some sites I've seen use [file].mustache and others [file].tpl. I'd prefer .tpl in case we ever switched template engines down the line.

GitHub Service Hook

We can get OpenUserJS listed as an official service hook, which will make integration simpler for users than a WebHook (#2).

Script Reviews

Up/Down arrow, with an optional comment. If someone downvotes and tries to write a comment show them any annoying message about how they should be more productive and file a ticket. There should be a button that appears that automatically turns their negative review into a ticket (it takes them to the page and fills out the form but doesn't submit).