Use monotonic ULIDs as the default node ID generator

[johannesmutter]

Currently, Session.generate_id() falls back to crypto.randomUUID() when no custom generate_id function is provided.

I think monotonic ULIDs would be a better default.

Why?

Svedit treats node IDs as opaque strings, but all the applications I have built on top of Svedit store nodes as standalone records rather than as a single document JSON. In those systems, documents are simply arrays of node IDs, and nodes such as quotes, tasks, or figures become first-class objects that can be viewed/ searched independently.

Using monotonic ULIDs provides a few nice properties at essentially no cost:

• IDs are lexicographically sortable by creation time.
• Creation order can be recovered without requiring a separate createdAt field.
• Simpler implementation of views like "All Quotes", "Recently Created Blocks", etc.
• Better database index locality compared to random UUIDs.
• Shorter IDs (26 characters vs. 36 for UUIDs).

Monotonic ULIDs (vs. regular ULIDs) also preserve ordering when multiple IDs are generated within the same millisecond.

Downsides

• Requires a small ULID implementation (either via the ulid package or an embedded implementation).

Migration

• Existing applications could override generate_id if they want to keep the old uuid

[michael]

Svedit itself has zero dependencies, and that's why the default id generator should use a native generator. However, every app is encouraged to come up with their own id provider. ULIDs may make sense in once scenario but should not be used in others, e.g. when you want to make it hard that ids are not guessable.

Added some docs and safe guards around id generation:

fc7c97c

[johannesmutter]

Keeping Svedit dependency-free makes sense.
Thanks for adding the docs.

---

ULIDs are not really guessable, in the sense that an attacker cannot predict the full ID, as a ULID consists of 48 bits: timestamp and 80 bits: randomness. You can't realistically brute-force or predict the random part. But yes you can know which object is older and roughly when it was created.

---

Aside of this: what do you think is a good strategy to express such "optionated decisions"?
Like I think most developers would benefit if ULIDs were the default, but that's just one example.
The demo app itself has already a few opionons. Is that the place to express them? or in the docs?
Or a more dedicated starter "app"?

[michael]

Yeah the demo app is the right place to express best practices. But i'd anyways treat them humble. Like "here's one way how you could do it, but feel free to adjust to your needs".

ULIDs are just cryptographically less secure because they are easier to brute force, since they are sorted and hence less random. Probably not a problem usually, but it really depends on the app. For the demo app, imo it doesn't really matter if we chose nanoid or ulid.