RFC: Specify the Protocol schema to be a local object rather than a website for type checking

[shamilovtim]

The intention behind the schema field is ostensibly to provide a sort of public shared shape of what a given protocol may look like. However there seems to be no mechanism for pulling this locally and validating it at compile time. If instead we have this field be a local JS object (and therefore allow it to be imported from an npm package) the Protocol a dev is registering can then be type checked at compile time and we can validate its shape through the type checker and intellisense. The exported ProtocolDefinition type can then take a generic and validate it against the schema the user provides to the protocol they are registering.

Related: https://github.com/TBD54566975/web5-wallet/pull/58

[shamilovtim]

Related: https://github.com/TBD54566975/web5-wallet/issues/73

[thehenrytsai]

The intention behind the schema field is ostensibly to provide a sort of public shared shape of what a given protocol may look like.

A slight correction would be: the intent is to provide a sort of a standardized shape of what a given record may look like. If we allowed a local JS object to be used for validation, then:

1. It would be a bit of an anti-pattern because it is not much of a "standardized schema" if the definition comes from the DWN itself.
2. Are we to trust/use whatever that JS object says for validation? This is a rhetorical question as it is a can of worms: can this JS object for validation be modified? If it is modified, do we re-evaluate existing records?
3. There is no way for us to validate record schema if the record is encrypted.

For the above reasons we don't get into the business of schema validation and defer the validation to applications.