Checklist

• I've searched the issues and pull requests for similar looking suggestions.
• I've checked the Unreleased section of the changelog for newly added features that sound like my suggestion.

Describe your Suggestion

An API could exist for a custom endpoint to be able to configure which events should be sent.

In its simplest form, this could consist of a single new message type being sent to the endpoint upon login, like for example "GET_CONFIGURATION", which would then read the response and try to interpret it as a serialized configuration for the plugin, much like the ::dinkimport command.

However, there are 2 main concerns with this feature that I think might require some further consideration which may make this feature a bit more complicated;

Transparency & clarity

While no one should assume that the data which this plugin might broadcast would be private otherwise, it still seems appropriate to ensure that the user is either made aware that it is being shared by the plugin, or still has a say in whether or not it does. Here are some ideas that might help make that happen:

• A popup/dialog window could be shown whenever an endpoint requests the configuration to be changed, which the user may confirm or deny. (Assuming this is within runelite's capabilities.)
• A prefix in the endpoint URL could be used to determine whether the webhook should have this capability. For example auto@http://www.myendpoint.com might have the ability to automatically update the configuration, while http://www.myendpoint.com might not.
• A single toggle in the plugin's configuration could control whether endpoints may or may not update the configuration.

Conflicting endpoints

Since this plugin includes the ability to work with multiple endpoints, a situation could occur where multiple endpoints are trying to make changes to the configuration which may end up contradicting another. While multiple endpoints may not be the most common, let alone those supporting this new feature, it might still be worth taking into consideration. Here are some ideas that might help remedy that:

• All configurations could be collected and combined into one configuration before being applied, in a manner such that both endpoints will at the very least get every notification they are trying to receive. If one endpoint specifies a notifier to be enabled, while another does not, the notifier would stay enabled. If one provides a lower minimum loot value than the other, the lowest minimum loot value is used. Since only custom endpoints are capable of specifying a new configuration, it can be assumed that they are also capable of filtering out notifier messages that do not meet its criteria.
• A configuration per endpoint could exist. This is a rather significant change, but seems to have been requested before.

Reasoning

While the advanced configuration and active updates are brilliant aspects of this plugin, it does make maintaining an ideal configuration for a given endpoint a bit of an involved and manual chore, even with the already convenient ::dinkimport command.

Allowing for the endpoint to configure the plugin automatically would benefit the user in the following ways:

• It makes the first time setup much simpler, as it will only require entering a single URL.
• If the plugin adds a new feature that requires to be enabled in the configuration, it can be done so automatically by the endpoint with no user intervention.
• If the endpoint requires a change for other reasons, such as; A mistake was made in the previously provided configuration, or the endpoint has to remove high-traffic notifiers for bandwidth reasons, it can be done so automatically.