dao Terminus webapp server side spec

Terminus whitelist server side should allow us to

Save up blockchain state space by indexing additional state information trough our nodes
Allow our customers to enchase blockchain state with their additional information

Proposed specification:

data classes:

class TerminusContracts(BaseModel):
    resource_id: uuid 
    contract_address: str
    pools: List[uuid] #I suspect this is how foreign key should work, but how does it scales if this list is veeeery long?  

class TerminusContractsListResponse(BaseModel):
   contracts: List[TerminusContracts] = Field(default_factory=list)


class TerminusPool(BaseModel):
     resource_id: uuid
     identities: List[uuid]  #To paginate probably must migrate in to new /TerminusPoolIdentities/ paginated resource?

class TerminusIdentity(BaseModel):
     resource_id: uuid
     address: str

endpoints:

GET /terminus/${DiamondAddress} -> (TerminusContract)
GET /terminus/${DiamondAddress}/pools/${poolId} -> (TerminusPool)
GET /terminus/${DiamondAddress}/pools/${poolId}/refresh -> (TerminusPool)
GET /terminus/${DiamondAddress}/pools/${poolId}/${address} -> (TerminusIdentity)

API logic:

GET /terminus/${DiamondAddress} -> (TerminusContract):

 terminus_contract_resource_id: BugoutResource = bc.list_resources(
                params = { "contract_address": DiamondAddress }
            )[0]
 terminus_resource = bc.get_resource( resource_id = terminus_contract_resource_id)

1. Update resource from web3 provider
2. Return resource

Case if terminus_contract not found:
Check web3 -> if contract exists and payment service conditions are met - create resource and set up crawler

GET /terminus/${DiamondAddress}/pools/${poolId} -> (TerminusPool): 
terminus_pool: BugoutResource = bc.get_resource(
                resource_id=terminus_contract[poolId],
            )
1. Update resource from web3 provider
2. Return resource

Case if resource not found: 
If payment service conditions are met - create resource and set up crawler.
  For each address found in crawler:
     add TerminusIdentity.

GET /terminus/${DiamondAddress}/pools/${poolId}/${address} -> (TerminusIdentity)
terminus_pool_resource: BugoutResource = bc.get_resource(
                resource_id=terminus_pool.identities[],
            )
if address in terminus_pool_resource.identities
    terminus_identity_resource: BugoutResource = bc.get_resource(
                resource_id=address,
            )
    terminus_identity_record_resource: BugoutResource = bc.get_pool_resource(
                resource_id=web3.sha(DiamondAddress + poolId + address),
            )

Feb 28 '22 15:02 peersky

@peersky: Wanted to put in writing what we discussed verbally in earlier meeting.

ID fields

Better for ID fields to have no semantic connection with the data they describe. If we used the hashing scheme that you were initially considering, for example, it could cause problems if we migrated from a contract at one address to another. This is just one reason to not put semantic information in ID.

There are situations in which we might want to put semantic information in primary key, but at this point it would bring more headaches than we need.

Simple data model

Better to make a simple, composable data model for now and we can add additional functionality (like KYC) later. Invariably, if we put too much stuff in the data model compared to the functionality we want to offer on day 1, most of it will become obsolete as soon as we release. Even worse, it might become an obstacle to rapid development of the data model when we do want to make the correct changes.

I suggest we create the following types of resources:

Customer

Contains the following information

id - primary key we use to refer to customer in DB
name - name of customer
notes - human-readable/writeable notes about customer

This data should only be visible to Terminus admins (anyone who has appropriate token on the Moonstream Terminus contract).