Including FSSSignalDiscovered event to list of allowed events to send over EDDN

It will allow EDDN listeners to:

1. Track FCs movements
2. Track combat zones
3. Track Resources extraction points (not quite useful since body info isn’t included)
4. Track NonHuman signals
5. Track high grade emissions signals
6. Track installations
7. Match FCs IDs and names

In order to decide which fields have to be removed I analyzed all keys in all my own journals record for FSSSignalDiscovered event, here is the list with some comments:

SignalName
TimeRemaining - on USS, I don't think it can be useful for anybody but I also don't think it is private information
timestamp
SpawningFaction_Localised - candidate to removing
SignalName_Localised - candidate to removing
IsStation
USSType
USSType_Localised - candidate to removing
SpawningState
SpawningFaction
event
SpawningState_Localised - candidate to removing
ThreatLevel
SystemAddress

There is also an event type that can be considered as personal information, it is missions related signals

{ "timestamp":"2021-10-27T20:33:30Z", "event":"FSSSignalDiscovered", "SystemAddress":3107509342922, "SignalName":"$USS; ", "USSType":"$USS_Type_MissionTarget;", "USSType_Localised":"Mission target", "SpawningState":"$FactionState_None;", "SpawningState_Localised":"None", "SpawningFaction":"$faction_none;", "SpawningFaction_Localised":"None", "ThreatLevel":4 }

Also please note that every jump for single player can generate more than 100 FSSSignalDiscovered events.

Additional values: horizons odyssey StarSystem StarPos With appropriate values as in journal-v1.0.json schema.

[Athanasius]

The new schema has been live for many weeks now without anyone bringing up an issue, so closing this.

[clonedArtie]

It’s easy to parse though. I certainly recommend for the specs that senders MUST NOT alter the SignalName any way.