Event Headers (was: Memo and Created At Fields)

[skilesare]

Do we feel like we need a memo or create at field for any of our update methods?

[JupiterM]

I think, at least for updates, a memo could be a good idea as it would allow for separation of state changes from information about state changes.

[skilesare]

Events: Do we want headers - Lachlan?

• Event: Signature of the Data if necessary
• Relayers and broadcasters could push data for logging and delay tracking.

Austin: Write up Headers.

Publication/Subscription: Do we want memo for? Yes...

Austin write it up.

[skilesare]

Added the following sections for Headers:

Event Broadcast Canisters and Event Relayers MUST NOT manipulate the data field. Any data annotations should be done in the Header collection.

Event Headers

Events also have an optional header property that, if provided should be an ICRC16Map. This collection allows for the emitter to provide additional data that is not directly relevant for the item, but that may be important for validation or measurement of the event. As the event travels from the publisher, through a broadcaster, a relay and ultimately to a subscriber, the network participants may add headers to this collection.

For the purposes of this standard the following headers are established:

icrc72:eventData:hash - a #Blob containing the representational independent hash of the event. icrc72:broadcaster: received - a #Nat the timestamp that the broadcaster received the event. icrc72:broadcaster:priority - a #Array of #Nat where the first item is the position in priority and second item is the total subscriber count. icrc72:relay:sent - a #Nat the timestamp that the broadcaster sent the event to a relay. icrc72:relay: received - a #Nat the timestamp that the relay received the event. icrc72:broadcaster:sent - a #Nat the timestamp that the broadcaster sent the event.

Data Type Update

  type Event{
    id: Nat
    timestamp: nat
    namespace: text;
    data: ICRC16;
    headers: ?ICRC16Map
  };

  type EventRelay{
    id: Nat
    timestamp: nat
    namespace: text;
    source: principal;
    data: ICRC16;
    headers: ?ICRC16Map
  };

  type EventNotification{
    id: nat;
    eventId: nat;
    timestamp: nat
    namespace: text;
    data: ICRC16;
    headers: ?ICRC16Map
    source: Principal;
    filter: ?text;
  };

Updated the following admin types with a memo field:

type PublicationRegistration {
  namespace: text;
  config: [ICRC16Map];
  memo: blob;
};

Appendix: [Allowed Publishers and subscribers should use the config](https://github.com/icdevs/ICEventsWG/issues/18)

type PublicationInfo {
  namespace: text;
  config: [ICRC16Map];
  stats: [Map];
}

type PublicationUpdateRequest = {
    publicationId : nat;
    config : opt [ICRC16Map];
    memo: blob;
};

type Skip = record {nat; opt nat};

type SubscriptionRegistration {
  namespace: text;
  config: [ICRC16Map];
  filter: ?Text; 
  skip: ?Skip;
  stopped: bool;
  memo: blob
};

type SubscriptionUpdate = {
    subscriptionId : nat;
    newConfig : opt vec {text, ICRC16};
    newFilter : opt text;
    newSkip : opt opt Skip;
    newStopped : opt bool;
    memo: blob;
};

[lachlanw]

1. I like the fact that the headers data structure is explicitly a Map some other internet protocol specs don't force this and leave parsing of header lines to the developers choice of code library; however it would require unique key values so how do we handle repeated keys of the same standard name? By concating an id?
2. Example would be if message passes through multiple relays. If an event relay canister appends a "received" or "sent" header to an event, should an identifier for that canister be added to the header key value? e.g. "icrc72:relay:sent:$relay_id$"
3. There is a trivial typo error in the list of header defs which should be checked in the corresponding additions to the draft: "icrc72:broadcaster: received" and "icrc72:relay: received" (extra space in each)