Ignore extra fields instead of forbidding

[tonycsoka]

The spec for lexicon, indicates that extra fields should be ignored.

Unexpected fields in data which otherwise conforms to the Lexicon should be ignored. When doing schema validation, they should be treated at worst as warnings. This is necessary to allow evolution of the schema by the controlling authority, and to be robust in the case of out-of-date Lexicons.

ATProto Lexicon#authority-and-control

Although this may change in future

The validation rules for unexpected additional fields may change. For example, a mechanism for Lexicons to indicate that the schema is "closed" and unexpected fields are not allowed, or a convention around field name prefixes (x-) to indicate unofficial extension.

ATProto Lexicon#possible-future-changes

At the moment, extra fields are causing an error, due to Pydantic being configured to 'forbid' these.
Changing the base mode ConfigDict with extra='ignore' and keeping strict=True, will keep validation, but allow extra fields.

[MarshalX]

Thank you for PR! Unit tests and documentation should be updated with this PR too

[tonycsoka]

Tests fixed, what needs to be done with the docs?

[MarshalX]

General question. How users can now access to extra fields? Previously it was easily possible with DotDict. Now tests doesn't verify that extra field value is "kek"

[tonycsoka]

General question. How users can now access to extra fields? Previously it was easily possible with DotDict. Now tests doesn't verify that extra field value is "kek"

As in the first comment, and unless I'm reading it wrong, the specs suggest that extra fields should be ignored.

From ATProto Lexicon#authority-and-control

Unexpected fields in data which otherwise conforms to the Lexicon should be ignored. When doing schema validation, they should be treated at worst as warnings. This is necessary to allow evolution of the schema by the controlling authority, and to be robust in the case of out-of-date Lexicons.

[MarshalX]

In the original SDK (js one) data is not dropped as I know. You are still able to access it. But it's out of type annotations (type script's one). I want to provide a way to access this data too

We are a not writing client for bsky. We should not limit users to a strict lexicon when protocol allows extra fields. SDK provides API to create records with extra fields. SDK should keep providing a way to work with extra fields

There are many records that already uses extra fields (non official ones). And someone could be interesting working or analysing it

We need to choose the best way that will work perfectly for both cases

[tonycsoka]

Fair enough, I'll think it over and drop this PR for now.