More readable URLs

[jasonaowen]

Instead of bare IDs, user and project pages should also have slugs that include the user or project name.

[jasonaowen]

User pages should use the user's public name, if available, and their internal name if not. (Probably we should also validate that a user has a public name set if their profile is set to public!) Projects currently just have the one name, so they should use that.

Consider using https://github.com/slugify/slugify to generate the slug.

[EL246]

Should we just append the username or project name to the url? So would /project/{projectId} would turn into /project/{projectId}/projectName?

[jasonaowen]

Yes, that's exactly what I was thinking!

Part of this will be handling variations - /project/{projectId} should continue to work, as should /project/{projectId}/unrelated-text; both could redirect to /project/{projectId}/{projectName}, or at least include a canonical link element in the HTML.

Implementation wise, I suggest doing one at a time, in separate pull requests.

I'm happy to talk more about this, if you'd like! Thank you for working on this, @EL246!

[j9peters]

The project URL's have been updated.

User URL's are in process.

[jasonaowen]

I think we should also update the links to projects to include the full URLs, with slugs, rather than show links that require a redirection. That includes the project lists shown on the front page, the projects page, the tag page, and the author page.

[jasonaowen]

There is a data leak risk here: by exposing some user-entered information in the URL, people who have access to a user profile or project description that isn't publicly available could share the URL, and that user-entered information would be leaked to whoever receives the URL.

For projects - which currently include the title in the URL - we considered the alternatives of adding a public name to the project, or adding an explicit field where users can specify the slug they would prefer. Both of those bring a lot of extra complexity, to the UI, the user's mental model, and to the implementation. We decided not to do either of those.

For users, an additional question is which user name to use in constructing the URL: public or internal? It would be possible to redirect logged-in users to the URL with the internal name, and redirect logged-out users to the URL with the public name. That approach has the drawback of potentially leaking the internal name, and has the surprising property that the URL of a user's profile changes based on whether or not the viewer is logged in. It also assumes the behavior of users changing their public name to be something different from their internal name, and we haven't seen that much so far in practice. We decided to only use the public name in constructing user profile URLs.

One option, which could apply to both projects and users, is to simply not add slugs to entities set to internal or private visibility. This trades some of the benefit of this feature for additional security. How likely are people to share these links outside of the RC community? Is it worthwhile to make it safer to share a link on Twitter at the cost of making it less attractive to share on Zulip? Or is it better to accept the risk of some data leakage and have more consistent, prettier URLs? We haven't decided yet.

Thanks to @j9peters for discussing this with me!

[j9peters]

User profile URL's have been updated with the exception of the "Hello, <user>!" link shown in the upper right-hand corner of the website. That link redirects properly to a /user/id/user-name URL, but could be improved by directly linking to the slugified URL.

@EL246