Nested threshold

[andrewzhurov]

#122 introduced weighted clause to fill the use-case hole of MultiSig AID of MultiSig AIDs.
E.g., we have Alice and Bob and Carol, whose MultiSig AIDs have threshold of

[1/2 1/2 1/2]

now, when they assemble to a group MultiSig AID, they only need to agree on weight of each member,
and their corresponding threshold can be slammed in as is, handy!
Say, they agreed to have 1/2 for each member:

[{1/2 [1/2 1/2 1/2]}
 {1/2 [1/2 1/2 1/2]}
 {1/2 [1/2 1/2 1/2]}]

The caveat is that it's possible to slam in only a single-clause threshould (actually, it's clause), as presently threshold as "a list of clauses that are ANDed together" is a special root-level construct, afaik.
Were, say, Alice use

[[1/1] [1/2 1/2 1/2]] ;; requires 0 and any 2 of 1,2,3

she's out of luck to preserve this config when joining a group MultiSig AID.

To that end, is it worth considering to allow threshold appear within a threshold?
So we can have happy Alice in that MultiSig group as:

[{1/2 [[1/1] [1/2 1/2 1/2]]
 {1/2 [1/2 1/2 1/2]}
 {1/2 [1/2 1/2 1/2]}]

[SmithSamuelM]

@andrewzhurov

In general the solution to more sophisticated or more complicated weighted clause examples is to develop a syntax that supports a recursive descent parser for nested AND/OR Clauses. This has drawbacks in terms of the complexity of such clauses. So we have been reluctant to go that far, believing that there were yet to be real world use cases that justified that complexity. Obviously one can manufacture use cases as you have done to need another layer of nesting and then another and so on.

Given that the rest of the SSI world does not even support a single weighted clause, we have been conservative about adding such a feature.

That said, a syntax that supports recursive descent is not impossibly difficult to develop. The caveat is that we have productions instances of KERI that would break unless the new syntax were fully backwards compatible. Which complicates things a lot.
So we need to have fully backwards compatible syntax that is expressible in json, is expressible in base-64 CESR.

So I don't have any use cases that justify such an effort. But if you have one and want to suggest some working code that satisfies the constraints above, then I would consider it.

[andrewzhurov]

Appreciate the feedback! KERI has neat threshold primitives, that I believe are already enough to cover AND/OR and nesting.

[[1] [1/2 1/2 1/2]]

^ outer [] is an AND.
As spec presently defines: clauses in a list are logically ANDed together.

Where OR can be expressed as

[1 {1 [...]} {1 [...]}]

A bit verbose, but works already.

As to nesting, the time I learned of weighted clause {} I 1) thought its very elegant 2) assumed it naturally allows for nesting.
So one could

[{1/2 [{1/2 [...]}]}]

I'm not certain whether I've been a bit too eager with my excitement about it 2:)
As from what I gather, spec seems to imply that weighted clause is max one level deep, or at least impls interpret spec this way.

Bottom line is: we've got neat primitives, could we allow them to be recursive/nesting?
Here's a POC with support of nested AND and nested weighted clause {}.
No new syntax or anything ground-breaking, same ol' primitives with support of recursion.
I'm no expert on CESR and production KERI systems, do you think it'll play well with them?

Having this would allow to take any arbitrary threshold and nest it within another.*
Which would be very handy to have for the use-case of assembling a group AID out of AIDs.
Be it to assemble a Company AID out of CEO's, CTO's etc. MultiSig AIDs for vLEI ecosystem or assemble grassroots DAOs bottoms up.
A core feature of a local-first KERI wallet app I'm working on.

* except simple/M-of-N thresholds, but those can be easily expanded to a clause.