FEP process suggestion: don't use title-based hash for slug

21

It could work like this:

  • If you’re publishing a FEP without submitting it to the FEP repository: use hash ID or sequential ID.
  • If you’re submitting a PR: use sequential ID.
22

One smaller change that could help is increasing the slug truncation limit from 4 characters to 8 characters, which significantly reduces collision chances without too much extra length

1 Like
23

That could work. Extending the hash length could be something we do when we start seeing collisions.

At this point, I think it would be an improvement if we just stopped requiring the hash to change when the title changes. I’m not a fan of the numeric counter for reasons I’ve already stated.

I should have phrased the suggestion as: “don’t require title-based hash for slug”. In other words, a title change wouldn’t require a slug change.

24

516bff0c? That’s too long, too hard to memorize.

I am neutral on this proposal, don’t see any downsides. Are you interested in submitting a PR?

25

Is it really? It’s the difference between 2 words vs 1 word. Either way, I doubt “memorization” is a good criteria for FEP slugs because there are already way too many FEPs to memorize.

One downside goes like this:

  • A writes a FEP using a title that results in slug S1.
  • A changes the title of the FEP, but keeps S1 instead of generating slug S2.
  • B writes a FEP using the original title of A’s FEP (or any title that hashes to S1), and there is now a conflict between A’s FEP and B’s FEP both using slug S1.
26

This is not a new downside or one specific to what I proposed.

I’d prefer that we don’t require even the initial hash to be title-based. If it must remain that way, we could suggest that people use something like their codeberg user name as a prefix for the title (only for the purpose of initial hashing). This avoids the reused title issue although it still doesn’t eliminate the collision risk.

What’s the current official process for resolving collisions at FEP submission time? I assume the FEP author would just generate or select a new non-colliding hash.

27

Currently, the downside is that a new title might collide with an old hash. Allowing hashes to not change even when the title changes does add an additional consideration for when the old title is used by someone else (which currently isn’t an issue because changing the title changes the hash, so using the old title should result in the old hash which is “freed up” after the title change).

I don’t think there is an official process on resolving collisions right now, is there? It does seem like the assumption is that the author would just have to change their title until it produces a non-colliding hash.

Personally I think “choose your own slug based on some name policy” could be the best path forward, although “increase the truncation length” is a close second to me.

28

I suggested two potential ways to address this, although I think the clashes themselves are the significant issue and not whether the clash is caused by two different titles or a re-used title.

  1. Don’t use title-based hashes
  2. Variant: use namespaced titles for hashing (if we really need the hash to be title-based for some reason)

+1

29

I memorize IDs of my own FEPs because I often refer to them in discussions. So this property is really important to me.