Skip to content

Proposal: Relax the requirement that IDs must be "string representations of numbers" #25244

@nikclayton

Description

@nikclayton

Pitch

https://docs.joinmastodon.org/api/guidelines/#id goes to pains to point out that Mastodon IDs are represented as strings, not numbers, with:

However, this does not mean that IDs are integers, nor should they be cast to integer! Doing so can lead to broken client apps due to integer overflow, so always treat IDs as strings.

It then undoes this in the next section, writing:

With that said, because IDs are string representations of numbers, they can still be sorted chronologically very easily by doing the following:

  • Sort by size. Newer statuses will have longer IDs.
  • Sort lexically. Newer statuses will have at least one digit that is higher when compared positionally.

That sorting algorithm works even if IDs include non-numerals.

For example, GoToSocial IDs look like this, 01G65Z755AFWAKHE12NY0CQ9FH. Newer IDs have a longer length, or if the length is the same sort lexically, with newer IDs sorting before older IDs[1].

I suggest relaxing the documented requirement, and represent that as re-written documentation that looks like this:

Vanilla Mastodon entity IDs may appear to be integers. However, they are not, nor should they be cast to integers. The format may change in the future. Always treat IDs as ASCII strings with characters in the range 0-9, a-z, and A-Z.

Whatever string representation of IDs is used, across a single server IDs can be sorted chronologically with the following algorithm.

  • Sort by size. Newer statuses will have longer IDs.
  • Sort lexically. Newer statuses will have at least one character that is higher when compared positionally.

A valid Mastodon ID might be represented as "1234567890". But it may also be represented as "01G65Z755AFWAKHE12NY0CQ9FH".


[1] This is https://github.com/ulid/spec. I am not suggesting that the official Mastodon implementation adopt ULID for ID representation, that would be orthogonal to this proposal.

Motivation

Beneficial to:

  • Server authors, who want to experiment with alternative ID representation
  • Client authors, who misread the current spec as meaning that an int64 is the correct way to represent a Mastodon ID (https://tapbots.social/@ivory/110373517595723248).

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions