view release on metacpan or  search on metacpan

doc/notes-on-distributed-operations  view on Meta::CPAN

	Tentative Version: The local object may be updated by tenta- 
	tive transactions.  The most recent value due to local up- 
	dates is maintained as a tentative value. 
	Similarly, there are two kinds of transactions: 
	Base Transaction: Base transactions work only on master 
	data, and they produce new master data. They involve at 
	most one connected-mobile node and may involve several 
	base nodes. 
	Tentative Transaction: Tentative transactions work on local 
	tentative data.  They produce new tentative versions. 
	They also produce a base transaction to be run at a later 
	time on the base nodes. 
	
	
	
        

More about authz:

AKA: I CAST PKI. YOUR PROJECT FAILS


    Authorization is performed using cryptographically signed assertions:

        Every database has a base "trusted authorizers" property: the public keys of principals allowed to make assertions about it.

        Every database has a list of signed authorization assertions:
            $PRINCIPAL_KEY_ID has the right $RIGHTNAME for the database with UUID $UUID 
    

            $RIGHTNAME is one of:

                manage_access (make authz assertions)
                change_db_model (send cryptographically signed database schema update assertions)
                create_records  (each of these four CRUD rights can optionally take a table name to check)
                read_records    (bad idea: allow these signed assertions to include a code chunk used to decide applicability)
                update_records
                delete_records


            We need to protect against Mallory, the malicious user, who will hang on to his authz assertion even after revocation. So, revocations of signed authz assertions should be kept and propagated like regular authz assertions. Servers must ne...
cryptographically signed by Audrey, the trusted authorizer generating the revocation certificate.

            On every sync, every client should propagate its trust database to the peer. 

        While a local user could modify the "trusted authorizers" property to allow an unauthorized user to commit transactions, 
i       it would not compromise system integrity as this property would not change on upstream replicas and 
        transactions from unauthorized users, as well as authz assertions by unknown masters would be discarded.
        It should be possible for a trusted user (Tony) to sign existing transactions generated by his collaborator Ursula,
         such that they could be passed to tony's upstream replica with a trusted authorizers list whcih does not include ursula


Application behaviour:
    
    * Application-specific behaviours are side effects.
    * Some side effects run when an update is replicated in
    * Some side effects run when an update is created locally
    * Some side effects run when an update first enters the system, regardless of whether it's locally created or replicated
    * Some side effects only cause other database updates. These can _potentially_ be rolled back when the transaction
      is created
    * Some side effects perform an external action. These can never be rolled back. They cascade. Once a side effect has taken place, we're stuck with the transaction.