Re: Request for feedback on draft-go-protocol (shortlink resolution)

Hi Tim,

Thank you for the questions and for sharing that perspective from your time
at Google and AWS!

To answer your first question, this draft is born from practical,
real-world use.

Who needs this?

I maintain this algorithm as a TypeScript library (jsr.io/@fartlabs/go)
that is already in production use across several open-source organizations
and projects (e.g., acmcsuf.com, fartlabs.org, etok.me).

The problem we face isn't with public shortlinks (which I agree are less
common), but with internal, organizational link management. Many
organizations, including my own, use a "go-link" system (e.g. go/example)
to manage internal knowledge.

The core issue is portability. We want to define our entire shortlink
configuration as a simple, static Record<string, string> (essentially a
JSON file) and have it behave identically whether it's deployed on a
Cloudflare Worker, a Vercel Edge Function, a Deno server, or a simple
static site.

Without a standard, each new implementation has to re-invent the wheel for:

   -

   How to implement internal redirects (e.g., go/docs -> go/docs/latest).
   -

   How to handle query parameters from the shortlink vs. the destination.
   -

   How to handle fragments.

This leads to inconsistent behavior and a high maintenance burden for
small, FOSS-oriented teams. This draft solves that by standardizing
the resolution
algorithm, making the ruleset itself portable and the behavior
deterministic, regardless of the platform.

Your point about the TinyURL design problem is well-taken. That's a
challenge focused on scalable generation and storage. This draft is
intentionally scoped to the other side of the problem: deterministic
resolution. It's designed to be stateless and work with any given ruleset,
not define how that ruleset is generated or stored.

The motivation is to provide a "batteries-included" spec for developers and
organizations who just want their internal go/links to work consistently
everywhere.

Given this context of internal/organizational use, I'd be very grateful if
you (or others on the list) could take another look at the draft's specific
mechanisms, like the longest-prefix matching and query precedence rules,
which are key to enabling that "simple key-value" management style.

Again, thank you for your feedback.

Best regards,

Ethan Davidson

https://etok.me