Oh, the other big reason is the deserialization pipe needs to be aware of these things.  If the UI sends you a custom event (which we dont' have wired yet), we need to have our serializers available on that thread/socket to appropriately deserialize.  That's why I used the non-blocking concurrent map so we can register these things and start getting semantic messages on-demand.   Not sure it's the best design (and I hate globals generally), but couldn't think of something better, and it only exposes what I already had.   I'm hoping the design of the setting to register serializers means we aren't locked to the `DynamicSerialization` global, and I think maybe I should expose the *interface* for serialization on the sbt client side (e.g. you have to register through your sbt Connector (I can do that now).