Sharing an event stream source across different event stream handlers

[Arlodotexe]

Apps that use Nomad don't always need to create separate event stream keys for each part of the application that uses the library (e.g. Nomad-enabled storage sync, peer sync, project data sync), even if they add a source created by another running application.

With the way event stream handlers are set up, we could use one single event stream across multiple types of event stream handlers in the same application.

In contexts where Nomad is used to converge data into a 'roaming' state this final state should never affect the event stream, meaning if the inner EventStreamEntry.TargetId are properly unique then this enables safe sourcing of multiple roaming states from a single event stream.

The only thing preventing this as of writing is that EventStream has an explicit TargetId that represents a single distributed object that the event stream applies to, which so far has acted as a sanity check but is reflected in some of our helpers in OwlCore.Nomad.Kubo and OwlCore.Nomad.Storage.Kubo.

[Arlodotexe]

This has functional analogy in how the kubo-based storage implementation of nomad works, where the root object contains the full roaming dag / event stream while child objects contain a subset of the roaming dag or event stream entries. The event stream entries contain a unique TargetId, but this doesn't necessarily correspond to a roaming key.

In the storage implementation, it corresponds to an OwlCore.Storage.IStorable.Id string, which is implemented as the roaming key + a path to the item.

There's work being done to reassess the inbox AllEventStreamEntries member on IEventStreamHandler, for reasons tangential to the issue outlined here. It's unclear if this member is truly necessary given that these simply cache the resolved event stream entries for re-use or trickle-down.

The plan is to do this on the implementation and remove it from the interface, if we can.

Important distinctions:

• TargetId exists on both EventStream<T> and EventStreamEntry<T>
• In order to share a single event stream across different handlers, we should either:
  1. Set both handlers to the same event stream, filter individual events by TargetId.
     • Is feasible as long as TargetId only exists on EventStreamEntry<T> and not the event stream itself.
  2. Create new event stream objects to represent the 'subset' of event stream entries applied to that object.
     • Not feasible unless TargetId is removed from EventStream<T>.
     • Is feasible regardless of whether TargetId is on EventStreamEntry<T>.
• Some handlers can be 'virtual' in a sense, inheriting the data needed to operate as a handler from the parent but not necessarily acting as a publishable roaming root.
  • Only in this scenario would you pass down something like AllEventStreamEntries, or more aptly, ResolvedEventStreamEntries.
  • Requires TargetId on event entries, but not on the event stream itself.
• Some handlers only yield other root handlers, to which entries are always resolved on instantiation.
  • Since each handler is a new context each time there are no 'resolved' entries to pass it. It would need resolved on each instantiation or cached just outside the factory. This encourages sparse resolution.
  • Caching via the repo (which is always available to root handlers, not usually via virtual handlers) takes care of re-resolution if an object is referenced many times throughout a graph.

In short, the inclusion of TargetId on event stream entries enables sharing an event stream (resolved or not) across related but distinct classes, whether they're actually published together or are aggregated at runtime.