Implement isInsurance mode to block local invites and invites to other isInsurance server

[nikzen]

Description

With the new TI-Messenger Spec, there are two different kind of backends - TIM-Pro for Professionals and TIM-ePA for Patients. We need to implement a configuration option which allows this plugin to be used inside the TIM-Pro or TIM-ePA Backend.

Solution

Implement config option tim-type to switch between pro or epa.

ePA

• If enabled, the plugin needs to block all local invites.
• If enabled, the plugin needs to block all remote invites if the other server is type insurance (This information is stored on the federationList)

Pro

• If enabled, the plugin needs to enable this endpoint GET /v1/server/isInsurance
• If enabled, the plugin needs to enable this endpoint GET /v1/server/findByIk

[nico-famedly]

Strictly speaking we could also query the federation list to know, if we are an insurance and switch modes, but having a config option is probably easier :)

[jason-famedly]

I have questions:

1. Is there any expectation for more 'modes' coming in the future? If not, a boolean may be appropriate instead of using pro and epa
2. Which one should be default? Allowing time for migration may be important
3. Does 'pro' mode include the same restrictions from 'epa' mode? In other words, when in 'pro' mode local invites are allowed and remote invites are allowed(but will be blocked by another server that is in 'epa' mode. Issue famedly/product-management#2385 may be involved in such case)?

[nikzen]

I have questions:

1. Is there any expectation for more 'modes' coming in the future? If not, a boolean may be appropriate instead of using pro and epa
2. Which one should be default? Allowing time for migration may be important
3. Does 'pro' mode include the same restrictions from 'epa' mode? In other words, when in 'pro' mode local invites are allowed and remote invites are allowed(but will be blocked by another server that is in 'epa' mode. Issue Bug: Trying to start a chat on a tim-server unauthorized opens an empty chat product-management#2385 may be involved in such case)?

1. There might be a tim-connect flag as well in future.
2. I think pro should be the default.
3. Local invites: Possible with pro, inpossible with epa. Remote invites: General possible within the gematik federation with pro & epa. If the invite is possible in the end is decided by the remote server, based on the user access list.

[jason-famedly]

I found this:
https://gemspec.gematik.de/docs/gemSpec/gemSpec_TI-M_ePA/latest/#AF_10233
and I'm implementing it into #35 work, as it seems rather related to this. Does it stand to reason I should work this in here too? I feel like it's a little contrary to item 3 above.

[jason-famedly]

I believe this is complete now, partly in

• feat: Enable new back-end configuration options #37

and

• feat: Implement local room creation limitations with included invites #39