Implementation requirements:

• Demonstration of use

(Copying the comment here because we're encouraged to keep discussions in threads on the diff so that they can more easily be split-tracked.)

@fnwbr said:

When describing the alternative the risk of “leaking metadata to the home server” is being mentioned.

How does the proposed solution mitigate that risk?

The proposed solution encapsulates all information related to the FHIR resource in a room event. In encrypted rooms, this event will be end-to-end encrypted. So unless the event is used in public rooms, there should be no additional metadata leakage introduced by this proposal.

(Copying the comment here because we're encouraged to keep discussions in threads on the diff so that they can more easily be split-tracked.)

@denis-loh said:

I am not sure, if it is a good idea to introduce a deep coupling to a specialized feature into a public standard. I know that there are also other use cases where custom room events are used (for instance in German BOS communication systems). If they would also contribute their custom types, wouldn't it dilute the matrix standard too much in future?

This MSC would conflict with the generalization (matrix)/ specialization (fhir) concept of the specification.

It's a fair question whether or not the use case is large enough to warrant inclusion into Matrix.

That being said, I don't think this proposal introduces a "deep coupling" between Matrix and FHIR. It's already possible to exchange FHIR via Matrix today. All this proposal does is add a handful of metadata properties to facility that. This doesn't feel much different from how URL previews include properties from the Open Graph standard just that Open Graph is probably more widely known.