orthecreedence
commented
6 months ago It just occurred to me that this could be as simple as giving each transaction a branch_name field. If it exists, it only references previous_transactions from that branch when creating. If the branch doesn't exist, it will need a branch_from arg. Either way, this requires updating all the dag::Transactions::<transaction>() functions.
Because identities are DAGs, it means all transactions within the identity are bundled together. For an individual user, this is probably not an issue, but for an institution that provides hundreds or thousands of stamps (tm) per day, eventually the identity could grow to enormous proportions.
One way of handling this is to formalize branching structures. In essence, right now a branch is only created when two instances of an identity informally diverge (ie, two devices add new transactions on their own copy of an identity) and are immediately merged when the identity re-integrates. This is a fine default, but perpetuates indefinite growth.
Allowing for formalized branching might solve this...an identity has a "master" branch that contains all its most core operations, but from there can have separate branches or even sub-branches.
An organization that provides membership might have a master branch that sets up its admin keys, policies, and formal structures, and off of this it might have a branch for memberships where it defines an admin key specifically for that purpose, and off that branch might provide a branch for each new member. The idea here is that while you will still be downloading the entire identity and all stamps of all members, at some point if one of the members leaves the group, that branch and anything on it can eventually be removed (for instance, after a year or so). Or maybe every year, if membership is refreshed, an entirely new membership branch, with new admin keys, is created and members are moved over as they renew. This would allow for key rotation and sunsetting of member branches.
This maintains cryptographic integrity of the identity but allows for transactions to be shifted in and out based on some internal retention policy. This could work hand in hand with stamp expiration dates, because if a member does not renew and the stamp expires, there's no real need to publish a stamp revocation and hang onto it forever.
This requires some thought on how identities are built and verified before I can commit to something like this, but overall might still allow for the useful aspects of a DAG without having to deal with strict append-only operation.