it seems reasonable to me that commits with non-authorized data would not be shared to other role-holders before first being returned to the party that can do the authorization.

Even if it does, that would still be fine as blame can clearly be laid at the party claiming a role and then not signinf off on the data, either because:

1. if you disregard the data then there is unfullfilled requirements, or
2. if you consider the data then there is a party that hasn't yet signed

So it comes down to the question of "did entity X call signInivitation()?"

If they did, but didn't sign the other data, then that data is to be disregarded (treat it as it simply wasn't there). If they didn't, then treat treat the invitation as non-complete as a role requirement still remains to be fullfilled.

approved now so that I can see in the log that I have reviewed and approved this earlier and can re-review only the changes.

I assume these either are no longer needed, or have been moved elsewhere prior to this MR.

this creates two storage adapters.

I assume it's better to do "const storageAdapterPromise = createStorageAdapter(...);

then await expect(storageAdapterPromise...

./ doesn't seem like a temp directory.

maximum of 1 here, but checks in this MR compare against both >1 and >2

Fixes the follwing issues:

• #2
• #8
  • Populated the sent/send information
  • Add role based descriptions for other non-receive transactions
• #12
  • Correct tenses
  • Spelling Mistake
  • Role based description in output
• #18

And other non-reported issues

Minor descript changes pending, this all looks good to me.

same here, could drop "to the receiver."

same here, could drop "to the receiver."

same here, could drop "to the receiver"

same here, could drop "to the receiver"

similar here, could drop the "to the receiver" (where else would it be sent?)

This could be "Sent $()" for simplcity.

the "to the receiver" doesn't really add much value, I think.