Question about "not used for storage so rendering is not significant" about equinox HOT 1 CLOSED

Hi, thanks fort taking the time to ask the question...

The main point with Guids is that there's the rendering with dashes (.ToString()/string) vs the un-dashed representation with .ToString("N")

Within JSON, when rendering/parsing with Newtonsoft or STJ, there's going to be a default rendering (with an option to globally override that).

The comment is drawing attention to the fact that the issue of having a canonical rendering is not relevant as there's no such reflection-driven usage.

You're correct to also consider the XSS aspect (and when you embed a value within a stream name, you need to be sure that it'll be acceptable in any store you maintain it in - i.e. embedded quotes may or may not trigger issues etc)

(The contact preferences aggregate uses an email address in the stream name, which is a pretty bad idea and could do with. being fixed (you need to canonicalize things etc) as its misleading to anyone that'd not got all these concerns internalized to the degree you clearly do)

Most of these Id types were developed (and used in prod) to varying degrees before the arrival of FSharp.UMX.

In general, I tend to use it for UMX strings as a default; IME it's a pragmatic choice in that:

• there's good compile-time type safety, which is generally when it matters for ID types
• if you use it within a model that either gets persisted as an event, or gets serialized directly out as a view model by STJ or Newtonsoft, there's no question of the canonical rendering (which can be problematic with Guids)
• you can't mess up the serialization like you can with an SCDU or any other representation
• while a string is no perf panacea, it can often outperform a Guid as e.g. a dictionary key
• there's relatively few allocations compared to e.g. SCDUs

Of course, there are negatives too:

• you can't Make Illegal States Unrepresentable like you can with SCDUs
• STJ in particular doesn't have good ways of managing validation (and UMX'd strings can't be told apart at reflection level anyway)
• strings are about as prone to XSS as it gets

So, this brings us to two sets of questions:

1. your particular need, and its specifics esp wrt XSS. In general I'd start from the position that you should be modelling how you're going to validate and canonicalize such things as a concern separated from an actual event-sourced model - at the point where you're using Equinox or something equivalent to read a stream with a name derived from a specific id, you should be in a position where you're not second-guessing XSS concerns anymore
2. the samples, and whether they represent best practice - probably not; in general they're trying to cover a variety of real things that have been done, but e.g. the email in the stream name are clearly wrong (would consider taking a PR if you're interested).

I think there's definitely changes to the samples and/or extensions to the comments that would help a future you get more answers than questions compared to what there's there atm.

The specific question of stream names and canonicalization is covered in more detail in FsCodec's readme - if you have any ideas how to express canonicalization and XSS concerns more completely I'd definitely like to hear them over there...

Hope this helps a little; feel free to refute or ask follow-ons ;)

from equinox.