Raison d'etre
GUID and UUID are not good ID schemes for the web because they are not designed for human consumption. They are too long and too hard to type, therefore not adequate for a URL. Youtube solved this problem perfectly with their 11-character video IDs, which:
- are short,
- are as easy to type as is realistic to hope for, and
- contain a lot of information in them.
Now you wish to use the same scheme in your application.
- Below is a specification. It is identical to what YouTube does, as far as we know. Let us call it "Livid".
- This project contains implementations of the spec:
- in Dart (TODO)
- in Javascript (TODO)
- in Python
Livid specification
Length and alphabet
- 11 characters long (commonly constant, though not formally guaranteed) (webapps.stackexchange.com).
- Characters drawn from a URL-safe Base64 set
A–Z a–z 0–9 - _(64 possibilities) (webapps.stackexchange.com).
Bit structure and payload
- Encodes a 64-bit integer payload.
- 11 Base64 characters ≈ 66 bits; only about 64 bits carry payload.
- The last character is restricted to 16 possible values to zero out unused bits.
The regular expression pattern for valid IDs is [A-Za-z0-9_-]{10}[AEIMQUYcgkosw048].
Encoding process
- Generate a random 64-bit unsigned integer.
- Encode in Base64, producing an 11-character string.
- Standard Base64 uses
+/; we replace/with-and+with_for URL safety. - No padding (
=) is used, as the length is fixed (stackoverflow.com, wiki.archiveteam.org, webapps.stackexchange.com).
- Standard Base64 uses
- If the integer collides with an existing ID, regenerate. Collisions are extremely rare in such a large space.
Collision and randomness strategy
- IDs are randomly generated, not sequential, to avoid enumeration, scraping, and privacy leaks (reddit.com).
- Collision-checking ensures uniqueness.
Validity and guaranteed uniqueness
- Though the 11-char format is stable, there's no official commitment to keep it permanently (webapps.stackexchange.com).
- To validate or test an ID, you must query the existing data (webapps.stackexchange.com).
Summary table
| Feature | Description |
|---|---|
| Length | Exactly 11 chars |
| Character set | [A–Z][a–z][0–9][- _] |
| Encoded data | 64-bit + 2 unused bits |
| End-char restrictions | Only 16 values (last 2 bits zeroed) |
| Generation method | Random + Base64 URL-safe encoding |
| Collision handling | Check uniqueness, retry on conflict |
| Validation | Query the server/API |
| Guarantee | No official guarantee on format stability |
Metadata
Release files for livid 0.0.2
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | Provenance | |
|---|---|---|---|---|
| livid-0.0.2.tar.gz | 3.8 kB | Without provenance | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| livid-0.0.2-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 7.9 kB
Release files / livid-0.0.2.tar.gz
| Download URL | livid-0.0.2.tar.gz |
|---|---|
| Size | 3.8 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
932d64834d819bc6402c001740da23bbf1cbaa10e5fa752e06505079dcce28ab
|
|
BLAKE2b-256 checksum How to use checksums |
4514b88ddccc4995a26739a0ca7ce2048b7f74b594a0acc4225c5e039fd6d57b
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
poetry/2.1.3 CPython/3.12.9 Linux/6.1.0-37-amd64
|
Release files / livid-0.0.2-py3-none-any.whl
| Download URL | livid-0.0.2-py3-none-any.whl |
|---|---|
| Size | 4.1 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
e582412d52f84bc72bc7afe0b575a1adc11a964892e7eb08cc123b1f50b21fcc
|
|
BLAKE2b-256 checksum How to use checksums |
ce7f3f6184ce1d8d8cf677c444061e615cb72486aeeb520a0c8a8714354b9571
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
poetry/2.1.3 CPython/3.12.9 Linux/6.1.0-37-amd64
|
Security for livid 0.0.2
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
No provenance found
None of the files in this release were uploaded with provenance metadata.
A note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.
To learn more about protecting yourself from malicious actors, visit our package security documentation.