[Resolved] Lightweight or heavyweight messages

[afrittoli]

Lightweight events only transport metadata about the event that occurred and permanent links to artefacts.
Heavyweight events transport artefacts too, such as execution logs, test results and binary content.

Pros of lightweight events:

• less CPU utilisation for all components sending / transporting / receiving the event between sender and recipients
• less network traffic
• artefacts only downloaded when actually needed - i.e. if a recipient is going to ignore a message, it should not be forced to receive large content associated to it
• the producer of the artefacts can decide who may access them
• the producer of the artefacts may control their lifecycle and expire them if needed

Cons of lightweight events:

• artefacts may not be accessible by the recipient of the message
• artefacts may be expired once the recipient of the message tries to download them
• artefacts might get compromised (e.g. via man-in-the-middle attack)
• extra download / logic is required to download artefacts once the message has been received, which might be an issue in case of hermetic builds / isolated environments

Personally I feel that pros outweigh cons, and workarounds are available for some of the cons:

• artefact shas and signatures can be used to avoid compromised artefacts
• a proxy may receive the event, apply the filter, download and validate the artefacts if needed and send another event with embedded artefacts to trigger a build in case of hermetic builds

[sbtaylor15]

I agree with using a light weight message as long as you have the "links" to get the heavy weight data. This also allows for securing the heavy weight data by doing authorization of for the person wanting that data. For example, a private repo event happens and downstream several events later the "user" wants to get heavy weight data from the git repo. That "user" needs to have access to the private repo otherwise the should get an access denied.

[erkist]

I also vote for light-weight messages in the spec. I assume users could add more info if their specific use case needs it, but the spec itself should be kept light-weight.

[m-linner-ericsson]

Agree, reading from https://github.com/cloudevents/spec/blob/v1.0.1/spec.md#size-limits

Generally, CloudEvents publishers SHOULD keep events compact by avoiding embedding large data items into event payloads and rather use the event payload to link to such data items. From an access control perspective, this approach also allows for a broader distribution of events, because accessing event-related details through resolving links allows for differentiated access control and selective disclosure, rather than having sensitive details embedded in the event directly.

I like this definition and would like us to base our protocol on it.

@sbtaylor15 would you agree to this definition?

[sbtaylor15]

Yes, I agree.

[m-linner-ericsson]

Apart from #77 what is left in this discussion?

[erkist]

Probably nothing. I will resolve this discussion.

Decision: We should go for light-weight messages