Revise repo write validation for unknown Lexicons #2748
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
To date when using
com.atproto.repo.{createRecord,putRecord,applyWrites}
to write to a repository, by the default the PDS will reject any writes into a collection with a Lexicon unknown to the PDS. This behavior is controlled by thevalidate
input. We would like to change this behavior in order to be forward looking into a world where a PDS may have a dynamic set of Lexicons that are either resolved on the fly or otherwise loaded at runtime.Record validation by the PDS is a driver of coherent/compatible data across the network, but network participants can't rely on all data in the network adhering to a given Lexicon: ultimately each party (e.g. an appview, feed generator, or client app) needs to validate repo records themselves. So while validation within the PDS is very useful to nudge applications towards writing proper data, it provides no strong guarantee. Furthermore, a PDS's access to a given Lexicon should not be a bottleneck to users' usage of apps that rely on it. Otherwise you could easily imagine downtime of a service that serves a given Lexicon cascading into write degradation for all apps making use of it. Since validation at the PDS provides no strong guarantee, it's not worthwhile to have such a bottleneck.
The proposal here is to a. loosen the requirement that by default the PDS must have a given Lexicon to permit writes, b. report back to the caller whether the PDS was able to perform validation. More specifically we'll update
com.atproto.repo.{createRecord,putRecord,applyWrites}
such that:validate
input no longer has a default (technically a breaking change for PDS implementations). Whenvalidate
is not set, the PDS will perform validation for any Lexicons available to it and skip validation for any Lexicons unavailable to it.createRecord
andputRecord
include a new optional fieldvalidationStatus
that will be set to'valid'
if the PDS was able to validate the record and'unknown'
otherwise.applyWrites
method now has a response containing the a list of write results, preserving the order of thewrites
input received.