Raid management should be moved to be ledger based.
Raid will be a creation in the addon and will be conceptually related to the ingame raid. Purpose of this change is to enable easy raid management across multiple raids happening in the same time, with a disconnect protection.

This change will consist of 3 modules (MVC):

1. Raid Manager Module (Controller)
2. Raid object Model
3. Raid Manager GUI (View)

High level features that are expected from the Raid Manager:

• Everyone should be able to access the list of currenty active raids
• Assistants should be able to create raids. Creator becomes the Raid Manager (RM) (naming unclear - TBD?)
• Raids should be named (or have a description) for further reference
• Raid creation should require a roster selection and the raid should be tied to a roster (multiple raids should be able to use same roster)
• On creation Raid should be populated with players in current raid (if creator is in raid). Missing profiles and adding to roster should happen automatically.
• One player can be only present in only one raid
• "RAID_ROSTER_UPDATE", "GROUP_ROSTER_UPDATE" events should be used to detect change in group roster (players joined/left raid) and update the raid roster and if a change is detected then the Raid needs to be updated. Worth being aware that this events may come often and in huge numbers so bucketing them might be worth consideration (check EventManager). This should be handled only by RM.
• Assistants should be able to take over Raid Manager role anytime if current RM is not in the mentioned raid or is offline as a failsafe. The new RM needs to be in the raid to overtake
• We assume that we are in specific Raid if at least 5 other players in current raid are same as the stored player information - review this requirement TBD. This is needed to connect current game status with the stored information
• Raid Manager becomes the only person that can award raid-based points (on kill, interval, on time, end time, standby bonuses)
• Items may be auctioned by any of:

1. Master Looter if one is present and is an Assistant
2. Raid Leader if no master looter is present and he is Assistant
3. Raid Manager

• Only the Raid Manager can end the Raid

Backend mechanisms

• Raid creation / changes / starting/ending should be stored in the ledger
• Raid could be in multiple states (TBD): Created -- state change --> In Progress -- state change --> Ended. This type should be derived from the events in ledger

Ledger changes

• Add Ledger entries for:

1. Raid creation, containing:

• List of players (integer GUID) in raid (can be empty if not in raid),
• raid name/description
• selected roster id (what happens if roster gets deleted during raid? - TBD)
• [optional?] modified configs if using different than roster default

2. Raid update containing (assuming batch update):

• Raid UUID
• List of joining user iGUIDs
• List of leaving user iGUIDs

3. Raid end

• Raid UUID

4. Raid Manager overtake:

• Raid UUID
• New manager iGUID (integer GUID)

5. Point Updates for raid:

• player iGUID list
• raid UUID
• value

6. Modify loot to have optional raid UUID to connect loot to a raid

GUI

Easiest approach here would be to copy-paste the profile GUI and implement it in simlar way.

• There should be a list of raids
• Hovering over raid should show current RM and Players in that raid
• There should be management options (either dropdown menu or ace options like in profiles)
• Players should have option to singup to a Standby list to a raid - TBD

Standby flow is still undefined: Should it be also stored in ledger or should it be temporary?
How many raids should player be able to sign bench to? Should this limit be related to raids or rosters used by raids?

I propose removing constraints that are not strictly necessary for first implementation:

One player can be only present in only one roster

This seems to be unrelated to raid, or do you mean one player can only be present in one raid?
These kinds of restrictions are hard to guarantee; we must define what happens if we see something that violates this, for example: a player X is in raid Y event is ignored if player X is in an active raid or something like that

Assistants should be able to take over Raid Manager role anytime if current RM is not in the mentioned raid or is offline as a failsafe. The new RM needs to be in the raid to overtake

I propose not removing the constraints. Allow assistants to overtake any time; also don't require them to be in the raid.

Raid Manager becomes the only person that can award raid-based points (on kill, interval, on time, end time, standby bonuses)

The risk of doubling up on events like this can be easily mitigated:

1. On kill is unique per raid, so duplicate events can be simply ignored.
2. On time and end of raid occur at most once so duplicate events can be ignored.
3. Interval can easily be deduplicated as well; if we have minimum interval of 5 mins (which is 10x lower than the expected interval) then it is easy to deduplicate any events closer together than 1 minute.

We assume that we are in specific Raid if at least 5 other players in current raid are same as the stored player information - review this requirement TBD. This is needed to connect current game status with the stored information

What is the use of this extra check? Why not accept that we are in the raid when ledger tells us we are?
Assumptions must have a purpose, for me the purpose of this one is unclear. For things like point overview etc the ledger is leading even if I'm not invited yet.
Also if I'm on the bench, addon-wise I can be considered in the raid etc.

"RAID_ROSTER_UPDATE", "GROUP_ROSTER_UPDATE" events should be used to detect change in group roster (players joined/left raid) and update the raid roster and if a change is detected then the Raid needs to be updated. Worth being aware that this events may come often and in huge numbers so bucketing them might be worth consideration (check EventManager). This should be handled only by RM.

Again I feel limiting the event handling of this to RM is unnecessary. Mutators can very simply handle duplicate events.
An approach where any assistant in the raid only creates the events if he hasn't received them, combined with every assistant picking a random delay should be good enough and simpler to implement.

Also, we need a way to manually do this, my proposed implementation would look like this:

1. On event or manual trigger mark raid as dirty.
2. On recurring timer of ~10s check if raid is dirty, if so calculate changeset (as separate or single join / leave events) and broadcast it. If changeset is empty (because maybe we received an event from someone else) then just mark raid as not dirty.

This approach simplifies implementation at the risk of getting a little bloat in the ledger.

Point Updates for raid:

If this is for the full raid we should not use include the player guids, we can get them from the state easily.

Raid Leader if no master looter is present and he is Assistant

I'd drop the if no master looter is present requirement.

Only the Raid Manager can end the Raid

Imo this can also be dropped; any assistant could do it. It should have confirmation and if people screw up we can easily reopen raid (via IGN)

Many of the above constraints are there just to resolve the duplication problem. I'll look into creating a more generic solution at the sync level.
Think of an API that roughly does this:

1. Propose entry using a custom deduplication key (for example: raid id, type: bosskill, boss: XYZ)
2. After 5 seconds everyone who proposed can decide who has prio and therefore know whether to broadcast or not.

The advantage of this approach is that CLM doesn't need to worry about it and we can optimize for it at the comms layer.

Note that all of my suggestions are based on the assumption that the constraints are in place to help with implementation, data integrity and deduplication.

[optional?] modified configs if using different than roster default

I think raid start entry should contain all config for the raid. Otherwise you must solve for situation default config changes during raid. Mostly this is interval / start / end DKP values right?