Webpage Integration: Public Profile Routing

[henryajisegiri]

Goal

Implement public-facing profile routing so each user's profile is accessible via a unique URL.

---

Scope

Full-stack: URL routing, resolving the username in the URL to the correct user profile, and error handling for invalid or missing profiles.

---

Background

The public profile view and its data wiring have been implemented. This ticket adds the routing layer so profiles are publicly accessible at a unique URL per user. This is Phase 2 of the public profile integration.

---

Acceptance Criteria

Route

• Each user's public profile is accessible at a unique URL (unique hash) based on their username.
• The username in the URL is resolved to the correct user record and the corresponding profile is rendered.
• Clicking a user's name or avatar anywhere on the platform routes to their public profile.
• Clicking the "Share" button copies the profile URL unto the clipboard

Invalid or missing profiles

• If the username does not match any existing account, an appropriate error is shown.
• If a user has deleted their account, an appropriate error is shown.

Username changes

• If a user changes their username, the old URL redirects to the new profile URL automatically.

---

FE/BE Actions

Description	URL
Fetch public profile by resolving username from URL

---

Out of Scope

• Public profile view and data rendering
• Username change flow

[herzog0]

Dev note

This is just a recommendation that came to mind during refinement, feel free to modify the overall plan at any level that you want.

The idea:

1. Create a new table user_profile_routing_key. Fields are: timestamps, id (pk), routing_key (unique), user_id;
2. Requests to boost.org/user/<routing-key> (not sure if this is the right path) will search for the corresponding record in the table above, find the user_id and continue the profile context hydration process with this user that was found (also, something else in #7);
3. Records in this table are never deleted or updated, the table can only grow;
4. Whenever a user updates their display_name (which currently serves as a type of username, cause there's no real username concept in the site) the system normalizes and sanitizes it, kebab-case it, appends a random 4-character code at the end of it and save it in the user_profile_routing_key pointing to its owner;
5. The 4-character code is necessary in this case because we're deterministically generating the routing keys from users display_names, but display_name is not unique, so the random suffix code will guarantee uniqueness (an alphanumerical alphabet selecting 4 random chars should be enough);
6. Users' display_name may be null (or an empty string), in order to still give them public URLs without exposing their user_i, PII or an enumeration exploit, we generate a random cuid2 to every user on a new field called public_user_id in the users_user table; (btw, cuid2 is not Postgres-native, so you should ask your preferred AI for the sample pSQL code that generates the function and uses it as the default value of the public_user_id field, as a Django migration)
7. Navigating to the boost.org/user/<routing-key> url, the backend searches first for that key in the public_profile_id field, assuming it's a cuid2, then, if not found, it looks in the user_profile_routing_key, assuming it's a routing key. Or do the inverse, first check for routing key then cuid2 (less roundtrips between tables sometimes);