Bring Your Own Models (BYOM)

[dbluhm]

I would like to recommend that we restructure the API of this library to accept standard objects (i.e. dictionary or perhaps dataclass?) wherever it is expecting a Message object. didcomm-python should then perform any necessary validation for the given operation but otherwise assume the data is well structured as received from the caller.

I make this recommendation for a few reasons:

• People (including me) are opinionated about their models. Letting the caller bring their own models (or not; I think it's perfectly acceptable for people to just wing it with raw dictionary values) averts problems for our library users in the long run. This will enable an ACA-Py developer to continue to use their Marshmallow models, others to use Pydantic, still others to use attrs, and the rest to YOLO it.
• Frankly speaking, the current Message model definitions are pretty rough right now. They're defined with a mixture of attrs and dataclasses but are not actually using attrs to perform any validation; instead, the validation is done by hand.
• Most operations using Message almost immediately convert it to a dictionary and operate on that anyways.

This raises questions about what the return object of the unpack operation should be. I think there are plenty of examples out there where the caller specifies a class or a callable that can be used to deserialize the object.

I am not suggesting that the Message object should be removed altogether. If the user wants more structure than a dictionary but doesn't want to define it themselves, then Message would be available. Additionally, there's likely value in continuing to use it internally for the Forward message.

Open to thoughts.

cc @TelegramSam @chumbert @burdettadam

[mwherman2000]

@dbluhm Not just a curiosity question: have you given any thought about when to use:

1. a new DIDComm Message model, vs.
2. a Verifiable Credential attached to an existing DIDComm Message type?

Michael

[TelegramSam]

@dbluhm Not just a curiosity question: have you given any thought about when to use:

1. a new DIDComm Message model, vs.
2. a Verifiable Credential attached to an existing DIDComm Message type?

Michael

The purposes of a DIDComm message and a Verifiable Credential are pretty darn different. I don't see any real confusion here. Can you explain further what you mean? @mwherman2000

[TelegramSam]

What about behaviors a message should have? Like automatic message IDs, the ability to generate a reply from a message matching thread ids, etc? Should we not have those in favor of the flexible model? Just teasing out the implications of what you are proposing.

[dbluhm]

I think message ID insertion could be done as part of validation during pack operations, if we wanted. Generating a reply message with threading I would leave to the caller.

[dbluhm]

On giving it a bit more thought, I think all message and thread ID convenience tweaks should belong as part of the model implementation and associated helpers. This does not invalidated #64; making the Message class included with the library easier to use is a goal I think we should keep.