Identity database schema and publishing algorithm

[richardhuaaa]

I would love feedback on the publishing algorithm and resulting schema, if I've missed an edge case or if anything has been over-complicated. I will polish and publish the description somewhere more logical in the next PR.

I've optimized for:

• More expensive writes in exchange for more performant reads
• Support for high concurrency/reentrancy
• Consistency and correctness

Being able to resume a publish after the server goes down is a side effect and not a primary goal

[richardhuaaa]

The other thing to consider is with any event log like this, validation on each subsequent publish gets more expensive as the log gets longer. Is there a denial-of-service attack possible here by repeatedly appending to one inbox_id?

[neekolas]

The other thing to consider is with any event log like this, validation on each subsequent publish gets more expensive as the log gets longer. Is there a denial-of-service attack possible here by repeatedly appending to one inbox_id?

Completely agree. We are going to have to have some sort of overall limit to the length of the event log. Not just a denial of service on the nodes, but also on other group members who have to download and process these logs.

50? 100?