Upcoming features

Following are some notes on possible features to be built out at some point.

Logging in with a Google account

Allow people to log in with their Google accounts. Depends on #32.

• Move the GitHub-specific fields on the users table into a separate relation.
• Add a new table to hold Google-specific fields.
• Add a "Log in with Google" button to the sign-in page.
• After clicking on the login button, the user is presented with the Google permissions page and accepts the permissions. If everything works, the user is then redirected back to Digraph.
  • Extend the registration workflow to have the user choose a "login" name to be used in url paths. (It's not really a login name, since the user doesn't provide it when logging in, but this is the name used by other services, so we'll use it here as well.)
  • The potential login name provided by the user during this second step is cross-checked with GitHub login names and is considered invalid if an identical GitHub login name exists. The input field forces the user to choose a GitHub-like login name by disallowing certain letters and combinations of letters.
• Once the new user has chosen a valid login name, account registration will be marked as complete, and the next time the user logs in, they will go straight to the landing page.

The cross-check against GitHub is needed to prevent issues from arising when a GitHub user with the same account name later attempts to log in. Things should just work for GitHub users without their having to select a different login name.

Automatic tagging of links with topics

Save the user the trouble of tagging some links with frequently used topics that are easy to infer, such as Articles in the New York Times. Provide a view or set of views that can be configured by users to automatically apply tags using different patterns and selection criteria. The matching rules will be specific to a repo.

• Add a screen for settings on a repo that will eventually contain a description that can be edited, links to permissions and a red delete button.
• Add metadata fields to the repo table, or add a table of repo metadata, to hold things like the description.
• Add a link for getting to the settings for a repo — perhaps a gear icon somewhere.
  • Only show the screen if the person has permissions to configure the settings on the repo.
• Add a section for tagging rules, with a list of rules that can be edited inline.
• Add a table to hold rules with a reference to the repo for the rule.
• Add a table to hold patterns for rules with a reference to the table of rules.
• Add a table to hold topics for rules with a reference to the table of rules.
• Add a service to upsert a rule.
• Add a service to delete a rule.
• Add a mutation to upsert a rule.
• Add a mutation to delete a rule.
• Add a form for editing a rule. The form has one (or more?) patterns that can be used to match against a url, a title, and (at some point) the contents of a document. The patterns can be a simple string match or a regex. The form also has an element to choose a tag to apply (or a multi-select of tags to apply?).

Questions:

• Should a rule apply only a single topic, or should it be possible to configure a rule to apply multiple topics? Restricting a rule to a single topic keeps things simple. Allowing a rule to apply several topics might be more convenient. Perhaps the UI can start out allowing only a single topic, while the tables are modeled to potentially allow additional topics per rule in the future.