Shorter domains: valname.val.run

[stevekrouse]

Instead of username-valname.web.val.run

Issue 1 - we need to check for global uniqueness for these. The UI is also a bit confusing: the URL for this val is longer than you might want because it's not unique, try changing the name to get a domain without your username

Issue 2 - ensuring web and express URLs still go where they need to. I guess if we make it *.val.run then we can handle all these redirects in code and it should be unambiguous

[pomdtr]

How would you guarantee uniqueness ? Through a random id at the start / end ? I'm not a fan of this pattern as it make url hard to remember.

I would love something like:

<val>.<username>.val.run, but it's probably cumbersome to generate a wildcard certificate for each user.

[stevekrouse]

If you want a shorter domain you have to choose a name that nobody else has chosen before. If you want to keep the name of your val, then we'll append your username like we do now.

[pomdtr]

I see. Does it means that the val name will not necessarily be linked with the subdomain anymore ?

[stevekrouse]

I imagined them still linked in this scheme, but I could imagine disassociating them too

[postpostscript]

I like the idea of shorter URLs for vals but I'm personally not a fan of this as a required default (i.e. exposed as the default URL in the UI for a val) for a few reasons:

• As a new user, it would be less intuitive to have some val URLs be user-namespaced by default and others not
• It wouldn't be possible to determine a val's name/owner from its URL (and vice-versa) without hitting an API (worst as a browser user wanting to view the source code)
• As a consequence of that, forking a project with multiple HTTP vals that link to each other would become more complicated if the URLs could not be determined easily in code

I personally would love the following:

• Use a namespaced/deterministic option by default. The current default is fine, but I like [name].[author].val.run too!
• Have a way of adding a custom vanity URL (in the format [whatever].val.run) to a public HTTP val, with the default URL still being accessible. I'd use this before using the existing custom domain feature! Some of the potential issues in the previous list apply here too, but I think it being opt-in + the URLs being structurally different from the default would negate most of those

[boucher]

Agreed that this sounds quite complicated an unintuitive, and prefer your proposal (perhaps add a shortid generator in the ui as well)

[timqian]

I believe valname.val.run would be an excellent choice.

• For users: A shorter domain is easier to remember, making it simpler for users to access the app.
• For val.town: A shorter domain attracts more creators to use this subdomain, which is beneficial for the brand.

Additionally, platforms like GitHub, Vercel, and Hugging Face Spaces all use similar subdomains for user-created sites. This approach makes it more familiar to builders.

[CarlQLange]

FYI usernames can have underscores in them, but domains can't, so having the username in there in the first place can cause problems. (I guess more of a bug, but it would be another reason to have valname.val.run.

[stevekrouse]

Quick update: we are planning to work on this sort of thing in the next ~month. Excited!