Facilitating cross-operator patch requests as an alternative to full pairing

[Arlodotexe]

Background

The 'Nomad' library was designed to facilitate making convergent state updates from multiple operator-owned nodes or devices.   Adding an event stream from another node as a source is considered 'Pairing' and is recommended to be treated as login-like functionality for a node operator, as it allows a single node operator to bridge their multiple devices.

Problem

'Pairing' is something that should only be done between devices owned by the same 'node operator', since events from a source are always applied to the relevant handler. There's no fancy gating functionality for events between paired devices, because "paired" means "fully trusted", akin to a login.

Further, there's no precedent on how to facilitate "patch requests" across node operators. This is something we need to carefully flesh out, leveraging the existing system when possible.

Observations

Event stream handlers are only needed when you're publishing to the roaming state, as the latest roaming ipns published by other nodes cannot be retrieved when you're also publishing to it.

In other words, roaming data from another node operator is always read-only, and won't need an event stream handler to read the data. It's simple, static json that cannot be modified.

If you wanted to modify a read-only roaming state anyway, you could:

• Create an event stream handler with an unpublished/empty event stream, starting at the read-only roaming state.
• Use the handler normally to make local-only modifications.

The change won't be reflected in the roaming data since you aren't a paired source, but it would appear locally. This maintains the separation between node operators and offers a solid entry point for designing a "patch request" system.

Proposed Solutions

Given the above observations, we could extend the idea of local-only modifications to a "patch request" system.

Creating event stream diff

We can re-use a modifiable handler to create a diff of event stream entries against the current read-only state for the patch.

• Create an event stream handler with an unpublished/empty event stream, starting at the read-only roaming state.
• Use the handler normally to make local-only modifications.
• When modifications are complete, collect the new event stream entries and publish the patch request for the read-only operator to see.

Publishing patch requests

Patch requests need to work in a fully p2p environment, which includes node operators keeping the common 'roaming' key online even as source nodes go online or offline. This is what Nomad was built to do, so we'll build this "patch request" using a standard Nomad setup.   To publish a patch request in a standard Nomad setup, you need:

• A new local event stream key to hold updates to proposed patch diffs and metadata.
• A new roaming key to consolidate changes from all nodes owned by a single operator.
  • Ideally, patch requests are published separately from instead of integrating with existing roaming data. This allows "patch request" events to be added to one or more local event stream while still consolidating those sources into a single "patches" roaming key.

Delivering patch requests

Users will also need a way to deliver the roaming key containing patch requests to the node operator of the read-only roaming data.

Available options are:

• Mutual registration with a third party (Routed or registered + recurringly observed)
  • Depends on a third party to stay online
• Ambient discovery (pubsub, real-time)
  • Works in a fully distributed manner
  • Discovery is probable, but not guaranteed
• Manually added (recurringly observed)
  • To observe change requests, the roaming cid of another operator is supplied directly by the user or other tooling.

Our best option may be enabling a combination of these.

Handling patch requests

Change requests can either be handled manually or automatically via rulesets.

Open Questions

• How is the requester notified of updates regarding their patch request?
  • Routing is delegated externally, so this depends on the consuming application.
  • Regardless of patch state reporting, a successful patch should be reflected by roaming/source.
  • This may be difficult to detect efficiently, depending on if the Cid of the patched event entry changes.
• Do patch requests need expiration or cancellation?
• How is a patch request stored in the local event stream?
  • Single, dedicated event entry wrapper?
  • Raw event entries as-is?
  • Any additional patch metadata?
• Should the timestamp for an accepted patch be the time of request or the time of review?

Prerequisites

Needs https://github.com/Arlodotexe/OwlCore.Nomad/issues/3

[Arlodotexe]

Covering exploration of the idea of consuming an event stream source directly from another node operator (co-operator) without publishing to the roaming key (partial pairing), we could do this and have pre-defined rulesets for ingesting specific events.

However, it's become apparent that using a single event stream source from another node operator isn't viable, as an event stream only represents one source device and could go offline.

The fix to this is to consume a roaming key instead, at which point your implementations is looking like just another Nomad module that could be bundled separately. Given this, it still makes sense to build a reuseable library for event stream patch requests between operators.