feat: reef notifications for RFCs should include the full RFC

[holloway]

feat

• claude should be told to only make additive API changes now that the API is live in prod.
• reef notifications for RFCs should include the full RFC, so that we have the info necessary to render the notifications more like the design.

chore

• refactor Reef to validate only the subset of Red RFCCommon schema that it cares about, and GIGO the rest. This means we delete a lot of the Reef copy of the Red RFCCommon schema because it was validating parts of the object that we never use. Instead it will just pass Red data for an RFC back to Red (the GIGO bit), and Red can validate with the narrower RFCCommon schema as needed.

[rudimatz]

As I understand, with this PR reef will store additional info about each RFC for each notification.

I think this introduces 2 issues to evaluate:

1. redundant info (rfc data is stored per user; each notification holds the RFC info, so this will grow with each new subscriber)
2. RFC data will become stale over time; RFC metadata might be updated, but the card will show the original (stale) data

I wonder if its better to have reef only store the reference (e.g. rfc10032) and get details from red's index - as I understand it works currently like that - and use that data for the cards.. possibly with some caching if needed.

EDIT: we already have cards for the RFCs in sets. can that logic be re-used for the web notifications?

[jennifer-richards]

I think this introduces 2 issues to evaluate:

1. redundant info (rfc data is stored per user; each notification holds the RFC info, so this will grow with each new subscriber)

Looks to me like it will do this. I think the red data include the abstract. If the pass-by-name method is hard to make work for some reason, I think dropping that might help considerably. Could also limit to a set of fields that are likely to be relevant.

Or run with this for now and prune later. Unless we have ~millions of notifications, the scaling is tolerable I expect.

Do WebNotifications expire and get pruned? They probably should if they don't.

2. RFC data will become stale over time; RFC metadata might be updated, but the card will show the original (stale) data

Also correct, but I think that's either acceptable or even desirable. The notification reflects the event that occurred, and later changes should get their own notification if they're important enough to call out. It should be rare.

[jennifer-richards]

Comprehensibility issue: I have read this comment several times and have no idea what it's saying

[holloway]

The 'reduction' is the subset of fields that Reef cares about in an RFC and that's what the cache has, not the full RFC document as defined by RFCCommon in Red.

The comment is saying that the cache has the subset, so we need to refetch it.

[holloway]

Rewritten. I gave some stern words to Claude

[rudimatz]

Do WebNotifications expire and get pruned?

No, currently not. Probably a question for RPC if/when they should expire

[holloway]

Storing the RFC with the notification as a snapshot was intentional (the RFC could change if we evaluated this lazily when they view the web notification).

I agree that old webnotifications should be pruned.

[rudimatz]

ok fair point... notification is "at one point in time" and might become stale