We've been relying on a variety of sources of truth for conventions on data attached to Sentry events.

For errors/transactions we have:

• top level fields on the error like user/release/environment
• contexts: expected to follow https://develop.sentry.dev/sdk/event-payloads/contexts/
• tags (some top level fields and contexts are promoted to become tags during processing)

For spans we have:

• tags
• data: expected to follow https://develop.sentry.dev/sdk/performance/span-data-conventions/

For breadcrumbs we have:

• data: no format atm, but UI and replay product relies on certain format/values in breadcrumbs

For crons we have nothing atm.

For metrics (DDM) we have:

• tags

Let's write an RFC that accomplishes the following:

1. Establishes attributes field for spans/breadcrumbs/crons/metrics that is the top level key value store for arbitrary data about a sentry signal (we can alias to data for backwards compat). Attributes will be flattened and rely on keys for separation (http.X vs. db.Y).
2. Defines attributes to follow conventions that are superset of OTEL's semantic conventions
3. Formalizes attribute conventions via some format that will be consumed by Relay/Kafka/Backend/Frontend (we can make this rust/python/js library that we publish, or just a plain json schema)

Goals:

1. There is a clear mapping between what exists today vs. attributes we want for our spans/metrics/breadcrumbs in the future
2. Everything is backwards compatible - an old SDK sending data should still keep working with modern Sentry (exceptions can apply)